A Plain-English Guide to Leading a Team of Agents

In August 2026, Grok launched a feature called Bot: you can raise a crew of AI workers, each with a name, an avatar, a role, and its own memory, living on a cloud computer that belongs to you. They can open a browser, read and write files, log into apps with your accounts — and keep working after you close your laptop. They can also message each other and start group chats among themselves.

Communities quickly started building org charts for them: a “chief of staff” with a research analyst, a writer, and an ops person reporting up to it, looking every bit like a real team.

Just as quickly, another kind of post started showing up. Someone built a six-person (six-bot) team and burned through more than 40% of a week’s quota on day one — they later discovered that three of those six bots were re-checking the exact same batch of web pages.

This piece is here to help you think this through before you build your own crew.

In the last piece, we covered how to work well with one agent — delegating, equipping, guarding the gates, checking the work, and compounding what you learn. This piece takes on the thought almost everyone has next:

“One agent works great, so a squad must work even better.”

My answer might surprise you: most of the time, it doesn’t. But I’ll walk through both why it usually doesn’t and when it actually does, so you can judge for yourself by the end.

1. Three Words Worth Telling Apart: Temp Worker, Crew, Full-Time Staff

A lot of terms have piled up in the last couple of years — subagent, multi-agent, agent teams, bot mode, A2A. They’re really three levels of the same underlying idea, and what separates them is whether the agent is still around once the job is done.

Level one: the subagent — a temp worker.

The main agent takes on a big job and dispatches a few smaller ones: “you check these three, you check those three.” Each small one finishes its work in its own clean room, comes back with a one-page summary, and disbands on the spot, leaving nothing behind. Next time you dispatch it, it’s starting fresh.

Level two: multi-agent — a work crew.

Several agents work on one task at the same time, and may talk to each other and pass results back and forth. They stick around a bit longer than a temp worker, but they’re still orbiting this one job — once it’s done, they scatter too.

Level three: agent teams / bot mode — full-time staff.

This is the genuinely new thing in 2026. Every member has a fixed name, role, set of permissions, and its own long-term memory, persisting across many tasks and many days. Teach your “research analyst” a rule today, and it still remembers it next week. Grok’s Bot is the flagship example of this level: each bot is a standing identity that can even be set to “start working on schedule, without you saying a word.”

Why does the distinction matter? Because the cost profile is completely different across the three levels.

A temp worker leaves when the job’s done, which means no historical baggage — that’s actually its biggest advantage. Full-time staff have memory and continuity, but that comes with a new problem: what if it remembers wrong, and last week’s misunderstanding is still following you around today — like an old employee carrying a stale assumption.

One line to keep: persistence is an asset, and it’s also a liability.

2. Why You’d Even Want a Team: Three Motives, Only Two Real

Be honest with yourself first: you want to build a team for one of three reasons.

Motive one: one brain’s desk is too small. This one’s real.

Everything a model can see in a given turn sits on a finite “desk” — the industry calls it a context window. The fuller it gets, the easier it is for key information to get buried in the middle. If a task’s material genuinely exceeds what fits on one desk, you have no choice but to split across desks — that’s a hard constraint, not a preference.

Motive two: you want speed. Also real.

Research ten companies one at a time and it takes ten units of time; run all ten in parallel and it takes a little over one. As long as those ten lines of work are independent of each other, parallelizing is pure upside.

Motive three: you want “specialized division of labor.” This one, is mostly an illusion.

We’re so used to the logic of human organizations: when something’s complex, you split it into roles, each doing its own part. But division of labor among humans rests on a premise — each person’s mind is genuinely separate, their abilities genuinely differ, and communication has a real cost.

Agents don’t meet the first two conditions. The “legal specialist” and the “copywriter” you dispatch are very likely the same model, just with different opening instructions. Giving one a name doesn’t actually make it an expert — but the communication overhead sticks around in full.

The test is simple: if your “division of labor” just means giving the same brain a few different job titles, all you’ve bought is overhead. There’s only one kind of division of labor that actually means something — giving them access to different things (one read-only, one able to write; one with internet access, one restricted to the internal network) — which is the “equipping” from the previous piece, just applied differently.

