There’s exactly one agent I talk to all day, and it never writes code. Everything I’ve described in these posts, from the RPI pipelines and the worktree integration rounds to the browser testers and reviewers, routes through a single thread: the lead. I want to walk through what that job actually consists of, because I think it’s the most underexamined role in agentic engineering, and then say something slightly spicy about which models are good at it.
What the lead actually does
The lead workflow makes the lead an orchestrator with a hard rule: delegate all code changes, always. It doesn’t read source files to scope tasks; it doesn’t patch failing code itself, ever. What it does instead is translation and traffic control. I speak in product terms: a bug report, “this refactor scares me,” a garbled voice-to-text feature request it has to interpret. The lead turns each one into a unit of work: spawn an agent, in its own worktree by default, with a prompt that specifies the outcome and the constraints but never the implementation. Research and planning agents stay on main and write reports to known paths; implementers get branches; every assignment ends with an exact completion contract: DM me the summary, the file list, the branch, the commit log, the checks you ran.
Then it waits. No polling, no check-ins; completions arrive as messages. When branches come back ready, the lead runs an integration round: switch to main, cherry-pick each finished branch on, one at a time, preserving the agent’s commit boundaries, then run the validation gate on the integrated result rather than each branch in isolation, and push only on green. When two branches conflict, it doesn’t untangle the diff itself or hire a stranger to do it. It tells the two agents who wrote the code to message each other and sort it out, then integrates their updated branches in the next round. After a green push it cleans up: finished implementers removed, remote branches deleted, research agents kept around because their context stays useful. And through all of it, the sequencing decisions are the quiet skill: a new request usually means a new parallel agent, but migrations, lockfiles, generated files, and broad refactors of one subsystem get serialized, because those are the known conflict magnets.
Written out like that, it’s obvious what this job is. There is not a single line of code in it. It’s judgment, end to end: what to parallelize, what to serialize, whom to spawn, what to tell them, when a branch is ready, whether the integrated whole is shippable, who should resolve what. The lead is a judgment engine, and the implementers hanging off it are its hands.
Why Claude gets the role
Some history that I think explains more than it gets credit for. Claude Code was the first harness with sub-agents: the Task tool could spawn them from its earliest releases in early 2025, and custom subagents were formalized as a first-class feature that July. At the time, no other product was seriously thinking about agents delegating to agents, and honestly, the early execution was rough; I’ve written before about what the spawn-tree model got wrong. But being early meant something that compounds: Anthropic has been optimizing its models in environments where completing a task means delegating, where the trajectory that reaches the goal is one in which the main agent orchestrated, dispatched, reviewed, and integrated rather than doing everything itself. Stack that against how these models are post-trained, and you’d expect a Claude model to have unusually strong instincts for the lead role. That’s exactly my experience.
This isn’t a knock on GPT models; they can absolutely run a team, and half my roster is Codex on any given day. It’s an anecdotal but very consistent preference from someone who talks to a lead agent more hours a day than to any human: Claude models are simply more pleasant and more right as leads. They hold a theory of mind about me, themselves, and the other agents that shows up everywhere the job is social: knowing what only the lead knows and what a worker needs spelled out, writing prompts for other models (meta-prompting is most of the lead’s actual output), keeping a dozen parallel streams straight without confusing who owns what. A Claude lead feels like it’s trying to understand what I’m for before doing what I said, and it makes, more often than any other model I’ve given the job, the judgment call I would have made myself. That’s the entire job description. There’s some special sauce in the Anthropic post-training here, and whatever it is, it matters more to my daily output than a few points on any coding benchmark.
Working memory is priced flat
There’s an economic tailwind that makes the Claude lead even easier to justify. My lead threads run long, with days or sometimes weeks of accumulated project context, and that context is the product. It’s working memory. The lead already knows what shipped last Tuesday, why we abandoned an approach, and which agent owns which worktree, without looking anything up, because it’s all in the same thread. A well-fed lead feels like a colleague several weeks into the job instead of a new hire every morning.
Anthropic prices that memory flat: prompts up to a million tokens bill at the same per-token rate as small ones, so a 900k-token request costs the same rate as a 9k one. That is not the norm. Gemini doubles its input rate above 200k tokens, and in my usage Codex bills long-context prompts at roughly 1.5x. For implementers, who live briefly and die after a phase, the difference is noise. For a lead whose entire value is a giant, constantly reread context window, it decides the economics of the job: the model best suited to hold the working memory is also the one that doesn’t charge rent on it.
The right model for each role
The division of labor that fell out of this is clean. Claude models lead: they translate my ambiguity into concreteness, working with me until intent becomes a spec. GPT models implement: they are exceptional at executing an ordered, clearly specified task to completion. And the pipeline is designed so each seat gets what it’s best at: by the end of an RPI planning phase, every implementer prompt is so focused and self-contained that there’s no room for ambiguity left, which means nearly any frontier model can execute it well. One Claude lead becomes my gateway to all of them: ambiguity goes in one side, unambiguous assignments come out the other, and the workers never see the fog I started with.
The benchmark that doesn’t exist
Here’s what bothers me. Every serious coding benchmark measures the workers: issues resolved, patches merged, tests passed. Nothing measures the lead, and the lead role is where modern agentic engineering is actually won or lost. Nobody benchmarks whether a model correctly decides that a worktree is ready to integrate or needs another pass. Or how it sequences cherry-picks across five finished branches. Or whether it resolves a merge conflict by routing it to the agents with context instead of hacking at the diff itself. Or which requests can safely run in parallel and which will collide in a lockfile. Or the softest skill of all: drawing my true objective out of a two-sentence request before spending an hour of team time building the wrong thing.
Those are the judgment calls I watch a lead make dozens of times a day, and model choice visibly changes their quality. I’m planning to design a benchmark around exactly this: lead-role evaluation, integration judgment, delegation quality. I think it’s the most important unmeasured capability in frontier models right now. The industry keeps optimizing the hands. The differentiating scarcity, in my stack anyway, is the head.