Last month I watched a founder demo his "fully autonomous GTM agent" to me on a call. One prompt: find prospects, enrich them, write the emails, load the sequence. It ran for four minutes and produced a campaign. It looked incredible.

Then we read it.

The research step had decided, on its own, that a staffing agency counted as a target account. The enrichment step had found an email at the wrong company and the copy step wrote a confident, personalized first line to a person who does not work there. And somewhere in the middle, a tool call had failed, the agent had silently retried it twice, and burned through a chunk of his enrichment credits before moving on like nothing happened.

The agent was not broken. The architecture was. He had built one giant agent with no seams, handed it four jobs, and had no way to see which one went wrong. When everything is one blob, every failure is invisible until it reaches your prospect's inbox.

This week's release is the architecture I use instead. It is a public repo called the Conductor Pattern, and it is deliberately the least exciting way to wire up agents I could design. That is the point. Boring is what runs unattended.

There is a reason the "one prompt, full campaign" demo always looks better than it works. A single agent told to do four things in sequence has no internal checkpoints. It cannot fail loudly because it does not know where one job ends and the next begins. So when the enrichment is thin, it does not stop. It writes copy anyway, and the copy is good enough to hide the fact that the data underneath it is garbage.

The failure mode is not bad output. It is confident bad output. The model papers over its own mistakes because you gave it permission to keep going no matter what.

The fix is not a smarter model. It is seams. You break the work into agents that each do exactly one thing, you forbid each one from doing anything else, and you make them hand work to each other through a contract you can inspect. When a stage fails, it fails at a seam you can see, and the whole line stops instead of laundering the mistake forward.

The Conductor Pattern is a drop-in folder for any Claude Code project. It has four agents and one rule everyone obeys.

The conductor owns the pipeline and nothing else. It does not research, enrich, or write. It reads a campaign brief, dispatches the specialists in a fixed order, checks each handoff, and gates the send. Think of it as the operator who never touches the work, only the flow.

The signal-scout is read-only. Give it an ICP and a buying signal and it finds accounts that match, identifies the buyer at each, and captures an evidence URL so the signal is auditable instead of asserted. It is structurally forbidden from enriching or writing copy. It finds and it reports. That is all it can do.

The enricher takes the accounts the scout found and fills in verified contact data through a waterfall. It runs a domain-match audit on every email, because a valid email at the wrong company is worse than no email at all. It computes a coverage figure, and if coverage falls below your threshold it stops and tells you which fields came up short. It cannot write a single line of copy.

The copywriter takes the enriched contacts and the original signal context and drafts one message per contact, tied to the event, not the segment. If a draft would read identically with the company name swapped out, the rule is to rewrite it. The copywriter cannot push to a sequencer. It hands the drafts back and stops.

The thing tying them together is a single file: dispatch.schema.json. Every specialist returns the same shape. An agent name, a status, the payload, a confidence score, a log of every tool call it made, and a list of anomalies. The conductor validates that shape before it advances. A stage that returns prose instead of a valid payload gets rejected at the seam.

The repo ships with a REPO-RULES.md that every agent re-reads before it starts. Three rules do the heavy lifting.

Lanes are absolute. Each agent's charter names not just what it does but what it must refuse. The scout must refuse to write copy. The copywriter must refuse to send. If an agent is asked to step outside its lane, it returns a status of OUT_OF_LANE and stops. This sounds rigid. It is. A capability an agent does not have is a failure mode you never have to debug. The founder on that call did not have a "research agent wrote emails" bug because his research agent could write emails. Mine cannot.

Dry-run is the default. Every command starts in preview mode. A real external call happens only when you have explicitly turned off dry-run and approved the preview in the same session. There is no flag that sends without a human in the loop. The /preview-campaign command physically cannot reach a sequencer. You run it, you read exactly what the campaign would do, and nothing has left your machine.

Never retry silently. This is the one that saved me the most money. A failed tool call, a coverage miss, or a low-confidence payload sets a non-OK status and halts the pipeline. The conductor surfaces the anomaly and waits for you. It does not re-run the stage hoping for a better roll. Silent retries are how credits vanish and how bad data gets laundered into output that looks finished.

Here is the part most people overconfigure. You do not need to edit the conductor, the enricher, or the copywriter to point this at your market. They are generic on purpose.

The only file that knows what a buying signal looks like for you is signal-scout.md. It has a Signal definitions block. Out of the box it ships with three: a first GTM hire posted in the last 30 days, a priced funding round in the last 60, and a technographic change in the last 45. Each definition says what the signal is, what counts as evidence, and who the buyer is.

To make this yours, you edit that one block. Add the signal your best customers exhibit right before they buy. Define what evidence is acceptable so the scout cannot assert a signal it cannot prove. Then you set your ICP in the brief and run it. When your targeting changes next quarter, you edit that block again, and nothing else moves. That is the whole reason the work is split this way. Your targeting is the thing that changes most often, so it lives in exactly one place.

Cold outreach against bought static lists has cratered to somewhere around a 3 percent reply rate. The operators pulling double digits are not sending more. They are sending against live signals, with copy tied to the specific event a company just went through, not a segment label.

But a signal-driven motion has more moving parts than spray-and-pray, and more moving parts is exactly where unsupervised agents go wrong. This is the trap of the moment. The same shift that makes signal-first outbound possible, agents that can research and reason and write in one session, is the shift that makes it dangerous to let them run without seams. The answer is not to go back to manual. It is to give the agents a structure rigid enough that one person can run the whole thing and still sleep at night.

That is what the conductor pattern buys you. One operator, running signal-driven campaigns at the cadence a small team used to need, with a stack that stops and asks instead of guessing and sending.

Three steps.

You get back a scored account list, an enriched and verified contact table, and rendered drafts, plus the full tool log and any anomalies the run flagged. Read it. When it is right, run /run-campaign with the same brief, and approve at the gate. Nothing reaches a single inbox before you say so.

The repo is public and MIT licensed. Fork it, gut the signal definitions, and point it at your market. If you build a signal block worth sharing, I want to see it.

More systems like this one are in the library.