Splitting roles isn’t division of labor. Splitting permissions is.

3. Four Shapes of Orchestration: Really Just Four Kinds of Office

If you’re actually going to build one, the industry has settled on a handful of shapes that work. I’ll translate them into office scenes you already know, so you can tell at a glance which one fits your job.

Shape One: Orchestrator–Worker (an editor dispatching interns)

The most common shape. A main agent holds the full task and, as needed, dispatches a few disposable subagents, each working on its own clean desk on one small slice, returning only a one-page summary before it disappears.

Think of it like an editor: “you check these three, you check those three, and come back to me with one page each — don’t dump all hundred pages you skimmed through onto my desk.”

This shape solves two problems at once: parallelism (speed) and desk isolation (the main thread’s desk never gets buried).

It genuinely works. Anthropic has published internal benchmarks on their own research system: this “one orchestrator plus several workers” setup beat a single, stronger model working alone by roughly 90% on research-type tasks.

But hold all three qualifiers together — internal benchmark, research-type tasks, a specific model pairing. That doesn’t mean “multi-agent is always stronger.”

The cost is public too: this kind of system burns roughly fifteen times the tokens of ordinary chat.

Good for: broad searches, parallel lines of research, sifting through large batches of material.

Shape Two: Pipeline (sequential handoff)

A finishes and hands off to B, B finishes and hands off to C. Like an approval chain: draft → proofread → typeset.

Good for: work where the steps are fixed and the order can’t be scrambled.

Risk: errors compound down the line — if the first stage misreads the brief, the next three stages will polish that misreading beautifully.

Shape Three: Triage Desk (routing / handoff)

A “front desk” sits at the entrance, judges who should own this, and routes it there. Like hospital triage.

Good for: cases where incoming tasks are varied but each type has a clear owner (customer-support tickets, for instance).

Risk: this is the number-one failure mode I’ll cover below in detail.

Shape Four: Writer–Reviewer (review loop)

One agent produces, another is dedicated entirely to finding fault, and they go back and forth a few rounds before delivery.

This is, in my view, the highest-value multi-agent pattern for ordinary people, and it perfectly matches “reading in parallel, writing single-threaded” — the fault-finder only offers opinions, never touches the work itself. It contributes intelligence, not action.

Good for: quality-sensitive output with a clear standard to judge against (external copy, data verification, compliance checks).

4. Why More Agents Often Makes Things Worse: Three Failure Modes and a Bill

The Cognition team (the one behind Devin) published a bluntly titled piece in 2025: “Don’t Build Multi-Agents.” Their argument: multi-agent systems fragment context — each member sees only its own slice, makes decisions that are locally sensible but mutually contradictory, and the whole thing blows up at merge time.

That’s their position, not an industry consensus. But combined with what practitioners keep reporting, three failure modes show up again and again — worth knowing before you build your own crew.

Failure One: Passing the Buck (endless handoff)

A thinks it’s B’s job and hands it off; B thinks it’s C’s job and hands it off; C hands it back to A.

The root cause isn’t that they’re dumb — it’s that nobody owns the task. Every handoff means re-understanding the job from scratch, and every re-understanding loses a little context. After three loops, nobody can say what the original ask even was.

You’ve seen plenty of this in human organizations too — the only difference is a human loop of three takes three days, and an agent loop of three takes three minutes, with the meter running the whole time.

Fix: any given task must have exactly one owner. The triage desk can decide who takes it, but once decided, it can’t get kicked back.

Failure Two: Rumor Contagion (hallucination taken as fact downstream)

This is the most dangerous one. A fabricates a number; B takes it on full trust and builds further reasoning on top of it, writing it up with what looks like solid logic.

By the time it reaches you, what you’re looking at is output that’s passed through “multiple stages,” which feels more credible. But it’s really the same error copied three times, picking up more convincing detail with each copy.

A principle applies here with extra force: agent output always looks complete, and looking complete is not the same as being correct. What multi-agent systems tend to do is make that sense of completeness even stronger.

