How to Orchestrate Coding Agents

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

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.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows 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.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

Sub-agents are agents with a clear persona that the main agent hands work to. Each works in its own context window, several can run in parallel, and each can use a cheaper model when the job doesn't need a frontier one.

Create one with the /create-subagent skill, or ask the agent to write the file. Either way, you get a Markdown file in .cursor/agents/ whose frontmatter sets the name, description and model. The presenter's file ran to about 150 lines.

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. asks clarifying questions, researches the codebase and returns a plan you can edit. In the webinar, the presenter planned on a high-reasoning model, and the plan listed what the agent learned, a proposed design, the files it would add and a to-do list. That to-do list is your control surface, so read it and cut the extras before you execute.

Have one agent spawn sub-agents grouped by vulnerability class: infra, AppSec, prompt injection and XSS. 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. produces a table of findings. Then, for every finding, require the full attack chain with code snippets and a simulated proof of concept. That proof step is where sub-agents earn their keep, because each finding has to survive an attempt to demonstrate it.

Plan first. The to-do list that plan mode returns shows which parts of the work are independent before any code exists, and fanning out only works on independent parts.

If you start the sub-agents first, 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 different assumptions about the same code, and nothing shared to check them against. Reconciling them 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 the plan costs a keystroke. Once sub-agents have built against it, cutting it means throwing work away, and keeping the work means shipping scope that nobody planned.

Not reliably. Because of the presenter's warning above, the webinar's orchestrator stayed on a reasoning model. Cursor's docs only say that the model picker, Auto included, sets the parent's model, and that each custom 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. either inherits it or names its own.

Either way, the lever that saves money is on the sub-agents. Each request bills at the list price of the model that ran it, and Cursor's docs warn that five sub-agents in parallel use roughly five times the tokens of a single agent. The orchestrator also holds the plan and everything the sub-agents report back, so its context keeps growing. 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 instead of a transcript of how it got there.

No. Keeping the prompt, diff, result and reviewer note works for one agent, but it does not survive a fan-out. Six runs leave six prompts, six diffs, six test outputs and six reviewer notes. That is too much to read later, even for the person who made it.

Keep the plan instead, once, plus 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 someone coming back in a month cannot rebuild that from the repository. The individual prompts matter less, because each one came from a line in that plan.