Anthropic's own multi-agent research system beat a single agent by 90.2% on its internal research benchmark - and to get that lift it burned about fifteen times more tokens than a normal chat. That one pair of numbers from Anthropic's engineering write-up is the whole argument for multi-agent cold email in miniature: splitting one AI SDR into a team of specialized agents can produce a large jump in quality, and it can also multiply your cost and your failure surface for no gain at all. Which one you get depends entirely on the shape of the work you hand it.
So before you wire up a research agent, a writing agent, a sending agent, and a reply-triage agent and call it an AI SDR team, it is worth being precise about when that structure earns its keep in outbound and when a single well-built agent quietly wins.
What "multi-agent cold email" actually means
A single-agent AI SDR runs the whole loop in one continuous context: it picks an account, researches it, drafts the message, sends, and later reads the reply and decides the next step. One thread, one memory, one decision-maker. That is the shape most people mean by an AI SDR.
Multi-agent cold email breaks that loop into specialists:
- A research agent enriches the account and pulls signals - funding, hiring, a product launch.
- A writing agent turns those signals into a first-touch message.
- A sending agent handles delivery, pacing, and which mailbox to use.
- A triage agent reads replies and classifies them.
- An orchestrator (or lead agent) decides who works on what and in what order.
The appeal is obvious. Each agent gets a narrow job, a focused prompt, and a small tool set, which is easier to reason about than one giant agent that has to be good at everything. The trap is equally real, and the two most cited pieces of engineering writing on the topic land on opposite sides of it.
The case for splitting: the orchestrator-worker pattern
Anthropic's research system is the canonical argument in favor. It uses, in their words, an "orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel." A lead agent reads the query, plans an approach, and spawns subagents that each chase a different thread at the same time.
Mapped onto outbound, that pattern fits one stage almost perfectly: research at the top of the funnel. Ranking a list of a thousand accounts, enriching each, and drafting a first-touch angle are independent jobs. There is no reason account 700's research has to wait for account 12's. This is exactly the "heavy parallelization" and "information that exceeds single context windows" that Anthropic says multi-agent systems are built for.
There is a second, quieter reason the numbers came out the way they did. Anthropic found that in web-browsing tasks, "token usage by itself explains 80% of the variance" in performance - and a fan-out of subagents is a way to spend a lot of tokens across many context windows in parallel instead of cramming everything into one. For research, more parallel token budget buys more coverage. That is a genuine structural advantage, not a marketing line.
The multi-agent win is real, but it is specific: it shows up on wide, parallelizable work where subagents do not need to know what the others are doing. Cold email has exactly one stage like that, and it is research.
The case against: dispersed decisions get you double-sends
Now the other side. Cognition, the team behind the Devin coding agent, published a piece titled "Don't Build Multi-Agents" that reads like a direct rebuttal. Their core claim: multi-agent architectures are fragile because "the decision-making ends up being too dispersed and context isn't able to be shared thoroughly enough."
Their two principles are worth memorizing before you split an outbound agent:
- "Share context, and share full agent traces, not just individual messages."
- "Actions carry implicit decisions, and conflicting decisions carry bad results."
Their illustration is a coding one - two subagents building incompatible halves of a Flappy Bird clone because neither saw the other's assumptions - but the outbound version writes itself. Your research agent decides an account is worth a warm, curiosity-led opener. Your writing agent, working from a thinner slice of context, produces a blunt demo ask. Your sending agent, unaware that a follow-up is already scheduled, fires a second touch the same afternoon. Nobody made a wrong call in isolation. The calls conflicted because the context did not travel with them.
In outbound the failure mode is worse than an ugly UI. A dispersed decision is a double-send to a live prospect, a message to someone who already opted out, or two agents burning the same domain on the same account. Those are not quality bugs. They are deliverability and compliance incidents, and they are precisely what an agent that owns the whole motion in one thread avoids by construction.
Where the line actually falls in cold email
The two camps are not really in conflict once you stop treating "multi-agent" as an identity and start treating it as a tool matched to a task shape. Anthropic says multi-agent excels at parallel work and struggles when there are "many dependencies between agents." Cognition says single-threaded wins for deep, sequential work. Outbound has both shapes, at different stages.
| Stage | Task shape | Better fit |
|---|---|---|
| List ranking + research | Wide, parallel, independent per account | Multi-agent fan-out |
| Drafting first touch | Depends on research context | Either, if context travels |
| A single reply conversation | Deep, sequential, one memory | Single-threaded agent |
| Send / suppress / follow-up | Shared, irreversible, must not conflict | Shared tool, not an agent |
The practical architecture that most teams converge on is not "all multi-agent" or "all single-agent." It is fan out for research, collapse to one thread per conversation. Spawn subagents to research and pre-draft across the whole list in parallel, because that stage is embarrassingly parallel and benefits from the extra token budget. Then, the moment an account becomes a live back-and-forth, hand it to a single agent that holds the entire thread - the account history, the last reply, the scheduled follow-up - in one context, so no second agent can contradict it. That is also the cleanest place to keep a human in the loop, because there is exactly one decision-maker to review.
The part both camps agree on: the floor is a tool, not a prompt
Here is the detail that matters more than your topology, and it is the one place Anthropic and Cognition quietly agree. Anthropic's subagents share a coordinating state. Cognition's whole thesis is that shared context is what keeps a system coherent. Translate that to outbound and it means one thing: the irreversible actions cannot live inside any individual agent's head.
Send, suppress, and follow-up have to be shared tools with limits enforced inside them - a suppression check that runs on every send no matter which agent calls it, a volume cap the sending agent cannot talk its way past, an audit log that records who sent what. When those controls live in the tool layer, the number of agents above them stops being a safety question. One agent or five, they all hit the same floor. When those controls live in prompts instead, every new agent you add is a new way to double-send.
This is the same reason tool calling for cold email is really about what the tools enforce, not how many agents call them. A governed send layer that any agent reaches as a tool is what lets you experiment freely with agent topology - fan out, collapse, add a specialist, remove one - without turning each experiment into a deliverability risk. The protocol you expose it over, MCP or a plain API, is downstream of that. Get the shared floor right first and the rest of the architecture becomes reversible.
If you are still assembling the pieces, the single-agent version in how to build an AI SDR is the right place to start - you split it into a team later, once you have found the stage that is actually parallel, not before.
Your next step
Do not start by drawing an org chart of agents. Start by putting your send, suppression, and follow-up actions behind a shared layer that enforces its own limits, then run a single agent against it end to end. Once that floor is solid and you can see which stage of your loop is genuinely parallel, split only that stage into subagents - and leave every live conversation on one thread. Wire your outbound actions to FoxReach's cold email MCP server as the shared tool your agents call, and you can change the topology above it as often as you like without ever changing the floor beneath it.
