Outbound Execution Agent
The draft-only outbound execution 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.
Turning an approved prospect into a ready-to-send email is repetitive and error-prone, and naive automation risks sending unreviewed or duplicate mail. Lucent needed a controlled way to produce outreach drafts that keeps a human in the loop before anything is sent.
The Outbound Execution Agent solves that operational problem narrowly and on purpose. It is the execution layer between the Lucent OS outreach queue and Gmail. It takes one prospect that a person has already approved, creates exactly one Gmail draft, updates the record, and logs the action. It never sends email automatically.
Draft creation is kept separate from prospect qualification by design. This agent does not source, score, enrich, or follow up; that work belongs to the AI SDR Agent. Separating the two keeps the approval boundary real: one system finds and qualifies prospects, and a different system drafts to them only after a human approves. Inside the broader operating system, this agent sits at the end of the stack, drawing approved prospects from the same record store the rest of the operation reads from and writing its results back to it.
The documented capabilities.
Each capability below is supported by the build documentation. The system creates drafts only; it does not send. There are no metrics here, because no measured outcomes exist yet, and none are claimed.
Approved prospect processing
Takes one prospect that a human has already marked approved for outreach and fetches that exact record by its id. Nothing is processed unless the approval flag is set.
Outbound workflow preparation
Normalizes the trigger payload and the fetched record, then validates that the email, subject, and body are present before any draft is created.
Gmail draft creation
Creates exactly one Gmail draft for the approved prospect using a compose-only scope. The draft is created for a person to review; it is never sent from this workflow.
CRM status updates
Writes the result back to the prospect record in Supabase, setting the outreach status to draft created, storing the draft id, and clearing the previous error state.
Operational visibility
Logs each action to the activity log, and the outreach queue shows per-prospect badges such as Ready To Draft, Needs Approval, Missing Email, and Draft Created.
Approval-preserving execution
Requires the approval flag, processes one prospect per click, and dedupes on the stored draft id and status so a prospect cannot be drafted twice. Sending stays a manual human step.
One approved prospect, one reviewable draft.
A run moves in a fixed order from an approved prospect to a created draft. Each step preserves the draft-only boundary: software prepares the draft, and a person sends it.
A prospect is approved
In the Lucent OS outreach queue, a person edits and approves one prospect, setting approved_for_outreach to true. The Create Draft button stays disabled until the email, subject, body, and approval are all in place.
An operator clicks Create Draft
The operator clicks Create Draft on a single prospect card. The action posts that one prospect id to the Lucent OS outbound run route. There is no bulk action and no schedule trigger.
Lucent OS forwards the run
The server-side route validates the id, calls the n8n production webhook with a short timeout, treats any success response as accepted, and returns immediately. Execution is fire-and-forget; Lucent OS does not wait on it.
The payload is normalized
n8n receives the webhook, normalizes the payload down to the prospect id, and routes a selected-prospect run to Fetch by Prospect ID rather than the manual fallback path.
The prospect is fetched
The workflow fetches that one prospect from Supabase and normalizes the response into a single lead record for the steps that follow.
Required fields are validated
The workflow confirms the email, subject, and body are present. Idempotency checks skip the prospect if a draft id is already set or the status is already draft created.
One Gmail draft is created
A single Gmail draft is created with a compose-only scope. The workflow creates the draft only; it has no send step and cannot send mail.
The record is updated and logged
Supabase is updated to draft created with the stored draft id and a cleared error, and the action is written to the activity log. On a failure the error is logged and the prospect is skipped.
A human reviews and sends
The card moves from Creating to Draft Pending to Draft Created. A person opens the draft in Gmail, reviews it, and sends it by hand. The send is always a human action.
Idempotency checks on the stored draft id and status mean re-running the workflow does not create a duplicate draft, and the client disables the button once a draft exists.
AI proposes. A human approves and sends.
The model is deliberately simple: AI proposes, a human approves, approved records enter execution, drafts are created, and humans send. Nothing leaves the business without a person in the loop.
AI proposes
The agent prepares outbound work from upstream content. It produces a reviewable draft, not a finished, sent action.
A human approves
A person sets the approval flag on a prospect before anything runs. Approval is a required gate, not an option.
Approved records enter execution
Only a prospect marked approved for outreach is fetched and processed. An unapproved record never reaches the draft step.
Drafts are created
The workflow creates exactly one Gmail draft per approved prospect. The output is a draft for review, nothing more.
Humans send
Sending stays a manual human step performed in Gmail. There is no auto-send and no bulk send from this workflow.
The boundary is enforced
The compose-only scope, the one-prospect-per-click rule, dedupe on draft id and status, and the absence of a schedule trigger keep the draft-only boundary in place.
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 (queue and spine)
- Role: Provides the outreach queue, the approval flag, and the record store, and triggers the run. No language models run inside it.
- What it handles: The /outreach queue and /agents card surface the work; a Create Draft click posts one prospect id to the run route.
Outbound run route
- Role: The server-side Lucent OS route that hands a single approved prospect to the workflow.
- What it handles: Validates the prospect id, calls the n8n production webhook on a short timeout, and returns on acceptance without polling.
n8n workflow
- Role: The self-hosted workflow engine where normalization, validation, draft creation, and the record update execute.
- What it handles: Webhook, normalize payload, fetch by prospect id, normalize lead, validate, create Gmail draft, update Supabase, log activity.
Gmail integration
- Role: The draft surface for reviewable outreach.
- What it handles: A Gmail credential with a compose-only scope creates the draft. The integration is confirmed working for draft creation and cannot send.
CRM (Supabase)
- Role: The record store the rest of the operation reads from.
- What it handles: The prospects table holds the approval flag, message fields, draft id, and status; activity logs record each action. The service role key stays server-side only.
AI SDR Agent (upstream)
- Role: The separate pipeline that sources, scores, and enriches prospects into the CRM this agent later drafts to.
- What it handles: Populates qualified prospects and their outreach content. It does not draft or send; this agent does not source, score, enrich, or follow up.
What is running today.
The status is stated exactly as it is documented, including the one known caveat, rather than dressed up.
Operational, draft-only. Real Supabase-backed prospects have been confirmed working end to end through Gmail draft creation and the Supabase update. One known caveat: a Draft Pending state can persist in Lucent OS if n8n accepts the trigger but skips or fails before updating Supabase, which is most likely with stale or local test rows.
What operating the agent taught us.
These are observations from building and running the agent, not claims about results.
A draft-only boundary is both a safety design and the proof. Keeping the system at a reviewable draft, with no send step, is the concrete demonstration that automation drafts and a human approves and publishes.
Approval gates have to be a required field, not a convention. Making the approval flag a mandatory condition before a prospect can be fetched is what makes the gate real rather than nominal.
Draft creation and qualification are different jobs. This agent only creates drafts for approved prospects. Sourcing, scoring, enrichment, and follow-up stay with the AI SDR Agent, so each system does one thing.
Dedupe is part of the build, not a setting. Checking the stored draft id and status before creating a draft is a locked design decision that prevents a second draft for the same prospect.
Terminal-status writes keep the operator honest. Without a failure status written back on a skip, a Draft Pending state can persist in the queue. The fix is identified and not yet built, and it is documented rather than hidden.
Test against real records, not stale rows. The pending-state caveat surfaces most with stale or local test rows, so confirmation runs use real Supabase-backed prospects.
The last step of a connected stack.
The Outbound Execution Agent is not a standalone tool. The AI SDR Agent sources and scores prospects, Lucent OS queues, gates, and records them, and this agent drafts outreach to the approved ones under human control off the same queue.
The AI SDR Agent finds and qualifies. Lucent OS holds the record, the approval flag, and the queue. The Outbound Execution Agent turns one approved prospect into one reviewable draft, so the whole run stays traceable and a person stays in control of what gets sent.
See how Lucent operates.
Go back to the Proof Hub for the full internal stack, or read the systems this agent runs alongside: the Lucent OS spine and the AI SDR Agent that feeds it.