←
How to talk to coding agents
Chapter 06of07

Orchestration

Watch yourself for a few minutes. Short prompt, short response. Short prompt, short response. It feels like flow, but the agent finishes in seconds and you spend the next ninety thinking, scanning, retyping. You're the bottleneck.

Ping-pongYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do next~14 minBrief & shipYou — writing a prompt or briefAgent — running~5 mintime →
Same work, very different wall-clock cost. The grey blocks in the top row are you, deciding what to type next.

Orchestration is the move from typist to conductor — from messaging the agent to briefing it, from one thread to several. Stop tuning the next prompt and start tuning the next hour.

Chain, don't ping

If you already know steps two through five before you send step one, write them all into the brief and let the agent walk the chain on its own. The agent loses nothing by knowing the destination; you lose four context switches.

Pinging
> Read the auth module.

(reads, waits)

> Now find the session bug.

(finds, waits)

> Now write a test for it.

(writes, waits)

> Now open a PR.
Briefing
> Read the auth module, find the
  session bug we keep seeing on
  refresh, write a regression test,
  and open a PR. If you hit a fork,
  pick the smaller change and note
  the alternative in the PR body.

Rule of thumb: if you already know the next prompt, write it into the brief instead.

Stagger and overlap

You can only write one brief at a time. The agents don't all start in parallel — you start them in a cascade. Brief thread one, kick it off. While it runs, brief thread two. Then three. By the time you've sent the third, the first is delivering. You step in, glance, send a follow-up, and the cycle continues.

Thread 1You — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningThread 2You — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningThread 3You — writing a prompt or briefAgent — runningYou — reading, thinking, deciding what to do nextYou — writing a prompt or briefAgent — runningtime →
Plans (purple) cascade — you can only write one at a time. Agent work (pink) overlaps freely. Grey is the small but real cost of switching attention between threads.

Three things to notice. The purple bars never overlap — that's your hands, and there's only one of you. The pink bars do, freely; the agents don't wait for each other. And after every agent finishes, there's a small grey gap before you come back: real attention costs, and you can only spend it on one thread at a time.

Fan out

One agent works on one thing at a time. You don't. The moment a task is independent of another, run them side-by-side — separate tabs, separate worktrees, separate windows.

You — writing a prompt or briefYou · briefAgent — runningAgent · testsAgent — runningAgent · docsAgent — runningAgent · refactormergetime →
One brief fans out; three streams run in parallel; one merge to review. Use this shape only when the tracks don't depend on each other.

Good candidates: tests in parallel with the implementation, five unrelated bugs at once, three library spikes side-by-side. Bad candidates: anything where agent B reads what agent A produced — don't parallelize a chain. Budget for the merge too; three branches become one review queue.

Specialize the roles

Give different agents different jobs and let them hand work to each other. A researcher reads and plans. An implementer takes the plan and writes. A reviewer comes in cold and critiques. Each role wants a different mindset and a different context window — splitting them enforces a discipline you'd struggle to keep alone.

Researcherreads & plans
Implementerwrites the diff
Reviewercritiques cold
Each handoff is a concrete artifact — a plan, a diff. Name them and the seams between roles stop being fuzzy.

Most modern tools support this directly — sub-agents, background tasks, parallel runs. The spin-up cost is now smaller than the cost of switching contexts in your own head.

Run long, check less

The biggest leaps of the last year have been long-horizon tasks — jobs that run for thirty, sixty, ninety minutes while you do something else. Whole-repo refactors. Migrations. Test backfills. The instinct is to babysit. Resist it; babysitting collapses long jobs back into ping-pong.

Write a brief that can survive without you: a clear goal, an explicit success criterion (“all tests pass, build is green”), permission to make small judgment calls, and a fallback for when stuck (“leave a TODO and continue”). Come back to a finished branch, not a half-finished conversation.

The conductor's job

With multiple agents going, your job changes shape. You're triaging, not typing. Which branch needs a decision? Which run is stuck? What's ready to merge? The skills that matter are reading diffs fast, holding several threads, killing runs that have gone sideways, and writing briefs that don't need follow-ups. These are management skills — learnable, and they compound.

Command the fleet

One agent makes you faster. The shift in orchestration is bigger than that: suddenly you have access to a whole team — cheap, fast, and always available. The bottleneck is you — how well you brief them, unblock them, and keep several moving at once.

That's the skill to invest in. Optimize the hour, not the message. Chain steps. Fan out independent work. Specialize roles. Let long jobs run. The conductor's edge is patient briefing and clean handoffs — nothing else.