How We Run 24 GTM Agents: The Full Backend Build (2026)

The autonomous SDR did not happen. By early 2026 the companies that plugged in a fully autonomous agent and removed the humans have largely gone back to hybrid models, and the one benchmark that compares the two puts a human-supervised seat at about $278,000 of pipeline against $94,000 for an AI-only seat. What works is narrower and more interesting: many small agents, each owning one job, each ending at a person.

We run 24 of them on our own pipeline. This is how each one is built, from the consultant's chair: the method that works in 2026, the system we actually run as the worked example, the prompt's shape, and the thing that broke. Where you have to bring your own ICP, voice or data, the section says Personalize this. Everything else transfers.

It is one loop. Content brings engagers. Engagers become leads. Leads become replies and calls. Calls become the material for the next post, and the same agents harvest who engaged with it. Every agent below sits somewhere on that loop.

What every agent stands on

Twenty-four agents are not twenty-four services. They are twenty-four jobs on one substrate, and the substrate decides whether they can share state, which is the whole difference between a system and a pile of workflows.

The method. Four things have to be shared: a ledger of every person and company ever touched, one identity key per entity, one ICP definition every agent reads, and one human surface where anything that could embarrass you is seen before it leaves. A workflow tool holds each flow's state separately, and the first time two flows touch the same person you are re-enriching and re-sending. The reason to write this yourself is not cost. It is that the state has to be yours.

How we run it.

• Runtime: Python 3.12 and FastAPI on Railway, deployed with Nixpacks. Two services: the outbound engine (scrape, qualify, enrich, personalize, push) and the revenue OS (replies, bookings, CRM, Slack).
• Scheduling: no queue product. An `asyncio` worker starts inside FastAPI's lifespan on every boot and drains three queues in parallel, scrape, enrich and send, each behind its own gate with its own backoff so a stuck queue cannot hot-loop its siblings. Caps: 8 scrapes, 10 enrichments, 8 sends. It lives in the lifespan and not a background task because a Railway redeploy kills a background task mid-batch.
• Ledger: Supabase Postgres. One fat `leads` row per prospect, keyed on the normalized LinkedIn URL, carrying the raw scrape as JSON, the ICP score with its breakdown, the email status, the campaign, and provenance: which source, which post, what engagement type. Row-level security is on with zero policies, so only the service role reads it, and a script asserts the policy count stays at zero.
• The vault: a `contacts` table with one row per email any list build has ever produced. 56,139 rows today. The first line of every list script is a lookup against it.
• Models: routed by task. Bulk qualification runs on a cheap model through OpenRouter. Claude Sonnet handles the judgment calls and is the fallback for qualification, with its system prompt cached on a 1-hour TTL, because the workload is bursty and the default 5-minute cache expired between bursts. Claude Haiku gates high-volume passes at about $0.02 per thousand people judged.
• Scrapers: Apify actors for LinkedIn posts, comments, reactions and profiles, with `profileScraperMode: "main"` mandatory on engager actors. The `short` mode returns opaque URNs that no enrichment provider can resolve.
• Human surface: Slack. Every agent that produces something a person should see posts a card with a score and a reason.

Personalize this: the identity keys. Ours are the LinkedIn URL for leads and the email for contacts. Decide them before any agent runs; change them later and every dedup check you have ever made is wrong.

The enrichment waterfall, which five agents share

The method. A waterfall is a provider order with a stop rule, and in 2026 the numbers are settled: multi-provider cascades find emails on 85 to 98% of contacts against 55 to 65% for any single source, and teams that order providers by geography and segment beat the default order on both hit rate and cost. There are three ways to have one. A managed cascade like FullEnrich aggregates 20-plus providers and takes the ordering decision away from you; operators report moving from about 65% valid emails on a single source to about 90%. A spreadsheet like Clay gives you 150-plus providers and the lowest practitioner-reported bounce rates, around 10 to 14%, but the product centers the human operator and the table, so calling it from an agent is a second-class path. A custom waterfall is three API clients and one table of hit rates, and it is the only version that learns your segments.

How we run it. Three waterfalls, because three motions measured three populations and the providers did not agree.

