Mostly no. If you run one or two AI agents, you do not need a lead role above them, you need two cleanly bounded briefs. At that size you are the overview: you read every result anyway, and an extra instance that reads back to you what you could see yourself in five minutes is overhead that burns time and compute. Anthropic states the underlying rule plainly: find the simplest solution possible and increase complexity only when it demonstrably improves the outcome. The point where a dedicated oversight role starts to pay off is not a count, it is a condition, and you recognise it by four things: nobody can say what was finished yesterday. Two roles do the same work twice. Reports claim things that did not happen that way. Handovers happen verbally in a chat window instead of in writing. Before you build a role for that, three simpler measures apply: a written responsibility per agent, one shared place where results are filed, and a fixed handover format. Only once those three are in place and the signs persist is the role the right answer.
I run my business with a workforce of fourteen AI employees, each with its own role, its own personnel file and its own limits. Who does which job is laid out in the org chart, thirteen of them with a page of their own. The role that keeps the overview over the others did not arrive on day one, it arrived on September 3, 2026, when the workforce had already been running for quite a while. How it grew is in My AI Workforce, and everything about roles lives on the AI employees page. This post answers the question of whether you need such a role. How you actually bring several agents together is in Orchestrating Multiple AI Agents.
Why the answer is usually no
A lead role is itself an agent. It reads, checks, writes, and costs exactly what any other agent costs. How large that item becomes depends on the model, the tools, how much runs in parallel and the task itself. Anthropic gives one order of magnitude for its own research system: in that data, agents used about four times the tokens of a chat, and systems made of several agents about fifteen times. No calculation carries over from that, but the direction does: it only pays off when the task is worth the extra spend. With two agents running, it almost never is, because the problem the role solves does not exist yet at two agents.
There is a second point that gets overlooked. An oversight role can only review what is documented somewhere it can reach. Live addresses and system states it calls up itself, but for everything that happened inside the business it needs reports, filed results and handover files. Without those it reviews nothing and guesses instead. Putting a lead role on top of a messy setup does not tidy the setup, it creates a second source of claims. So the order is always: the filing first, the role second.
And a third: not every multi-agent structure is the right cut in the first place. Anthropic notes that domains requiring all agents to share the same context, or involving many dependencies between agents, are a poor fit for multi-agent systems today. If you notice that your two agents constantly have to feed each other, you do not have a management problem, you have one agent too many.
Four signs that the point has been reached
These four states are not a scale, they are switches. If one of them holds persistently, you have an overview problem, no matter how many agents are running.
1. Nobody can say what was finished yesterday
The test is uncomfortably simple: name, without looking, what your agents delivered yesterday, then go and find the evidence for it. If it takes you more than a few minutes, or if one result has no file at all, the state is reached. An agent has no memory across sessions; your file system does. Whatever is filed nowhere is gone the next day, for everyone involved.
2. Two roles do the same work twice
Anthropic describes a run in its own research system where one subagent investigated the 2021 chip crisis while two others worked in parallel on current supply chains, with nobody having divided the work. Paid for three times, needed once. Their remedy: every brief names an objective, an output format, guidance on tools and sources, and explicit task boundaries. If you have done that and still get duplicate results, what is missing is a place that sees beforehand what is already running.
3. Reports claim what did not happen
This is the most expensive of the four signs, because it feels the best. A report says six pages are live, the old text block has been replaced everywhere, the check ran. Nobody calls up the six addresses, nobody searches the project for the old sentence, and a few days later it turns out half of it was wrong. Once you start believing reports because verifying takes longer than reading, you need someone whose actual job is that verification.
4. Handovers happen verbally instead of in writing
Verbally here means: in the chat window, in your head, in passing. That works as long as you sit inside every conversation yourself, and it breaks the moment two agents work separately. The Claude documentation is unambiguous here: each subagent starts with a fresh, isolated context window, it does not see your conversation history and it does not see the files your main conversation has already read. It can read them if it has the permissions for it, but only if its brief says where they are. Whatever agent one held in its head exists for agent two only if somebody wrote it down.
Three simpler measures that work first
Three of the four signs disappear without any extra role. These three measures cost an afternoon, and they are the precondition for a lead role to have anything to review later on.
- A written responsibility per agent. One paragraph per role, in the role file, not in the chat: what this agent delivers, in what format, and what is explicitly not its job. The dividing line runs along the output, not along the tools. "One researches, the other writes" is a durable boundary because the handover is a finished document. "One uses web search, the other the file system" is not, because both are holding the same task by different ends. What that persistent role context looks like technically is in CLAUDE.md: Claude Code's Memory.
- One shared place to file results. A folder where every result lands as a file, with the date in its name, always in the same spot. No result lives in a chat history. That alone answers sign 1, and it is the basis for any later verification, because only what is written down somewhere can be checked.
- A fixed handover format. Always the same fields: sender, recipient, date, the matter at hand, a link to the context instead of a copy of the content, and the open points. The link rather than the copy is the crucial part: it leaves one single source instead of several copies that go stale separately. When you move something, you update the links, because paths do not stay correct on their own either. With that format, signs 2 and 4 fall away, because everyone can see what someone else has already picked up.
How to set these three up concretely, step by step up to the second agent, is in Orchestrating Multiple AI Agents. And you do not have to work out where to draw the lines on your own: the community is full of people who have already cut their roles, and a question in a post often saves you half an afternoon. And if the first point makes you realise that your agent does not deliver a clear result at all but is really a conversation, what is missing is not the lead role but the onboarding: Hiring an AI Employee: The Process and Which Tasks You Can Hand Off to AI.
What the role actually does
If what mainly remains after those three measures is sign 3, reports that nobody holds against the real state, then that is the case a dedicated role exists for. And for exactly that one move: claim against evidence.
The difference from a status board sits in row two. A dashboard can do a lot: report runs, run tests, check that something is reachable. What it does not do is hold a report's claim against the thing that claim is about. The role calls up the six addresses the report claims are live. It searches the project for the old and the new sentence. And when it finds no evidence, it writes "not verified" instead of smoothing over the gap. That is precisely why it decides nothing: an instance that checks and approves at the same time is checking its own work. That self-checking is a weak safeguard is shown, at least for one clearly bounded case, by the study Large Language Models Cannot Self-Correct Reasoning Yet (Huang et al., ICLR 2024): when models were asked to correct their own answers purely from within, with no feedback from outside, results on reasoning tasks sometimes got worse rather than better. That does not carry over to every form of self-checking. So my reason is additionally a house rule: author and reviewer are never the same instance. The practical rules for separate review roles are in Claude Code Subagents: Best Practices.
What this role looks like in my business
In my business, the place that keeps the overview is called Kai. He has no interface of his own, he reads what the others leave behind anyway: git history, the reports and protocols in the shared folder, the workforce's mailbox. After a session he holds one employee's claims against what is actually on the file system and on the live website, and writes a short report of what I need to decide.
His review from September 5, 2026 shows what that looks like. He checked the work of two employees and found three things: an incomplete correction pass, after which a live site contradicted itself in five places; an employee who had been running permanently on a permission level without prompts; and a changed knowledge file with no log of who had changed it. The same review confirmed the other direction too: a completed rollout, six core routes checked live with HTTP 200, the outdated sentence showing zero hits afterwards, the new one present twice.
That is the whole trick, and it is unspectacular. Kai reports in both directions, what checks out and what is missing; in that one review alone, "not verified" appears three times. He decided none of it: no approval, no commit. His tools and his limits are on Kai, who keeps the overview.
Kai assumes that several roles are already running in your business and filing their results. If that is where you want to go, build the ones that deliver work first: Learn Claude: The Path in Five Stages is the entry point, and the ten cases in AI Agents: 10 Real-World Examples show which tasks make good first agents.
Frequently asked questions
How many AI agents before you need a lead role?
There is no count for it. The usable rule of thumb is a behaviour: once you start skimming reports instead of reading them, you need a place that reads before you do. In my business that role arrived after the workforce had been running for a while, not on day one.
What does an extra role like that cost?
It costs what another agent costs: compute plus your own time for onboarding it. How much exactly depends on the model, the tools and the task. In its own research system Anthropic measured roughly four times the tokens of a chat, and roughly fifteen times with several agents; that is an order of magnitude from someone else's setup, not a forecast for yours. How I calculate the running costs of a workforce is in What an AI Employee Really Costs.
Can one AI agent really check another AI agent's work?
Yes, and more of it than people tend to credit. Calling up addresses, searching a project for a sentence, holding files against a report: those are moves with an unambiguous outcome. Beyond that it can judge against set criteria, find errors and give reasons why something does not hold. What it does not own is the authority: deciding and approving stay with you.
What is an AI lead role allowed to decide?
In my business: nothing. It reviews, judges against criteria and evidence, condenses, asks questions and flags gaps, but approves nothing and changes no one else's results. Where exactly the line runs between establishing a fact and deciding is in What Can an AI Lead Role Decide?.
Where to go from here
Run the four-point pass; it takes ten minutes. For each agent, write down what it delivered yesterday, then find the evidence. Note where two roles touched the same thing. Take one claim from the last report and verify it. And check whether every handover has a file. If you end up with at most one sign, do not build a lead role, build the three measures from the middle of this post. If you end up with three or four, the role is due, and then as a role of its own with a single brief: claim against evidence.
The path there, from your first session to your own workforce, is what we work through step by step in my community, with the ready-made role packages as the starting point.
