How to Build a Fully-Agentic Outbound GTM Factory

Outbound execution is becoming automatable end to end. Sourcing, enrichment, copy drafts, campaign ops: an agent can now run all of it on a schedule, and the marginal cost of another campaign is approaching zero. What stays scarce is judgment: who to target, what to offer, what to say.

This guide is how to build the machine around that judgment. One scheduled agent that runs your outbound, a git repo that holds the work, and a human who approves everything before it reaches a prospect. We run our own outbound this way; what follows is written so you can replicate it.

What it does. Every Monday, the agent reads the current campaign brief out of your planning doc, sources a few hundred leads, drafts the copy, and posts a proposal to Slack. A human replies "go ahead". Every weekday, it pushes approved work live, syncs results, and triages replies.

What it is not. It doesn't decide who to sell to. Every material improvement in a build like this comes from a human questioning a premise. Plan for that.

You build and manage the whole thing through your local coding agent (Claude Code or Codex). Runtime is where it lives and runs unattended.

How the factory runs

One scheduled agent, one git repo, and a handful of vendor APIs.

The stack

Thanks to coding agents like Claude Code, you can now plug in as many data sources and systems of record as you want. Think of agents as the new users of this software, instead of humans: if a tool has an API, SDK, or CLI, your agent can read from it and write to it. Adding another vendor used to mean another integration to build and maintain; now it just means more coverage and more places to cross-check a bad record.

The last row is the piece most teams don't have yet. Runtime is an operating system for coding agents like Claude Code and Codex: a safe, sandboxed computer for each agent, a place to keep your vendor keys, skills that carry what the agent has learned between sessions, built-in connections (MCP and integrations) to the rest of your tools, and scheduling so it all runs on its own. Without it, you'd be building all of that glue yourself before writing a single outbound script.

Step 1: Write the campaign brief (human)

Before the agent runs, write down three things in your planning doc:

• Who: the segment you're targeting this campaign, and why now
• What: the value proposition for that segment, in their words
• How: the message and channel you're testing

An agent can tell you whether a segment converts. It cannot know that a segment was already tried and rejected for a reason that never made it into a database. That context lives with people, which is why the brief is the input to the factory rather than something it generates. When you want to change direction, you change the brief, not the machine.

Step 2: Put the work in a git repo, not in the agent

Ask your coding agent to build a repo of small, single-purpose scripts. The agent decides what to do and in what order; the scripts do the actual work the same way every time. If you let the agent improvise the work itself on every run, you get a slightly different pipeline every week.

A few of the scripts the agent ends up running:

Build them one at a time and have the agent test each before moving on. For example:

"Create a script that searches [your data vendors] for this campaign's criteria, removes duplicates and anyone we've already contacted, and writes a list file. Fail loudly if results come back suspiciously low; that usually means a filter is misconfigured, not that the market is small."

Step 3: Create the template

Now ask your agent to create a template in Runtime. The template is the brain of the factory: it holds the repo, the secrets, the skills, and the scheduled agent, so every run boots with the same context.

"Create a Runtime template from this repo, with network access to our sourcing, sending, Slack, and CRM APIs."

Add your vendor API keys from the Runtime dashboard, under your template's secrets, rather than pasting them into a chat. Runtime hands them to the agent when it runs, and they never show up in a conversation or a log.

One check before you trust it: ask the agent to confirm each key is the one you meant to use, not an old one saved under a similar name. A wrong key fails in ways that look like a broken tool.

Step 4: Ask your agent to write skills

Skills are markdown documents of durable knowledge, the same idea as skills in Claude Code, attached to the template so every future run loads them instead of rediscovering things. Ask your agent to write one per topic as it learns:

"Write what you've learned about [vendor]'s API into a skill: which endpoints under-report, which fields are misnamed, what a valid request looks like. Attach it to the template and confirm new sessions load it."

Good skill topics for this system:

• Vendor API quirks the docs don't mention
• Your copy voice, with examples of what worked and what didn't
• Segments that already failed, and why

Step 5: Schedule the agent

One prompt turns the setup into a running factory:

"Schedule this template's agent to run every weekday morning. On Mondays: read the current campaign brief, source and dedupe a lead list, draft copy, and post a proposal to Slack. Every day: push anything a human approved, sync yesterday's results, and triage new replies. Never take an action that reaches a prospect without approval."

The prompt is the agent's operating manual, and two habits make it work harder:

• Say why, not just what. "Prefer warm lists, they convert several times better than cold" produces better judgement than "prefer warm lists".
• Name the failure you're preventing. "Post the proposal as plain text; don't paste raw JSON into Slack" only makes sense as a rule once you've seen the alternative.

From here you manage the factory the same way you built it: through your local coding agent, which can read the scheduled runs, update the prompt, and adjust the scripts.

What stays human, permanently

One design implication: make the agent behave differently for a new campaign than for a continuing one. A segment with campaign history can run autonomously and report. A new segment should stop before spending money and open a conversation: here's what I'd target, here's the evidence for and against, here's the copy.

Lessons that cost the most

1. Save everything to git. Each scheduled run starts from a fresh copy of the repo, so anything today's run produces for a later run must be committed and pushed. If it only exists inside one session, the next run will never see it.

2. Double-check before the steps you can't undo. Some sender platforms say "success" to a request that silently did nothing. Find the actions you can't take back, like pushing a list live, and have a script verify the data right before each one.

3. Learn your copy from your own replies. Pull every thread you've opened, separate the ones that earned replies from the ones that got ignored, and look at what's different. Most teams find a few simple patterns explain most of it, and that their most personalized messages aren't the ones that convert.

4. Filter with the vendor's categories, not keywords. Matching keywords against how companies describe themselves misses most of the market, because companies don't describe themselves the way your filter expects. Use the vendor's own industry categories instead, and when a filter returns a suspiciously small market, suspect the filter.

Measuring it

Decide up front which number you'll read, and size the campaign for it:

• Cold outbound converts at roughly 5-10% accept and 1-3% reply. A small list produces one or two replies, which can't distinguish a good message from a lucky one.
• Accept rate stabilizes around 100-150 sends per segment, so it's the readable metric in week one. Reply rate isn't, at any volume you can send.
• Track all the way to booked calls, otherwise you're only ever measuring replies. Sort call recordings by type (internal, investor, vendor, customer) before matching them to campaigns, since a lead can match a call by name without being a real prospect conversation.

Then look at where booked calls actually come from: outbound versus referrals, network, and inbound. Most teams are surprised by the split. Build the factory anyway, since outbound is the most mechanizable channel you have, but let attribution decide how much to feed it.

A realistic timeline

Budget most of the time for vendor APIs rather than for the agent. Most of the lessons above are about a vendor behaving differently from its documentation.

The point

The factory doesn't make outbound good. It makes outbound cheap, repeatable, and measurable, which means the quality of your pipeline becomes a function of the quality of your decisions instead of the size of your team. Write a better brief, get a better week.

Back to planning.

---