• Live engine, per lead: Prospeo only, with `only_verified_email` on, so finding is verifying. Prospeo's database refreshes on a 7-day cycle where most providers take 4 to 6 weeks, which is why it holds the live seat. LeadMagic was in the chain until June and was dropped when its hit rate stopped paying for its slot.
• List builds: Apollo people search (free, verified by reading the credit balance before and after) into Apollo `bulk_match` at 1 credit per match and about 75% yield, into Prospeo `enrich-person`, which bills only on a hit, into BounceBan.
• Influencer engagers: AI Ark `people/export/single` (1 credit on a hit, 0 on a miss) into Prospeo. That order took the segment from 40% to 80% email yield.

The stop rule matters more than the order. A miss is only a miss if the provider says so. Rate limits, timeouts and 5xx are transient, and a transient miss keeps the lead queued for retry. We learned that on a day when 753 of 1,506 leads marked `NOT_FOUND` were actually rate-limit errors.

Verification has one source of truth: a table of dated verdicts per address with a 30-day TTL, and the verifier of record is BounceBan, because it resolves catch-all domains. NeverBounce refuses them, and on agency domains it passed 1 of 8 addresses that BounceBan cleared. Skipping that rule once marked 176 good leads as bounced. This matters more than it used to: in 2026 a bounce rate over 1.5% is the signal to pause a domain and over 2% to stop, and reputation damage lands before Postmaster Tools shows it.

Cost controls are hard caps in the scripts: a maximum credit spend per run, and a per-run Apify budget that defaults to $40. Hit rate is tracked per provider per segment, and it swings: AI Ark hits about 40% on influencer engagers and about 90% on mid-market operators.

Personalize this: your provider order is an empirical result, not a setting. Run 200 people from each segment through each provider once, write the hit rates down, and let the agent read that table.

Find the people

Six agents, one question: who is already in motion toward you. The 2026 version of that question is not "who fits the ICP" but "who fits the ICP and did something this week." Signal convergence beats any single signal; a new CTO plus active hiring plus a comment on your post is worth more than a perfect firmographic match doing nothing.

1. The agent that builds lookalikes from your closed-won

The method. Seed with closed-won or high-LTV accounts, never with the whole customer list, because the losses are in there too. Enrich the seed across firmographics, technographics and growth signals, then score the market against it. The current generation of tools does this with embeddings over the company's website and attributes rather than rule matching, and the threshold decides the job: a 1 to 3% similarity band for pipeline, 5 to 10% for awareness. Clean the seed first. Deduplicated records and validated domains matter more than the model.

How we run it. Honest version: half built. What runs today is a market list cut by the size bands and functions of deals we actually won. For the US recruiting market that meant 52,923 harvested firms, 9,226 verified as live US recruiting companies, 1,605 in tier 1, 5,907 contacts, 9,691 deliverable addresses. The lookalike is the band, not a similarity model. The ledger already carries what the model needs: every won deal's company facts sit in `company_facts` with headcount from AI Ark at 0.1 credit per company, and the embedding version is next on the roster.

Personalize this: start from three won deals. Write down the two facts they share that your losses do not, usually a size band and one function they were hiring for, and cut the list on those before any model gets involved.

2. The agent that finds ICP people engaging with your posts

The method. Engagement on your own content is the warmest public signal that exists, and in 2026 there are three ways to capture it. Social-listening platforms like Trigify watch engagement across LinkedIn and turn it into lists, tracking more than 30 trigger types. Team-first tools like Teamfluence capture every interaction with your team's own presence and qualify against an ICP in the product. Or you read your own engagement directly, which is what we do, and the reason is the qualification step: the tool's ICP is a form, and ours is a file every other agent reads too.

Whatever captures the signal, the shape is the same: pull, gate cheaply, enrich, score, route to a person. Never send. LinkedIn flagged 23.5 million automated sessions in one quarter of 2026, restrictions now arrive before warnings, and the safe envelope is about 20 connection requests a day and 100 a week. An agent that reads is defensible. An agent that acts on your account at volume is not.

How we run it. Fires every 30 minutes with 0 to 4 minutes of jitter, off my own logged-in Chrome profile, never a rented session. It reads the reactions and comments on my last five posts through LinkedIn's own feed endpoints, paced 1.2 to 3 seconds between calls, and it does not trust pagination: it fires two offset calls and diffs the people back, and if the set did not move it logs the pull as capped rather than pretending it saw everyone.