Fix: any key fact that crosses a handoff must be re-verified — it doesn’t get to skip inspection just because “the last stage already passed it along.” This is exactly where the fault-finder role in Shape Four earns its keep.

Failure Three: Drifting Together (shared bias mistaken for confirmation)

You send three agents to evaluate the same proposal, all three say it’s good, and you think “that’s been triple-checked.”

But they’re very likely the same model carrying the same tendencies. Three identical brains voting gives you three votes and one opinion.

Fix: delete the phrase “multi-party verification” from your vocabulary. They aren’t three people — they’re one person saying the same thing three times.

The Bill: More Expensive Than You’d Guess

• Tokens run fifteen-times-plus. That earlier number isn’t scare talk.
• Debugging costs double. When one agent fails, you check its log. When five fail, you first have to figure out which stage actually broke — and since they only pass summaries to each other, the reasoning in between is often already gone.
• Quota burns fast. The six-bot team from the opening, burning 40% of a week’s quota in a day (an early user’s account) — the root cause was three bots doing redundant work with nobody noticing. In a human team, someone would complain about duplicated work; agents don’t complain — they’ll quietly, diligently, and simultaneously do the exact same thing.

The rule of thumb I’ve personally taken away from this whole debate:

Reading can run in parallel; writing has to stay single-threaded. The extra agents you add should contribute intelligence (researching, offering opinions, finding faults) — not action (each independently editing the same thing).

This is my own summary, not a direct quote from anyone. But it lines up exactly with your own experience leading a team: three people splitting up research is fine; three people editing the same slide deck at the same time is a disaster — you’ll spend more time reconciling versions than you would’ve spent writing it yourself.

5. Standing AI Colleagues: A New Thing, and a New Set of Pitfalls

Back to Grok’s Bot from the opening — it represents the third level: full-time staff. The new capabilities and the new risks it brings both deserve their own discussion.

The new capability is real. A standing bot has its own cloud computer, can log into your apps and click around like a person, and save files; you can close your browser and it keeps working; a workflow that runs well can be saved as a “routine” that fires off on schedule from then on. This is no longer “you ask, it answers” — it’s “it has its own shift.” That’s a genuine leap in product form.

But there are three pitfalls I think matter more than the feature itself.

Pitfall one: separate identities don’t mean separate isolation.

You raise six bots and intuitively assume they’re six separate coworkers, each minding their own business. But according to Grok Bot’s own documentation, these bots share the same cloud computer — files sit in one shared pile, browser login sessions are shared — and the official docs explicitly warn: don’t treat different bots as security boundaries.

Translated: you think you’ve got six people in six separate offices; what you actually have is six people sharing one desk and one already-logged-in account. That “research analyst” who should only ever touch public material, and that “admin assistant” who can log into your inbox, are standing on the same floor.

I’d call this the single most practical warning in this piece, precisely because it’s counterintuitive: giving agents different names doesn’t build different walls between them. Walls have to be built at the permissions layer, separately, on purpose.

Pitfall two: it now has a key.

Something that can log into your accounts on its own, read and write your files, and run routines automatically is fully capable of taking irreversible actions by itself — sending a message, making a payment, deleting a file.

One principle doesn’t bend here — it just gets more important: anything that touches money, external communication, or deletion has to stay inside your own gate. Being persistent and automated raises efficiency; it doesn’t raise judgment.

Pitfall three: it’s still very young.

Products like this only shipped in 2026, and early users report the cloud computer freezing, requests failing, quota burning through fast, exposure risk from shared logins, and context getting messier the longer it runs. It looks great in a demo. How it holds up inside your own messy real-world workflow — there isn’t enough evidence yet to say.

I’m not telling you to avoid it. I’m saying: use it first on the work where a mistake can be undone, and build your judgment from there.

6. Protocols: MCP and A2A, in One Minute

You’ll keep seeing these two acronyms in the news, and the division between them is actually simple:

