TL;DR: A single AI agent asked to research a prospect and then write the email tends to skip the research step under time pressure and write a generic email that sounds personalized. Splitting the job into a research agent that only gathers facts and a writing agent that only drafts from those facts, with a hard gate between them, produces sharper email and makes failures easy to diagnose.

#Table of contents

• The one-agent setup and why it seems fine at first
• What actually goes wrong inside a single agent
• The core problem: research and writing want different behavior
• What a split pipeline looks like
• The handoff contract between the two agents
• Where the split still breaks
• What the split costs you
• One agent vs two agents, side by side
• When one agent is genuinely fine
• How FirstSales structures this split
• Building this yourself
• FAQ
• Conclusion

#The one-agent setup and why it seems fine at first

Most AI SDR tools ship one agent per prospect.

You give it a name, a company, and a prompt.

It goes and looks something up, then writes an email in the same turn.

This looks efficient on a demo call.

One API call in, one email out, and the transcript reads like a person doing careful homework before writing.

The problem shows up at volume, not on the demo.

At 50 prospects a day, the agent starts cutting corners nobody told it to cut.

It reads the homepage, skims one LinkedIn post, and calls that enough context to write a "personalized" line.

Reply rates on this kind of output tend to sit in the 1-3% range that generic sends get, even though every email technically references something true about the company.

#What actually goes wrong inside a single agent

A single agent juggling research and writing is really doing two jobs with one attention budget.

Research is an open-ended task with no natural stopping point.

You can always check one more page, one more filing, one more recent post.

Writing is a closed task with a clear finish line: five sentences and a send button.

When one model has to do both in a single pass, the closed task wins.

Models are trained to produce a complete, well-formed answer, and a finished email looks complete even when the research behind it is thin.

There is no internal signal telling the model "you stopped researching too early," because the email it produces reads fine on its own.

This is not a prompting failure you can fix with a longer system prompt.

Prompt engineers commonly tell one model to "research thoroughly, then write a compelling email," and the model still cuts research short because nothing in that prompt actually blocks it from writing before the research is done.

The instruction to research and the instruction to write compete for the same context window and the same generation pass, and writing is the part with a visible reward.

#The core problem: research and writing want different behavior

Good research behavior looks almost the opposite of good writing behavior.

Research rewards breadth: checking multiple sources, tolerating dead ends, and being willing to conclude "there is nothing usable here" instead of forcing a fact.

Writing rewards narrowness: picking the one strongest fact, cutting everything else, and committing to a short, confident line.

An agent optimized to write well under time pressure will naturally under-invest in the open-ended research step, because research has no visible payoff inside that single generation.

You can see the same failure mode in AI SDR post-mortems that trace a bad campaign back to one root cause: the model treated "found something" and "found something worth using" as the same event.

A prompt drift issue compounds this over weeks.

As the single-agent prompt gets patched to fix one bad output, the research and writing instructions get longer and more entangled, and the model has even less room to actually do either job well.

#What a split pipeline looks like

The fix is structural, not a better prompt.

Run two agents with two separate jobs and a real boundary between them.

The research agent's only output is a small set of structured facts: a specific event, a specific number, a specific quote, each with a source and a timestamp.

It never sees the word "email."

Its only success criterion is fact quality, and it is allowed to return nothing if the prospect has no usable signal.

The writing agent never touches raw sources.

It only receives the structured fact packet from the research agent, plus the offer and the sequence step.

Its only job is to turn that packet into a short email, and if the packet is empty, it either falls back to a generic but honest template or the prospect gets skipped entirely.

This split maps almost exactly onto the distinction between AI SDRs and AI copilots: a research agent behaves like an information worker with a narrow scope, and a writing agent behaves like a drafting tool that trusts its inputs completely.

#The handoff contract between the two agents

The split only works if the handoff between the two agents is a strict contract, not a loose summary.

A weak handoff, where the research agent just passes along "some notes about the company," reintroduces the same ambiguity that broke the single-agent setup.

A strong handoff looks like a small, typed object: fact text, source URL, date found, and a category tag such as funding, hiring, or product launch.

The writing agent is not allowed to add facts that are not in that object.

It also should not be allowed to soften or generalize a fact past what the source actually said, since that is exactly the pattern prospects use to spot AI-written emails.