• A free stage-one gate on name and headline drops hard rejects and named competitors before any money is spent.
• Enrichment through an Apify profile scraper in "no email" mode at $0.004 per profile: followers, employer, the company page, country.
• Scoring by Claude Sonnet in batches of 25 against the canonical ICP, system prompt cached. Haiku was tried first and flagged a Google AI GTM lead and an AI-monitoring SaaS as competitors, so the competitor call runs on Sonnet. A 98-person run costs about $2 of Apify and 6 to 9 cents of Claude.
• One Slack card per person: tier badge, headline, the signal line ("commented x2 · liked · viewed your profile"), the top comment quoted, an "Open on LinkedIn" button. A ✅ reaction on the card is the only thing that queues a connection request, and the request goes from my own machine, capped at 10 a day, weekdays, 9 to 5 Pacific.

The trap: a dead API key once made every scoring batch fail, and the run still reported success, posting 20 unscored people to Slack with the competitor gate rejecting nobody. It now exits hard if every batch fails.

Personalize this: the ICP file, and the competitor rule inside it goes first.

3. The agent that catches profile viewers

The method. A profile view is the weakest deliberate signal and the strongest accidental one: it is often the first thing a buyer does after reading a post or an email. Capture it, score it low, and never let it promote anyone on its own.

How we run it. LinkedIn's "who viewed your profile" API returns exactly 30 people whatever you pass for `count` or `start`, so the agent scrapes the analytics page instead, and the list there lives inside a scrollable `main`, not the window. It scrolls that element up to 200 times and stops after three stagnant rounds. Views count a full point in the Slack strength score and zero toward CRM promotion, because a view accumulates passively on every poll and a comment is a decision.

The trap: 62% of viewers were being dropped for free, because the seniority check ran against a title field that viewers structurally do not carry until after paid enrichment. Nobody noticed until someone read the reject logs.

4. The agent that mines your competitors' audience

The method. The people commenting under a competitor's post are in the market and already listening to someone. The math is a funnel, and the competitor gate is the whole game: an audience that follows a vendor is full of that vendor's peers.

How we run it. Two motions. The standing one polls a `tracked_competitors` table every six hours through an Apify posts actor, waits four days for a post's engagement to settle, then scrapes likers and commenters at 200 per post and pushes each through the same ingest path as an inbound webhook. About $0.04 per competitor per week for posts and $3 to $5 a week for engagers.

The other points the same chain at the three people your buyers already follow. A real run on one creator: 3 posts, 60 engagers, $0.24, 57 unique people, 17 qualified before the competitor gate. Then the gate: 11 of the 17 were competitors. Seven survived. That ratio is why the competitor rule is gate one on every scoring prompt we run, and why the post says run this one at volume.

Personalize this: the three creators. Pick the ones whose comment sections hold your buyers, not your peers, or you will pay to enrich your competitors.

5. The agent that reads hiring momentum, social presence, the tech they run

The method. Job postings are a public statement of where budget is going next, and hiring is the highest-converting trigger in B2B. The clean source is not a job board. It is the company's own ATS: Greenhouse, Lever and Ashby boards are plain JSON with no anti-bot layer, so the same fetch that reads the roles reads the technographics. Layer funding, headcount growth and technographic detection on top, and score convergence, not presence.

How we run it. Hiring is read from the company's own site over plain HTTP: homepage plus careers page, parked and expired domains detected by regex, and the ATS flagged by name (Bullhorn, JobDiva, Loxo, Crelate). A firm hiring its own sales or account people is spending to grow revenue right now. Social presence comes from Trigify's creator discovery, cross-referenced against the same ICP exclude lists. Headcount and firmographics come from AI Ark at 0.1 credit per company. Every trigger has a source and a cost next to it in one table.

The trap: a staffing firm's `/jobs` page is its clients' requisitions, not its own hiring. Only `/careers` counts. Getting that backwards inflated hiring signals by roughly a third across two list builds.

6. The agent that scrapes wherever your ICP actually lives

The method. A directory is a list someone else already qualified, and a review site is a list someone else already paid to be on. Both beat a database, because the entry itself is a signal. The engineering pattern for anything behind Cloudflare is solve once, then paginate: open the site once in a real browser to clear the challenge, then reuse the cookie from a fast HTTP client for every page after.

How we run it. Clutch, gated on minimum project size, hourly rate and team size. G2, which since the Capterra, GetApp and Software Advice acquisitions covers four universes in one scrape, filtered to the 20 to 300 review band. The HubSpot Solutions Directory, Zapier Solution Partners, Partnerbase. Solve-once with undetected-chromedriver, then `curl_cffi` on the reused cookie. Inc 5000, award lists, podcast guest lists, Google Maps and community rosters are on the roster and not yet in code. Saying so because the post lists them.

