We run outbound for over 200 B2B clients: domain setup, inbox infrastructure, DNS, campaign operations, deliverability.
One client fleet alone runs about 40 domains and 176 mailboxes, which means a lot of repeatable, high-volume work that never changes in structure, only in detail.
People assume the AI behind that work is one chatbot subscription with a clever prompt. It is not.
It is a stack of narrow agents, each one built to do a single job and nothing else.
We learned that the hard way. Early on we tried routing DNS checks, inbox provisioning, and campaign QA through one general-purpose assistant.
It worked until volume climbed, and then it started making the kind of mistakes a narrow, single-purpose agent never would.
So the real question is not which AI tool to buy. It is which job each tool owns, where planning lives, and where a human still has to sign off.
Each agent owns one job, never the whole pipeline
Our stack runs four agents, each built on the Claude API and each scoped to one function: one handles DNS record setup, one handles inbox creation, one runs campaign operations, and one gathers intelligence on deliverability and market signals.
None of them can touch another's job. The DNS agent never sees campaign copy. The campaign agent never touches a Cloudflare record.
That isolation matters once you are managing a fleet the size of 176 mailboxes across dozens of domains. A bad prompt in one narrow agent stays contained.
A bad prompt in one agent trying to do everything does not.
Planning sits above the agents, not inside them
Sequencing logic lives in our n8n workflows, outside any single LLM call. We do not rely on one agent chaining its own next steps through prompt reasoning.
A new inbox has to finish its three-week warmup before the campaign agent is allowed to start sending into it.
That dependency is enforced by a scheduled trigger, not by an agent's judgment call.
This is the same discipline we apply in client automation engineering work: map the process and its dependencies before you let anything run on its own.
Memory stays scoped to the job, not shared across agents
Our intelligence-gathering agent ingests and scores dozens of sources every week, building up its own research memory.
That memory does not leak into the campaign agent's context, and it should not.
We saw what happens when old data persists past its use.
In one onboarding, a CRM still listed a US manufacturing software company as a UK health and wellness brand, because stale enrichment data had never been corrected.
Shared memory across agents creates the same risk at machine speed.
Scoping memory to the job that needs it keeps a stale research note from quietly steering a live campaign decision.
Human review still sits where judgment actually matters
Agents are good at flagging problems. They are not the ones who decide when to burn a domain.
We have seen sending domains degrade to a health score of 68, with mail landing in spam, and get replaced with fresh domains scoring 98 and 100.
The agent reports the score drop. A person decides whether to retire the domain or try to recover it.
That split, agents detect, humans decide, is the actual boundary of what we automate. It is also why none of our bots run campaigns unsupervised.
The stack only pays off at volume
At 15 new prospects a day per mailbox across 176 mailboxes, one client fleet alone pushes over 2,600 prospects into sequences every day.
No person is reviewing each one before it goes out.
That volume is the actual argument for narrow agents over one do-it-all assistant.
A single tool trying to plan, remember, and execute across that much daily movement becomes the bottleneck it was supposed to remove.
Splitting the work across task-specific agents is how a small team keeps serving 200-plus clients without the headcount a stack like that would normally require.
The Questions We Get Asked
Do we need a separate agent for every task, or can one AI tool handle it all?
One tool can handle small volume, but it starts making cross-context mistakes once the workload grows.
Splitting tasks across narrow agents keeps errors contained to one job instead of spreading across everything.
What happens when an agent makes a mistake?
It stays contained to that agent's scope because none of our agents can act outside their assigned job.
A human still reviews anything with financial or deliverability consequences, like retiring a domain.
Is this approach only for agencies, or can an in-house RevOps team use it?
Any team running repeatable, high-volume outbound work can apply the same split: one agent per function, planning logic outside the LLM, and a human checkpoint on consequential decisions.
The size of the team matters less than the discipline of keeping jobs narrow.