The coding agent workflow a team can actually run
Stefan-Iulian Tesoi · · 9 min read
Give each agent one specified work order, an isolated branch or worktree, and a definition of done it can check itself against. Then review what comes back against the criteria written before the work started, rather than against the agent's account of what it did. That is the whole coding agent workflow, and every part of it exists because of a specific way the obvious approach fails.
The obvious approach is to open a chat window, describe the task, and read the diff. It works, it is how everyone starts, and it stops working somewhere between the second agent and the second week.
What is a coding agent workflow?
The repeatable path a piece of work takes from "we should do this" to "this is done", when the building is done by an agent rather than a person.
It is not a prompt, and calling it one is the first mistake. A prompt is the dispatch step, and what MCP standardises is the handover around it. What surrounds it — deciding which work is next, writing it down precisely enough to act on, isolating it from other work in flight, and checking what came back — is the part that decides whether the agent was useful, and none of it happens in the chat window.
Teams that skip straight to dispatch get a real and misleading result. The first week is genuinely fast, because the backlog contains months of well-understood work that was never urgent enough to schedule. Running AI coding agents in a team feels solved right up to the point that queue empties, and then throughput falls back to the rate at which somebody can specify new work.
The four stages: specify, dispatch, execute, verify
Four stages, and only two of them involve the agent at all.
| Stage | Who does it | What it produces | What happens if you skip it |
|---|---|---|---|
| Specify | A person, or a tool drafting for one | A work order: outcome, criteria, paths, dependencies | The agent guesses, plausibly, and you find out at review |
| Dispatch | Automatic | The agent holding one item and an isolated branch | Two agents edit the same file in the same hour |
| Execute | The agent | A diff, plus a record of the checks it ran | You review a diff with no stated intent to compare it against |
| Verify | A person, reading evidence | An accepted item, or a returned one with a reason | "Done" means the tests that existed already still pass |
The asymmetry is the point. Stages one and four are human judgement and cannot be delegated to the thing being judged; stages two and three are mechanical and should never need a person. Most teams do the opposite — they automate none of the dispatch, and hand the judgement to whoever is least busy.
How should agents receive their work?
By pulling one item at a time from a queue, with everything the item needs inside it, over a connection rather than a copy-paste.
The copy-paste version is where everyone starts and it has three problems that only show up at scale. A person is the transport, so work moves at the speed of someone's attention. The item gets edited in transit, so what the agent built is not what the backlog says. And nothing records which agent took which item, so two of them can take the same one.
The connected version is what the Model Context Protocol is for: the agent reads the ready column itself, loads the item in full, and hands the work back for review when it is done. In practice a Claude Code team workflow looks like a developer running claude in a worktree and the agent pulling its own next task — no one pastes anything, and the audit trail is a side effect rather than a discipline.
What the item has to carry is fixed by what the agent cannot ask for:
- The outcome, stated as something observable rather than as a component to build.
- Acceptance criteria that name a command and a result, not a feeling.
- The repositories and paths it will touch, because "the API" is not a location.
- Dependencies as item ids, because "after the auth work" is invisible to anything parsing the item.
- The regression notes for the area — what has broken here before, and what must not break now.
Connecting a coding agent is the mechanical half of that, and it takes a few minutes. Getting the items into a state worth connecting to is the half that takes a week.
Why isolation matters: branches and worktrees
One agent, one branch, one working directory — and the third of those is the one teams forget.
Two agents sharing a checkout share its HEAD. When the second one switches branches, the first one's uncommitted work moves with it, and the failure is silent: no error, no conflict, just a diff that quietly contains somebody else's changes. git worktree is the answer and has been in Git since 2015 — a second working directory on the same repository, with its own branch and its own index, costing a hardlinked checkout rather than a clone.
The rule that follows is short:
- Each agent gets its own worktree, created from the current main.
- Each worktree has exactly one branch, named for the item.
- Merge back fast-forward only, then delete both the worktree and the branch.
- Never let two agents share a directory, however briefly.
Fast-forward only is doing more work than it looks. It fails loudly when main has moved underneath you, which is exactly when you want to be stopped — a merge commit would have silently produced a result neither agent tested. In this workspace it has stopped a merge mid-flight more than once, and each time the right response was to rebase and re-run the checks rather than to force it through.
What does review look like when an agent wrote the code?
Reading the evidence against criteria fixed in advance, rather than forming an opinion about a diff.
This is the stage that changes most, and the change is uncomfortable. Reviewing a colleague's pull request, you are partly checking the code and partly checking that you and they understood the task the same way. With an agent the second half is not available: it has no independent understanding to compare against, only the item it was given. So the question stops being "is this good code" and becomes "does this satisfy what we wrote down, and did the checks it claims to have run actually run".
That makes code review cheaper per item and more demanding in a specific way — you have to have written the criteria first, and a criterion that cannot be checked mechanically will not be checked at all. Four things worth insisting on:
- The command, not a description of it. "Ran the tests" is not evidence;
pnpm run ci, exit code 0, is. - Failures reported, not omitted. A suite that failed and was fixed is more informative than one that passed first time.
- Scope, so a reviewer can re-run it instead of trusting the summary. "351 files, 3682 tests" is a claim someone can falsify.
- What a machine could not check, named separately, because that is the only part a person must actually do by hand.
An agent should be able to reach "ready for review" on its own and no further. Every workflow that lets it past that point eventually ships something nobody read.
In Laimonade an agent can move an item as far as In Review and the executor refuses any attempt to set Done — closure is reserved for a person. That is a constraint rather than a feature, and it is the one that makes the rest safe to automate. How Laimonade works sets out where each stage sits.
How many agents can one person actually supervise?
Two or three, and the limit is review capacity rather than anything about the agents.
The arithmetic is unforgiving. An agent finishing an item every forty minutes produces roughly twelve items a day; a careful review against written criteria takes ten to twenty minutes. One person is therefore saturated somewhere around two concurrent agents, and a third produces a queue rather than throughput. Teams routinely discover this by running six and finding that nothing gets accepted.
Three things move the number, and only one of them is buying more compute:
- Better criteria. A criterion that is mechanically checkable turns twenty minutes of review into two.
- Evidence attached to the item. Re-deriving what an agent did, from the diff, is most of the review cost.
- Smaller items. A diff nobody finishes reading is a diff nobody checks, whatever the intention was.
This is also why "how many agents" is the wrong planning question. The right one is how many specified items per day the team can produce and accept, and that number is set by people at both ends.
What goes wrong, and what it looks like
Four failures, each of which presents as something other than what it is.
- The month-one cliff. Throughput drops in week five and it reads as the agents getting worse. Nothing about them changed; the backlog of pre-specified work ran out.
- Plausible wrong work. An item omitted a fact, the agent filled it in sensibly, and the result passes review because it looks deliberate. This is the expensive one, and the only defence is criteria written before the work.
- Two agents, one file. Silent, because Git does exactly what it was asked. It presents as a mysterious regression a week later.
- Review debt. Items pile up in review, someone starts accepting them on the summary rather than the evidence, and the verify stage quietly becomes a rubber stamp.
Every one of these is a failure in stage one or stage four — the two stages with a person in them. An AI agent development process that only automates the middle will hit all four in its first two months, which is not an argument against automating the middle. It is an argument for noticing where the work actually moved. The sprint workflow describes what running this looks like week to week, with Claude Code or Cursor on the other end of the connection.
Frequently asked questions
Do agents need their own Git branches?
Their own branch and their own working directory, which are two separate requirements. Two agents in one checkout share HEAD, so when one switches branches the other's uncommitted work travels with it — no error, no conflict, just a diff containing somebody else's changes. A worktree per agent costs a hardlinked checkout and removes the entire class of problem.
How do you stop two agents editing the same file?
Sequencing at the backlog level, not locking at the file level. If two items in the same sprint touch the same module, that is a dependency, and it belongs on the item as an id rather than being discovered at merge time. Isolation stops them corrupting each other's working state; only ordering stops them doing contradictory work.
Should an agent be allowed to mark its own work done?
No, and this is the one rule worth being rigid about. An agent reporting on its own output has no independent view to check against, so "done" would mean "I believe I finished", which is exactly the claim review exists to test. Let it reach ready-for-review with evidence attached, and keep closure with a person.
Does this work with Cursor as well as Claude Code?
Yes — the workflow is about where work comes from and how it is checked, not about which tool writes the code. Any agent that speaks the Model Context Protocol can pull items and hand work back, and Claude, Claude Code and Cursor are the ones we use daily. Nothing in the four stages assumes a particular editor.