# lead-followup

**Trigger:** a new row in the `leads` table (lead-form submission via /api/lead.js).
**Cadence:** event-driven, debounced 5 minutes (a single human submitting the form twice in a row should only fire once).
**Agents (in order):** queen-coordinator -> lead-watcher -> human approval -> sendgrid send.
**Output:** a draft reply waiting in Brian's inbox for approval, plus the classified lead row in the `leads` table with a suggested action.
**SLA:** draft generated within 2 minutes of submission; Brian approves and sends within one business day (per the marketing site's promise).

## How it runs

1. Queen-coordinator gets the new-lead event. If the same email/domain already has a lead row from the last 30 days, queen attaches the new note to the existing row instead of creating a new one (avoids duplicate first-touches).
2. Queen routes to lead-watcher.
3. Lead-watcher classifies the lead (operator | multi_unit | brand_hq | partner | noise) and drafts a first-touch reply per its prompt.
4. The drafted reply lands in Brian's inbox as an "approve and send" email (sendgrid template `lead-acknowledgement.md` with the draft preview inline).
5. Brian approves, edits if needed, sends. The send updates the lead row's `first_touch_at` timestamp.

## What this workflow does NOT do

- Does not auto-send the reply. gate-outbound applies.
- Does not push the lead into a CRM. We do not have one yet; until then, leads live in D1 and Brian works from his inbox.
- Does not route to a sales team. Brian is the sales team in CL-002.

## What changes when there's more than Brian

A future CL will add a partner_watcher agent and route partner-classified leads to a partnerships inbox. For now, all classifications route to Brian.

## Cost

Sub-cent per lead. Negligible.