Claude Code for GTM Engineering: Outbound

Q: Can Claude Code run LinkedIn outbound campaigns?

Yes, through an MCP server. Add GTM Bud with claude mcp add --transport http gtm-bud https://gtmbud.com/mcp and sign in. Claude Code can then create campaign drafts, preview prospects, write offers and messages, read results and prepare replies. A launch needs your confirmation, and the agent shows each reply for your review.

Q: Where should campaign definitions live in a GTM repository?

One Markdown file per campaign in a folder such as outbound/briefs. The file holds the audience sentence, the reasons, the offer idea, the rules for replies and the campaign ID once the draft exists. GTM Bud holds the live state. The file holds the intent and the history of decisions.

Claude Code for GTM engineering usually stops at the edge of the repository: the enrichment scripts, the notes and the SQL live in files, and outbound lives in browser tabs. You can close that gap with a routine of four parts. Campaign briefs are files. The agent builds campaign drafts from them through an MCP connector. Results are appended to a log file. A written review comes before each launch.

This article is for a GTM engineer who already works in Claude Code with a repository of notes and scripts. It uses the GTM Bud connector as the sending layer. The setup command is on GTM Bud for coding agents, and it is this one:

claude mcp add --transport http gtm-bud https://gtmbud.com/mcp

Start Claude Code. It asks you to sign in to GTM Bud. Sign in in the browser and select Allow. Codex and Cursor take the same address, https://gtmbud.com/mcp, in their MCP settings.

What goes wrong when outbound lives in tabs?

Three things go wrong, and each one is a missing file. Nobody can say why a campaign targets who it targets, because the reason was a conversation. Nobody can diff this month’s audience against last month’s, because the old one was overwritten in a form. And nobody reviews a launch, because there is nothing to review except a screen.

A repository fixes the first two for code. The routine below does the same for campaigns, with one honest caveat that shapes everything: GTM Bud holds the state, and your repository holds the intent. The two are not synced. The agent is the only thing that connects them, and only when you ask.

The repository layout

outbound/
  CLAUDE.md            rules for the agent in this folder
  briefs/
    2026-10-fintech-cfo.md
    2026-10-logistics-ops.md
  reviews/
    2026-10-fintech-cfo.review.md
  log/
    results.md         appended, never rewritten
    decisions.md       one line per change, with the reason
  playbooks/
    account.md         a copy of the account reply playbook

Four folders, four jobs. Briefs say what you want. Reviews say who checked it. The log says what happened. Playbooks are a readable copy of the reply rules that GTM Bud holds.

Part 1: What is in a campaign brief?

A campaign brief is one Markdown file that a new teammate could read and rebuild the campaign from. It has six parts.

# Fintech CFO, UK, October

campaign_id: (empty until the draft exists)
status: brief

## Audience
CFOs and finance directors at fintech companies with 100 to
600 employees in the United Kingdom that are regulated by the FCA.

## Why this audience
Three of our last five customers. Source: notes/closed-won-q3.md

## Seller
Website: example.com
LinkedIn profile: the personal profile of Amara (Head of Sales)

## Offer idea
A written benchmark of month-end close time against 20 UK fintechs.

## Reply rules for this campaign
- Price question: no number, offer a call with Amara.
- "Send me something": send the benchmark outline, ask one question.

## Not in scope
No companies under 100 people. No crypto exchanges.

Two details matter. The campaign_id line starts empty, and the agent fills it after create_campaign_draft returns. Most tools need that ID, so the brief becomes the place where a file and a campaign are tied together. And the seller section names a personal LinkedIn profile, because the seller profile of a campaign takes a personal profile and a company page cannot launch.

Part 2: How does the agent build a draft from a brief?

The agent reads the brief, writes the targeting criteria from the audience section, and calls the connector. GTM Bud checks the criteria and saves the draft. The order below follows the build order that the server gives the agent, with the seller profile set once the draft exists.

you    Build the draft for outbound/briefs/2026-10-fintech-cfo.md.
       Stop after the prospect preview. Change no other campaign.