If the research agent returns an empty packet, the pipeline needs an explicit branch, not a silent fallback to invented detail.

Some teams route empty-packet prospects to a lower-effort generic sequence.

Others just skip them for that cycle and retry with fresh research later, which usually avoids sending an email built on decayed, stale data that was accurate weeks earlier and is no longer true.

Teams that skip this branch entirely tend to end up in the same place as any human-in-the-loop cold email process that removes the human check: quality drifts down slowly enough that nobody notices until reply rates already show it.

#Where the split still breaks

Splitting the pipeline does not remove every failure mode, and it is worth naming where it still goes wrong.

The most common one is a research agent that finds a fact but mischaracterizes it, and the writing agent has no way to catch that because it trusts the packet by design.

A second failure is timing: if research runs once and gets cached for weeks, the writing agent will confidently reference an event that is no longer current, which reads worse than no personalization at all.

A third is over-narrow research scope, where the research agent is told to check exactly one source and returns a technically true but weak fact just to satisfy its own completion signal.

None of these are arguments against splitting the pipeline.

They are arguments for putting a quality gate on the research agent's output before it ever reaches the writing agent, the same way you would gate any input with an automated pre-send check before a message leaves the system.

#What the split costs you

Two agents is not free.

Every extra network call adds latency, and a research call that waits on a slow page load or a rate-limited API can add several seconds per prospect before the writing agent even starts.

At a few hundred prospects a day that is a manageable queue.

At a few thousand, it becomes a real infrastructure question, and teams end up batching research overnight so the writing agent always has a fresh packet ready when a sequence step fires.

There is also a coordination cost that a single agent never has to deal with.

Someone has to own the schema for the fact packet, version it when the writing agent's needs change, and make sure both agents agree on what a "usable" fact looks like.

Skipping that ownership is how teams end up with a research agent that returns a format the writing agent was never updated to parse, which silently produces empty or malformed emails instead of an obvious error.

None of this outweighs the reply-rate cost of sending on thin research once you are past a few dozen prospects a day, but it is worth budgeting for rather than treating the split as a free upgrade.

The honest comparison is not "one agent, zero overhead" against "two agents, extra overhead."

It is one agent with a hidden overhead of bad output you discover late, against two agents with a visible overhead of latency and schema maintenance you can plan for up front.

#One agent vs two agents, side by side

#When one agent is genuinely fine

None of this means every workflow needs two agents.

For a short list of ten or twenty highly researched target accounts, a human doing the research and a single AI pass for the draft works fine, because the human is the actual research agent in that setup.

Single-agent pipelines also hold up reasonably well when the "research" step is really just a lookup against structured data you already trust, like a CRM field or a firmographic database, rather than open-ended web research.

The split earns its complexity at volume, specifically once you are running enough prospects per day that nobody is manually checking each research step before the email goes out.

That is also roughly the volume where account tiering starts to matter, since your top tier can justify a slower, more expensive research pass while a lower tier runs a lighter version of the same split.

#How FirstSales structures this split

FirstSales runs research and drafting as separate steps rather than one combined generation, specifically so a thin research result cannot get papered over by a confident-sounding email.

Every draft still goes through human review before it sends, which catches the cases where the research agent's fact was accurate but the writing agent's phrasing of it landed oddly.

FirstSales draft approval screen showing an AI-drafted email pending human review

That review screen is also where the research-to-writing handoff becomes visible to a human for the first time, since the fact the email is built on sits right next to the draft line that uses it.

Teams that skip this review step and let a single combined agent send directly tend to rediscover the failure mode described above, usually after a batch of emails that all reference the same generic "I noticed your company is growing" line.

#Building this yourself

If you are building this pipeline in-house rather than buying it, the practical steps are straightforward even without special tooling.

Give the research agent a narrow output schema and reject any output that does not match it, rather than trusting free text.

Cap the research agent's job to a small number of sources per prospect, but require it to actually check all of them before returning, instead of stopping at the first hit.

Log every fact packet with a timestamp so you can measure, later, how often the writing agent is working from research older than a week.

This is roughly the internal architecture FirstSales uses for signal-based prospecting, where a research step surfaces a specific trigger and a separate drafting step is the only thing that ever sees the prospect's inbox.

