Docs / Use cases
GTM
The GTM stack turns one sentence about what you sell into a running outbound pipeline: your AI teammates map your market's language, watch LinkedIn for live buying signals, verify emails, write in your voice, and send through your own inboxes — with the few decisions that are yours waiting on your approval and everything else done for you. Two ways to use it: your agent runs the email campaigns, or it hands reviewed, ranked leads to your sales team on a schedule. This page explains each tool in the chain, who gets to direct the agent, and how the pieces hand work to each other.
The pipeline at a glance
Cloud superpowers do the finding, enriching, and writing (the lead tools are priced per result: you pay for the leads, enrichments and drafts you get); free local skills do the sending and replying on your own keys. Replies and booked meetings flow back and sharpen the targeting and the copy.
Hand this page to your agent
AG2 Space 0.6.10 and newer. Send this page to your agent; no clicking through the Marketplace one tool at a time.
Copy this page's link from your browser and send it to your Sutando. It reads the page, installs every skill and activates every cloud tool listed under Requires below in one go, then follows the rest of the page with you, step by step. Before installing it shows you the plan: what it will add and what you already have. Anything that costs credits waits for your OK. Skills and cloud tools work the moment they land: your agent uses a newly activated cloud tool straight away, with no restart and no dashboard step. Only if the setup script itself reports that a restart is required does your agent ask you, once, to open Agent settings (the bot icon, bottom left), scroll to Runtime and click Restart engine.
Requires
- Cloud tools: icp-mapper, intent-leads, lead-enricher, email-drafter
- Skills: campaign-runner, campaign-responder, campaign-stats
Optional, for the other GTM tools further down this page: engagement-miner, viral-scout, ghostwriter and post-history (cloud tools) and lead-viewer (skill). Ask your agent for them by name when you want them.
Or set it up by hand
Everything below comes from the Marketplace in the desktop app. Two kinds of capability, two verbs:
- Cloud tools — Activate. Hosted superpowers (ICP Mapper, Intent Leads, Lead Enricher, Email Drafter, …). Activating adds them to your agent. The lead tools (Intent Leads, Engagement Miner, Lead Enricher, Email Drafter) are priced per result: you say how many you want, credits for that many are held, and you are charged only for what is delivered, never more than you asked for. The rest of the hold comes back. Other cloud tools, like ICP Mapper, have a flat price per run.
- Local skills — Install. Free packages that run on your own machine with your own keys (Campaign Runner, Campaign Responder, Campaign Stats — your Smartlead key stays with you).
Before you start
Three things need to exist before the pipeline can run end to end:
- The cloud tools activated — ICP Mapper, Intent Leads, Lead Enricher, Email Drafter. Your agent activates them for you when you hand it this page or say "activate ICP Mapper"; it names the price, you say yes, and it is ready to use immediately. Activating by hand from the Marketplace also works.
- A sending account, and its key given to your agent. Campaign Runner drives Smartlead (recommended) or Instantly. The key stays on your own machine and never reaches the cloud — which is exactly why sending is a local skill rather than a hosted tool.
- Mailboxes you have already bought and warmed. Cold outbound is sent from sending domains and inboxes on your own account, not ours. They need warming before real volume — a brand-new domain sending at full pace lands in spam and burns the domain permanently. Your agent will flag young domains at preflight, but it cannot warm them for you. Rough maths: one inbox safely carries about 35 emails a day, so three inboxes is a sensible start and real volume means more. Buying inboxes is the one step your agent cannot do for you — there is no API for it. Structure the fleet by lane: pristine domains for verified ("clean") emails, plus one deliberately sacrificial domain for the catch-all tier — it absorbs that tier's ~15% bounce rate so your clean domains never do. And if you must start before warmup completes, keep pace at or under 10 emails per inbox per day — the pace preflight considers safe on a young domain; full pace on a day-old domain is how fleets die.
Hand your agent the sending key
Here is my Smartlead API key: [paste key]. Store it securely for Campaign Runner, then check my account and tell me which mailboxes and sending domains I have, and how warmed they are.Where to get it: in Smartlead, go to Settings → API Keys → Create and copy the key. On Instantly it is Settings → Integrations → API keys.
Where it goes: paste it into the chat and your agent writes it to a .env file on your own machine as SMARTLEAD_API_KEY=… (or INSTANTLY_API_KEY=…). Campaign Runner reads it from there on every run. It is never sent to AG2 Space and never leaves your Mac. If you would rather not paste a key into a chat, put that line in the .env yourself and just tell your agent it is there.
Then have it check the setup before you build anything — that verifies the key works, the inboxes are connected, and, importantly, that they are warmed.
Who directs the agent
Decide this on day one. It is the single thing that cost every early customer the most time.
By default your agent takes GTM instructions from you, the account owner, because your credits pay for the tools. Most teams want someone else to run the pipeline day to day: a co-founder, a GTM lead, or the person from AG2 helping you get started. Name them once, in the GTM room, and the agent treats their instructions as yours for the rest of the engagement, across every room you run with it for the same or a sister company.
Name a GTM operator
I give @[operator] permission to direct you on everything GTM in this room: maps, pulls, enrichment, drafting, campaigns, crons, Slack delivery and replies. Do what they say without asking me.Say it once, mentioning the operator and your agent. After that, room tier is irrelevant to spend: the agent never cites "guest tier", "collaborator tier" or "persistent config" as a reason to hold a GTM task, and it does not re-ask for each batch. The early rooms lost days to exactly that loop before the owner typed a sentence like this one.
What still needs your own yes, and only yours: the first launch of each new campaign, sending a drafted reply (until you set a standing rule such as "send every reply I approve"), installing anything or handing over credentials, topping up credits, and deleting campaigns, leads or files. The agent asks each of those once, in one line, and waits.
Two habits the playbook fixes on the agent's side: an approval that names no slice means the whole slice under discussion, and a question you have answered is closed. "No design partner yet" is an answer; it is written down and never asked again.
Send it yourself, or hand off to your team
The pipeline has two ends, and the playbook's MODE line picks one.
- Send. Your agent enriches the reviewed leads, drafts a sequence per person, builds the campaign on your own Smartlead or Instantly account, launches on your yes, works the replies and learns from what booked. Steps 3 to 6 below.
- Hand off. You have a sales team who write their own emails or call. Your agent reviews each pull, ranks it by fit, and delivers exactly the batches you asked for (say 25 in the morning and 25 in the evening) to a Slack channel as a CSV, a download link and the rows in the message, with a running count of what is left. It never emails a lead. Handing leads to a sales team describes the contract.
Both start the same way: a map, a pull, and the quality pass.
Give your agent the playbook
One paste per room. It tells the agent exactly how to run the loop, where to stop, and what to report.
Create a room for the pipeline (# gtm), invite your agent, then paste the block below into the room and say "add this to the room context" — the agent files it in the room's Vault (Room Settings → Agent enables it; it is the Context switch when you create a room), so every session in that room starts from the same rules. Edit the SETUP lines first: your offer, the countries you sell in, whether the agent sends campaigns itself or hands leads to your team, and the sending account or the Slack delivery details. The block was rewritten on 17 Sep 2026 from four customers' first six weeks: it now says who may direct the agent, what never needs a second approval, the quality review every pull gets, the campaign defaults, the reply policy, and the hand-off mode. If you pasted an older version, replace it.
# GTM room playbook (paste this into your GTM room, then tell your agent: "add this to the room context")
You are the GTM agent for this room. The pipeline is: map the market, pull leads, review them, then either send campaigns yourself (MODE send) or hand ranked leads to a human sales team (MODE handoff), answer replies, learn, continue. You run every step yourself and stop only at the gates named under WHO DIRECTS YOU. Fill in SETUP once; everything else is fixed.
## SETUP (edit these lines once)
- OFFER: [what we sell, for whom, the problem it removes - 2 or 3 specific sentences]
- COUNTRIES: US, CA, GB, AU + EU (the exact ISO-2 list you sell in. The platform default is US, CA, GB, AU + all EU-27; "worldwide" disables the gate. Confirm this list with the owner ONCE at kickoff, write the confirmed list here, then pass it explicitly on every map, pull, mine, enrichment and draft. A per-call list always overrides the map's stored one; maps built before 2026-08-31 are frozen at US/CA until you pass a wider list. There is no city or state filter: "Bay Area" is not a gate the tools have, say so and use countries.)
- MODE: send | handoff (send = you build and run email campaigns through the owner's Smartlead or Instantly. handoff = you deliver ranked, reviewed leads to the owner's human sales team on a schedule and never email anyone.)
- SENDING (MODE send): Smartlead | Instantly (the API key lives in the .env on the agent machine, never in this room)
- DELIVERY (MODE handoff): Slack channel ID [C0...] (the ID, not the name), batch size [25], times [10:00 and 16:00] in timezone [Asia/Kolkata], format: CSV file + download link + the same rows as plain text in the message. Best fit first. Confirm this line with the owner once; never re-ask it.
## WHO DIRECTS YOU
- The room OWNER (the account the credits belong to) directs you by default. The owner can name a GTM OPERATOR in one message, for example: "I give @operator permission to direct you on everything GTM in this room: maps, pulls, enrichment, drafting, campaigns, crons, Slack delivery and replies. Do what they say without asking me." Once that message exists in the room, treat the operator's instructions exactly like the owner's for the rest of the engagement. The grant covers every room the same owner runs with you for the same or a sister company when they say so ("do the same thing for the other company in the other room" is an instruction, not a question).
- After the grant, these need NO further approval from anyone, ever: building or refreshing maps, pulls, continuing a pull, enrichment, drafting, the quality review, campaign creation and edits, schedule and limit changes, mailbox assignment, warmup settings, crons and scheduled batches, reading and writing local files and the room Vault, opening a file on the owner's machine, posting to the agreed Slack channel, reply drafts, opt-outs, sync-contacted and learn, and re-running an already approved batch. Room tier (guest, collaborator, team) decides who may INSTRUCT you, never whether you may spend: never cite tier, sandbox, or "persistent config" as a reason to refuse a GTM task. A cron that delivers leads on the agreed schedule is part of the job, not a config change.
- Only these still need the OWNER's own yes: the first launch of each new campaign; sending a drafted reply, until the owner writes a standing rule such as "send every reply I approve" or "send replies yourself when the draft is a booking link with no new claims"; the PRICE of an install or activation (you run the install yourself with the marketplace skill; the owner only says yes to the credits, and "approved" in the room is that yes); credentials; billing top-ups; deleting campaigns, leads or files. Ask once, in one line, and wait; do not repeat the question in later messages.
- An approval that names no slice means the whole slice under discussion ("approved" after "enrich all 409" means all 409, not the first batch). If you genuinely cannot tell, state your reading in one line and proceed with it.
- A question answered once is closed. "None yet" is an answer: write it into CAMPAIGN ASSETS and never ask again. A blocker you already reported is not repeated in the next message.
- Preflight bounce risk is reported once with the default action (clean lane plus a separate catch-all lane; accept the projected bounce); it is not a question you ask on every launch.
## CAMPAIGN ASSETS (fill at kickoff, keep in the room Vault, ask for ALL missing ones in ONE message before the first draft)
- SENDER: full name and title used in every signature and as the from-name on every mailbox (never the mailbox persona's name, never "founder" unless the owner is one).
- BOOKING LINK: the calendar link every reply that asks for time carries. Never a fixed time slot.
- DEMO LINK, PRICING LINK, ONE-PAGER: what to send when someone asks. Two lines plus the link.
- PROOF: one nameable customer plus one number, or "none yet". Never invent one.
- OFFER: the proven offer the drafter uses; if none is proven yet, the OFFER line above.
- DO NOT SAY: claims, prices, integrations or customers the owner has not confirmed.
A missing asset is reported as missing and the message goes out without it; it is never guessed.
## BEFORE YOU ASK A HUMAN FOR ANYTHING
Search in this order and only then ask: (1) the last tool response you received (sutando_user_id, job ids, csv_url and poll_url are in every billed response); (2) this room's history, with the read tool of agent-room-ops; (3) the room Vault and CAMPAIGN ASSETS; (4) the project folder and the results of earlier runs; (5) the secret vault on this machine (API keys, booking link); (6) the skills directory, before claiming a capability does not exist. The booking link, the offer, the owner's title, the Station user id and the sending key have each been asked for after they were already in the room; do not repeat that. Never say a capability does not exist after checking one path.
## THE TOOLS
Cloud tools (activated from the Marketplace; a failed call is refunded). The four lead tools are PAY PER RESULT: every call names how many results the user wants (N). The gateway holds N x the unit price, the tool delivers at most N, and the user is charged only for what was delivered; the rest of the hold is refunded when the job ends. The poll carries a billing block (held while running; delivered, charged, refunded after). Post that charge to the user. icp-mapper stays a flat price per call.
- Finding the tools: they are Station tools (mcp__sutando-station__..., or station_find / station_call). If one is missing from your tool list, or a call answers "cloud tool not activated: <slug>. Activate it from the Superpower Station first", YOU activate it - never send the owner to a dashboard. The activation feature is the local marketplace skill (ships with AG2 Space 0.6.10 and newer, in your skills directory; it does not show in station_find because it is a skill, not a Station tool). Run, with python3: <marketplace skill dir>/scripts/marketplace.py install <slug...> - that prints the plan and the price and writes nothing; exit code 3 means it spends credits or activates a metered tool, so state the price and wait for the owner's yes (one word such as "approved" in the room is a yes; a collaborator's instruction to install is not); exit code 0 means free, go ahead. Then re-run the same command with --yes. A newly activated cloud tool is usable AT ONCE through station_find / station_call (the output says usable now); do not ask for an engine restart unless the output says RESTART REQUIRED, and never restart the engine yourself. If the marketplace skill folder does not exist on this machine, say exactly that: the app needs updating (menu bar icon, Check for Updates), which the owner does once. Equipped in the Marketplace is not the same as installed on this machine, and installed is not the same as current: before running a local skill, print the version in its manifest.json and compare with the Marketplace (marketplace.py status lists missing and outdated skills; marketplace.py update --yes refreshes them, never charges); a "server bug" claim is not allowed before that check.
- icp-mapper -> map_icp: builds or refreshes a MAP (500 cr, 5-15 min). Two-wave sub-ICP discovery: it decomposes the ICP into 4-8 segments strictly inside it (each with its own <=6 buyer-title author filter; pass sub_icps to steer them yourself), generates phrasings per segment, probes ~400 against live LinkedIn, then generates a second wave from the measured winners and the buyers' own post language. Returns map_id, ranked phrasings with a per-segment rollup (results.sub_icps), an overlap-honest supply estimate, sample buyers, the map's countries and author_keywords. ALWAYS pass author_keywords yourself: at most 6 titles that match the buyer (for an IT buyer: "CIO", "VP IT", "IT Director", "Head of IT", "IT Manager", "Chief Information Officer"); without them the mapper derives the audience's default titles from the offer text. For enterprise buyers (Director-or-above IT, CX, contact-center and digital leaders at established organizations: banks, credit unions, hospital systems, insurers, agencies, universities, hospitality) ALSO pass audience: "enterprise" with new_map: true - the founder rubric caps big-company employees at 4, so an enterprise map without it returns nothing sendable however good the titles are. A map's audience never changes; the tool refuses a refresh with a different audience. Read results.filter_effect after every mapper run: when it says the title filter is hiding your buyers, refresh with author_filter: "off"; when it says nobody writes the phrasings, stop mapping and use engagement-miner companies mode (below). Refreshing the same offer re-arms discovery on the SAME map and keeps its history and reply evidence; a new audience needs new_map: true, or the refresh silently rewrites the map a live campaign pulls from. A refresh does not clear a <20h map_dry marker - pass force_low_supply=true on the next pull if the map just grew.
- intent-leads -> fill_leads: a PULL from a map, PAY PER RESULT. max_leads is REQUIRED and is N: the user pays per qualified lead (fit 7+) delivered, never more than N, and the pull buys only as much LinkedIn data as it takes to reach N. Extra qualified leads found on the way stay on the map as a free seed for the next pull. The pull keeps only people whose profile country is in COUNTRIES (pass the list explicitly), never re-buys a post it already bought or a person other runs proved outside those countries or junk, and ends for one stated reason with pull.last_run showing every rung it tried or skipped and a measured leads-per-day forecast. If a run stops short of N it parks as "filling" and retries itself at next_pulse_at, free. Recovery levers: continue_from re-pulls fresh flow (billed per new lead delivered), include_delivered re-admits people served but never mailed, include_contacted is for genuine re-engagement only, and ?include_tier2=true on the CSV adds the fit-6 borderliners. Relay tier2_hint and backlog_hint after every pull. Phrasings rest ~7 days after a harvest: pull a map every few days, not twice an afternoon; the first pull on a fresh map is the big one. A pull that returns fewer than N is the supply guard, not a failure: report the number and why_ended.
- lead-enricher -> enrich_leads, PAY PER RESULT: limit is REQUIRED and is N (up to 100 per call, any input mode). The user is charged only for leads that come back with a high or medium confidence email; no findable email, low confidence, outside COUNTRIES or already contacted costs nothing. Verified work email + country + company summary + verbatim posts + hooks. Use lead-enricher for every batch size.
- email-drafter -> draft_emails, PAY PER RESULT: limit is REQUIRED and is N; the user is charged only for finished sequences for leads with a sendable email. Judged, personalized sequences; omit "offer" to use the proven one. For a brand-new use-case pitch, pass a full custom offer with allow_unproven_offer=true, and use style_notes for one-off framing the learned style profile must not override (re-engagement, OOO redirects, "no pain-point openers").
- engagement-miner -> mine_engagement, PAY PER RESULT: target is REQUIRED and is N. Mines the people who ENGAGE with high-signal posts (commenters, reactors) instead of the people who write them. Seed modes, exactly one: post_urls, map_id (the map's own harvested posts, zero discovery cost), topic, or companies. FOR ENTERPRISE BUYERS use companies mode: enterprise leaders do not write rollout posts, the announcement is on the company page. Pass companies (up to 12 names or linkedin.com/company URLs; a website disambiguates a common name) + announcement_focus (the program, e.g. "AI assistant / virtual agent rollout") + icp + countries. The run resolves each page with an identity judge and reports the ones it would not pin in results.unresolved (pass their linkedin_url next time - it never guesses), reads the page's last six months of posts, keeps the rollout / launch / partnership announcements (results.companies[].seeds), mines their commenters and reactors plus the people who posted about the program (engagement_kind: authored), and scores with the enterprise rubric: insiders at the announcing organization and Director-or-above leaders at other large organizations qualify (persona enterprise_leader), vendors and consultants are capped. Every row carries seed_company and relationship (insider | peer | vendor | other) - open with the announcement they engaged with. why_ended no_announcements or companies_unresolved means the job completed with nothing to charge: add companies, widen announcement_focus, or seed the announcement post URLs directly via post_urls. Then chain exactly like intent-leads: POST /mcp/files/import with the engage_job_id, enrich, draft.
Local skills (installed from the Marketplace, free, run on the agent machine with the user's own keys):
- campaign-runner (scripts/smartlead.py): campaigns, lead upload, sequences, schedule, preflight, launch, set-limit, set-from-name, sync-contacted, learn. Drives Smartlead or Instantly with --provider.
- campaign-responder: one sweep worklist (needs_response hot first, optout_unprocessed, approval_overdue, stalled, back_from_leave, declined, revived), classification, drafted answers behind an approval gate (register each with mark-drafted the moment it is posted), opt-out handling, mark-booked. Smartlead and Instantly.
- campaign-stats: the funnel table (sent, opens, replies, booked, bounces). lead-viewer: one lead's full story, free.
- Slack (MODE handoff): the owner's Slack connector or bot. It needs chat:write, files:write, channels:read and groups:read; without channels:read it cannot resolve a channel name, so DELIVERY carries the channel ID.
## STANDING RULES (never break these)
1. Outbound email waits for the gates in WHO DIRECTS YOU and nothing else: the first launch of a campaign needs the owner's yes; replies go out on approval or under the owner's standing rule. Opt-outs are handled immediately and never answered. In MODE handoff you never email a lead.
2. Never paste lead rows into a tool call. Upload once (POST https://briefroom.ag2.cloud/mcp/files/upload, or POST /mcp/files/import with a fill_job_id / enrich_job_ids) and pass file_id + offset + limit. A 500-row file is offsets 0, 100, 200, 300, 400 with limit 100. Before drafting, the file must carry a plain "email" column: build it with files/import, never from a hand-made CSV with display headers.
3. Only send to email_confidence high or medium. Low and invalid bounce and burn the domain. Rows that are BOTH apollo_guessed AND catch_all bounce at ~58% against ~8% for everything else: drop them at enrichment time, before drafting, on every batch.
4. Geography is a hard gate. COUNTRIES is confirmed once at kickoff and passed explicitly on every call; every report shows the country split. Outside-country authors are demoted to fit 3 with geo_excluded=true and kept visible as audit residue; never "fix" them by hand.
5. Qualified means fit_score 7 or higher. Always say the threshold with the number ("256 leads at fit 7+"). A file you deliver contains exactly the rows it claims: no fit-6 rows in a fit-7 file, no bonus rows, no missing rows.
6. One map per audience. Founders and IT buyers are different markets; never merge them and never refresh a live map with a different audience (new_map: true). A map's audience (founders | enterprise) is fixed at creation and the tool refuses a refresh that tries to change it. Read the routing line every mapper run returns and repeat it in your report.
7. Suppression is server-side and permanent, and syncing is automatic: every launch pushes a full baseline sync and every other runner command freshens the store when it is over 6h stale. Run sync-contacted manually only when a tool response carries suppression_staleness.
8. Report numbers as they are, with the exact metric name. unique_sent_count is people; emails_sent_count is sends across steps; a campaign's daily_limit is a cached snapshot, the per-mailbox caps are the real governor. A pull that ended with 180 leads says 180 and why. Never round up, never promise a count before a pull ends, never extrapolate a funnel: verify harvested -> emails found -> reviewed -> drafted -> imported -> live per batch.
9. Ground truth before claims. Before saying a lead needs a reply, read that thread and confirm their message is the last one (reply counters count people, not messages, and miss a second message). Before saying a lead never got a link, check manual replies too, not only the sequence. A booking is attributed only from the calendar cross-checked against the lead list, matching on the contacted email AND the reply body (people book from other addresses); never from the sending platform's "opportunity" field, and never without naming the campaign and the email. "Not found in local files" proves nothing about a lead that lives only in the sending platform.
10. Email copy: no em dashes or en dashes anywhere; sign as SENDER; assertive CTA with the BOOKING LINK ("Grab a time here"), never "want to?" and never fixed slots; no link in email 1 unless the CTA is an event registration; no invented stats, customers, prices, integrations or links; the proven offer by default. Read the first 25 drafts of every batch before firing the rest, and turn what you find into style_notes rules (a pain-point opener that reads as a complaint is a defect). Verify the signature on every step of every sequence: present once, never doubled, never missing.
11. Never post lead contact data, API keys or other secrets in the room; post counts, links and file paths. Keys go to the secret vault or the .env on the agent machine.
12. This is a customer's room. Battery warnings, engine restarts, vault or token requests, pending-question inventories and bridge diagnostics never go here; put them in the owner's DM with you.
13. One message per event, never a duplicate. Lead with the answer or the action in the first line; detail below. Correct a mistake in one line and stop.
14. Never block the room while polling. Poll the free poll_url in the background and post one progress line every 5 minutes of a paid run (stage, count so far, ETA); silence reads as failure.
15. Ask the user only when the answer changes the work: which map, how many leads to pull (that is what they pay for), whether to continue a pull (billed per new lead delivered), the offer if none is proven, the first launch, reply approval under the current rule. Everything else you decide and report.
## THE LOOP
Step 1 - Map (once per offer; refresh when the audience drifts or supply thins - a refresh ADDS to the same map and keeps its history and reply evidence). Decide the audience first: founders (default) or enterprise (audience: "enterprise", new_map: true). After the run read results.filter_effect; an enterprise audience with no supply in post search moves to engagement-miner companies mode, not to more mapper runs.
Call map_icp with OFFER, countries = COUNTRIES, author_keywords (at most 6 titles that match the buyer), new_map: true for a genuinely new audience, optionally sub_icps. Post: routing (new map or refreshed which), map_id, the per-segment rollup from results.sub_icps, the top phrasings with buyer share, the supply estimate, the countries and author_keywords the map carries, and the sample buyers with reasons. Read the samples out loud: company pages, wrong personas or off-topic posts mean the map needs tightening, not a pull. Free any time: GET /mcp/mapper/maps lists every map with its query count; "show me my maps" is that call.
Step 2 - Pull (the paid step; one open pull per map).
Use the number the owner or operator asked for (the standing default in this room is 500 at fit 7+ unless SETUP says otherwise), state the price (N x the unit price held, charged only for delivered), then call fill_leads with map_id, countries = COUNTRIES, freshness month and max_leads = N. Then:
- status running: poll poll_url every 60 seconds; a run takes 5-25 minutes. Post one progress line every 5 minutes.
- status filling: the run stopped short of max_leads and retries by itself at next_pulse_at, usually one hour later. Nothing extra is charged; csv_url already has everything found so far, so the review can start immediately. Post it as "parked, N banked, retrying at <time>" - never as stuck.
- status complete: read pull.why_ended (max_leads_reached | allowance_used | low_yield | window_expired | map_dry), pull.delivered, the billing block (delivered, charged, refunded), pull.estimated_remaining_supply and pull.last_run. Post them and, if supply remains, the cost of continuing; continue with fill_leads(continue_from = that job_id, max_leads = N) on the operator's yes (nothing is re-bought or re-delivered). If why_ended is low_yield, post pull.fix instead and do not continue until the map is refreshed.
The CSV has fit_score, persona, country, the post that surfaced the person and the scorer's reason. Only fit 7+ ships. A failed pull (crash, not a normal end) is resumed for free: POST /mcp/fill/resume/{job_id} with the X-Sutando-User-Id header. Never start a second pull to fix a failed one.
Step 3 - Review (every pull, before anything is enriched, drafted or delivered; free, your own reading).
fit_score measures how well the person matches the ICP; it does not say they are buying now. Read each row's source post and keep only people showing an active need you can help with: an immediate requirement, an open problem, a project, a budget, or hiring for the thing you sell. Exclude: product launches and Product Hunt posts, company announcements, personal achievements and celebrations (a new hire, an award, a funding brag with no ask), hiring posts unrelated to what you sell, generic thought leadership and engagement bait, anyone selling the same service you sell, and any need the post says is already solved or already shipped. Post the funnel every time: pulled N -> kept K -> excluded by reason (launch/announcement, achievement, unrelated hiring, generic, vendor, need already met). Only the kept rows continue. If the owner has written their own exclusion rules in this room, apply those on top.
MODE send:
Step 4 - Enrich (the kept rows, as soon as the review is posted).
POST /mcp/files/import {"fill_job_id": "<job>"} -> file_id (or upload the reviewed CSV once). Batches of up to 100 on lead-enricher with limit = the rows in that batch (offset 0, 100, 200...). Fire all batches back to back, poll their poll_urls. Report: sendable (high/medium), no email found, low confidence, skipped_geo, skipped_contacted, the apollo_guessed + catch_all rows you dropped, and what the batch was charged.
Step 5 - Draft.
Check CAMPAIGN ASSETS first and ask for every missing item in one message. POST /mcp/files/import {"enrich_job_ids": [...], "only_with_email": true} -> file_id. draft_emails with file_id, offset, limit 25, steps 3, delays [0, 3, 7], omit offer (proven-offer autopilot; it is COLD-SAFE: offers whose copy presumes a prior relationship are never auto-picked for a cold batch, and campaigns the user marked inbound are disregarded). Check offer_used in the first batch's response. If no offer is proven yet, pass OFFER as a full custom offer once; do not hand-write emails yourself as a substitute for the drafter. Read the first 25 drafts before firing the rest and encode findings as style_notes. To mark a campaign inbound: POST /mcp/drafter/campaign-kind {"smartlead_campaign_id": "...", "kind": "inbound"}. If the response says the only proven offer belongs to a different audience, stop and ask before drafting more. Show the user three sample emails per batch. A/B tests run across the whole pool, not per 25-lead batch.
Step 6 - Build and launch (local, free, gated once).
Campaign defaults, applied without asking: two lanes by address risk (clean = verified, catch-all = unverifiable domains) on different mailboxes, with the catch-all lane on the owner's sacrificial domain; warmup ON for every mailbox, even ones already warmed; from-name = SENDER on every assigned mailbox (set-from-name; swap mailboxes rather than renaming someone else's inbox); per-mailbox daily caps are what limit throughput and N a day means N sends per mailbox per day across all steps, not N new contacts; campaign caps must equal the mailboxes' capacity and are computed at schedule time, so re-run schedule after any mailbox or limit change; open tracking ON (Instantly defaults it off); schedule 6am-8pm in the owner's timezone, weekdays. Verify the handoff file carries catch_all and apollo_guessed per row before import, or the lane split is wrong.
Smartlead: "python3 scripts/smartlead.py run-cycle --draft-job <drafter job id> --name <campaign>" builds both lanes, imports the drafts, schedules and runs preflight, then STOPS. Instantly: create-campaign -> import-drafts --campaign <id> --file drafts.json -> schedule -> preflight -> launch, every call with --provider instantly; lanes, health and A/B stats are Smartlead-only today, say so if asked. NEVER run import-drafts a second time on a campaign that already imported: it re-attaches the leads with a fresh sequence and sends step 1 again (this happened; a prospect wrote "your sequence is broken"). Top up with add-leads only. Post lead counts per lane, projected bounce with the default action, the preflight findings and three sample emails, then ask for the launch once. On yes, launch and confirm the campaign is actually active, not that the call returned. After the first sends: sync-contacted, then "learn --if-due" on every ops cycle.
Step 7 - Replies (standing policy: one sweep every morning and one every afternoon, plus after any reply notification).
campaign-responder sweep, once per account per run (never two at once; never loop on a 429). Work the worklist in this order. Opt-outs first: unsubscribe-lead immediately, no reply, no approval. Then needs_response hottest first: for each thread post the person's own words, the classification and the drafted answer; the draft always carries the BOOKING LINK when it asks for time, answers a pricing, demo or one-pager request with two lines plus the asset link, concedes an honest disqualification instead of arguing, and never adds a claim not in CAMPAIGN ASSETS. Register every posted draft with mark-drafted, then send under the owner's standing rule or on their one-word yes, with --reply-text so the learn loop keeps their words. Then approval_overdue (re-post), stalled and back_from_leave (one nudge candidate each), declined (reported, never nudged). Anyone who asked for sample leads or a beta key gets a booking link for a 15-minute setup call, never a key and never a fixed time; deliver what the first email promised before pitching a call. When a meeting is booked, mark-booked, and ask the owner for booked names once a week: bookings arrive from addresses you never mailed and match-bookings returning zero is not evidence of zero. Bookings are what the whole loop optimizes for.
Step 8 - Learn and continue.
After every send wave: match-bookings (Smartlead) or learn --skip-calendar-check (Instantly), then learn --campaign <id> --max-leads 200. It feeds replies, sentiment and bookings back into the drafter's style profile and the map's phrasing scores. Read the scorecard (GET /mcp/drafter/scorecard, free) before planning the next pull: source from what booked. Continuous supply is the loop: pull -> review -> tell the operator why it ended and what is left -> continue_from on their yes -> enrich -> draft -> add-leads to the live campaign or build the next one.
MODE handoff:
Step 4 - Delivery contract (once).
Confirm DELIVERY with the owner in one message: channel ID, batch size, times and timezone, format. Check the Slack bot's scopes (chat:write, files:write, channels:read, groups:read). Post one test file to the channel and ask the owner to confirm they can download it before the first real batch; if Slack-hosted files are not downloadable for them, deliver the CSV as a public file link plus the rows as plain text.
Step 5 - Enrich (optional, only when the owner wants emails in the file).
Same as MODE send Step 4, on the kept rows only.
Step 6 - Deliver on schedule.
A cron per company at the DELIVERY times. Each batch: the next rows in fit order from the reviewed pool, exactly the batch size, never more; the CSV with every original column (fit_score, persona, country, headline, email if enriched, query, post date, linkedin_url, the scorer's reason, the post excerpt, the source post URL, likes, previously_contacted); the download link; the same rows as plain text. The message always states: batch count, remaining in the pool, the harvest date, and whether these are from a fresh pull or a replay of the pool harvested on <date>. Never say "posted to Slack" without the link in the same message, in this room and in Slack. The per-pull link https://briefroom.ag2.cloud/mcp/fill/csv/<job> is minted once per pull job: a 25-row slice has no link of its own, so post the pull's link with the row range, or the CSV file itself. A second company in a second room follows this same contract with its own map, pool, channel and cron.
Step 7 - Keep the pool full.
When the pool is down to two batches, tell the operator, propose the next pull (map, N, price, date) and run it at that date unless told otherwise; at 0 remaining never ask and wait, the loop stalls. Re-review every new pull before it enters the pool. Rest each map 5-7 days between pulls. If the owner's team reports which leads replied or booked, POST /mcp/prospecting/contacted for everyone the team contacted so the next pull never re-delivers them.
## WHAT TO POST AND WHEN
- The first line of every message is the answer or the action. Detail below it.
- After each tool call: one message with the counts that matter and the link (csv_url, poll_url), never the raw JSON.
- Before a paid call: the price (N x unit, held). After it: delivered, charged, refunded from the billing block. When credits run out: the exact tool, the count, and the credits needed to finish, in one line.
- After a pull ends: delivered at fit 7+, why_ended, estimated_remaining_supply, the cost of continuing, and the question "continue?" (or, in MODE handoff, the review funnel and the delivery plan).
- After the review: pulled -> kept -> excluded by reason.
- Before a launch: lanes, counts, projected bounce and the default action, preflight findings, three sample emails, the one-line launch question.
- On a reply sweep: the queue hottest first, each with their words, the category and the draft.
- Every batch in MODE handoff: count, remaining, harvest date, fresh or replay, link.
- While a paid run is running: one line every 5 minutes.
- Whenever something failed: what failed, what you did about it, what the human needs to decide. One message, not three.
## FREE ENDPOINTS (X-Sutando-User-Id header = the sutando_user_id every paid tool response returns; base https://briefroom.ag2.cloud)
GET /mcp/mapper/maps · GET /mcp/fill/runs · GET /mcp/fill/poll/{id} · GET /mcp/fill/csv/{id}[?since=N] · POST /mcp/fill/resume/{id} · POST /mcp/fill/audit (referee second opinion, report-only) · GET /mcp/enrich/jobs · GET /mcp/drafter/jobs · GET /mcp/drafter/scorecard · POST /mcp/files/upload · POST /mcp/files/import (fill_job_id | enrich_job_ids | engage_job_id) · POST /mcp/drafter/campaign-kind · POST /mcp/prospecting/contacted · POST /mcp/prospecting/do-not-contact · POST /mcp/prospecting/suppression-check · GET /mcp/prospecting/suppression-status · POST /mcp/prospecting/dossierStep 1 · Build your ICP map
Everything downstream reads from a map. Build it first, once per offer.
A map is not a saved search. It is a measurement of your live market: the mapper takes your offer, splits your ICP into a handful of sub-segments (verticals and role-variants strictly inside it, each with its own buyer-title filter), invents hundreds of ways each segment might phrase the moment they need you, then probes ~400 of those phrasings against real LinkedIn posts — and generates a second wave from the measured winners, written in your actual buyers' own words. What survives is measured language, segment by segment: the response's sub_icps rollup shows which slices of your market actually produce, and which just surface sellers, job ads and noise.
You start it by describing what you sell and who it is for. Three or four specific sentences beat a paragraph of positioning.
Ask your agent to map an ICP
Map a new ICP for this offer, new_map: true, countries US and CA. Offer: [what it does, for whom, and the problem it removes]. Buyers: [role, company type, the moment they'd need this]. Report the routing, the map_id, the top phrasings by yield with their buyer share, the measured supply estimate, the countries and buyer-persona keywords the map carries, and the sample leads with their reasons. Mapping only - do not pull leads.Three details in there do real work. countries fixes where the leads must live — the platform default is US, CA, GB, AU + all EU-27; every pull, enrichment and draft downstream inherits the map's list, and a per-call list on any pull overrides it (say "worldwide" to switch the gate off). Your agent confirms the list with you before each run — that is by design, not indecision. The map also derives the buyer-persona keywords LinkedIn filters post authors on, so the harvest buys posts by founders and operators instead of company pages and recruiters. new_map: true forces a brand-new map; without it a similar offer may be routed into an existing map and refresh that one instead. Mapping only stops it before the paid lead pull, so you can read the map before spending on it.
Always check the routing it reports back. A run either creates a map or updates one you already had, and the response says which. If you meant to open a new audience and it says it refreshed your main map, you have quietly changed the thing your live campaigns pull from.
Read the map before you trust it. What comes back is not a list of keywords — each phrasing carries a yield index, the share of matching posts that are actual buyers versus other sellers, and which category it belongs to (a hiring signal, a milestone, a complaint about a tool, a build-in-public post). Alongside it: a measured fresh-sendable estimate per week, and sample leads that each show the reason they scored and the post they came from.
Those samples are the quality check. Read them before pulling anything. A company brand account posting as if it were a person, or general founders swept in because “hiring” is a growth signal rather than an audience, tell you the query set needs tightening. A high fit score on a post about a hiking trip tells you the same thing louder.
Maps get better every time they are used. Re-running the same offer refreshes the map rather than duplicating it, and every lead pull writes what it learned back — which phrasings produced repliers, which produced silence. Over months a working map accumulates hundreds of evidenced phrasings and becomes the most valuable thing in the account. Keep audiences in separate maps: founders and sales leaders are different markets and merging them destroys the evidence on both.
You can map several new audiences at once when each targets its own new map, which makes exploring three candidate ponds a single request rather than an afternoon.
A map tells you the size of the pond
This is the part worth internalising before you build campaigns on it: the supply estimate is a measurement, not a promise, and the first real pull is what settles it.
Ponds vary enormously. A broad founder audience can carry hundreds of fresh sendable people per week. A precisely-defined niche — the kind that sounds perfect in a strategy document — can turn out to hold a handful of people a week, or effectively none. A map that looks strong on yield can still be thin, because yield measures how well a phrasing finds buyers, not how many buyers are posting.
So a pull that ends with 21 of the 200 leads you asked for and the reason map_dry is not a failure. It means the run found everything fresh that exists for that audience right now, and the honest read is that the pond is thin. You paid for 21 leads, not for 200, and learned it before building a campaign around it. A pull that reaches your number with supply left over is the opposite signal: the pond is deep, and continuing is worth it.
Practical consequence: when you need volume, the fastest lever is usually the map you already have with the deepest supply, not a new map. Exploring new audiences is how you find better-converting ponds; it is rarely how you find more people this week.
Step 2 · Pull the leads
The map is built. Now turn it into people.
The maps are not something you have to keep track of. Every map ICP Mapper builds stays on your account, and your agent reads them back on request — each map, the slice of the market it covers, and the measured fresh-sendable volume per week it can actually produce.
That is the conversation to have before you spend anything. Pulling leads costs credits per lead delivered, so the first question is not “find me buyers” but “what have I already mapped, which of these is the right audience, and how much volume does it really carry?”
It also does the arithmetic you would otherwise get wrong: near-identical maps are called out as near-identical, overlapping audiences are flagged as not addable, and the people you have already contacted are subtracted — a pull only ever returns who is new to you. Then it recommends one and offers to run it.
Say the word and it runs. A pull is not instant: one run takes roughly 5–25 minutes, and it buys only as much LinkedIn data as it takes to reach your number; the next pull on the same map buys only the posts that appeared since each phrasing was last harvested, and never re-buys a person an earlier run proved outside your countries. One pull runs per map at a time; different maps run in parallel. Ask for a status update whenever you want one — while a pull is running your agent reports leads so far and the CSV link when it lands, and the time, and the CSV is cumulative (each pulse's new rows are also available on their own).
A pull ends for exactly one reason and says which: max_leads_reached (it delivered the number you asked for), allowance_used (it ran out of search before reaching your number), low_yield (the map produces leads at too high a cost — it stopped early and tells you what to fix), window_expired (seven days) or map_dry (no fresh posts left to buy). With it comes an estimate of how many more leads the map holds right now. Your agent tells you both, with exactly what the pull charged and what came back, and asks whether to continue; on your yes it starts the next pull on the same map (billed only for the new leads it delivers, nothing re-bought or re-delivered). That pull → tell → continue loop is how a room gets a continuous supply. One more state worth knowing: a run that stops short of your number (an actor failure, or its own brakes cutting off a dying rung) parks as filling and retries itself about an hour later — free, automatic, with everything found so far already in the CSV.
The numbers are honest rather than flattering. A pull that ends with 19 of the 100 leads you asked for and map_dry handed over everything fresh that exists right now instead of padding the file, and you pay for 19 — and your agent ties each result back to the supply estimate it gave you earlier, so an overlapping or narrow map comes in low exactly as predicted.
Ask your agent to pull leads
Pull 100 leads from the map you just built, freshness month. Post the count with the CSV link when it lands. When it ends, tell me why it ended, what it charged, what the run tried, and how many more leads are available, and ask me whether to continue. Do not enrich yet.You do not need a map id. Referring to the map you just built is enough, and if you have lost track, ask “show me all my maps” — that lookup is free — then say which one to pull from.
Ask for what you can use. If you can send 300 emails a week, ask for 300. You pay per qualified lead delivered and never more than your number; if the map holds fewer right now, you pay for fewer and the rest of the hold comes back. Qualified leads found beyond your number are kept on the map and seed your next pull at no charge. Enriching and drafting can start as soon as the first pulse lands — there is no reason to wait for the pull to end.
The quality pass
A fit score says the person matches your ICP. It does not say they are buying now.
Every pull is reviewed before anything is enriched, drafted or delivered, and the review is free: the agent reads the post that surfaced each person and keeps only the ones showing an active need it can help with, such as an immediate requirement, an open problem, a project, a budget, or hiring for the thing you sell. Out go product launches and Product Hunt posts, company announcements, personal achievements and celebrations, hiring posts unrelated to what you sell, generic thought leadership and engagement bait, anyone selling the same service you do, and any need the post says is already solved.
The numbers are humbling and worth knowing. On one customer's pull of 336 people at fit 7 or higher, the review kept 57. The rest were real people matching the ICP who were celebrating, launching or selling, not buying. A 10-out-of-10 founder cheering a new CMO hire is a perfect ICP match and a useless lead.
Your agent posts the funnel every time (pulled, kept, and the excluded count by reason) so you can see the pond's real yield. If you have your own rules, write them in the room and they apply on top.
Add your own exclusion rules
From now on, when you review a pull, also exclude [anyone at agencies, anyone under 10 employees, posts older than two weeks]. Show me the funnel with those reasons counted separately.Rules you write in the room are filed with the playbook and used on every future pull.
Step 3 · Enrich them
Ask your agent to enrich
Enrich every lead from that pull. Batch them, and report how many came back sendable (and what that cost), how many had no findable email, how many are low confidence, and how many were skipped as outside my countries.It merges multi-map pulls into one file and runs it in batches of up to 100. You never pass rows around by hand.
Handing leads to a sales team
MODE handoff: reviewed, ranked leads delivered on a schedule. The agent never emails anyone.
Two early customers used the pipeline exactly this way, and every problem they hit was a missing agreement rather than a missing tool. The playbook now collects that agreement once, in the DELIVERY line: the Slack channel ID (not its name; the bot cannot look names up without the channels:read scope), the batch size, the times and their timezone, and the format. The Slack bot needs chat:write, files:write, channels:read and groups:read, and before the first real batch the agent posts one test file and asks you to confirm it downloads. Slack-hosted files were not downloadable for one customer for four days; the fallback is a public file link plus the rows as plain text.
Then every batch follows the same shape: the next rows in fit order, exactly the number agreed and never a bonus row, as a CSV with every original column, the download link, and the same rows in the message. The message also says how many remain in the pool, when the pool was harvested, and whether this batch comes from a fresh pull or replays that pool, because your team will ask "is this new data?".
One limit to know: the per-pull download link (briefroom.ag2.cloud/mcp/fill/csv/<job>) is minted once per pull, so a 25-row slice has no link of its own. The agent posts the pull's link with the row range, or the CSV file itself. When the pool is down to two batches it proposes the next pull with its price and date and runs it unless you say otherwise, so the drip never stalls at zero.
Set the delivery contract
Deliver the reviewed leads to Slack channel C0XXXXXXX, best fit first, 25 at 10:00 and 25 at 16:00 Asia/Kolkata, as a CSV file with a download link and the rows in the message, with the remaining count, until the pool is empty. Post a test file first so I can check the download works.If you run two companies with one agent, each gets its own room, map, pool, channel and schedule; say "do the same for the other company" in the other room and the agent applies the same contract there.
Step 4 · Draft the emails
Ask your agent to draft
Draft a 3-step sequence for the sendable leads, delays 0/3/7. Use my proven offer if I have one - if the only proven offer is scoped to a different audience, tell me before drafting anything.Leaving the offer out is the default: it drafts with whichever of your offers has real reply history. That caveat in the prompt is worth keeping — a proven offer aimed at the wrong audience is worse than an unproven one aimed at the right one.
Step 5 · Build and launch the campaign
These run on your machine with your own keys (Smartlead or Instantly), so your sending identity never leaves your hands. They're free — no credits.
Campaigns are built in two lanes: a clean lane for verified addresses and a catch-all lane for domains that accept everything and cannot be verified. They get different mailboxes and are judged against different bounce lines — a couple of percent is alarming on the clean lane and normal on the catch-all. Mixing them means the catch-all bounces drag your good domains down with them.
Your agent builds both, assigns mailboxes, sets the schedule, and runs preflight — then stops. Preflight is where young domains, thin mailbox pools and pace problems surface. Nothing sends until you say go.
The defaults it applies without asking, learned the hard way on the first campaigns: warmup stays on for every mailbox, even ones that arrived pre-warmed; the from-name on every mailbox is the sender named in the campaign assets, never the mailbox's own persona; the per-mailbox daily caps are what actually limit throughput, and "40 a day" means 40 sends per mailbox across all steps, not 40 new people; the campaign's own cap is computed when it is scheduled, so any later change to mailboxes or limits means re-running the schedule; open tracking is switched on (Instantly ships it off); and a campaign that has already imported its leads is never re-imported, only topped up, because a second import re-sends the first email to everyone. Projected bounce is reported once with the default action (clean lane plus catch-all lane), not asked about on every launch.
On Instantly the same skill creates the campaign, imports the drafts, schedules, runs preflight and launches on your yes, and the reply desk works there too; lanes, health monitoring and A/B stats are Smartlead-only for now, and your agent says so rather than improvising.
Ask your agent to build the campaign
Build the campaign from those drafts with Campaign Runner. Split clean and catch-all into their own lanes, assign my warmed mailboxes, schedule 6am-8pm in my timezone, run preflight on both, and stop there. Show me lead counts per lane, projected bounce, and three sample emails before I launch.The last sentence is the important one. Ask for the samples and read them — that is your last look before real people get email.
Then, when you are happy
Launch both lanes. Confirm they are actually active, not just that the launch call returned.learn harvests every reply, sentiment, and booked meeting, and feeds them back upstream — the Drafter's style profile learns what your audience answers, and the map learns which phrasings produce repliers vs. dead ends. The system gets sharper with every campaign you run.What this looks like day to day
You do not go and check on campaigns. The sweep runs on its own and posts into your room: what replied, what it already handled, what needs you.
Two lanes, and it knows the difference. An unsubscribe is actioned immediately and never answered — removed from the campaign, added to the sending block list, written to permanent do-not-contact across every tool. A genuine reply is classified (interested, interested-with-an-objection, soft no, hard no) and a response is drafted and held. A flat “no thanks” is reported and closed with no draft at all, because there is nothing to say.
Health comes as a recommendation, not an action — each campaign with its bounce rate, reply rate and send count, and a plain call: pause these three, this one is fine. Whether it acts on that itself or waits for you is a standing rule you set once. Standing rules stick: which campaigns never feed the learning loop, what always needs your approval, what it should never do without asking.
Approvals are a queue you can ask for. Ask what is waiting and you get the list with each reply, its category, and the draft. Approve them by name, or say what to change and it rewrites — “ask what they meant by that, and say I do not see them registered” is enough. Nothing sends until you say so.
It checks records instead of guessing. Asked about a prospect, it pulls the real lead record, the company site and the profile rather than inferring from the email. It will also correct itself: a first guess at what a reply meant, revised once it had read the actual record, and said so plainly.
And it cross-references. The most useful thing it caught in a week was a prospect replying “I’m in, thanks!” who had never actually completed the signup form — enthusiasm in the inbox, absent from the registration data. The draft became a nudge to the real signup link instead of a thank-you.
Step 6 · Watch for replies and answer them
The campaign is running. This is the part that actually books meetings.
sweep: a single worklist of who needs a response (hottest first), unprocessed opt-outs, drafts that were posted for approval and never sent, stalled threads, people back from leave, and declines that are reported but never chased. It filters auto-replies and out-of-office, classifies intent, drafts in-thread responses behind a mandatory approval gate, records booked meetings, and handles unsubscribes as permanent do-not-contact across every layer. Works on Smartlead and Instantly.Before the first draft, the agent collects the campaign assets in one message and keeps them in the room's Vault: the sender's name and title for signatures, the booking link, the demo, pricing and one-pager links, one nameable customer with a number (or "none yet"), and anything it must not claim. Every early customer supplied these piecemeal, days late, while warm replies waited: the booking link after five hours, the demo link after thirteen days, the proof point never. A missing asset is reported as missing; the reply goes out without it rather than with an invented one.
Set the cadence once and your agent sweeps on its own: one sweep every morning and one every afternoon, and again when a reply notification lands, is plenty. That single command replaces separate checks for new replies, stalled threads and revivals. Each sweep detects new replies, filters auto-responders and out-of-office noise, classifies what each person actually needs, drafts an answer, and re-surfaces any draft you have not approved yet, so nothing waits silently.
It drafts. It does not send. Scheduled sweeps never send email, no matter how routine the reply looks. You see the person's own words, the exact draft, and who it goes to, then you approve.
The one thing it does act on alone is an opt-out. Anyone saying stop, in any wording, is unsubscribed from the campaign, added to your sending block list, and written to a permanent do-not-contact list that every future pull, enrichment and draft is screened against. That one is not a judgement call.
Set up the reply sweep
From now on, sweep my campaigns for replies every morning and every afternoon. For each genuine reply, post their words, what they need, and your draft with my booking link. Handle opt-outs immediately without asking. Send a draft only when I say yes.Change the interval to suit your volume. Ask for a sweep on demand any time with “any new replies?” The sweep reads each thread's last message rather than counting replies, so a second message from the same person is never missed.
Or let it send what you would approve anyway
Standing rule: send replies yourself when the draft is a booking link with no new claims. Post anything else for my approval.A standing rule like this is the difference between a reply desk that books meetings while you sleep and one that waits for you every morning. Bookings that arrive from a different email address than the one contacted are invisible to the tools, so tell your agent when someone books; it records them and asks once a week.
Working the queue
Show me everything waiting for approval, hottest first.Then approve them by name, or say what to change and it rewrites. When someone books, tell your agent — recorded bookings are what teach the system which copy actually converts, and they are the number the whole loop optimises for.
What it learns, and how you see it
The loop is not a black box — ask for the scorecard and read it.
After campaigns have run, the reflection comes back as a readable verdict rather than a dashboard. It compares your campaigns against each other and says which audience and which copy worked: hyper-specific personal observations and a concrete deliverable outperforming generic pain points, one persona replying at twice the rate of another, one campaign producing nothing at all.
It separates copy problems from delivery problems, which matters more than any copy lesson. A campaign with replies but a low rate is a copy question. A campaign with zero opens across every send is not a copy question at all — that is deliverability, and rewriting the emails would have been wasted work. The reflection says so, and proposes the experiment that would actually settle it.
Verdicts are attached to offers, not vibes. Each offer accumulates sends, replies and booked meetings, and gets graded — proven, promising, unproven, underperforming. Your own offer being graded underperforming across a few hundred sends is the system telling you something true and unwelcome, which is the point.
The map learns at the phrasing level too. Individual phrasings carry their own measured reply rates, so the winners get promoted for future pulls and the zero-reply volume gets demoted. Personas are measured the same way. That is how the pond gets cleaner without you tuning anything.
Lessons are versioned and applied to future drafts automatically. You can ask what the current lessons are, and you should occasionally — it is the fastest way to understand what your audience actually responds to.
Guardrails
- The gates are few and fixed. The first launch of a campaign and the sending of a drafted reply wait for your yes (or your standing rule); everything upstream runs without re-asking once you or your operator asked for it. Launches pass preflight first.
- Suppression is permanent and server-side. Anyone who opted out or was already contacted is excluded from every future pull, enrichment, and draft — enforced in the cloud, not by agent memory.
- Deliverability is protected by default. Low-confidence emails never send, bounce history is remembered forever, and campaign health auto-pauses at bounce spikes.
- Geography is a hard gate. Your countries (US, CA, GB, AU + EU-27 unless you say otherwise — and your agent confirms the list before each run) are enforced from each person's LinkedIn profile at the pull, again before any email lookup is paid for, and again before drafting. Outside-country authors stay visible in the run's audit trail at fit 3, flagged geo-excluded — they can never ship. A post never says where its author lives, so the agent is never asked to guess it.
Other GTM tools
Not part of the outbound pipeline — reach for these separately.
POST /mcp/files/import with its engage_job_id hands the qualified tier straight to the enricher. Where to go when a post-search pond drains.Inbound and outbound feed each other: Viral Scout and Ghostwriter build the presence that makes cold email land warmer, and Post History grounds a call in what the person actually writes about.
Mining engagers
Three ways to seed it, in rough order of how well they work. The best seeds are posts about a problem — someone complaining that outbound is not working pulls buyers into the comments. Celebration and announcement posts pull congratulations, which is a different crowd entirely.
Seed it with specific posts
Mine the people commenting and reacting on these posts: [paste 2-5 LinkedIn post URLs]. My ICP is [who you sell to]. Score them and give me the ones worth contacting, with each person’s own comment.The strongest version of this is a competitor’s post, or any post where your buyers are visibly complaining about the problem you solve.
Or seed it from a map you already have
Mine engagers from the posts my [name the map] map already harvested. Same ICP as the map. Tell me how many qualified people it found and how they differ from the leads the map itself gave me.This costs nothing extra to discover — it reuses posts your map already paid to find.
Or seed it from a topic
Find high-signal posts about [the problem you solve, phrased how a frustrated buyer would say it] and mine the engagers. My ICP is [who you sell to].Topic runs get better with repetition: phrasings that produced qualified people are re-probed first next time, and ones already tried are never bought again.
Engagers come back with the same fields as any other lead, plus their own comment — which is the whole point. Someone who wrote a sentence about their problem under another person’s post has handed you the opening line of your email. Feed the file into enrichment and drafting like any other pull.
Content: scout, then ghostwrite
These two are meant to be used together, in this order.
Find what is working right now
What is going viral on LinkedIn about [your topic] this week? Show me the posts, who wrote them, and why each one works structurally.Then write yours in that shape
Write my next LinkedIn post. My LinkedIn is [your profile URL]. Topic: [what you want to say, or paste rough notes or a transcript]. Use the structure of the [pick one from the scout results] post, but entirely my content and my voice.Your own profile URL is required — that is how it learns your voice, by reading your last few months of posts. Without it there is nothing to sound like, so it will ask before writing anything. If you give it a name instead, it looks the person up and confirms the match with you first, so it never writes as the wrong person.
Borrowing a structure is not borrowing content: facts come only from what you gave it and from your own posts, so it will not inherit numbers, customers or stories from the post whose shape you liked.
Reading someone before a call
Pull [name or LinkedIn URL] last 20 posts and summarise what they care about, how often they post, and what lands best for them.Also the honest way to plan your own content: ask for your own history first and see what actually performed before deciding what to write next.
Credits & billing
The lead tools are priced per result: Intent Leads per qualified lead, Engagement Miner per qualified engager, Lead Enricher per lead with a sendable email, Email Drafter per sendable draft. Every call says how many you want. Credits for that many are held when it starts, you are charged only for what is delivered (never more than you asked for), and the rest of the hold is refunded when the job ends. Your agent reports the exact charge from the job's billing summary, so you always see held, charged and refunded.
ICP Mapper and the other GTM tools keep a flat, published price per run. A failed run is refunded automatically, and a hold that never settles is refunded on its own. Watch every debit and refund as a line item in your dashboard's wallet activity. The local skills (Runner, Responder, Stats) are free.