agent  Read  outbound/briefs/2026-10-fintech-cfo.md
agent  create_campaign_draft  (name: "2026-10 fintech CFO UK")
       Draft created. 5 criteria. 1 flagged:
       "regulated by the FCA" may not show on a profile or a
       company page. Suggested: "company states FCA
       authorisation on its website".
agent  Edit  brief: campaign_id set, status: draft
agent  Edit  log/decisions.md: "FCA criterion flagged, waiting"

you    Take the suggestion and make it a must-have.
agent  update_campaign_targeting
       All criteria passed the check.
agent  update_seller_profile
       Website and personal profile saved. GTM Bud reads both.
agent  start_prospect_preview
agent  get_prospect_preview
       Preview finished. Cards written to
       reviews/2026-10-fintech-cfo.review.md for marking.

After the preview, the build continues in a second pass, once a person has marked the prospects:

mark_prospect_fit for each mark in the review file.
get_value_offer_brief, then the agent researches and writes the offers, then save_value_offers. If GTM Bud finds problems, it keeps nothing, and the agent fixes and saves again.
get_sequence_brief, then the agent writes one message set for each selected value offer, then save_campaign_sequence. GTM Bud saves the messages only if all its checks pass.
update_reply_playbook for the campaign, from the reply rules in the brief. The agent prints the exact text first, and saves after you approve it.

The targeting, seller profile, value offer and sequence tools change a draft only. They do not change a live campaign. The reply playbook is the exception: it can change while a campaign is live, which is why the agent prints the exact text first. The draft-only rule is a useful property for a file-driven routine: a stale brief cannot rewrite the messages of a campaign that is already sending.

Part 3: What does the results log look like?

The results log is an append-only Markdown table with one row per campaign per reading, and the as-of time in every row. The agent calls get_campaign_results for each campaign and appends. It never edits an old row.

| read on    | campaign               | status | CR sent | CR accepted | replies | interested | unlabeled | as of (UTC)      |
| 2026-10-13 | 2026-10 fintech CFO UK | active |         |             |         |            |           | 2026-10-13 08:02 |

The number cells are empty here on purpose. They would be your numbers.

Three rules for the log:

Record the as-of time. Numbers refresh when someone asks and can be up to about 15 minutes old. The as-of time is the exact time of the calculation.
Record the unlabeled count. Replies are labeled Interested, Warm or Not interested. A high count of replies with no label means the Interested number is not final.
Commit the log. A weekly commit of results.md gives you a history that no dashboard screenshot does. git log -p outbound/log/results.md is your trend view.

For what each number means and how to combine campaigns, see LinkedIn outbound results in your terminal. This article only places the numbers in a file.

decisions.md is the second log, and the more valuable one after three months. One line per change: date, campaign, what changed, why, who said yes.

Part 4: What is the review step before a launch?

The review step is a file that a second person fills in before anyone types “launch”. The agent prepares it. A person signs it.

# Review: 2026-10 fintech CFO UK

[ ] Brief and saved targeting agree (agent: diff below)
[ ] Every previewed prospect marked by Amara
[ ] Full sequence read by a person (pasted below)
[ ] get_launch_readiness: no open item
[ ] Launch preview read at launch time

Reviewer:            Date:

Each line has a reason.

Brief and targeting agree. The agent calls get_prospect_preview, which returns the current targeting, and prints the difference from the brief. This catches a change that someone made on gtmbud.com.

Prospects marked. By the person who knows the buyer, not by you.

Full sequence read. The agent calls get_campaign_sequence and pastes every message. The launch preview shows the first message of each channel only, so the review file is where the second and third messages get read.

Readiness. get_launch_readiness returns a checklist, and each open item says what to do. Typical open items are outside the terminal: a LinkedIn account that is not connected, no sending account chosen, no schedule set. Those three are done on gtmbud.com. A launch also needs an active plan or trial.

Launch preview. launch_campaign always takes two calls. The first returns the preview and a token. The agent calls again only after you agree in the session.

