Short answer: One agent asked to do everything in lead generation will overthink the easy steps and lose the thread on the hard ones. Split the pipeline into specialised agents — source, qualify, enrich, write, deliver, report — each with a narrow instruction set and a clean handoff format. Small teams see the biggest gain, because the bottleneck is attention rather than headcount. Twin decomposes a plain-language goal into exactly this kind of sub-task graph automatically.
The monolithic agent problem
Teams typically start with one prompt: find leads matching our ICP, enrich them, write a message, and put them in the sequencing tool. It demos beautifully and then degrades. The reasons are structural, not model quality:
- Uniform reasoning depth. The same instruction set governs opening a list page and judging whether a company is a fit. Give the model enough reasoning latitude for the judgement call and it starts inventing steps on the trivial one.
- Context dilution. By step nine, the criteria from step one are competing with nine intermediate results for attention.
- Undiagnosable failure. When the run produces bad leads, there is no way to know which stage was wrong.
- All-or-nothing retries. A failure in delivery forces a re-run of sourcing, which costs money and re-scrapes data you already had.
The decomposition that works
Six agents, each with one job and one output contract:
- Sourcing agent. Given a search definition, it produces raw records from the sources you actually use — a list platform, a directory, a marketplace, a public register. It does not judge. Cheap model, high volume.
- Qualification agent. Given raw records and your ICP criteria, it returns a fit score with a one-line reason. This is the reasoning-heavy step and deserves a frontier model.
- Enrichment agent. Given qualified records, it fills the missing fields: verified email, current title, headcount band, where the operations actually sit rather than the registered headquarters.
- Signal agent. Given a company, it looks for timing evidence — a leadership change, a funding event, a new hire in the relevant function — and returns a signal with a date or nothing at all.
- Message agent. Given a record plus a signal, it writes the outreach. Constraint-heavy, low creativity: name the signal, name the fit, name the offer.
- Delivery and reporting agent. Pushes to the sequencing tool or CRM, then reports what shipped and what was rejected at each stage.
Why the handoff format matters more than the prompts
The reliability of a multi-agent system lives in its interfaces, not its instructions. Three rules:
- Every agent emits structured records, never prose. Prose handoffs are where information quietly disappears.
- Every agent may return no result for a record. Forcing an answer is how hallucinated emails and invented funding rounds enter the pipeline.
- Every stage is idempotent. Re-running the enrichment agent on the same batch must produce the same output and must not re-charge you for records already enriched.
Cost: the underrated benefit
Reasoning depth is the main cost driver. In a monolithic agent every token runs at the depth required by the hardest step. Decomposed, only qualification and message generation need a strong model. Sourcing, enrichment and delivery run on small, cheap models. For a team running a few hundred leads a week, that split is typically the difference between an unbudgeted line item and a rounding error.
There is a second saving that shows up later. When one stage breaks — a source changes its layout, a vendor changes a response shape — you fix one narrow agent, not a 400-line instruction blob you no longer fully understand.
A realistic weekly cadence for a small team
- Monday: sourcing agent runs against three saved searches, producing a few hundred raw records
- Monday afternoon: qualification agent scores them; anything below threshold is archived with its reason
- Tuesday: enrichment and signal agents run over the survivors only
- Wednesday: message agent drafts, a human reviews a sample of twenty, then delivery pushes the batch
- Friday: reporting agent posts stage-by-stage conversion so you can see which stage is leaking
Nobody on the team spends more than an hour on any of it.
The three mistakes that kill multi-agent pipelines
- Chaining on prose. If the qualification agent hands the enrichment agent a paragraph instead of a record, the pipeline will drift within a week. Structure every boundary.
- No stage-level metrics. Without per-stage pass rates you cannot tell whether your ICP is too narrow or your sourcing is too broad, and you will tune the wrong thing.
- Skipping the human sample. Reviewing twenty messages a week costs fifteen minutes and catches tone drift long before a prospect does.
A good rule: if you cannot name which agent produced a bad lead within thirty seconds of seeing it, your pipeline is not decomposed enough yet.
Where Twin fits
Twin takes a goal written in plain language and decomposes it into sub-tasks automatically, so you do not hand-build the orchestration graph. Each sub-task runs with the model and reasoning depth it actually needs, and Twin can operate the tools involved even when they have no API — a list platform, a directory, an internal back office — because its agents drive real web applications in the cloud. Runs happen on schedules or on events, they self-heal when an interface shifts, and every stage is inspectable. That is what turns a promising demo into a lead generation pipeline a small team can actually rely on.
