How RevReply works.
The runtime loop that handles every reply, every follow-up, every channel switch. Same loop for every customer. Different setup per customer.
The pattern
Interrupt and inject.
Most automation systems run from a script. The script decides what happens next. The customer trusts the script — until the real conversation does something the script wasn't built for.
RevReply doesn't run from a script. It runs from a loop. Every outbound action — every email, every CRM write, every CC, every channel switch — pauses the system, pulls fresh context, and regenerates the action against the latest state.
That's interrupt-and-inject: the loop interrupts itself before taking action, injects whatever has changed (new signals, new configuration, new replies, new CRM state), and only then decides what to do.
In practice
- No fixed scripts. Each step is a fresh decision against the latest state.
- Configuration is the only thing scripted. The runtime loop reads it on every event.
- Every send is auditable: the loop logs which signals it pulled and why.
The runtime loop
Six phases. One loop. Runs on every event.
The interactive diagram below is the same loop the runtime executes for every customer. The boxes you see are the ones we've built so far.
Diagram not rendering? Open the full board in Miro.
The six phases
What happens between trigger and writeback.
Phase 01
Triggers
Every event that should make RevReply think — an inbound reply, a stage change in your CRM, a calendar update, a scheduled follow-up firing. Each becomes an event on the queue.
In Riipen's case
When Marcus replies to the Internship outreach, that's a trigger. When his CFO loops back two days later, that's another. When the Mar 13 follow-up fires because he went quiet, that's a third.
Phase 02
Interrupt — the pause-before-sending
Before any outbound action, the system stops. It doesn't trust the prior plan. It doesn't trust the template. It pauses to read state.
In Riipen's case
When Marcus replies, RevReply doesn't run the next message in the sequence. It interrupts and asks: given what just changed, what should happen next?
Phase 03
Context assembly
Pull the customer's configuration, fetch fresh signals (LinkedIn, news, hiring data, sales call notes), check the context-usage ledger to avoid repetition, look at past channel performance.
In Riipen's case
For Marcus, RevReply pulls the new LinkedIn signals (his team just expanded), the existing ledger (LinkedIn role mention used in initial reply), and the channel scores (LinkedIn at 0.84).
Phase 04
AI decision
Pick a channel. Pick a tone (per the assigned profile). Decide whether to send, hand off to a human, or spawn a sub-thread. Generate the message body against the latest state.
In Riipen's case
The AI chooses LinkedIn (highest score, fresh engagement signal), Operations and finance profile, and generates a message that ties to the hiring signal without re-using LinkedIn role mention.
Phase 05
Action
Send the message — or open a Slack review thread for human-in-the-loop review, or spawn a sub-thread to the CFO, or update a CRM field. The system supports many action types.
In Riipen's case
RevReply spawns a sub-thread to Sarah Chen (CFO) with a tailored intro CCing Marcus. The Slack #revreply-followup channel gets a notification for review before the message goes out.
Phase 06
State writeback
Update everything: the context-usage ledger, the channel scores, the CRM stage, the activity log. The next trigger will see the new state.
In Riipen's case
Marcus's ledger now shows hiring activity used in this LinkedIn message. The CRM stage moves from Engaged to Demo Scheduled. The Mar 18 reply will work off this updated state.