How to make an AI agent finish the whole job
The last essay argued that the engineer's job is to steer. This is the operational half: how to hand a big, messy pile of work to an agent and get all of it back — with a plan, a task table it can't lose, and a clean room per task.
In AI writes the code. Who steers the system? I argued that once the machine handles implementation, the human's leverage moves to framing, judgment and direction. This post is about the part we hand over: once you've decided what to build, how do you make the agent actually build all of it — correctly, and without quietly dropping half the work?
Because that's the real failure mode. Give an agent a big brief — "do all of this" — and one of two things happens. Either it works in a single conversation until the context fills up, the output degrades, and it starts forgetting what it did at the start; or it declares victory having done maybe 60% of the list, and because the list was long, you don't notice the gaps until they bite you later. The naïve "just do everything" prompt is the problem, not the agent.
The first prompt's job is not to do the work
The move that fixes this: the first prompt you send is not "implement all of this." It's "turn all of this into a plan and a task table, ask me anything ambiguous, and don't start building until I've approved it."
That reframing does a lot of work, and it isn't just my habit. Anthropic's own guidance on building agents calls it the orchestrator-workers pattern: a central agent breaks a complex task into subtasks, delegates them, and synthesizes the results. The orchestrator's first output isn't code — it's a decomposition. So the first prompt asks the lead agent for two artifacts:
- an implementation plan — how it intends to approach the work, written after reading the whole brief;
- a segmented task table in plain markdown — the work broken into small, well-scoped tasks, each with a status field:
todo / doing / done.
And before it writes either, it has to ask you the questions it needs to remove ambiguity. A good brief already carries most of the answers, but the agent surfaces the gaps you didn't notice. You answer, you correct its assumptions, you approve — and only then does anyone start building. No worker gets launched until the plan is validated; I've learned to be strict about that gate. (The exact prompt is at the end of this post.)
The task table is memory the agent can't lose
The task table is the load-bearing idea, and it's worth being precise about why. It is not documentation. It is shared, durable memory.
Every worker can read it: what's assigned, what's done, what's left. And here's the part that matters most — if a worker runs out of context halfway through its block, it doesn't silently stop. It re-reads the table, sees which of its tasks are still todo, and finishes them. Nothing falls through the cracks, because "did I do everything?" is answered by a file, not by a model's fading memory of a long conversation.
| # | task | owner | status |
|---|-------------------------------|--------|--------|
| 1 | reshape the onboarding flow | chip A | done |
| 2 | add the new permission role | chip B | doing |
| 3 | rework the results view | chip C | todo |
| 4 | migrate the export templates | chip D | todo |Anthropic hit exactly this in their multi-agent research system: they persist the lead agent's plan to external memory "when the context window exceeds certain thresholds to prevent loss of information." The task table is the same instinct, made checkable — a plan that outlives the context window.
Where the brief comes from: cleaning the brain-dump
It's worth saying where the brief itself comes from, because that's half the craft. Mine usually starts as raw notes — a meeting, a call, a stream of "we need to change this, and this, oh and this." That's the dump. It is not a prompt yet.
The prompt is what comes out after a pass of editing: grouping the ideas, resolving contradictions, turning vague wishes into concrete tasks with a clear objective, and marking the genuine open questions to hand to the agent. The tasks are defined by a human. This is the essential-complexity work from the last post — deciding what to build — and it's exactly the part the machine can't do for you. A vague brief just produces a vague plan, faster.
Clean-context workers beat one long chat
For the actual building, the temptation is to keep going in the same conversation. Resist it. The more you pack into one context, the worse the output gets — and this is now well documented, not a hunch. Models attend well to the beginning and end of a long context and lose the middle, and every frontier model tested shows measurable degradation as the input grows. In practice, a long build chat is one where you keep having to say "you missed a few things, keep going," each nudge costs more tokens, and the quality drifts down.
The alternative is to give each task, or group of related tasks, its own fresh context. In Claude these get spun off as separate chats — I call them chips — each starting clean, each running in its own parallel worktree so they can't step on one another. The lead agent writes the prompt for each worker: the task, the constraints, the conventions, anything it learned while planning. The worker doesn't need the whole history; it needs its slice, stated well.
This is precisely why Anthropic's research system gives "each subagent a self-contained task description, an output format, and a fresh context window," and why that architecture beat the single-agent version by more than 90% on their evaluations. Separate context windows aren't a workaround; they're where the extra reasoning capacity comes from. A clean room per task produces better work than one increasingly cluttered desk.
Read every worker, then unify
When the workers finish — and this can run for hours — the job is not over. This is the step people skip. You read every worker's output, one by one. They will have found things: a bug the plan didn't anticipate, a better way to group something, a note that they left a decision for you, a suggestion to spin off a follow-up. Some of the most valuable output of the whole run lives in these reports.
Then you unify. A final pass — feed the lead agent each worker's conclusions plus instructions to reconcile them — and it checks the table (is everything marked correctly? is anything still open?), integrates the branches, and produces the single coherent version you'll validate. And validation is now easy, which is the entire point: you have the task table in front of you and you walk it, task by task, confirming each is what you wanted. Small fixes go straight to the main chat. Then delete the spun-off chats and keep the sidebar clean.
The prompts, so you can steal them
You only ever write three prompts. The prompts the workers receive? The lead agent writes those — it composes one for each worker out of the plan and everything it learned while planning. That delegation is the whole point, so there's no worker template for you to fill in. Your three are the kickoff, the feedback, and the unify. Here they are, stripped of any project — the angle brackets are yours to fill.
1. The kickoff. A little context, the objective, then the whole ordered brief, then the instruction to plan — not build.
<What just happened — the meeting, the call — and where this input comes from.>
The objective is the usual: a solid plan with the tasks to do, from what I give
you below, each with a status indicator so every agent can coordinate — what's
done, what's left — and nothing gets forgotten. Then you'll spin off several
clean-context workers so each does its part well. We work on a new branch, <name>.
Here is the brief:
<THE ORDERED BRIEF. This is the human work: your raw meeting notes cleaned up
into concrete, well-scoped tasks — each change written as something to do, the
open questions you actually want the agent to weigh in on, the goal behind each
item, and pointers to any files or references it needs.>
With that: analyse it and write the usual sprint-kickoff plan (an md file),
defining absolutely everything. Ask me whatever you need first so it's well
defined, with nothing left in the drawer. When we've both confirmed the plan,
we put the agents to work.
Do not launch a single worker until I've reviewed and approved the plan.2. The feedback. You read the plan it wrote, answer its questions, correct what's off — and only then is it cleared to run.
I've reviewed the plan. Here's my feedback; fold it in and then we're ready.
- <Answer each question the plan asked.>
- <A correction or a new decision — e.g. "X should actually work like this;
check whether what we already have covers it, and change what's needed.">
- <A challenge to one of its choices — "I don't see why we'd keep Y;
wouldn't Z cover it?">
The rest looks perfect.3. The unify. The workers have finished; this folds every report into one version for you to validate.
All the workers finished. Here are their reports:
<paste each worker's report>
Review every report and the work behind it, and evaluate it. Check the task
table: is everything marked correctly, and is anything still open or missed?
Pull out the bugs they found, the decisions they left to me, and any follow-ups
they suggest, and list them for me. Then, if it's all sound, unify it —
integrate the branches into one coherent version — so I can start validating
by hand. Invent no new scope; if something is unresolved, surface it rather
than paper over it.The bigger shift: one mind per project
Step back and the arithmetic is startling. Work that would have taken a team several days — or that a role-segregated team could only do by passing specifications back and forth — comes together in a single day, with everything at least attempted and a checklist to verify it against. Replit's CEO put the ceiling bluntly: agents could give one person the leverage of a hundred. That overshoots, but the direction is right, and a good run genuinely feels like it.
Which changes how I think small consulting and research projects should be staffed. For years the default was a segregated team — frontend, backend, QA, integration — each person deep in one lane. When each of those lanes is something an agent now does well, keeping the segregation mostly adds coordination cost: the frontend dev prompts their slice, waits on the backend dev to prompt theirs, they meet to reconcile an API contract, another prompt wires it together — when one well-framed prompt, with shared context and clear goals, could have produced the whole feature at once.
I don't think this means four of every five people are redundant. I think it means that where you needed five people for one project, you can now run five projects of one person each. Each person can cover what used to be uncoverable, because expert front-end, back-end and QA knowledge is on tap — the nearest thing to having that whole team on call, people who know each craft better than you do, with you as the one who decides where they point. You become the profile that used to hand you tasks; the model becomes the one that carries them out. What the project needs is one person who holds the whole of it: captures the requirements, analyzes them, designs the approach, defines the tasks, sets the validation criteria, and steers. Call it the project's implementation lead, or just its mind. The industry seems to be drifting the same way — toward generalists who own a problem end to end rather than specialists isolated by role.
You take on the real work of an engineer — deciding how to solve the problem — and hand the typing to the machine. Coding used to be the longest phase, but it was never the most important one: no amount of fast typing rescues a bad design, and the design is the part that needs human judgment. You own the what and the why. The how is the machine's.
The takeaway
The code was never the hard part. Making sure all of it gets built, correctly, from a clear idea of what "all of it" even is — that's the job. A plan, a task table the agent can't lose, and a clean room per task are how you keep it honest to the whole of it. You steer; it builds; the table makes sure nothing is left in the drawer.