Three vertical layers: data sources feed the Maestro generation pipeline; the consumer drafts and writes to DynamoDB; surfaces present work to humans for review, then the Sender delivers it. Everything else is plumbing.
Two different producers that now converge on the same DynamoDB single-table and the same Hub v2 review queue. Conflating the producers is the #1 source of debugging confusion — but the store and the surface are shared.
Trigger: n8n “Auto Tasks” schedule (every X hours/days).
Source: HubSpot list_id or Airtable view_id.
Verb: POST /generate → SQS → task_consumer Lambda.
Auth: API Gateway endpoint (us-east-2).
Output: source='sales' items in the DynamoDB tasks table (pending_review).
Reviewer: deal owner per playbook, in Hub v2.
Trigger: inbound email, form, Slack, manual.
Source: Robin (R3 ops) / Frank (finance) orchestration.
Verb: POST /api/queue/ingest (cut over from Airtable, #259).
Auth: x-hook-secret header (QUEUE_HOOK_SECRET value).
Output: source='robin' items in the same DynamoDB tasks table.
Reviewer: account owner + human in Hub v2.
Engineers see “Robin” in both flows and assume one pipeline. The producers are independent — sales does not call Robin, and Robin does not call /generate. What they share is the DynamoDB single-table (segmented by source) and the Hub v2 review surface. Task data no longer lives in Airtable; Airtable now holds only the config brain (SSOT kill-switch, Agent Settings, guardrails, suppression, templates).
Task data moved to DynamoDB, but the brain stays in Airtable (per ADR 0001). The task_consumer Lambda reads these three tables on every run to draft in Gabrielle’s voice and stay inside the guardrails.
Table tblRiSakPTB4cVJSr. Each bot has purpose, data_sources, escalation_logic, tools_allowed. The sales bot is Gabrielle Sales (recK11xdc82ArNEX2, formerly Sales_Assistant) — the consumer reads its voice/system-prompt to draft.
Table tblmjEywNRz7Hv2w5. applies_to="All bots" — not per-playbook. Categories: Inbox Rules, Content, Human Required, Communication Limits, Data Hygiene. Priorities 1 (Critical) → 5 (Catch-all).
Table tblOenbL6Iq2WZo4C. Two heavy-link records: recXbj3ykSg5Tqw9v Suppression_List (DNC, 9 outreach playbooks) and recPk47mTFYk78BWG Company Employee Database (rep inbox/Slack, 16 SSOT links). Owner: Farid.
Every sales playbook shares Gabrielle Sales (the bot formerly called Sales_Assistant) as the base bot. Only 2 add Account Manager, and 4 COLD/stale playbooks add Lead Generator. The rest of the registry never touches the sales pipeline — those rows belong to Operational Tasks or are not yet wired.
Used by: every sales playbook the consumer drafts for.
Role: drafts the outbound message body, applies tone & CTA per playbook context.
Owner: Jess
Used by: TQ-01, RB-01 (existing-customer touchpoints).
Role: pulls relationship context so drafts reference open quotes / recent orders.
Owner: Jess
Used by: 4 COLD / stale-revival playbooks.
Role: enriches prospect signals (firmographic, intent) before Gabrielle drafts.
Owner: Jess
Before §4.6, the assumption was that each bot in the registry had a dedicated playbook. The truth is 3 bots power all the sales playbooks; the other bot rows are Operational-Tasks-only (Robin, Frank, R3, Health Sentinel, etc.) or unfinished. Editing Gabrielle Sales has fleet-wide blast radius — the task_consumer Lambda reads its voice for every draft — so treat it as a critical config.