Reply Engine
Status: production on my own outbound. Sends without approval, inside hard rails.
Problem
Cold email dies in the gap between a reply landing and a human answering it. I also learned the hard way that a slow reply costs far less than a confident wrong one: a draft that ignores something the prospect said two messages ago.
How it runs
A reply comes in and the engine fetches the entire conversation, both directions, before drafting a word. Not the latest message, the whole thread. That rule exists because an early version drafted from the newest message only, and a prospect's condition stated three messages earlier got steamrolled. A page-capped pull is not the thread.
Each prospect gets a small recipe built from their own context: who they are, what they sell, what we've already said. The draft then has to survive a validator gauntlet before sending. Two examples of the rails:
- A calendar link goes out only when the prospect actually asked to talk. "Tell me more" gets an answer, not a booking page. The default close is "say the word and I'll find a time."
- Formatting and claim checks run on every draft: no invented facts about them, no salesy tells, length caps.
Anything the validators can't clear escalates to a human review card instead of sending. Tripwires watch aggregate behavior (bounce spikes, odd volumes) and pause the whole layer if something looks wrong.
Stack
Node on an always-on VM, webhooked to the sending platform, with the validator gauntlet as plain testable functions. Escalations land as cards on my task board, so a stuck conversation stays visible instead of dying in an inbox.
Worth stealing
Validate the context, not just the output. Most people gate their AI drafts on tone and format. The violations that actually cost you deals are context violations, and a gate that never saw the full thread can't catch them.