How to Orchestrate Coding Agents

The working pattern for coding agent orchestration is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Running coding agent orchestration as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

Sub-agents are baby Cursors: smaller agents with a clear persona running inside a bigger one. The orchestration win isn't only speed. It's keeping separate concerns in separate context, and picking a cheaper model for the jobs that don't need a frontier one.

Create one with the 'create sub agent' skill, a short Markdown file (about 150 lines) that defines the persona and instructions. A Cursor-specific lever: you can set a different model per sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. Press Enter for the full definition..

Fan out by vulnerability class, then validate each finding

For a thorough security review, one agent spawns sub-agents grouped by class (infra, AppSec, prompt injection, XSS). Each produces a table of findings, then for every finding you require the full attack chain with code snippets plus a simulated proof of concept. Forcing that proof step is where sub-agents earn their keep.

Prune the to-do list before you let it run

Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. (best with a high-reasoning model) usually asks clarifying questions, then returns what it learned, a proposed design, the files it will add, and a to-do list. That to-do list is your control surface. Read it and cut the extras before you execute. Plan mode calls sub-agents while it works, and you can edit the plan conversationally in the same chat.

Before, and it is not a close call. The to-do list plan mode hands back is your only view of which pieces of the work are genuinely independent, and independence is the entire premise of fanning it out.

Start the sub-agents first and each one arrives at its own design for the same feature. None of them is wrong on its own. The trouble shows up at review: three plausible approaches, three diffs built on three different sets of assumptions about the same code, and nothing shared to check any of them against.

Reconciling that costs more than running the jobs one after another would have.

The order also decides where pruning happens. Cutting a to-do while it is still a line in a plan costs a keystroke. Cutting it after the sub-agents have built against it means throwing work away, and I think most people quietly keep the work and ship the extra scope instead.

No. Spawning sub-agents needs a reasoning-capable model, so the agent doing the orchestrating has to be one, and not every model can spawn them at all. The per-sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. Press Enter for the full definition. model setting is the lever you have, and it only points at the leaves.

Which is an awkward shape, because the orchestrator is the agent holding the plan and everything the sub-agents report back, so it is also the context that keeps growing. Not much to do about that except keep the returns small. Ask each sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. Press Enter for the full definition. for a table of findings and its proof, not a transcript of how it got there.

No, and this is the piece of single-agent advice that does not survive fan-out. Six runs make six prompts, six diffs, six test outputs and six reviewer notes, and nobody reads that folder afterwards. Including the person who made it.

Keep the plan instead, once. Add whatever proof each sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. Press Enter for the full definition. was asked to produce. The plan is the only record of why the work was split the way it was, and that is the thing someone coming back in a month cannot reconstruct from the repository. The individual prompts, mostly, you can read back out of the diff.