• MCP is the standard interface for an agent connecting to tools — how it calls your calendar, files, database.
• A2A is the standard interface for an agent delegating to another agent — how it hands off a task to a different agent, even one built by a different company.

Worth noting: both protocols are now hosted under the Linux Foundation’s Agentic AI Foundation — MCP since December 2025, A2A since August 2026. The foundation’s member list includes OpenAI, Anthropic, Google, Microsoft, and AWS.

The fiercest competitors in the field just sat down at the same table to agree on how the interface should work. That usually means this layer is becoming infrastructure, the way USB did — anyone’s mouse plugs into anyone’s computer, and the port itself stops being a selling point.

There are two practical implications for you, one good, one less so:

The good news: going forward, you won’t be as locked into a single vendor’s ecosystem — team members can come from different providers.

The less good news: once agent A can smoothly delegate to agent B from another company, it gets a lot harder to see who’s talking to whom, and who has permission to touch what. I think that’s the next real governance problem — not within a single agent, but on the lines connecting them.

7. The Real Difficulty Isn’t Technical, It’s Managerial: Five Decisions for Building a Team

If you’ve decided to build one, make these five decisions in order. None of them require technical knowledge, but getting any one wrong turns the team into a liability.

Decision one: decide who can write before you decide who does what.

As covered above, splitting roles isn’t division of labor — splitting permissions is. The smallest viable setup is: a group of read-only agents, plus one that can write. Anyone doing research, checking, or offering opinions gets read-only access; the one agent that actually edits files or sends things stays singular, and its actions still pass through your gate.

Decision two: the unit of handoff is the “deliverable,” not the “responsibility.”

Human handoffs can rely on shared understanding and follow-up questions; agent handoffs only have the words you actually wrote down. So don’t say “you own market analysis” — say “produce a table with these five columns, and every row needs a source link.”

My way of putting it: the smallest unit of orchestration isn’t a task — it’s an “acceptable chunk” — a piece of work with a clear output, at the end of which someone (or some rule) can say “this chunk passes.”

Why? Because errors compound. A ten-step process, even at 99% success per step, only holds together nine times out of ten once you multiply it out. In a twenty-step chain, any deviation at any point gets amplified by all nineteen steps that follow; break it into four segments instead, and a deviation can only accumulate within one segment before the boundary cuts it off. Segmenting isn’t for management aesthetics — it’s to fight that multiplication.

Decision three: start by automating a handoff, not a job.

Most people’s first instinct is “have AI take over this role” — that direction almost always fails. A role is held together by countless implicit judgment calls, ad hoc exceptions, and interpersonal coordination, none of which is written down in any process document.

A much more reliable starting point is the moment where one person finishes something and hands the result to the next person. These moments have three natural advantages: clear inputs and outputs, a ready-made acceptance standard (downstream will complain if it’s wrong), and they’re usually already written down (tickets, emails, spreadsheets).

One related judgment call: route well-defined work through a fixed process (filling client names and amounts from 50 contracts into a spreadsheet — a hard-coded path is stable, cheap, and reproducible); only let it explore freely when the steps genuinely aren’t fixed (“figure out why sales dropped this month”). The most common waste is treating the first kind like the second: it’s really just data entry, but you make it re-think how to do it from scratch every single time — expensive and unstable for no reason.

Decision four: keep the ledger where you can see it.

Four numbers are enough to track the trend: first-pass success rate, rework rate, human review time, cost per task.

Pay special attention to the third one. A lot of “AI productivity gains” are actually quietly shifted into downstream review workload — upstream saves two hours, downstream spends three extra hours checking, and the books still show it as a net gain.

Decision five: accountability has to land on a person’s name.

When an agent does the work, “the system did it” isn’t an acceptable answer. This isn’t bureaucratic box-checking — only when someone is accountable does anyone actually go read the logs nobody wants to read.

8. When to Deploy a Team, and When Not To

Now that the mechanics and the management are covered, here’s a table you can apply right now.

The conclusion first: push a single agent to its limit before you add a second. For most workplace situations, one well-configured agent is more than enough. This doesn’t contradict either Anthropic’s or Cognition’s public stance — one says multi-agent works well in specific settings, the other says don’t split things apart carelessly — the line between them is exactly the three signals below.

