By this point in my work with AI, I have stopped asking:
Which AI tool is the most capable?
The capabilities increasingly overlap.
Chat can write code.
A coding agent can reason.
A work agent can investigate a problem and sometimes continue all the way into building a solution.
So capability alone no longer tells me how I should organise the work.
The better questions are:
What responsibility should I give each AI?
and:
Do I even need all of them?
There is no ideal combination of Chat, Work and coding agents.
A simple task may need one AI.
A months-long project with unclear requirements, sensitive data and consequential decisions may justify a deliberately separated team.
The objective is to use the fewest roles that still give me enough understanding, control and confidence in the result.
The knowledge worker owns the system
Before assigning jobs to AI, I have to define my own.
I am not simply the person transferring prompts.
I am the owner of the problem and governor of the workflow.
I remain responsible for:
- why we are doing the work;
- what outcome matters;
- the domain knowledge and constraints the AI needs;
- what information may be shared where;
- which risks are acceptable;
- when a proposed solution is sufficiently understood to proceed;
- and whether the final result actually solves the real-world problem.
The AI systems perform assigned roles.
The knowledge worker decides where those roles begin and end.
The four roles
Knowledge worker — owns purpose and judgement
The human supplies domain context, sets boundaries, approves important decisions, judges real-world correctness and decides which AI role takes responsibility next.
Chat — helps the human think
Chat is useful for:
- clarifying vague ideas;
- challenging assumptions;
- explaining technical output;
- comparing alternatives;
- independently reviewing another agent's proposal;
- and turning approved thinking into a clearer instruction.
Its primary output is better human understanding and a clearer decision.
Work — helps determine what should be done
Work is useful when the problem itself still needs investigation.
It can:
- examine approved files and data;
- understand an existing process;
- analyse evidence;
- develop logic;
- explore alternatives;
- and turn an unclear problem into a concrete proposal.
Its primary output is a sufficiently clear answer to what should be built or changed.
Coding agent — implements what has been agreed
The coding agent:
- inspects the codebase;
- plans the implementation;
- writes and modifies code;
- tests it;
- resolves technical problems inside the approved scope;
- and reports what changed.
Its primary output is working software that implements an approved requirement.
These roles are narrower than the tools' capabilities.
That is deliberate.
What an AI can do is not the same as what I have made it responsible for doing.
Choose the team from the work
I now use six questions to decide which roles I need.
1. Do I understand the problem?
If not, I need help thinking or investigating.
2. Do I know what the solution should be?
If not, Work may need to examine the evidence before implementation begins.
3. Does anything need technical implementation?
If yes, eventually I may need a coding agent.
4. Can I independently judge the proposed solution?
If not, a separate Chat review may be useful.
5. What happens if we are wrong?
The more consequential and difficult to reverse the mistake, the more valuable deliberate review becomes.
6. What information is involved?
A task based on public material and one involving confidential client data should not automatically use the same workflow.
The question is not merely what information the AI could access.
It is:
Which environment have I decided is appropriate for that information, and which other AI roles genuinely need any of it?
Seven useful setups
These are not rigid architectures. They are starting points.
1. Knowledge worker + Chat
Use this when the main problem is thinking.
Examples: developing a strategy, exploring an idea, understanding something unfamiliar or comparing alternatives.
No Work or coding agent is needed if there is nothing substantial to investigate or build.
2. Knowledge worker + Work
Use this when the task is evidence-heavy or file-heavy and Work can reasonably produce the required outcome.
Examples: analysing documents, examining business data, understanding an operating process or producing a recommendation.
This setup is also useful when raw client material should remain within one approved working environment rather than being repeatedly reproduced across separate Chat sessions.
If I later want an independent Chat opinion, Work can prepare a sanitised handoff containing the relevant conclusions, assumptions and questions without transferring unnecessary raw data.
3. Knowledge worker + coding agent
Use this when I already know what should be built.
Examples:
Fix this known bug.
Add this approved feature.
Implement this specification.
If the requirement is clear and I can judge the result, additional AI layers may add little value.
4. Knowledge worker + Chat + coding agent
Use this when:
I know roughly what I want, but I need help translating it into something suitable for implementation.
This is close to the workflow I used for my website.
Chat helps me specify and review.
The coding agent builds.
5. Knowledge worker + Work + coding agent
Use this when:
I do not yet know exactly what should be built, but I can confidently evaluate Work's proposal once it becomes clear.
Work investigates.
I approve.
The coding agent implements.
A separate Chat layer may be unnecessary.
6. Knowledge worker + Chat + Work
Use this when a difficult problem needs both independent thinking and deep investigation, but the result does not require production software.
Examples might include redesigning an operating process, developing a business model or analysing a strategic decision.
7. Knowledge worker + Chat + Work + coding agent
This is the most separated—and most expensive—setup.
It becomes useful when several conditions coexist:
- the problem is initially unclear;
- substantial evidence or data must be examined;
- some information is sensitive;
- the result requires technical implementation;
- I cannot independently evaluate every layer;
- the work will span many sessions;
- requirements will evolve;
- and mistakes would be consequential.
The workflow might be:
Knowledge worker + Chat
clarify the problem
↓
Work
investigate and propose the solution
↓
Work creates a minimum, sanitised handoff where needed
↓
Knowledge worker + Chat
challenge and understand the proposal
↓
Human approval
↓
Coding agent
implement the agreed scope
↓
Human/Chat review
If implementation reveals that the requirement itself is wrong:
move back upstream to Work.
This is not the ideal AI team.
It is the high-governance version for work where misunderstanding the project costs more than additional handoffs.
A simple selection rule
The framework can be reduced further.
I cannot clearly express the problem
→ Chat
The problem requires evidence or investigation before I know what should be done
→ Work
I know what should be built
→ Coding agent
I do not understand the proposed solution well enough to approve it
→ Chat
The data should remain in one controlled working environment
→ Work, with sanitised handoffs to other roles
The consequence of being wrong is high
→ add separation and explicit review
The task is clear, cheap and reversible
→ collapse roles for speed
That is the basic design rule:
Use the fewest AI roles necessary to do the work well. Add separation where uncertainty, consequence, data sensitivity or lack of expertise makes another layer valuable.
The handoffs are where control lives
Choosing the roles is only half the problem.
I also need to define when responsibility changes hands.
Chat → Work
Move when the problem is clear enough to investigate systematically.
The handoff should state:
- the problem;
- why it matters;
- what I currently understand;
- what remains unclear;
- assumptions to test;
- questions Work should answer.
Work → knowledge worker
Move when Work believes it understands the problem well enough to propose what should be done.
The handoff should include:
- the proposed solution;
- rationale;
- evidence considered;
- assumptions;
- alternatives;
- unresolved issues;
- risks;
- acceptance criteria.
If Chat will independently review the proposal, Work should provide only the context Chat genuinely needs.
Then I stop and decide whether I understand enough to approve the next stage.
Knowledge worker → coding agent
Move when I understand and approve what is about to be built.
The implementation brief should contain:
- approved functionality;
- scope;
- constraints;
- relevant project context;
- what should not change;
- acceptance criteria;
- testing expectations.
Coding agent → knowledge worker
Move when the bounded implementation is complete, or when coding uncovers a problem that no longer belongs inside the approved implementation.
The agent should report:
- what changed;
- what was tested;
- what passed or failed;
- unexpected findings;
- unresolved issues;
- any deviation from the brief.
Then I decide where the work goes next.
When the problem changes category, move it upstream
This may be the most useful rule in the framework.
Suppose the coding agent discovers that the database structure cannot support an important business rule.
The temptation is:
Let the coding agent figure it out.
But the problem has changed.
It is no longer:
How do we implement this approved feature?
It has become:
Is the proposed system design still correct?
So:
Implementation problem inside approved scope
→ coding agent
Requirement or business-logic problem
→ Work
I do not understand the implications
→ Chat
Objective, risk tolerance or data-access boundary changes
→ knowledge worker
The current AI should not inherit a new responsibility merely because it discovered the problem.
A reusable AI Team Operating Charter
For a substantial project using Chat, Work and a coding agent together, I would now give each environment an explicit boundary from the beginning.
A starting prompt could look like this:
Project operating model
This is a long-running project. The knowledge worker remains responsible for the project objective, domain judgement, data-access decisions, approval of major changes and assignment of responsibility between AI roles.
Capability does not imply authority. Do not continue into another role's responsibility merely because you are technically capable of doing so.
Sensitive information is shared according to need, not convenience. Raw confidential material should remain within the explicitly approved environment. Other AI roles should receive only the minimum context required for their assigned responsibility, preferably aggregated, anonymised or abstracted.
Chat responsibility: Help the knowledge worker clarify intent, challenge assumptions, understand technical material, compare alternatives and independently review proposals. Do not act as the permanent source of project truth. When an important decision is made, prepare it to be recorded back into the project.
Work responsibility: Examine the approved evidence, investigate the problem, develop logic and turn uncertainty into a concrete proposal. Do not move from problem definition into production implementation unless explicitly authorised. When another AI needs context, prepare the minimum sufficient handoff.
Coding-agent responsibility: Implement the approved specification, make technical decisions within that scope, test the result and report what changed. Do not independently redefine business requirements. If implementation exposes a requirement-level problem, stop and escalate it upstream.
Handoff rule: When your assigned responsibility ends, stop. State what you learned, what you completed, what has been decided, what remains unresolved, what the next role needs to know and which role should take responsibility next.
Do not continue merely because you are capable of continuing.
That last line may be the most important instruction in the entire framework.
The human is the router
The more capable AI agents become, the less useful their product names are as descriptions of organisational responsibility.
The knowledge worker therefore has another job:
What kind of problem is this now, and which role owns it?
That makes the human the router and governor of the system.
Sometimes I will collapse several roles because the task is clear and the consequences are small.
Sometimes I will deliberately slow the workflow because the problem is uncertain, the data is sensitive or I do not understand enough to responsibly move forward.
The point is not to use more AI.
It is to design the right working relationship for the work in front of me.
Once I think about it that way, Chat, Work and coding agents stop looking like competing products.
They become roles that I can assemble, separate or collapse as circumstances change.
And the knowledge worker remains responsible for designing—and governing—the system.
By this point in my work with AI, I have stopped asking:
Which AI tool is the most capable?
The capabilities increasingly overlap.
Chat can write code.
A coding agent can reason.
A work agent can investigate a problem and sometimes continue all the way into building a solution.
So capability alone no longer tells me how I should organise the work.
The better questions are:
What responsibility should I give each AI?
and:
Do I even need all of them?
There is no ideal combination of Chat, Work and coding agents.
A simple task may need one AI.
A months-long project with unclear requirements, sensitive data and consequential decisions may justify a deliberately separated team.
The objective is to use the fewest roles that still give me enough understanding, control and confidence in the result.
The knowledge worker owns the system
Before assigning jobs to AI, I have to define my own.
I am not simply the person transferring prompts.
I am the owner of the problem and governor of the workflow.
I remain responsible for:
- why we are doing the work;
- what outcome matters;
- the domain knowledge and constraints the AI needs;
- what information may be shared where;
- which risks are acceptable;
- when a proposed solution is sufficiently understood to proceed;
- and whether the final result actually solves the real-world problem.
The AI systems perform assigned roles.
The knowledge worker decides where those roles begin and end.
The four roles
Knowledge worker — owns purpose and judgement
The human supplies domain context, sets boundaries, approves important decisions, judges real-world correctness and decides which AI role takes responsibility next.
Chat — helps the human think
Chat is useful for:
- clarifying vague ideas;
- challenging assumptions;
- explaining technical output;
- comparing alternatives;
- independently reviewing another agent's proposal;
- and turning approved thinking into a clearer instruction.
Its primary output is better human understanding and a clearer decision.
Work — helps determine what should be done
Work is useful when the problem itself still needs investigation.
It can:
- examine approved files and data;
- understand an existing process;
- analyse evidence;
- develop logic;
- explore alternatives;
- and turn an unclear problem into a concrete proposal.
Its primary output is a sufficiently clear answer to what should be built or changed.
Coding agent — implements what has been agreed
The coding agent:
- inspects the codebase;
- plans the implementation;
- writes and modifies code;
- tests it;
- resolves technical problems inside the approved scope;
- and reports what changed.
Its primary output is working software that implements an approved requirement.
These roles are narrower than the tools' capabilities.
That is deliberate.
What an AI can do is not the same as what I have made it responsible for doing.
Choose the team from the work
I now use six questions to decide which roles I need.
1. Do I understand the problem?
If not, I need help thinking or investigating.
2. Do I know what the solution should be?
If not, Work may need to examine the evidence before implementation begins.
3. Does anything need technical implementation?
If yes, eventually I may need a coding agent.
4. Can I independently judge the proposed solution?
If not, a separate Chat review may be useful.
5. What happens if we are wrong?
The more consequential and difficult to reverse the mistake, the more valuable deliberate review becomes.
6. What information is involved?
A task based on public material and one involving confidential client data should not automatically use the same workflow.
The question is not merely what information the AI could access.
It is:
Which environment have I decided is appropriate for that information, and which other AI roles genuinely need any of it?
Seven useful setups
These are not rigid architectures. They are starting points.
1. Knowledge worker + Chat
Use this when the main problem is thinking.
Examples: developing a strategy, exploring an idea, understanding something unfamiliar or comparing alternatives.
No Work or coding agent is needed if there is nothing substantial to investigate or build.
2. Knowledge worker + Work
Use this when the task is evidence-heavy or file-heavy and Work can reasonably produce the required outcome.
Examples: analysing documents, examining business data, understanding an operating process or producing a recommendation.
This setup is also useful when raw client material should remain within one approved working environment rather than being repeatedly reproduced across separate Chat sessions.
If I later want an independent Chat opinion, Work can prepare a sanitised handoff containing the relevant conclusions, assumptions and questions without transferring unnecessary raw data.
3. Knowledge worker + coding agent
Use this when I already know what should be built.
Examples:
Fix this known bug.
Add this approved feature.
Implement this specification.
If the requirement is clear and I can judge the result, additional AI layers may add little value.
4. Knowledge worker + Chat + coding agent
Use this when:
I know roughly what I want, but I need help translating it into something suitable for implementation.
This is close to the workflow I used for my website.
Chat helps me specify and review.
The coding agent builds.
5. Knowledge worker + Work + coding agent
Use this when:
I do not yet know exactly what should be built, but I can confidently evaluate Work's proposal once it becomes clear.
Work investigates.
I approve.
The coding agent implements.
A separate Chat layer may be unnecessary.
6. Knowledge worker + Chat + Work
Use this when a difficult problem needs both independent thinking and deep investigation, but the result does not require production software.
Examples might include redesigning an operating process, developing a business model or analysing a strategic decision.
7. Knowledge worker + Chat + Work + coding agent
This is the most separated—and most expensive—setup.
It becomes useful when several conditions coexist:
- the problem is initially unclear;
- substantial evidence or data must be examined;
- some information is sensitive;
- the result requires technical implementation;
- I cannot independently evaluate every layer;
- the work will span many sessions;
- requirements will evolve;
- and mistakes would be consequential.
The workflow might be:
Knowledge worker + Chat
clarify the problem
↓
Work
investigate and propose the solution
↓
Work creates a minimum, sanitised handoff where needed
↓
Knowledge worker + Chat
challenge and understand the proposal
↓
Human approval
↓
Coding agent
implement the agreed scope
↓
Human/Chat review
If implementation reveals that the requirement itself is wrong:
move back upstream to Work.
This is not the ideal AI team.
It is the high-governance version for work where misunderstanding the project costs more than additional handoffs.
A simple selection rule
The framework can be reduced further.
I cannot clearly express the problem
→ Chat
The problem requires evidence or investigation before I know what should be done
→ Work
I know what should be built
→ Coding agent
I do not understand the proposed solution well enough to approve it
→ Chat
The data should remain in one controlled working environment
→ Work, with sanitised handoffs to other roles
The consequence of being wrong is high
→ add separation and explicit review
The task is clear, cheap and reversible
→ collapse roles for speed
That is the basic design rule:
Use the fewest AI roles necessary to do the work well. Add separation where uncertainty, consequence, data sensitivity or lack of expertise makes another layer valuable.
The handoffs are where control lives
Choosing the roles is only half the problem.
I also need to define when responsibility changes hands.
Chat → Work
Move when the problem is clear enough to investigate systematically.
The handoff should state:
- the problem;
- why it matters;
- what I currently understand;
- what remains unclear;
- assumptions to test;
- questions Work should answer.
Work → knowledge worker
Move when Work believes it understands the problem well enough to propose what should be done.
The handoff should include:
- the proposed solution;
- rationale;
- evidence considered;
- assumptions;
- alternatives;
- unresolved issues;
- risks;
- acceptance criteria.
If Chat will independently review the proposal, Work should provide only the context Chat genuinely needs.
Then I stop and decide whether I understand enough to approve the next stage.
Knowledge worker → coding agent
Move when I understand and approve what is about to be built.
The implementation brief should contain:
- approved functionality;
- scope;
- constraints;
- relevant project context;
- what should not change;
- acceptance criteria;
- testing expectations.
Coding agent → knowledge worker
Move when the bounded implementation is complete, or when coding uncovers a problem that no longer belongs inside the approved implementation.
The agent should report:
- what changed;
- what was tested;
- what passed or failed;
- unexpected findings;
- unresolved issues;
- any deviation from the brief.
Then I decide where the work goes next.
When the problem changes category, move it upstream
This may be the most useful rule in the framework.
Suppose the coding agent discovers that the database structure cannot support an important business rule.
The temptation is:
Let the coding agent figure it out.
But the problem has changed.
It is no longer:
How do we implement this approved feature?
It has become:
Is the proposed system design still correct?
So:
Implementation problem inside approved scope
→ coding agent
Requirement or business-logic problem
→ Work
I do not understand the implications
→ Chat
Objective, risk tolerance or data-access boundary changes
→ knowledge worker
The current AI should not inherit a new responsibility merely because it discovered the problem.
A reusable AI Team Operating Charter
For a substantial project using Chat, Work and a coding agent together, I would now give each environment an explicit boundary from the beginning.
A starting prompt could look like this:
Project operating model
This is a long-running project. The knowledge worker remains responsible for the project objective, domain judgement, data-access decisions, approval of major changes and assignment of responsibility between AI roles.
Capability does not imply authority. Do not continue into another role's responsibility merely because you are technically capable of doing so.
Sensitive information is shared according to need, not convenience. Raw confidential material should remain within the explicitly approved environment. Other AI roles should receive only the minimum context required for their assigned responsibility, preferably aggregated, anonymised or abstracted.
Chat responsibility: Help the knowledge worker clarify intent, challenge assumptions, understand technical material, compare alternatives and independently review proposals. Do not act as the permanent source of project truth. When an important decision is made, prepare it to be recorded back into the project.
Work responsibility: Examine the approved evidence, investigate the problem, develop logic and turn uncertainty into a concrete proposal. Do not move from problem definition into production implementation unless explicitly authorised. When another AI needs context, prepare the minimum sufficient handoff.
Coding-agent responsibility: Implement the approved specification, make technical decisions within that scope, test the result and report what changed. Do not independently redefine business requirements. If implementation exposes a requirement-level problem, stop and escalate it upstream.
Handoff rule: When your assigned responsibility ends, stop. State what you learned, what you completed, what has been decided, what remains unresolved, what the next role needs to know and which role should take responsibility next.
Do not continue merely because you are capable of continuing.
That last line may be the most important instruction in the entire framework.
The human is the router
The more capable AI agents become, the less useful their product names are as descriptions of organisational responsibility.
The knowledge worker therefore has another job:
What kind of problem is this now, and which role owns it?
That makes the human the router and governor of the system.
Sometimes I will collapse several roles because the task is clear and the consequences are small.
Sometimes I will deliberately slow the workflow because the problem is uncertain, the data is sensitive or I do not understand enough to responsibly move forward.
The point is not to use more AI.
It is to design the right working relationship for the work in front of me.
Once I think about it that way, Chat, Work and coding agents stop looking like competing products.
They become roles that I can assemble, separate or collapse as circumstances change.
And the knowledge worker remains responsible for designing—and governing—the system.
Continue reading