The enrichment layer is where outbound systems die

Outbound systems rarely die where people expect. Sending email at scale is a solved problem. Building lists is a solved problem. The place systems actually die is the middle: the stretch between "a prospect replied" and "someone sent them something worth replying to." That stretch is the enrichment layer. It is where the third-party data lives, where the timeouts happen, and where the silent corruption creeps in.

This post walks through the anatomy of our own reply-to-deck pipeline, the same architecture we deployed for Breez. Not the whiteboard version. The running one, including the parts that exist only because something broke.

The moment of maximum value

An interested reply is the most valuable event an outbound system produces, and the most perishable. The prospect is paying attention right now. Every hour between their reply and a substantive response burns intent. So the design goal is specific: when a real reply lands, everything up to the final send should already be done by the time a person looks at it.

Here is what actually runs, stage by stage.

Stage 1: reply detection. Webhooks monitor the email and LinkedIn inboxes continuously. Each new reply is classified: genuine interest, polite decline, or a question. Only interested replies trigger the rest of the pipeline, and every detection posts to a dedicated Slack channel so the team sees the deal the moment it exists.

Stage 2: research. Two sources run for every interested lead: Perplexity researches the company, and Apify scrapes its website. The results merge into a single research record. The edge cases are handled in code, not by hope. No website on file: skip the scrape rather than stall. Scrape timeout: continue with partial data, flagged as partial. Scraped content too long for downstream prompts: truncate it, a rule that exists because the pipeline once choked on exactly that and the fix was written into the directive so it never recurs.

Stage 3: strategy, in three passes. Strategy generation is not one heroic prompt. It is three narrow model calls in sequence: a research analyst pass that extracts hooks and pain points from the merged record, a calculation pass that works through the prospect's cost and savings math, and a message writer pass that drafts the actual follow-up. Each pass does one job and hands a structured result to the next. When output quality drops, you can see which pass drifted instead of staring at one giant prompt wondering where it went wrong.

Stage 4: deck assembly. The structured strategy data is flattened into template tokens and PandaDoc assembles a personalized proposal, 40+ data points per deck. Proposal creation becomes a pipeline stage measured in minutes, not an afternoon of copy-paste.

Stage 5: the gate. The drafted message and finished deck land in Slack and the pipeline stops. A person reviews, edits if needed, and sends. The machine never talks to a live deal. This is not a temporary training wheel. It is the permanent design: automation runs to the edge of consequence, and a human owns the crossing.

One reconciled record per lead

The structural decision that makes the five stages reliable is unglamorous: every stage reads from and writes to a single reconciled record per lead.

Compare that with the default stack most teams assemble: a CRM, a separate enrichment tool, a sequencer, and a proposal tool, each holding its own copy of the lead. Those copies diverge quietly. The enrichment tool has the old company name, the sequencer has a different contact, the proposal pulls numbers from a third place. Nobody notices until a prospect receives a deck addressed to the company they left last year. The error was not in any one tool. It lived in the gaps between them, which is exactly where nobody is looking.

A single record removes the gaps. Research appends to it, strategy reads from it, the deck is generated out of it, and the Slack review shows it. When something looks wrong at the gate, there is one place to check.

Compliance is plumbing, not a policy doc

Canadian commercial email lives under CASL, and the honest way to handle that is to build it into the sending layer rather than write a memo about it. In the deployed system, every message identifies the sender, unsubscribes actually work, and delivery is warmed up and throttled rather than blasted. The Breez engine was built to respect CASL from the first send. Compliance you have to remember is compliance that eventually fails; compliance in the plumbing does not depend on anyone's memory.

Why this layer kills systems

Step back and the pattern is clear. The enrichment layer is the only part of an outbound system built almost entirely on inputs you do not control: other people's websites, third-party APIs, scraped pages, rate limits. Demos assume those inputs cooperate. Production knows they fail weekly.

So the architecture assumes failure. Every stage either completes or reports exactly what is missing, to a channel humans actually watch. Partial data is labeled partial instead of masquerading as complete. And the final gate means the worst case of any upstream failure is a person catching it in Slack, not a prospect catching it in their inbox.

If your outbound system cannot tell you, precisely, what happens when an enrichment call times out, that is the place to look before adding more volume. The insights are free. If you want a pipeline like this pointed at your market, start with the free audit. The plan is yours to keep either way.