The Conductor Pattern

A drop-in multi-agent stack for running go-to-market work inside Claude Code: one conductor that owns the pipeline, and three narrow specialist sub-agents that each do exactly one job and hand back structured data.

Most people building "agent swarms" wire five agents together, let each one freelance, and discover three weeks later that the research agent quietly started writing emails, the copy agent pushed a sequence nobody approved, and a silent retry burned half their enrichment credits. This repo is the opposite. It is boring on purpose. The boring part is what makes it run without you watching it.

The pattern in one paragraph

A conductor reads a campaign brief and dispatches work to specialists in a fixed order: find the signal, enrich the matches, draft the copy. The conductor never does specialist work itself, and no specialist reaches outside its lane. Every handoff is a typed payload validated against one schema, not a wall of prose. Nothing leaves the building until a human approves a dry-run preview. When anything looks wrong, the run halts and surfaces the anomaly instead of retrying in the dark.

Why this beats one big agent

A single agent told to "find prospects, enrich them, and write the emails" has no seams. When the output is wrong you cannot tell which step failed, and the agent will happily paper over a bad enrichment with confident copy. Three things separate a stack that runs unattended from one you babysit:

1. Separation of concerns. The research agent is structurally forbidden from drafting copy. The copy agent cannot push to a sequencer. Each charter names what the agent must refuse. A capability an agent does not have is a failure mode you do not have to debug.
2. Structured handoff. Specialists return a typed payload (agent, status, payload, confidence, tool_log, anomalies), not free text. The conductor validates against schema/dispatch.schema.json before it moves on, so a malformed stage fails loudly at the seam instead of corrupting the next one.
3. Safety rails as defaults, not options. Dry-run is the default. The only path to an external send is an explicit human approval gate. A non-OK status halts the pipeline. There is no silent retry anywhere in the stack.

Repo structure

gtm-conductor-pattern/
├── README.md
├── REPO-RULES.md            # the non-negotiable rules every agent inherits
├── LICENSE
├── .gitignore
├── .claude/
│   ├── agents/
│   │   ├── conductor.md      # orchestrator. owns control flow, does no specialist work
│   │   ├── signal-scout.md   # read-only. finds accounts matching a buying signal
│   │   ├── enricher.md       # waterfall enrichment with a coverage gate
│   │   └── copywriter.md     # drafts copy. cannot push to any sequencer
│   └── commands/
│       ├── preview-campaign.md  # /preview-campaign: dry-run, zero external calls
│       └── run-campaign.md      # /run-campaign: full pipeline, approval-gated send
└── schema/
    └── dispatch.schema.json  # the one contract every sub-agent returns

What it targets

Input: a campaign brief, which is a short text or YAML block naming (a) an ICP, (b) one buying signal to hunt for (a hiring pattern, a funding event, a technographic change, post engagement, a job sighting), and (c) a channel (email or LinkedIn).

Output: a dry-run preview containing a scored account list, enriched and verified contacts, and rendered copy drafts. On explicit approval, and only then, the conductor hands the approved drafts to your sequencer.

How to tune it for your own signals

Open .claude/agents/signal-scout.md and edit the Signal definitions block. That is the one place that knows what a buying signal looks like for your market. Add your own: which job titles in a posting count, which funding stages matter, which technographic move is a trigger. Then set your ICP in the brief. The conductor, enricher, and copywriter do not need to change when your targeting does; only the scout's signal definitions do. That separation is the whole point.

Why this matters

Cold outreach against static lists has cratered to roughly 3 percent reply rates. The teams pulling 10 percent are not sending more, they are sending against live signals with copy tied to the event, not the segment. But a signal-driven motion has more moving parts, and more moving parts is exactly where unsupervised agents go wrong. The conductor pattern lets one operator run signal-driven campaigns at the cadence of a small team without the stack quietly doing something you did not sanction.

How to run it

1. Copy the .claude/ and schema/ folders into your project root.
2. Set the env vars listed in REPO-RULES.md (your enrichment, search, and sequencer keys).
3. Run /preview-campaign with a brief. Read the dry-run. Nothing has left your machine.
4. When the preview is right, run /run-campaign with the same brief and approve at the gate.

/preview-campaign "ICP: seed-to-Series-A B2B SaaS, 10-50 staff, US. Signal: posted a first GTM hire in the last 30 days. Channel: email."

Built by The GTM Architects, 2026. For technical founders and lean GTM operators who want the machine to run without babysitting it.