An Outbound Engine That Researches Every Lead Before Drafting
Chronexa’s live outbound system combines company research, trigger detection, solution routing, personalised drafting, human approval, campaign delivery and failure recovery in one auditable pipeline.
- Proof basisRunning inside Chronexa
- IndustrySales & Revenue Operations
- Year2026
- ServicesAI Agents, Sales Automation, Data Enrichment
Verified against Chronexa’s active n8n workflow and architecture documentation. This study describes the running system and its controls; it does not claim a reply-rate or revenue lift that has not been independently measured.
The short answer
Chronexa built an n8n outbound engine that researches a company before it drafts an email. It combines Apollo or spreadsheet lead data with Exa web research, writes the evidence and draft to Baserow, waits for human approval, then sends approved records to ManyReach. Retries, duplicate checks and a dead-letter queue stop failures from disappearing.
Tools and systems used
- n8n
- Apollo
- Google Sheets
- Exa
- Anthropic
- Baserow
- ManyReach
- REST APIs and webhooks
The problem was not writing emails
The slow part of serious outbound is deciding why a company is worth contacting now. A researcher checks the business, role, technology stack and recent changes, then maps that evidence to a credible problem. At volume, teams either abandon the research or spend most of the day assembling it.
Chronexa needed a system that could increase research coverage without turning uncertain AI output into an automatic send.
Failure had to be visible
External research APIs return gaps. Models occasionally produce malformed output. Leads can be duplicated across lists. A useful production system needed explicit retry, duplicate and dead-letter paths instead of a single optimistic chain.
How the workflow runs
- Normalise the lead
A feeder cleans names, roles, company domains and source fields before research begins.
- Research two sources
Exa checks recent public coverage and the company website so the draft is not based on one weak signal.
- Route the problem
The model maps the evidence to a relevant Chronexa solution and returns structured output.
- Draft the sequence
The engine prepares a short opening email and follow-ups, with the source context kept beside the copy.
- Hold for review
Baserow acts as the review queue. A person edits, approves or rejects the record.
- Send and track
Only approved, non-duplicate records are pushed to ManyReach on the scheduled sync.
The running system
A feeder normalises each lead before the engine searches recent company news and crawls the company website. The result is classified into a solution family, then used to draft a short initial email and follow-ups. The draft, its evidence and routing decision are written to a human review queue.
Approved records move to ManyReach on a scheduled sync. The system checks for duplicates before queueing, separates legitimate skips from API or parsing failures, retries recoverable errors and sends the rest to a dead-letter queue with the failed stage attached.
The operational result
A reviewer starts with a researched draft and the source context instead of a blank page. More importantly, the team can see why a lead was routed, whether it was approved, when it entered a campaign and where failures occurred. The system scales the preparation work while keeping sending authority with a person.
Why this is more than an email writer
The useful part is the state machine around the model. Each lead moves through named stages: received, researched, drafted, awaiting review, approved, synced or failed. Baserow holds the operational state. n8n performs the work. ManyReach only receives an approved record. This separation prevents a model response from becoming a send command.
The research stage uses Exa search and page content calls. Anthropic receives selected evidence and must return a fixed JSON shape. n8n validates that shape before the record can move forward. A parsing error is treated as a system error, not as an empty research result.
What we can and cannot claim
The running system reduces the preparation needed for each reviewed lead and makes research traceable. We do not publish an invented reply-rate or pipeline number. Those outcomes depend on the list, offer, domain health and reviewer decisions. The case study shows the production architecture and control points that are verified in Chronexa’s live workflow inventory.
Safeguards and failure handling
- No lead enters a sending campaign without human approval.
- Duplicate checks run before records are queued.
- Recoverable API and model failures are retried; unresolved jobs go to a dead-letter queue.
- The failed stage and source evidence are kept so an operator can diagnose the problem.