Personalize this: the directory that already ranks your buyers. Every industry has one.

Know the person

7. The enrichment waterfall agent that learns which provider hits for which segment

Covered above. The agent's job is the table, not the calls. Once more, because it is the part people get wrong: a rate limit is not a miss.

8. The taste agent

The method. Qualification is two layers. Deterministic rules first, because they are free and never hallucinate: geography, seniority, company size, never-contact domains. A model only on the survivors, returning strict JSON with a score, a breakdown that doubles as an audit trail, and a confidence. The ICP is written in prose in one file, because prose is what a model reads well and a form is what it guesses at, and the competitor rule goes first because it is the call the model gets wrong without it. In 2026 the prompt is cacheable end to end: the JSON schema passed as structured output joins the cache prefix automatically, cache reads cost a tenth of standard input, and the order is tools, then system, then messages, static content first.

How we run it. Hard filters in a YAML file disqualify on rules (score 1, never seen by a model). Survivors go to the scorer, which returns an `icp_score` from 2 to 10, an `icp_breakdown` of signal, category, weight and delta, a confidence, and `key_unknowns`. The system prompt is a plain text file of about 10,900 tokens, and its shape is the method:

1. Role framing and the input schema.

2. The north-star buyer definition.

3. The JSON output contract, before any scoring rule.

4. A score-to-tier table and one calibration anchor per score, 2 through 10.

5. Weighted axes for company fit and title fit, then red-flag overrides.

6. A confidence rubric.

7. Four worked examples.

8. The don'ts.

Before a profile is sent, a 30-key drop list strips pictures, URNs, full job history and recommendations. The row keeps everything; the model is billed for what decides the score.

The ICP file itself is read by every surface: signals, outbound, inbound. It throws if missing rather than falling back to a stale copy. Its structure: the competitor rule (services agencies that build GTM or AI are peers; software products are buyers even when AI-branded; an agency over 20 people is a buyer), a function-first target rule, a seniority list, role exclusions matched on the role rather than the whole headline, company quality gates (1,000 followers for a person, 2 employees and 200 followers for a company, 5,000 followers for a solo operator), geography as an allowlist in two representations because LinkedIn's viewer filter only knows metros, never-contact domains, and four tiers.

Two traps. A one-person consultancy with a LinkedIn company page passed every gate until a tier-1 lead's "company" turned out to have 13 followers, so company-page existence became a headcount and follower gate, not a tier penalty. And a client sat at tier 1 in Slack for a week because `exclude_companies` existed in the config and was never applied in the scorer.

Personalize this: the whole file. Write the competitor rule first, in prose, with the line that separates a peer from a buyer.

9. The account brief agent

The method. One page before anyone writes, built only from what the system already holds, with a no-invention rule in the prompt: every sentence maps to an input. The brief exists so the writer, the rep and the model are reading the same page, and so the model's creativity is spent on the sentence, not on the facts.

How we run it. The brief is assembled from the ledger: the person's row, the company's facts (headcount, ATS, the directory it was found in), the signals with their dates, and the last events on the deal if there is one. Claude writes a short brief on top. The same brief posts to Slack 30 minutes before every booked call, sourced from the CRM deal and the ledger's last events.

Personalize this: the facts you consider a brief. The rule about invention is not personal.

The brain and the vault

10. The company brain agent

The method. The brain is the memory every other agent grounds in, and the 2026 retrieval pattern is hybrid: BM25 keyword search and dense vectors run in parallel, fused by rank, because pure vector search fails on roughly 40% of real queries where the exact token carries the meaning, a product name, a client, a number. Where the index lives is a scale decision. Postgres with pgvector when the vectors need to sit next to relational data and be filtered by it; a local index when the corpus is small enough to search in under a second and the whole thing has to work with no network. The full build is its own post: how to build an AI company brain for GTM.

How we run it. Not a vector database. A Markdown vault, Obsidian-compatible, read by agents running in Claude Code. Four layers: `raw/` holds immutable sources and is never hand-edited, `wiki/` holds one compiled page per topic, `INDEX.md` and an append-only `log.md` catalog what is there and what changed, and `brain-search/` retrieves. What goes in: 414 sales-call transcripts pulled automatically from Fireflies, 17 project case files, playbooks per build type, settled architecture decisions, the founder's voice and goals, the positioning, and the canonical ICP file.