Run an outbound AI eval set against a fixed batch of prospects any time you change either agent's prompt, so a fix to the writing agent does not silently break the research handoff.

Finally, treat "no usable fact found" as a normal, expected output from the research agent rather than a failure state, since forcing a fact where none exists is the exact behavior you are trying to eliminate.

#FAQ

#Does splitting research and writing into two agents cost more than one agent?

Not usually.

Two smaller, focused calls are often cheaper in total tokens than one call juggling a long combined prompt, because each agent's context stays narrow.

#Can the same underlying model power both agents?

Yes.

The split is about role and prompt boundaries, not about using two different model providers, though some teams do use a cheaper model for research and a stronger one for the final draft.

#What should the research agent do when it finds nothing usable?

It should return an explicit empty result rather than a weak fact, so the pipeline can route that prospect to a fallback sequence or skip it for that cycle.

#How is this different from just writing a longer prompt?

A longer prompt still asks one model to do both jobs in one pass, so the same time-pressure trade-off happens inside that single generation, just with more instructions to ignore.

#Does this fix the personalization creepiness problem too?

Partly.

A cleaner handoff makes it easier to check whether a fact crosses into being unsettling before it reaches the email, which connects to the broader question of the personalization creepiness line.

#What format should the handoff between agents use?

A small structured object works best: the fact, its source, the date it was found, and a category tag, rather than a paragraph of loose notes.

#Should the writing agent ever be allowed to add outside knowledge?

No.

If it can pull in facts the research agent did not surface, you lose the main benefit of the split, which is a traceable path from source to sentence.

#Does this approach work for follow-up emails too, not just the first touch?

Yes, and it matters more there, since a follow-up that references a fact from three weeks ago needs the research agent to re-check whether that fact is still current.

#How do you catch a research agent that mischaracterizes a fact?

A spot-check sample of packets against their sources, reviewed weekly, catches this faster than waiting for reply rates to drop.

#Is a single agent ever more accurate than a split pipeline?

For very short, well-scoped tasks with one clear source, yes, since there is less room for the research step to drift.

#What is the biggest sign your single agent needs to be split?

A pattern where multiple prospects get emails that reference different companies but sound structurally identical, which usually means the writing step is compensating for thin research.

#Does the research agent need internet access, or can it work from a CRM?

Either, depending on what "research" means for your ICP.

A CRM-only research agent is simpler and faster, but it can only surface what is already in the CRM.

#How long should the research agent spend per prospect?

Enough to check every source in its assigned list, generally a small number of specific pages rather than an open-ended crawl.

#Can you run the writing agent without any research agent at all?

Yes, but then you are writing generic email, which is fine for a small top-of-funnel batch and a poor fit for anything claiming to be personalized.

#What happens if the two agents disagree on what a fact means?

They cannot disagree in a well-built pipeline, because the writing agent only sees the research agent's structured output, not the raw source.

#Does this split reduce hallucinated details in emails?

It reduces one specific kind: the writing agent inventing or exaggerating a fact, since it has no path to information outside the packet it was given.

#Is this pattern specific to cold email, or does it apply elsewhere?

It applies anywhere an AI system does open-ended research and then produces a short, confident output, including pre-call research for sales calls.

#How do you know if your current single-agent setup is actually failing?

Pull ten recent drafts and check whether the "personalized" line in each one is genuinely specific or a paraphrase of something on the homepage anyone could have written.

#Should the research agent write anything in natural language at all?

A short human-readable note alongside the structured fields helps a reviewer sanity-check it quickly, but the writing agent should still consume the structured fields, not the note.

#Does adding a research agent slow down send volume?

It adds latency per prospect, usually seconds, which matters far less than the reply-rate cost of sending on thin research at scale.

#Conclusion

A single AI agent doing research and writing in one pass will, over enough volume, quietly cut the research step short because writing is the part with a visible finish line.

Splitting the job into a research agent with its own narrow success criteria and a writing agent that only trusts a structured fact packet fixes that failure mode and makes every bad email traceable to a specific step.

The split costs a little more latency and a bit more pipeline complexity, and it earns that cost back the moment you are sending at a volume nobody can manually check line by line.

If your current setup is one agent doing both jobs, the fastest diagnostic is pulling ten recent drafts and checking whether the personalization is actually specific, or just confident.