AI SDR Agent
The prospect discovery and qualification system operating inside Lucent. This is internal proof, a look at a system Lucent runs on its own business. It is not a product page, and it contains no metrics or client outcomes.
Why this system was built.
Service businesses need a steady flow of qualified, enriched, scored prospects, but manual sourcing and enrichment is slow, inconsistent, and loses data between tools.
Before the AI SDR Agent, there was no durable, observable pipeline that turned a raw lead queue into scored CRM records with end-to-end traceability. The operational problem it solves is the top of Lucent’s own funnel: identifying prospects, validating and enriching their data, scoring them, and writing the qualified ones into the CRM, without losing fields between tools along the way.
Inside the broader operating system, the AI SDR Agent works Lucent’s own outbound. It runs in n8n and is orchestrated, gated, persisted, and surfaced by Lucent OS, which hosts no language-model agents in process. The agent sources and scores prospects into the same record store the rest of the operation reads from, which is what makes it part of a connected stack rather than a standalone tool.
The documented capabilities.
Each capability below is supported by the build documentation. There are no metrics here, because no measured outcomes exist yet, and none are claimed.
Prospect discovery
Pulls candidates from a lead queue and sources business data so the pipeline starts from real prospects rather than a blank list.
Website analysis
Reads each prospect’s website for signals such as the primary problem and pain keywords, so qualification works from real context.
Lead qualification
Scores each lead against ideal-customer criteria through the Lead Scoring Agent before anything is written to the CRM.
Enrichment workflows
Validates and enriches contact data and gathers review signals, then merges the sources into one enriched record per lead.
CRM population
Writes qualified prospects and activity logs back to the CRM, with every record correlated to the run that produced it.
Outreach preparation
Prepares draft outreach content for qualified prospects. Preparation stops at a draft; nothing is sent from this pipeline.
One run, step by step.
A run moves through the pipeline in a fixed order. Each step hands the next a cleaner, enriched record, and the whole run is tracked from trigger to CRM write.
Run is triggered
A run is started from Lucent OS, which forwards it to the n8n AI SDR workflow. The ai_sdr_runs lifecycle opens and tracks the run from start to finish.
Leads are pulled
The workflow fetches candidates from the lead queue as the working set for the run.
Business data is sourced
An Apify Google Maps scraper collects business data, which is normalized into a common shape for the steps that follow.
Website signals are read
A website signal scraper extracts signals such as the primary problem and pain keywords from each prospect’s site.
Reviews are gathered
A reviews scraper collects rating, review count, and a reviews summary for each business.
Enrichment is merged
The enrichment merge step combines the scraped sources into a single enriched record per lead.
Leads are scored
The Lead Scoring Agent scores each enriched lead against ideal-customer criteria.
Outreach is prepared
The Outreach Agent generates draft outreach content for qualified leads. Nothing is sent at this step.
Records are written to the CRM
The record is prepared and written back to the CRM by webhook callback. run_id correlates prospects and activity logs to the run, and created and failed counts are derived server-side.
A timeout in an enrichment step degrades that single record rather than killing the run, so the pipeline keeps moving through transient scraper failures.
AI prepares. A human approves.
The agent does the sourcing, scoring, and drafting. People decide what goes live. Nothing leaves the system without a human in the loop.
AI proposes
The agent sources, enriches, scores, and drafts. It produces qualified prospects and draft content, not finished actions.
Human review is required
A person reviews and approves a prospect before any outreach can go live. Approval is a required step, not an option.
No autonomous send
The AI SDR Agent prepares outreach but never sends it. There is no auto-send and no bulk send from this pipeline.
Sending is a separate agent
Outreach is sent by the Outbound Execution Agent, a separate human-gated layer that turns one approved prospect into exactly one reviewable draft.
Endpoints are authenticated
Run and observability endpoints require authentication, so runs cannot be triggered or inspected without it.
Every run is recorded
Runs, prospects, and activity logs are tracked and correlated, so what ran and what it produced stays auditable.
The parts of the system, and what each one does.
Each component is described by its role and what it handles. Only documented components are listed, and there are no metrics, because no measured outcomes exist yet.
Lucent OS (trigger and spine)
- Role: Orchestrates, gates, persists, and surfaces the pipeline. No language models run inside it.
- What it handles: A POST to the AI SDR run endpoint forwards the run to n8n and opens the ai_sdr_runs lifecycle record.
n8n workflow
- Role: The workflow engine where the sourcing, enrichment, scoring, and preparation steps execute.
- What it handles: The language-model work runs here in sub-agents, not inside the application.
Data sources
- Role: The scrapers and queue that feed the pipeline.
- What it handles: A lead queue, an Apify Google Maps scraper, a website signal scraper, and a reviews scraper.
Sub-agents
- Role: The scoring and outreach models reachable over n8n webhooks.
- What it handles: The Lead Scoring Agent scores qualified leads; the Outreach Agent prepares draft outreach content.
CRM (Supabase)
- Role: The record store the rest of the operation reads from.
- What it handles: Stores prospects and activity logs; run_id correlates every record to its originating run for end-to-end traceability.
Run observability
- Role: The layer that makes every run visible and inspectable.
- What it handles: A Run History view on the agents dashboard, with created and failed counts derived server-side.
What is running today.
Observability is in place. The one open item is being monitored honestly rather than dressed up.
Operational. Observability Phases 1 to 4 are complete: run-lifecycle tracking, a Run History UI, hardened endpoint authentication, and graceful degradation when an enrichment step times out. Production runs are being monitored until at least one run confirms end-to-end success. Until then, end-to-end production success is still being confirmed.
What operating the pipeline taught us.
These are observations from building and running the pipeline, not claims about results.
Observability comes before volume. Run-lifecycle tracking turned an opaque automation into an inspectable system, and it was worth building before scaling volume.
Server-derived counts make a pipeline auditable. Computing counts server-side and correlating every record by run_id is the difference between an automation and an auditable pipeline.
Data does not survive a pipeline by default. Enrichment fields can be dropped between n8n nodes, so the item stream has to be preserved deliberately rather than assumed to carry through a merge.
Non-fatal timeouts keep runs alive. Making an enrichment timeout degrade a single record instead of failing the whole run kept the pipeline running through transient scraper failures.
Preparation and sending are different jobs. Keeping outreach preparation separate from sending is what makes the human approval boundary real rather than nominal.
One part of a connected stack.
The AI SDR Agent is not a standalone tool. Lucent OS is the spine. The agent sources and scores prospects into it, and the Outbound Execution Agent drafts outreach to those prospects under human approval off the same queue.
Lucent OS triggers the run, holds the record, and makes it inspectable. The model work runs in the n8n workflow, not inside the application, so the whole run stays traceable from trigger to CRM write.
See how Lucent operates.
Go back to the Proof Hub for the full internal stack, or read the flagship Lucent OS case study to see the spine this pipeline runs on.