Only consider a team when all three hold at once:

1. The task fans out rather than digs down — it needs many independent lines of exploration at once (researching ten companies simultaneously), not a single thread pursued layer by layer;
2. The material genuinely exceeds what fits on one desk;
3. No two lines of work are writing to the same thing (reading in parallel, writing single-threaded).

Conversely, if any one of these four shows up, don’t:

• You can’t clearly define “done.” One agent will amplify vagueness; a group will dress that vagueness up as consensus.
• Multiple lines need to edit the same thing. The cost of reconciling conflicts eats the entire gain.
• The task digs down, not out — where each step depends on the judgment made in the step before. Splitting this kind of work apart only loses context.
• You haven’t worked out how you’d debug a failure. You can read a single agent’s log; whether you can read a group’s log is worth confirming before something goes wrong, not after.

9. Back to That Cloud Computer

The six-bot team from the opening, burning 40% of a week’s quota — we can diagnose it now: it wasn’t a technical problem, it was a management problem. Three members were re-checking the same batch of web pages because nobody owned that task, and nobody had defined what “done checking” even meant.

Anyone who’s ever managed people will recognize this problem instantly — the only difference is that in a human team, someone complains about duplicated work. Agents don’t complain — they’ll quietly, diligently, and simultaneously do the exact same thing until the quota runs out.

Three takeaways to keep:

1. Splitting roles isn’t division of labor — splitting permissions is. Giving them different names doesn’t build different walls between them. A group of read-only agents plus one that can write is the smallest viable setup.
2. Reading can run in parallel; writing has to stay single-threaded. Extra agents should contribute intelligence (researching, reviewing, finding faults), not action. For quality-sensitive work, pairing in a role that “only critiques, never edits” is the highest-value multi-agent pattern there is.
3. Push a single agent to its limit before you add a second. Only build a team when all three signals line up; miss even one, and what you’ve bought is mostly overhead and debugging cost.

One memory card: decide who can write first, hand off by deliverable, one owner per task, re-verify across every handoff, keep the ledger visible.

The memory card from the last piece still holds — delegate what’s reversible, equip minimally, gate the risky moves, never skip the check, let it compound. Leading a team is just doing those same five things again for every member, plus one more line: you also have to manage the lines running between them.

Sources

• Anthropic, “How we built our multi-agent research system” (anthropic.com/engineering) — the orchestrator–worker architecture; the ~90% improvement is from their internal research-task benchmark with a specific model pairing; the ~15x token figure is from their own product data
• Cognition, “Don’t Build Multi-Agents” (Walden Yan, cognition.ai/blog, 2025) — this team’s position, not an industry consensus
• Grok Bot’s public launch materials and product documentation from August 2026 (standing cloud environment, bot-to-bot messaging, routine tasks; “don’t treat different bots as security boundaries”); early-user reports of quota consumption and shared-login issues ⚠️ mostly secondhand sources — verify against official documentation before publishing
• 2026 public summaries of multi-agent orchestration patterns (sequential / parallel / hierarchical / handoff / loop) and practitioner-reported failure modes (endless handoff, hallucination propagating down a chain)
• Linux Foundation / Agentic AI Foundation announcements on hosting MCP (2025-12) and A2A (2026-08)
• The sources cited in the previous piece, “Working With Agents” — METR, τ-bench, NIST, Microsoft × CMU, and others — listed at the end of that piece

Note: passages in this piece marked “my judgment,” “I think,” or “my own summary” are opinions; everything else is traceable public information. Descriptions of specific products reflect publicly available information as of September 2026 — products this new change quickly, so check the official documentation as of when you’re actually using them.

Coming up next: how to actually build this into your own workflow — where to start, how to measure whether it’s actually helping, and how to avoid a situation where “gains in efficiency” just means the work quietly moved downstream.

(If you still haven’t decided which agent to pick, you can revisit the earlier piece on that — it has a full framework for sizing that decision up.)