What you'll be able to do after this guide: design the outreach stages as a set of queues defined by CRM fields, decide which agent owns each field, and avoid the most common way multi-agent pipelines break.
Each outreach agent finds its work by filtering CRM fields, and finishes by changing them. A company at Review with a blank connection status is waiting for a first touch. A person at Connected with no message date is waiting for a message. Nothing else connects the agents.
| Stage | Picks up | Does | Leaves behind |
|---|---|---|---|
| 3 First touch | Review companies whose contact has a profile URL and a blank connection status | Creates a short first-touch task (for example "send a connection request") for a person; on the next run, reconciles the tasks they completed | Once the person confirms: connection status Request Sent, and the date the request was made |
| 4 Acceptance check | People at Request Sent | Compares them with a connections export a person downloads from the platform, for example weekly | Connection status Connected |
| 5 Message | People at Connected, company at Review or Contacted, outside cooldown | Runs every safety gate, drafts the message for a person to send | After the send is confirmed: last message date, company Contacted, deal moved to Contacted |
| 6 Email task | Request still pending after 7 days; routed to the first channel but untouched for 7 days; or no way to reach them on the first channel | Creates one email task with the draft | A task, and a marker note so the same contact is never tasked twice |
| 7 Deal sync | People messaged in the last 3 days | Reads replies that reach the CRM (synced emails, and social replies a person logs); a genuine reply becomes a deal | A deal at the right stage and a comment summarising the reply |
Several of these stages involve a social platform. Most platforms' terms don't allow bots to connect, message or collect data, so in this design the agents never act on, or read from, the platform directly. Instead:
Agents choose who, run the checks and prepare the words, then create a task for a person.
The person does the action on the platform and completes the task, adding a short note if anything was different (for example, "they'd already replied").
The next run reconciles: it writes dates and statuses only for actions the person confirmed.
Acceptances come from a connections export the person downloads, and replies reach the CRM through synced email or a note the person adds.
The agents still do the slow work (selection, research, safety checks and drafting). The person spends a few minutes on the actions.
Every field that acts as a queue or a clock must have exactly one meaning, and ideally one agent that writes it. Write a simple ownership table and put it in every outreach spec:
| Field | Meaning | Written by | Never written by |
|---|---|---|---|
| connection_status | What happened on the social channel | Stages 3 and 4 | Stages 5, 6, 7 |
| connection_requested_at | When the request was first sent | Stage 3, once | Everyone else |
| last_touch_date | When we last interacted in any light way | Stages 3, 4 and 5, after a person confirms the action | Stages 6 and 7 |
| last_message_date | When we last sent a direct message | Stage 5, after a confirmed send | Stages 4, 6, 7 |
| prospect_status: Contacted | A conversation exists | Stages 5 and 7, or a person after sending an email task | Stage 6 (an email task isn't a conversation) |
| Deal stage Contacted | First message sent | Stage 5 only | Stage 7 |
| Deal stages Responded to Proposal | Mapped from the real reply | Stage 7 only | Stage 5 |
Our email task agent used to time its seven-day wait from a general "last touch" date. That worked while only the first-touch agent wrote the field. Then we added a weekly re-engagement step for pending prospects to the acceptance check, and it updated the same date. Every re-engagement pushed the seven-day deadline back a week. A prospect who never accepted would never get an email.
The fix was a dedicated date, connection_requested_at, written once by the first-touch agent at the moment of sending and never changed. The email task agent reads only that. The general touch date now means only "when did we last touch them", which is all it can safely mean when several agents write it.
Any date that starts a countdown must be written once and never overwritten. If an agent finds the clock blank, it must skip the record and name it in the summary, not guess a date. A guessed date decides when a real person gets contacted.
When you introduce a new clock field, ship the agent that writes it first. Then backfill old records only where the old field still means the same thing. Then switch the readers over.
An agent that finds a field it doesn't understand will invent behaviour around it. Our first-touch agent once found a "messaging snoozed until" date that belonged to the message stage. It wasn't mentioned in its instructions, so it cautiously treated the field as "skip this company", and quietly shrank its own pool. The fix was one line in its spec: "This field is not yours. Never read it, never write it, never let it exclude a candidate."
Every outreach spec should have a "fields you must not write" list and a "fields you can ignore" list, each with the reason.
Before letting an upstream stage send a new kind of prospect onwards, make sure the next stage can handle it. When we let Segment B prospects into the first-touch stage, the message stage didn't yet have a Segment B version. Those prospects would have connected and then stalled: connected, never messaged, and out of the email route too. Build the downstream branch, then open the gate.
An agent that runs many times a day re-checks the same candidates every run. If a company can't be messaged for a structural reason (for example, you have no relevant page to point them to), it will be rejected again and again, filling the CRM with notes. A company-level "snoozed until" date, written by the agent that snoozes, stops this. When you clear a snooze, set it to empty, not to today: an agent filtering on "snoozed until today or later" will still skip a company snoozed until today.
Next: Safety Rules for Outreach.