Retrieval is local hybrid search: BM25 plus a vector score, min-max normalized and fused, over every Markdown file, chunked by heading. Embeddings run locally through fastembed on ONNX, no torch, no API call, and the index is three files on disk. The pgvector pattern runs in our client knowledge-base builds; for our own memory it was the wrong tool.

It stays current by ritual, not automation. Finishing a build means copying the case-file template, adding a row to the index, appending a line to the log, and updating the matching playbook. The log has dated entries every few days since spring, which is the only proof a ritual is real.

Personalize this: the raw sources. Calls are the highest-value input by a wide margin, because they hold the objections in the buyer's own words.

11. The people vault agent

The method. Everyone any agent touches is saved with provenance: which source, which run, what it cost, what was decided. Provenance is what lets you audit a decision a month later and what lets the waterfall agent learn. One write path. If two code paths can create a person, dedup is a habit, not a property.

How we run it. Three tables: `leads`, one row per prospect keyed on the normalized LinkedIn URL, with source, post and engagement type; `contacts`, one row per email any list build ever produced; `seen_leads`, a skinny record for people already judged and disqualified, checked before any paid scrape. Every write goes through one entry point, and on the CRM side there is a grep-checkable invariant that deal creation has exactly one caller.

The trap: the vault was backfilled late. Before the backfill actually ran it held about 800 rows, and a week of enrichment spend skipped the "do we already own this email" check. Run the backfill before the first list, not after the first bill.

12. The vault-first list agent

The method. Your own database before anyone else's. On a mature vault this is the largest single cost cut in the pipeline, because the people your ICP produces overlap heavily from one campaign to the next, and every overlap you catch is an enrichment you do not buy twice.

How we run it. Every list build starts with a lookup against `contacts`: 56,139 rows, 50,521 already sent or queued, the rest owned and never re-enriched. Only the people who are not there go to a provider.

Personalize this: nothing. Build the vault before the first campaign, and make the lookup the first line of every list script.

Write in your voice

13. The personalized variables agent, per lead

The method. Personalization at scale in 2026 is not a paragraph the model invents. It is one or two variables per lead, generated from facts the system holds, merged into copy a human wrote. Two rules make it safe: the model may only use inputs it was given, and it may never overwrite a fact the person supplied themselves, such as the comment they actually left. The reason is not aesthetics. A wrong inference in an opening line is the fastest way to a spam complaint, and the enforcement threshold at Gmail and Yahoo is now a 0.3% complaint rate, with 0.1% as the working target.

How we run it. Operator-managed prompts live in a `personalization_templates` table, one per variable key. For each active template the agent calls Claude with the template as the system prompt and the lead's context as the message: name, headline, about, the profile scrape, the ICP tier and score, and whatever the source already attached. Output is plain text stored under that key and pushed to the sender as a custom variable. Generated variables merge into personalization the source attached; they never replace it. And `{{companyName}}` is resolved only for engager leads; a lead from a list built company-outward keeps the company name the list started from.

Personalize this: the templates, and the list of facts a model may not overwrite. Ours is anything the person said in their own words.

14. The lead magnet agent

The method. A lead magnet that is custom per prospect converts a first email into a deliverable, and the only way to do that at volume is a renderer plus a content dictionary: the layout is code, the judgment is data, and a copy contract enforces the rules at generation time rather than in review.

How we run it. One Python renderer, one content dictionary per prospect, output is a self-contained page with hand-drawn SVG figures. More than 30 have gone out. Each carries the same shape: a map of the four systems the prospect would run, a five-stage outbound pipeline with the human approval gate named, a diagram of exactly which decisions stay human, a company-brain figure, a tracking board, and the table of agents that would come next. The copy contract sits in the renderer's docstring: plain professional language, no em or en dashes, no invented numbers, any company fact from a public source and the page says so. It attaches as a link in a short reply inside the existing thread, never as an attachment.

Personalize this: the content dictionary is the whole thing. The renderer transfers.

15. The verify and critic agent

The method. Two different mechanisms, and choosing between them is the design decision. For facts, verification is deterministic: a claim carries its exact quote and source, and a separate pass checks the quote against the source by string matching, not by asking a model whether it looks right. The 2026 production pattern is layered: cheap deterministic checks first (does the citation exist, does it resolve), a model judge only for the semantic question of whether the passage supports the claim. For voice and intent, a model critic is the right tool, scoring against written rules with a hard cap on revision loops.

