[KongchangAI]
· 2 min read· 1,302 words

n8n in Practice: Building a Trustworthy AI Lead Intelligence and Outreach Automation System

n8n in Practice: Building a Trustworthy AI Lead Intelligence and Outreach Automation System

A three-workflow n8n system uses deterministic rules and human approval to keep AI hallucinations out of sales lead decisions.

Developer Daniel Sarsha built an n8n-based lead intelligence and outreach system targeting private doctors in Hong Kong. Three workflows handle discovery via Tavily, trust-layer verification with deterministic qualification checks and a second research pass for conflicting evidence, and human-approved outreach via Slack before any email is sent. The core philosophy: AI handles flexible, low-risk research and drafting, while rules engines and human review control all high-stakes decisions — keeping hallucinations architecturally isolated from critical actions.

The biggest risk of using AI for sales lead generation isn't a lack of efficiency — it's a lack of trustworthiness. Hallucinated email addresses, fabricated job titles, and repeated outreach to the same prospects can turn an automated system into a liability. Developer Daniel Sarsha shared on YouTube a lead intelligence and outreach automation system built on n8n that offers a well-engineered answer to this problem: use deterministic rules and human approval to keep AI within clearly defined boundaries.

The system targets private doctors in Hong Kong as its lead pool and consists of three independent workflows responsible for discovery, verification, and outreach respectively. The core design philosophy is to strictly separate what AI is good at — research and drafting — from high-stakes judgments it shouldn't make on its own.

Workflow 1: Lead Discovery and Data Extraction

The first workflow handles lead discovery. Given a research request, it automatically generates targeted search queries, uses Tavily to search publicly available web sources, filters for relevant pages, and then uses AI to extract doctor data backed by verifiable sources.

The key detail here is "source-backed." Extracted records are standardized, fully duplicate entries are removed, and candidate leads are stored in a PostgreSQL database. At this stage, AI acts as an information extractor rather than a generator — all data must be traceable to a public source, laying the groundwork for the trust layer that follows.

Tavily is a search API designed specifically for AI agents. Unlike general-purpose search engines, it returns refined, structured content rather than raw lists of web links, making it particularly well-suited as the information-gathering foundation layer in automated workflows. In this system, Tavily plays the role of "controlled retrieval": AI generates the search queries, Tavily executes them and returns source pages with verifiable citations, and AI then extracts specific fields from those pages. This is fundamentally different from asking AI to "recall" or "infer" contact information. The former has a clear source URL for every data point; the latter is highly prone to hallucination — for example, guessing a plausible-looking but nonexistent email address based on common naming conventions.

Workflow 2: Trust Layer and Deduplication Verification

The second workflow is the trust core of the entire system. Each candidate lead is independently validated across multiple dimensions: the doctor's identity, specialty, whether they are located in Hong Kong, whether they qualify as a private service provider, and their current practice status.

The design philosophy here is worth examining closely. For records with uncertain or conflicting evidence, the system doesn't blindly accept them — instead, it routes them to a second research pass for re-verification. Daniel explicitly states: "AI helps interpret the evidence, but the final qualification determination is deterministic." This single sentence captures the soul of the entire system — AI output does not automatically enter the final lead database; it must pass through a rules-based validation gate first.

Duplicate records are handled by first standardizing names and providers, removing exact matches, then comparing possible aliases

Deduplication is handled with considerable care. The system standardizes doctor names and provider names, removes exact duplicates, and then further compares possible aliases. This handles the tricky cases where the same doctor appears under slightly different names, or appears repeatedly across multiple websites.

Email discovery also adheres strictly to an evidence-driven approach. The workflow never guesses email addresses. Instead, it checks whether the email is publicly associated with that specific doctor, validates the syntax, uses deterministic rules to exclude HKU (University of Hong Kong) related domains, and detects duplicate emails.

Provider qualification checks are one of several quality gates

Before any data is written to the database, the system applies a final set of quality gates that incorporate doctor verification, provider qualification, deduplication, email validation, existing database checks, and outreach history. Only leads that pass all rules are marked as qualified and stored.

The distinction between "deterministic rules" and AI inference is key to understanding this system's architecture. AI model outputs are inherently probabilistic — the same input may produce different results across runs, and the model cannot guarantee factual accuracy. Deterministic rules, by contrast, are hard-coded logical checks: is the email format valid? Is the domain on the exclusion list? Does the same record already exist in the database? These checks produce exactly the same result every single time, unaffected by model state. The design principle of combining both approaches is to confine AI to the role of "interpreting evidence and summarizing information," while delegating decisions with downstream consequences — like whether a lead qualifies for the database — to a rules engine that doesn't make random errors. This is precisely why the system can provide predictable guarantees around data quality while still retaining the flexibility that AI offers.

Workflow 3: Human-Approved Outreach

The third workflow handles the actual outreach actions. It loads qualified leads, confirms that an email is available and verified, checks whether that lead has been contacted before, and then generates a personalized outreach draft based solely on verified lead data.

AI returns a structured email subject, body, and "personalization rationale." There are explicit constraints here as well: the AI must not fabricate achievements, services, or any claims that lack evidentiary support. This hard constraint on AI output is critical to preventing outreach content from going off the rails.

Outreach drafts are generated solely from verified lead data

The most valuable step from an engineering perspective comes here: every draft is pushed to Slack for human review before sending, and the workflow pauses to wait. The reviewer can approve or reject the email. In the demo, Daniel approves an example draft.

The complete outreach event is written to the database, creating an audit trail and preventing duplicate outreach

Once approved, the prototype simulates the send action, writes the complete outreach event to PostgreSQL, and updates the lead status. This creates an audit trail and prevents the same lead from being contacted again in future runs.

Using Slack as the human approval touchpoint is a textbook implementation of n8n's "Human-in-the-Loop" pattern. n8n supports pausing workflow execution at specific nodes and waiting for an external response — only after a reviewer clicks approve or reject in Slack does the workflow continue downstream. The engineering value of this design lies in embedding human oversight inside the automation pipeline, rather than relying on operators to manually check results and take action outside the system. For actions like sending outreach emails that cannot be recalled once dispatched, forcing a pause at the workflow node level is far more effective than after-the-fact auditing. Additionally, all approval records and final actions are written to the database, forming a traceable operations log — particularly important for industry contexts with stricter compliance requirements.

Final Output and Architectural Takeaways

Each qualified lead record stored in PostgreSQL includes the doctor's name, specialty, affiliated hospital or clinic, geographic location, email address and verification status, source URL, final lead status, and any relevant verification notes. The result is a structured, fully traceable lead list.

Daniel summarizes the core technical decision as: completely separating the discovery, verification, and action phases. AI handles research and drafting — low-risk work that benefits from flexibility — while deterministic rules and human approval firmly control all high-stakes decisions.

The value of this system isn't in the sophistication of the models it uses. It's in what it demonstrates about a mature approach to AI engineering — one that acknowledges large language models will hallucinate, and then uses architectural design to keep those hallucinations away from critical decisions. For any team looking to deploy AI into real business processes, especially those involving external communications, this layered approach of "AI assists, rules provide the safety net, humans hold the final check" is far more worth emulating than chasing full automation for its own sake.

#n8n automation#AI lead generation#sales outreach automation#human-in-the-loop#deterministic rules#AI hallucination prevention#lead verification workflow
Share:

Related articles