Five agents in orbit around one database.

Two agents run the moment an email arrives. Three run on daily schedules. Every run writes one audit row to Postgres with tokens, cost, and timing.

12 labels3 daily crons602 tests1 LangGraph

00 / LIVELive ledger

lifetime totals · refreshed hourly
LIVE2,320emails classified
LIVE74news briefs generated
LIVE49morning briefs generated

01System design

label ≈ 7 s · job-app pipeline ≈ 29 s
Fleet system schematicGmail events flow through the Triager into 12 labels and the Job Apps pipeline, two cron agents publish briefs to Notion, a third syncs spend, and every run lands in a Neon Postgres audit ledger read by a Next.js dashboard.Gmail4 ACCTS · PUB/SUB WATCHTriagerJWT WEBHOOK · SONNET12 labelsFLAG WHEN ACTIONABLEJob AppsLANGGRAPH · OPUSNotionSTATUS ↑ · BRIEF PAGESNeon PostgresAUDIT LEDGER · RUNS · SPENDDashboardNEXT.JS · DIRECT READSNews Brief09:15 ET · CURATED NEWSMorning Brief10:30 ET · TASKS + CALSpend Sync04:00 ET · BILL → NEONPUBLISH · 1 PAGE / DAY EACHDISPATCHAUDIT ROWLABELSTATUS ↑SERVERLESS READ

02The daily schedule

00:0004:0008:0012:0016:0020:0024:00
triager
EVENT-DRIVEN · ~32 EMAILS / DAY
job-apps
FIRES ON JOB-APP EMAIL
spend-sync
04:00
news-brief
09:15
morning-brief
10:30

03Hard rules

✕
Never sends

No automated send path exists. Replies are human, every time.

↑
Never regresses

Saved → Applied → Screen → Interview → Offer. One direction only.

∅
Never fabricates

A date the email doesn't state stays null in Notion.

▣
Always audited

Tokens, cost, latency, path taken: one row per run.

The engineering is public.

Prompts and personal data are removed. The pipeline logic, tests, and infra are intact.

email →