How we run it. For research, every fact starts as an evidence card: claim, exact quote, source URL, date, confidence. A separate pass re-checks each card. An exact quote match of 12 characters or more is verified; word coverage of 85% (or 60% with the numeric value present) is partial; anything else is unsupported and dropped; a source with no cached text is a dead link and dropped. A fabricated quote cannot pass, because nothing in the pass has an opinion. For content, the critic is the third of three agents. It scores voice match and intent match out of ten and forces a revision on hard-rule violations: em dashes, generic AI phrasing, a metric that does not exist in the brain, a claim that contradicts our offers. Two revision loops maximum.

The trap: we built a critic for inbound replies too, one that classified and drafted before a human saw the thread, and deleted it. Deciding what mattered before the founder read it made the channel worse than no automation.

Replies and inbound

16. The positive reply agent on the Instantly inbox

The method. The reply agent's job is to make sure a human sees every reply that matters within minutes, with enough context to act. It classifies, it does not answer. Trust the sender's own interest score as a first pass, re-check it before acting on it, and fail open: an unscored reply that waits is cheaper than a missed one.

How we run it. Polls the inbox every 120 seconds and takes the webhook too. It gates on two things: the reply is not machine-generated, and Instantly's interest score clears a minimum. Unscored replies are held for a few hours and then posted anyway. The score becomes a badge on the Slack card: 🎉 for closed, meeting completed and meeting booked, 🔥 interested, 🌴 neutral or auto-reply, 🚫 not interested, 👤 wrong person, ❌ lost. A deferral ("try us in Q2") gets its own gate, a 🌱 card, and lands the deal in Nurture with a date parsed from the prospect's own words.

It notifies. It does not draft. And it re-checks the interest status before trusting a "lead interested" webhook, because measured without the re-check, about 96% of those webhooks were false positives.

17. The routing agent

The method. Routing is a small number of explicit rules over a small CRM, and the rule that matters most is where automation stops. Every stage a machine can move a deal into is a stage a human will stop looking at. Keep the CRM small enough that the routing agent's output can be read as a sentence: which campaign, which owner, which channel, and why.

How we run it. Nine stages, four custom fields (source, source detail, next action, next action date), nothing custom on people or companies. One open deal per person, enforced by a lock. Automation moves a deal forward as far as Call Booked; everything after is a human. Channels are the routing: raw replies in one, money moments in another, the work queue in a third, drafts for the founder to send by hand in a fourth. The gate for entering the pipeline is "a conversation started," never "qualified." The full design is in Revenue OS.

The trap: the service runs as exactly one replica, on purpose, because the duplicate-deal lock lives in process memory. Two replicas reintroduced a duplicate-deal bug the day they were tried.

18. The speed-to-lead agent

The method. This is the agent with the most evidence behind it and the fewest teams running it. Teams that respond within five minutes convert at about 21%, against 2.3% for teams that wait a day, the first responder wins around half of competitive deals, and only about 7% of B2B teams hit five minutes at all; the median response time is 42 hours. The build is a timer, a brief and a draft: measure elapsed time in business hours, assemble the account brief (agent 9), draft one email a human sends, and post the elapsed time where a person is measured on it. The number changes behavior. The email is the easy part.

How we run it. Honest version: the timer is built and the one-to-one email is not. The speed-to-lead metric runs in a client's system we built: business-hours-aware elapsed time from lead creation to first call, posted to Slack on every confirmed booking as a color-coded card, green under 300 seconds. On our own pipeline the fast path is the reply card plus the calendar link; the research-and-write-in-minutes agent for a fresh inbound is on the roster, and the brief it would write already exists.

Personalize this: the number that counts as fast. Set it before building anything, because the agent only matters if someone is measured on it.

19. The meeting prep agent

The method. A brief 30 minutes before the call, from the CRM and the ledger only, with the no-invention rule. The value is not the research. It is that the person walks in knowing what the prospect already said.

How we run it. Sources are strictly the CRM deal, the ledger's last events, and the person and company records. Claude writes the brief on top. Nothing on the page the agent was not given.

20. The follow-up agent, written from the transcript and the brain

