TL;DR: An AI outbound agent is a stack of five layers: data, the model that reasons, the tools it can call, the infrastructure that sends, and the humans who oversee it. Results are capped by the weakest layer, so find the weakest one before you buy anything new.
#What you will learn
- Why a stack view beats a tool list
- The five layers at a glance
- Layer 1: data
- Layer 2: the brain
- Layer 3: tools
- Layer 4: send infrastructure
- Layer 5: human oversight
- How the layers talk to each other
- Find your weakest layer
- Build order for a small team
- Where FirstSales sits
- Frequently asked questions
- Conclusion
#Why a stack view beats a tool list
Most buying conversations in AI outbound start with a list of products. Someone asks which data tool, which writer, which sender and which dashboard to buy.
That framing hides the real structure. Each product is one part of a system, and the system fails at its weakest part no matter how good the others are.
Our angle is simple. Treat an AI outbound agent as five layers, diagnose by layer, and spend your next dollar or hour on the weakest one.
The five layers are data, brain, tools, send infrastructure and human oversight. Each answers one question about the agent: what does it know, how does it think, what can it do, how does mail leave, and who is watching.
This view helps because the failure stories are consistent. Teams blame the model for bad emails that came from stale data. They blame the platform for bounces that came from broken authentication.
Industry coverage of failing AI sales agents points the same way. Our own analysis in why AI SDRs fail and common AI SDR mistakes shows that the cause is usually upstream or downstream of the model.
If you are new to the protocol that connects some of these layers, read what MCP is in plain terms first. This post places MCP in context, and it will make more sense once you know the menu idea.
For an even wider map of the surrounding products, see the cold outbound tech stack for 2026. That post lists categories, and this one explains how an agent uses them.
#The five layers at a glance
Read the table once, then use it as a diagnostic card. Each row names the layer, the question it answers and its classic failure.
| Layer | Question it answers | Typical failure | Fix first |
|---|---|---|---|
| 1. Data | Who are we writing to, and what do we know? | Stale or wrong facts | ✓ Verify and refresh |
| 2. Brain | How does the agent decide what to say and do? | Drift, generic copy | ✓ Evals and prompts |
| 3. Tools | What can the agent read and change? | Too many tools, too much power | ✓ Narrow the menu |
| 4. Send infrastructure | How does mail leave and land? | Authentication, limits, reputation | ✓ Audit before volume |
| 5. Human oversight | Who approves and stops things? | Skipped reviews, no kill switch | ✓ Name owners |
flowchart BT L1[Layer 1: Data - lists, signals, research, knowledge] L2[Layer 2: Brain - model, prompts, evals] L3[Layer 3: Tools - CLI, MCP, API] L4[Layer 4: Send infrastructure - domains, mailboxes, limits] L5[Layer 5: Human oversight - approvals, monitoring, kill switch] L1 --> L2 L2 --> L3 L3 --> L4 L5 -. watches and gates .-> L2 L5 -. watches and gates .-> L3 L5 -. watches and gates .-> L4
The arrows show a flow from facts to words to actions to mail. The dotted lines show that oversight cuts across the middle layers, because people need to watch decisions, actions and sending.
Notice what the diagram leaves out. It has no single box labeled "AI SDR", because the agent is the whole stack in motion.
That is also why AI workers and AI copilots differ less in the model than in how many layers they own. A copilot suggests, and a worker acts across several layers.
#Layer 1: data
The data layer holds what the agent knows about prospects, your offer and your market. Everything downstream is limited by its quality.
It has four parts. Contact and company records, buying signals, research on each prospect, and your own knowledge about what you sell.
Records. Names, titles, companies and email addresses. These decay constantly, which is why our note on B2B data decay and list hygiene matters for any agent that sends.
Verify addresses before you send. The guide to email verification before sending explains how to cut bounces at the source.
Signals. Events that suggest a prospect might care now, such as a hire, a launch or a funding round. Read more in signal-based cold email and buying signals for cold email.
Research. Facts about each prospect that let the email say something true and specific. The distinction between researching and writing is covered in AI research agent versus writing agent.
Knowledge. Your own offers, proof points and rules about what you can and cannot claim. A model without this invents claims, which is a compliance risk as well as a quality risk.
On FirstSales, the CLI has groups for contacts, contact-lists, kb and offerings, which cover records and knowledge. The walkthrough on importing leads from the terminal and the one on loading product knowledge and offers from Claude Code show the workflows.
Data problems look like model problems. A wrong first name, an outdated job title and a made-up claim all show up in the email, so they feel like writing errors.
Test the data layer by sampling. Pull twenty records and verify every field by hand, and you will learn more than from any dashboard.
Failure to watch for: confident emails built on wrong facts. First fix: verify addresses, refresh records and write down what the agent may claim.
#Layer 2: the brain
The brain is the model plus the instructions that shape it. It decides what to say, what to ask for and which tool to call.
Three things define the brain. The model you choose, the prompts and examples you give it, and the evaluations that tell you whether it is any good.
The model. Different models write differently and follow rules with different reliability. You will likely change models over time, so build around that.
The prompts. Instructions, tone rules, claims rules and examples. Treat them as code that needs version control and review.
The evaluations. A set of test cases that let you compare versions. Our post on building an eval set for outbound AI shows how to start.
Prompts drift. Small edits, model updates and added examples can change behavior in ways nobody planned, a problem covered in AI SDR prompt drift.
Quality at scale is a brain-layer topic too. The notes on AI email quality at scale explain why sampling and review rates matter.
Anthropic's guide to building agents gives a useful frame. It describes agents as systems where the model directs its own process and tool usage, and it recommends starting with the simplest workable design.
For outbound that advice translates well. Use a fixed workflow where the steps are known, such as research, draft and review, and give the model freedom only where freedom adds value.
Writing is the visible part of the brain, but judgment is the hard part. Deciding who not to email and when to stop is more valuable than polishing a subject line.
Failure to watch for: generic or drifting copy and invented claims. First fix: write an eval set, freeze the prompt versions and give the model your facts.
#Layer 3: tools
The tools layer is how the brain touches the world. It includes the command line, MCP servers and APIs.
Here the protocol we have been discussing lives. MCP gives an agent a menu of actions through one open standard, which Anthropic released in November 2024 and donated to the Agentic AI Foundation under the Linux Foundation in December 2025, according to the MCP maintainers.
Each interface has a role. The API is the raw contract, the CLI is the guarded command line, and MCP is the discoverable menu for assistants.
On FirstSales, the CLI is installed with npm i -g @firstsales.io/cli and runs as firstsales. It covers campaigns, contacts, domains, inbox, knowledge, offerings, alerts, API keys and billing, among others.
The product MCP server, firstsales-product, uses streamable HTTP and OAuth with PKCE. It offers a menu of mostly read tools and a few narrow writes, and we found no tool that creates a campaign.
So the working split is clear. Create with firstsales campaigns create, then use MCP to edit and watch.
Three disciplines keep this layer healthy.
Keep the menu short, as argued in why 100 MCP tools make an agent worse. Tier the tools by risk, as in which tools an agent should get.
Review descriptions for changes, as in MCP security for outbound.
Choose the interface by job, not by fashion. The comparison in CLI, MCP or the app: which for which job helps, and running outbound from the terminal shows the CLI-first approach.
This layer is also where least privilege lives. API keys should be created with api-keys create and the least access that works, and never pasted into a prompt.
Failure to watch for: a bloated, over-powered menu that can change under you. First fix: list the tools, tier them and remove the ones nobody uses.
#Layer 4: send infrastructure
The send layer is where words become mail. It includes domains, mailboxes, authentication, tracking, warm-up and sending limits.
This layer is governed by outsiders. Google asks bulk senders to keep spam rates below 0.1% and never reach 0.3%, and requires SPF, DKIM, DMARC and one-click unsubscribe from bulk senders.
Microsoft's rules for Outlook, described in its high-volume sender announcement, apply to domains sending more than 5,000 emails a day, and non-compliant mail goes to Junk before it may be rejected.
The law applies as well. The FTC's CAN-SPAM guide says each violating email can carry penalties of up to $53,088, with no exception for business-to-business email.
Infrastructure choices matter more than copy tweaks. Set up authentication with SPF, DKIM and DMARC, respect email sending limits, and check how many messages each mailbox sends in emails per inbox per day.
The CLI has commands for this layer. These include domains, tracking-domains, email-auth status and email-auth verify, warmup status and suppression check, and the walkthrough in setting up sending and tracking domains from the CLI goes through them.
Audit before you scale. The checklist in the cold email infrastructure audit catches problems while they are cheap to fix.
Monitor continuously after launch. See email deliverability monitoring, and keep a playbook for deliverability incident response.
Domains wear out if mistreated. The note on cold email domain burn rate explains the economics of protecting them.
Failure to watch for: mail that never reaches the inbox. First fix: verify authentication, set conservative limits and watch complaint rates.
#Layer 5: human oversight
The last layer is the people. It decides what the agent may do, approves what matters and stops what goes wrong.
Oversight is not a single act. It is approvals before launch, monitoring during a run and a kill switch when things go wrong.
Anthropic's guide describes agents that can pause for human feedback at checkpoints, which is the design pattern here. A person looks at the plan, the draft or the batch before it goes out.
The seven controls in guardrails for email-sending agents form the practical heart of this layer. They include readiness checks, test emails, volume caps, human approval, monitoring and a kill switch.
The safety lines are short. Run campaigns readiness and campaigns send-test-email before campaigns start, never paste an API key into a prompt, and treat deletes such as contacts delete as permanent.
How much review is enough is a live debate. The posts on the human review rate for AI email, human-in-the-loop cold email and unsupervised AI outbound lay out the options, and AI drafts, human sends describes a model that many teams adopt.
Reply handling is oversight too. People need a path for answering real prospects and a way to catch misclassified replies, as covered in the reply handling playbook and in AI reply misclassification.
Legal review belongs here. A compliance pass over AI-generated copy, described in the AI-generated email compliance review, prevents claims that your company cannot support.
The right level of autonomy is a choice. The trade-offs are in AI-assisted versus autonomous outbound and AI SDR versus AI-assisted SDR.
Failure to watch for: skipped reviews and no way to stop. First fix: name an approver, write a three-line kill switch runbook and practice it.
#How the layers talk to each other
Layers fail at their seams as often as inside. Understanding the handoffs helps you find problems faster.
Data to brain. The model sees the records and research you provide. If a field is blank or wrong, the model fills the gap with plausible text, so require facts and let the model say "unknown".
Brain to tools. The model chooses tools from the menu and fills their fields. Clear tool descriptions, small menus and strict schemas make good choices more likely.
Tools to send. Tool actions change campaign state, and the send layer acts on that state. A tool that edits a step in a running campaign changes what the next prospect gets.
Everything to oversight. Each layer should leave a trail a person can read. Logs, events and analytics let you check what happened.
Oversight back to everything. People change the data, tweak prompts, adjust the menu and change limits. Make those changes deliberately and record them.
Handoffs also explain how risk moves. Hostile text in a reply enters at the data layer, steers the brain, uses a tool and ends in the send layer.
Simon Willison named the pattern that makes this dangerous. He wrote that an agent combining access to private data, exposure to untrusted content and the ability to communicate externally can be tricked into leaking data.
"If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker."
Simon Willison, "The lethal trifecta for AI agents," June 16, 2025 (source)
In stack terms, private data lives in layer one, untrusted content enters layer one too, and external communication is layers three and four. Oversight at layer five is the break in the chain.
#One email, five layers: a walk-through
Follow a single email through the stack to see how each layer shapes the result. The story is a composite illustration and describes no real customer.
A prospect record sits in the data layer. It holds a name, a company, a title and an address that was verified last month.
A research step adds one true, specific fact, such as a product launch the prospect announced. The knowledge base adds what you may claim about your own offer.
In the brain layer, the model drafts three steps using those facts and your prompt rules. The eval set shows that this prompt version scored well on similar cases.
In the tools layer, the draft becomes sequence steps in a paused campaign. The agent used an edit tool to place the text, and it could not start anything.
A person reads the steps in the oversight layer. They run campaigns readiness, send a test email to an inbox they own and spot a clumsy line in step two.
They fix the line, and the campaign starts at a low daily volume. The send layer spreads messages across several mailboxes and respects its limits.
The next morning a person checks progress, bounces and replies. Everything looks normal, so the volume rises a notch.
Each layer did a small job. If any had failed silently, a different layer had a chance to catch it.
That redundancy is the practical benefit of thinking in layers. It also shows why the cheapest improvement is often a check at a seam between two layers.
#Common misdiagnoses
Teams often blame the wrong layer. The table below maps symptoms to the layer that more often causes them.
| Symptom | Common blame | More likely layer |
|---|---|---|
| Emails feel generic | The model | ✓ Data: thin research and no facts |
| Many bounces | The sending platform | ✓ Data: unverified addresses |
| Low inbox placement | Subject lines | ✓ Send: authentication or reputation |
| Agent edits the wrong thing | The model | ✓ Tools: vague or overlapping tools |
| Claims you cannot support | The model | ✓ Data: no rules about claims |
| Quality fell after an update | Bad luck | ✓ Brain: no eval set to compare |
| Problems found too late | Unlucky timing | ✓ Oversight: no daily check |
| Good copy, no replies | The writer | ✗ Often the offer, not any layer |
The last row is a reminder that the stack cannot rescue a weak offer. Layers make execution reliable, but they do not create demand.
Use the table as a first guess and then test it. A symptom can have more than one cause, and the evidence from your own data should decide.
#Make, buy or borrow by layer
Teams ask what to build and what to buy. The answer differs by layer, and the table below gives a starting view.
| Layer | Build yourself | Buy or borrow |
|---|---|---|
| Data | ✓ Your offers, claims and ideal customer rules | ✓ Contact records and signals from providers |
| Brain | ✓ Prompts, examples and evals | ✓ The model itself |
| Tools | ✗ Rarely worth building from scratch | ✓ The CLI and MCP from your platform |
| Send infrastructure | ✗ Risky to improvise | ✓ Managed domains, warm-up and checks |
| Oversight | ✓ Policy, owners and drills | ✗ Cannot be bought, only practiced |
Your knowledge of your customers is your edge, and nobody can sell you that. Keep ownership of the facts, the claims and the rules.
Be careful with the send layer. Improvised infrastructure is how teams lose domains, and the cost of a mistake lands on you.
Oversight is the layer that people try to buy and cannot. A tool can support it with alerts and checks, but the habits are yours.
#What to measure at each layer
A stack you cannot measure is a stack you cannot improve. Pick one or two numbers per layer and watch them weekly.
| Layer | Numbers worth tracking | Where to read them |
|---|---|---|
| Data | Share of sampled records that pass a manual check, bounce rate | Your sample sheet, campaign analytics |
| Brain | Eval set score by prompt version, share of drafts edited by reviewers | Your eval set, review notes |
| Tools | Tool count, tools never called, changes to descriptions | Your tool register |
| Send | Spam complaint rate, bounce rate, inbox placement trend | Provider dashboards, campaign analytics |
| Oversight | Time to pause in a drill, share of launches with a recorded approval | Your drill log, launch checklist |
Notice that the numbers are mostly cheap to gather. A sampled sheet, a register and a drill log need no new software.
Pull the campaign numbers through the read side of the tools layer. The CLI offers campaigns analytics, campaigns progress and campaigns events, and the MCP menu has matching read tools.
Set a target and a trigger for each number. For complaints, the sender guidance from Google gives you an anchor, and for the rest, choose targets from your own baseline after a few weeks.
Review the numbers in a fixed weekly slot. The meeting can last fifteen minutes if everyone brings their own layer's figures.
When a number moves, trace it down the stack. Rising bounces point to data, falling placement points to send, and odd edits point to tools or the brain.
Write down what you learn. A short log of cause and effect turns your team into the people who know how this system behaves, which no vendor can sell you.
#When to add a sixth thing
Readers sometimes ask whether the stack needs more layers, such as analytics, billing or a CRM. Those matter, but they attach to the five layers and do not replace them.
Analytics lives where oversight reads from the tools layer. Billing and credits belong to oversight too, since someone must watch spend, and the product menu has read tools for credit balance and usage.
A customer record system feeds the data layer and receives outcomes from the send layer. Treat it as a neighbor with a clear boundary, not a sixth floor.
Keep the model simple enough to explain on a whiteboard in two minutes. If a new tool does not fit one of the five layers, ask whether you need it at all.
#Find your weakest layer
Diagnosis beats shopping. Use the questions below to score each layer from one to five, where five means you would bet your domain on it.
| Layer | Question to score | Evidence you can gather this week |
|---|---|---|
| Data | Do twenty sampled records survive a manual check? | A sample sheet with verified fields |
| Brain | Do you have an eval set and versioned prompts? | The set, and a diff of the last prompt change |
| Tools | Can one person explain every tool on the menu? | A tool register with tiers |
| Send | Do authentication, limits and monitoring pass an audit? | The audit output and complaint rates |
| Oversight | Can anyone pause within a minute, and is approval named? | A drill result and a policy page |
Score honestly. Most teams find a one or a two in at least one layer, usually the one they never thought about.
Sort your scores and fix the lowest first. A single layer at one cannot be rescued by a five elsewhere.
If two layers tie, fix the one that is cheaper and more irreversible when it fails. Send infrastructure and oversight usually win, because damage there is hardest to undo.
Re-score every quarter. Teams grow, tools change and yesterday's five may be today's three.
An outside view helps too. The outbound process audit is a good lens when results have stalled and you cannot see why.
#Build order for a small team
If you are starting from nothing, the order matters. This sequence avoids the most common expensive mistakes.
Week one: send layer and oversight. Set up domains and authentication, define your limits, and write the kill switch runbook. These are the layers that hurt the most when ignored.
Week two: data. Clean a small list, verify addresses and write down your offers and claims. Keep the list small enough to check by hand.
Week three: tools. Install the CLI, run firstsales whoami --json and firstsales doctor --pretty, and connect MCP in a test workspace with read tools first. The recommended agent loop is to read state, plan the smallest change, preview with --dry-run, use --confirm only when intended and verify afterward.
Week four: brain. Draft your first sequence with the model, build a small eval set from real examples and review every email by hand.
Then: launch small. Create the campaign with firstsales campaigns create, run campaigns readiness, send a test email and start at a low volume with a person watching.
After that: widen. Add signals, add tools one at a time and raise volume slowly. Re-score the stack after each change.
The order puts the brain fourth on purpose. Teams that begin with the writing model build the most visible layer on top of the least reliable ground.
For hands-on builds in the terminal, the posts on GTM engineering first builds and the GTM engineer role show how a technical operator can own the middle layers. For lead sourcing with a coding agent, see Claude Code for lead gen.
#Where FirstSales sits
FirstSales is an AI SDR and cold email platform, so it touches several layers. We describe it here so you can judge fit without a pitch.
In the data layer, it holds contacts, lists, a knowledge base and offerings. In the send layer, it manages domains, tracking domains, authentication checks, warm-up status and suppression.
In the tools layer, it ships a CLI and a product MCP server. In the oversight layer, it provides readiness checks, test emails, alerts and pause controls that a person operates.
The brain layer is where you have the most choice. Whatever drafts the copy, the platform still provides the checks around it.
That mix is deliberate. The CLI is the guarded base for setup and launches, and MCP is the conversational layer for reading, watching and editing.
For a plain view of where the product fits among other categories, see where FirstSales fits in your outbound stack. For the difference between categories, sales engagement platforms versus AI SDRs compares the models.
No platform covers every layer for every team. Your data, your offer and your people still decide the result.
#Frequently asked questions
#What is an AI outbound agent stack?
It is the set of layers that let an AI agent run outbound: data, the model that reasons, the tools it calls, the infrastructure that sends and the people who oversee it.
#What are the five layers?
Data, brain, tools, send infrastructure and human oversight. Each answers a different question about what the agent knows, decides, does, sends and who watches.
#Which layer matters most?
The weakest one. A stack performs at the level of its lowest layer, so diagnose first and spend on the weakest.
#Is the model the brain layer?
The model is part of it. The brain layer also includes prompts, examples and evaluations that shape and test the model's behavior.
#Where does MCP fit in the stack?
MCP belongs to the tools layer, alongside the CLI and the API. It gives assistants a discoverable menu of actions.
#What is the difference between MCP, the CLI and the API?
The API is the raw contract, the CLI wraps it with guards such as --dry-run and --confirm, and MCP offers a menu that an AI assistant can discover and call.
#Can MCP create a campaign on FirstSales?
We did not confirm a tool that creates one. Use firstsales campaigns create, then use MCP to edit and watch.
#Why start with send infrastructure and oversight?
Damage in those layers is the hardest to undo. Broken authentication and no kill switch can cost you a domain.
#What spam rate should I stay under?
Google tells bulk senders to stay under 0.1% and never reach 0.3% user-reported spam. Treat those as targets for smaller senders too.
#What sender rules apply at 5,000 emails a day?
Google describes bulk senders at about 5,000 messages a day to personal Gmail, and Microsoft's Outlook requirements apply above 5,000 emails a day. Both expect SPF, DKIM and DMARC.
#Does CAN-SPAM apply to B2B cold email?
Yes. The FTC guide has no business-to-business exception, and penalties can reach $53,088 per violating email.
#How do I test the data layer?
Sample twenty records and verify every field by hand. The error rate in that sample predicts the error rate in your emails.
#How do I test the brain layer?
Build an eval set of real cases and compare prompt versions against it. Review drafts by hand while the set is small.
#How do I test the tools layer?
List every tool, tier it by risk and confirm that someone can explain each one. Compare the live list with your saved copy each month.
#What does human oversight include?
Approvals before launch, monitoring during a run, reply handling and a kill switch. It also includes legal review of AI-written claims.
#Should the agent start campaigns?
No. Starting is a person's decision, run in the CLI after campaigns readiness and campaigns send-test-email.
#Do I need all five layers on day one?
You need a basic version of each, with send infrastructure and oversight first. Strengthen the weakest layer as you learn.
#How often should I re-score the stack?
Quarterly, and after major changes such as a new model, a new tool or a jump in volume.
#Is a copilot a different stack from an AI worker?
It uses the same layers, but a copilot suggests while a worker acts across several of them. The more layers the agent owns, the more oversight it needs.
#What is the first step this week?
Score each layer from one to five with evidence, find the lowest and fix it before adding anything new.
#Conclusion
An AI outbound agent is five layers working together: data, brain, tools, send infrastructure and human oversight. Results rise and fall with the weakest layer, and the weakest layer is rarely the model.
Keep these points in view. Diagnose by layer, build send infrastructure and oversight first, keep the tool menu short and tiered, and make sure a person can stop the system in under a minute.
Your next step is a scoring session. Put the five layers on a page, give each a number with evidence and fix the lowest score before you add another tool.
Continue with guardrails for email-sending agents for layer five in depth, or which tools an agent should get for layer three. If you want the basics of the protocol again, what MCP is is the place to start.