Put the rule in outbound/CLAUDE.md so the agent holds the line for you:

Never call launch_campaign unless reviews/BRIEF-NAME.review.md has
every box ticked and a reviewer name. If it does not, print the
open boxes and stop.

This is an instruction to your agent in your repository. GTM Bud does not read it. The second call of the launch is the control that GTM Bud itself applies.

A week in the routine

Day	You type	Files that change
Monday	“Append results for every active campaign”	`log/results.md`
Tuesday	“Build the draft for the new brief”	brief, `log/decisions.md`
Wednesday	“Prepare the review file for the fintech draft”	`reviews/...review.md`
Thursday	“The review is signed. Launch.”	brief status, `log/decisions.md`
Daily	“Replies that need an answer”	none, unless a rule changes

Replies stay out of the files on purpose. The agent reads a conversation, writes an answer from the playbooks, and shows it. You approve the exact text, and GTM Bud instructs the agent to send only that. When the same question arrives three times, the rule goes into the playbook and a line goes into decisions.md.

Five prompts for the routine

“Read every file in outbound/briefs with status draft and tell me which ones have a campaign_id that list_campaigns does not return.”
“For the logistics brief, print a diff between the audience section and the targeting that GTM Bud holds now. Change nothing.”
“Get the account reply playbook and write it to outbound/playbooks/account.md. If the file differs from what GTM Bud returns, show me both versions.”
“Append one row per active campaign to outbound/log/results.md with the as-of time, then commit with the message ‘outbound: weekly results’.”
“Prepare reviews/2026-10-logistics-ops.review.md: paste the full sequence, the readiness checklist and the list of prospects that still have no mark.”

Three limits to plan around

No sync. A brief does not update when the campaign changes, and the campaign does not update when the brief changes. The diff prompt above is the whole mechanism. Run it before each review.

No unattended run. The sign-in happens in a browser, a launch needs your agreement in the session, and replies are shown for your review. A scheduled job that launches campaigns at night is not what this connector is for.

No list in, no file out. The connector does not take a lead list from your enrichment scripts. Targeting is a description and criteria. And GTM Bud does not produce a report file. The log exists because your agent writes it.

Frequently asked questions about Claude Code for GTM engineering

Can Claude Code run LinkedIn outbound campaigns?

Yes, through an MCP server. Add GTM Bud with claude mcp add --transport http gtm-bud https://gtmbud.com/mcp and sign in. Claude Code can then create campaign drafts, preview prospects, write offers and messages, read results and prepare replies. A launch needs your confirmation, and the agent shows each reply for your review.

Where should campaign definitions live in a GTM repository?

One Markdown file per campaign in a folder such as outbound/briefs. The file holds the audience sentence, the reasons, the offer idea, the rules for replies and the campaign ID once the draft exists. GTM Bud holds the live state. The file holds the intent and the history of decisions.

Does GTM Bud sync with my repository?

No. GTM Bud knows nothing about your files. The agent reads a brief and makes tool calls, and the agent writes what came back into a log. If someone changes a campaign on gtmbud.com, the brief does not change. Ask the agent to compare the two before each launch.

Can I run this workflow from cron or a CI job?

It is not built for that. The connector uses a browser sign-in, a launch needs your confirmation of a preview in the session, and the agent shows each reply for your review. Plan for a session with a person in it.

What should a pre-launch review check?

Five things: the brief and the saved targeting say the same, the founder or sales lead marked previewed prospects, every message in the sequence was read by a person, the readiness checklist has no open item, and the launch preview was read before the confirmation.

Put outbound in the repository, one brief at a time

Claude Code for GTM engineering gets more useful when outbound follows the same habits as the rest of your work: intent in files, changes with reasons, a review before anything ships. Start with one brief and one review file for your next campaign. The page on AI LinkedIn outreach for GTM engineers lists the steps that happen outside the terminal. If you have several audiences and no ranking yet, run five ICP hypotheses in one week first. If you are new in the role, the first 30 days outbound plan puts this routine on a calendar.