The method. A follow-up after a specific conversation has to reference what was said, which means the transcript is the input and the brain supplies the voice and the offer. The agent writes; the person sends, from their own address, because a follow-up from a sequencing tool is a follow-up from a stranger.

How we run it. The transcript is pulled from the brain, the positioning and voice beside it, and the draft references the call. Two facts shaped the sending. Instantly has no API for starting a fresh thread, only for replying into an existing one, so a booking that arrived through the calendar can never be emailed through it; those go out from the founder's own Gmail, as him. And two full follow-up sequences were built and cut the same day, because a founder who wants to write the proposal-gone-quiet email himself should.

Content that feeds the top

21. The agent that scrapes the posts that perform for your ICP

The method. Content research is a scraper with a budget. Every actor logs what it cost and what it returned, a daily cap is enforced by the database rather than by discipline, and per-turn caps stop a single research task from becoming a bill.

How we run it. Apify actors, each optional: LinkedIn post search, a Reddit scraper, an Instagram scraper at about $0.002 per post, an X scraper. Every run logs actor, cost, result count, duration and outcome to a usage table. A daily dollar cap enforced by a database view, $5 a day by default, plus per-turn caps: 5 Apify calls, 20 page fetches, 3 X scrapes, and a 90-second soft, 120-second hard timeout per turn.

22. The agent that drafts in your voice from your own calls and builds

The method. Three agents in a fixed order, run by a deterministic orchestrator rather than by a model deciding what to do next: a planner that emits a schema-bound plan, an executor that is the only agent with tool access, and a critic that grades against written rules. The voice is a file, not a fine-tune: real posts that performed, a corrections log, a banned list. And the grounding rule is absolute: the model writes from the brain, never from its general knowledge.

How we run it. PLANNER at temperature 0.3, forced to emit a plan through a tool call with a fixed schema: an intent category from seven, steps with rationale, risk flags, whether the plan needs confirmation, a confidence. EXECUTOR at 0.7, the only agent with tools, narrates what it does and never adds a step the plan did not contain without flagging it. CRITIC is agent 15. Every agent's system prompt gets the same context, 3,000 to 5,000 tokens: the tone-of-voice record, the active do and don't rules, the last ten style corrections, the current offers, this week's calendar, and an inventory of what the brain holds. The voice file was sharpened against 30 posts that performed, with a corrections log at the bottom. Some of its rules: no em or en dashes (also stripped in code by every writing tool), a hook is ten words and never more than fifteen.

Personalize this: the voice file. Start with the ten posts you would post again, and write down why each worked in one line.

23. The agent that logs what you posted and how it did

The method. A voice model learns from three signals: what was actually published, what was corrected, and what performed. Capture all three or the model learns from its own drafts.

How we run it. When a post goes out, the verbatim final text becomes a new numbered anchor in the voice corpus. When feedback comes back, it is appended to the corrections log with the rule it implies. When performance comes in, top, mid or low is written onto the anchor and the drafting agent weights the winners heavier. Edits to a draft are diffed automatically into a corrections table that the next generation's context injects.

24. Agent 2 harvests the engagers from those posts

That is the loop. The post draws the engagers, agent 2 pulls them within 35 minutes at worst, the taste agent tiers them, the waterfall finds their email, the variables agent writes to what they said, the reply agent posts the card, the routing agent starts the conversation, the call goes into the brain as a transcript, and the transcript becomes the next post.

Every one of the 24 has a Slack card, a spend cap, and a human somewhere on the path. None of them talks to a prospect without a person reacting first. That is the design, and in 2026 it is also the evidence: the human-supervised system is the one that produces pipeline.

What it costs to run

Model spend is not where the money goes. The signals scoring step costs about six cents a run against about $60 a month of Apify. Choosing Haiku over Sonnet on that step was proposed to save money and rejected once it was shown the model was 0.1% of the bill. Prompt caching does the rest: a cache read is a tenth of a standard input token, so a 10,900-token rubric costs full price once an hour and almost nothing on every lead after.

The bills that hurt were infrastructure. A hot-loop worker bug once produced $191 of Supabase egress in a month with zero emails sent. A dead API key with no retry cap wrote 48 million audit rows before anyone looked. Both are why every queue has a gate with backoff, every retry has a cap, and every provider has a budget.

This is the system behind the outbound engine and the LinkedIn scrape-to-cold-email pipeline we have written about before, and it is who we are. If you want the same 24 running on your pipeline, that is the work we do.