We built our outbound system with Claude as the intelligence layer. The architecture has Clay feeding the signals, HubSpot holding the record, Instantly and HeyReach executing the sequences, and Claude in the middle making the decisions that used to need a rep. The system reads signals, scores fit, decides which motion applies, and drafts the outreach to match it.
This isn't a story about Claude's capabilities. It's about what becomes possible when you architect the workflow correctly, and where the design decisions actually matter.
Here's how the system runs.
The problem we set out to solve
Cold outbound in 2026 produces 1 to 3% reply rates. Sending 1,000 emails to book ten meetings, burning through inboxes, watching reply rates erode quarter after quarter. Most teams have accepted this as the cost of doing outbound.
The deeper issue is that 95% of any target market isn't buying anything right now. The 1 to 3% reply rate isn't a copy problem. It's a timing problem. You're reaching people who have no reason to respond, because nothing has changed in their world that would make them want to.
The system we wanted to build does the opposite. It only fires when something has changed at a target account. A new VP. A funding round. A tech stack swap. The information that says this account is actually in motion, right now.
The challenge: detecting and acting on those signals at the speed they decay.
Why signals demand a different architecture
Signals decay fast.
A funding announcement is strongest 2 to 4 weeks after it lands. A new VP hire opens a 30 to 90 day window. A pricing page visit decays inside 5 to 10 days. Past that, the window closes and someone else is in the room.
A rep manually monitoring 200 accounts loses around 60% of high-signal events. The detection latency exceeds the signal's half-life. By the time a human spots it, the moment has passed.
So the system needs to do four things continuously, not on a Monday-morning cadence:
- Monitor the entire target account universe
- Detect signals the moment they fire
- Decide if the signal is worth acting on
- Trigger the right action inside the window
No human team can run all four at the speed and volume this requires. This is the work we architected Claude to do.
The architecture we chose
The system has two agents, designed deliberately as two and not one.
The first agent handles detection and triage.
We built it to monitor across six signal categories: funding events, leadership hires, tech stack changes, hiring surges, news mentions, and engagement signals like pricing page visits.
We picked these six because each one has a documented reply-rate lift in the 3 to 7x range over cold baseline. The signals that score lower than that (general job postings, surface-level web visits) we left out, because the volume they produce dilutes everything else.
When a signal fires, the agent runs enrichment, scores the account against our ICP rules, and routes qualified accounts into the approval queue.
We set the routing window at 24 hours because most signals start losing strength after that. Anything sitting longer than 24 hours, we treat as stale.
The second agent handles personalisation. It takes the enriched account, the specific signal that triggered it, the buyer's posture, and our value proposition, and writes the message.
This is where the most consequential design decision lives.
We built a pre-send QA gate into the agent itself. Every message it drafts gets scored against seven criteria before anything sends: relevance to the signal, specificity to the account, message length, claim accuracy, tone fit, deliverability risk, and CTA clarity.
We set the thresholds at 75 (auto-send), 50 to 74 (human review), and under 50 (blocked).
That gate is the difference between volume and quality at volume. Without it, you scale a generic message across thousands of accounts. With it, the floor stays high even when the throughput goes up.
We chose to keep the two agents separate because they need different prompts, different context windows, and different update cadences. The detection agent needs to evolve as new signal types prove valuable.
The personalisation agent needs to evolve as the value proposition sharpens. Putting them in one agent would mean every update risks breaking unrelated logic.
What sits underneath
The architecture decisions don't end at the agents. The stack underneath them determines whether the whole thing runs reliably.
Clay does the signal detection and enrichment. We picked it because the depth of signal coverage and the credit-transparent enrichment model is the only thing that scales without exploding cost. HubSpot is the system of record. Every decision the agents make lands there: account scored, sequence triggered, deal moved. Instantly executes email and HeyReach executes LinkedIn. Claude sits in the middle, reading from each tool via MCP and writing back to all of them.
The piece most teams underestimate: the CLAUDE.md file.
This is where we encode the institutional logic the agents run on. Our ICP definition, scoring weights, how we classify each of the four buying postures, what action maps to which posture, the tone we use for each segment, the rules for when to skip enrichment and when to deepen it. Without this file, every workflow starts from scratch and produces generic decisions. With it, the system inherits everything we've learned about what works for a given client and motion.
We treat the CLAUDE.md as a living document.
Every time we change a scoring rule or refine an action map, it goes in. Every workflow that runs after that point inherits the change automatically. That's the compounding mechanism.
The architecture gets sharper without the agents needing to be rebuilt.
If you want to see how this fits into a broader GTM stack architecture, [the GTM stack post] goes deeper.
What the system produces
The output is a different motion, not a faster one.
Three or four high-signal accounts surface daily, already enriched, scored, and with a draft message attached. The signal that triggered each one is visible alongside it. The rep approves, edits, or blocks. Anything they block becomes signal we use to refine the agent.
Reps recover two to two and a half hours a day on this system across our client deployments. Reply rates on the agent-drafted outreach hold at 8 to 12%, against the 1 to 3% the same teams were seeing on cold lists. The headcount math changes. A two-person team on this stack produces what a five-person team did on the old motion.
The reps aren't doing less work. They're doing different work.
The hours that used to go into list-building, research, and drafting now go into calls, posture reads, and the conversations that close deals. The system handles the work that follows rules. The reps handle the work that needs judgment.
Where this fails
If you wire this together before you've done the thinking, it doesn't help you.
A weak ICP definition in the CLAUDE.md means the agents confidently route the wrong accounts. Stale enrichment means messages reference things that aren't true any more. A QA gate without a sharp scoring rubric scales mediocre messages alongside good ones.
This is also why we don't deploy this on top of broken outbound motions. If the underlying targeting or message-market fit is wrong, automation only scales the wrong thing faster, into more inboxes at once.
Domain reputation goes first. Reply rates collapse next. Run our Outbound Diagnostic before building any of this. It tells you whether your motion is ready to be automated.
FAQs
1. Can Claude automate outbound sales? The right framing is that Claude can be architected to run outbound autonomously. We design a detection agent, a personalisation agent with a built-in QA gate, and the underlying CLAUDE.md that holds the institutional logic. Claude is the substrate. The architecture is what makes it work.
2. How do we use Claude for lead generation and prospecting? By building agents that monitor buying signals across the target account universe rather than working from static lists. Daily detection across six signal types, automatic enrichment, ICP scoring, and routing inside the signal window. The agents handle the volume. The reps handle the conversations.
3. What does signal-led outbound mean? Reaching out only when an observable event suggests an account is moving toward a purchase. Funding rounds, new executive hires, tech stack changes, pricing page visits. The opposite of spray-and-pray volume sequencing. Reply rates run 4 to 5x higher because every message references something that just happened at the account.
4. How does Claude connect to Clay and HubSpot? Through MCP, which lets the agents read and write to both in real time. Clay feeds signal data and enrichment in. HubSpot is where every decision lands. No exports between tools, no manual data handling.
