13 · Robin · Bot Runtime Use Case

Robin is designed but not running

Robin is the operations bot for the Amazon R3 program — drivers, sites, partners, finance. The behaviour, tone, and 18 task scopes are fully spec'd in Airtable base app6GEKoBtHW1iyu1. Every scope is Enabled = false, no n8n Workflow URL is populated, and the Robin Activity log shows only 4 events. The product exists on paper. The runtime does not.

Source of truth

Airtable · Amazon R3 Program

Three tables: Robin Config, Robin Task Scope, Robin Activity. Fetched live via Airtable Metadata + Data API using the PAT in .env.deploy.

Reality check

0 / 18 scopes enabled

Every Task Scope row has Enabled=false and an empty n8n Workflow URL. Only ClawBot's robin_tasks queue in appUDQ65M1lSnSM5p has live rows (mostly Finance + Partner from FIN-01 and Hauling Hub).

Why this page

Spec → runtime plan

Document what Robin should do, what currently writes into its queue, and the AWS bounded context that turns the Airtable spec into an actual always-on service.

Data model

Three tables · base app6GEKoBtHW1iyu1

Robin Config

tblWCM4jUyXPu6tnX

Identity + delivery settings: Display Name, Email, WhatsApp Display, Voice Profile, Languages, Email Signature, Active Hours, Quiet Days.

Per-channel reply delay: Driver / Site / Partner / General Inbound Reply Delay (min) + AI Disclosure Response + Headshot.

Robin Task Scope

tblIuSytm3wQBjxbl

One row = one capability. Fields: Task Name, Channel (Email/WhatsApp/Slack/Internal/OCR), Default Mode + Currently Active Mode (Draft / Auto / Escalate), Trigger Condition, Escalate When, Logic Steps, Approval Rule, Edge Cases, Context Inputs, Example Output, Email Template, Slack Template, n8n Workflow URL, Enabled.

Robin Activity

tblJtxatIxefHjp0N

Append-only event log: Subject, Timestamp, Channel, Direction, Action Type, Mode at Time, Outcome, Contact Name/Channel ID, Full Message, Confidence Score, Joan Reviewed, n8n Run URL, links to Order / Partner / Site / Driver / Ticket / Task Scope.

Plus the live queue

Across the wall in base appUDQ65M1lSnSM5p sits robin_tasks (tbl4YywNGbJynrrdk) — 40+ fields including task_guid, recommended_action, action_options, selected_action, edited_content, confidence, escalated, triage_status, audit_log_ref. This is where ClawBot/n8n actually write today; the R3 spec tables are aspirational.

Designed flow

How a Task Scope is meant to fire

Each scope is a tiny state machine: a trigger arrives on a channel, Robin runs the Logic Steps with the Context Inputs, picks a template, and either drafts for Joan, sends automatically, or escalates — based on Currently Active Mode and Approval Rule.

📨
01
Trigger
Inbound email / WhatsApp / cron / OCR
🧠
02
Match scope
Channel + Trigger Condition → 1 of 18
⚙️
03
Logic Steps
Resolve Context Inputs · run rules
✍️
04
Render
Email/Slack template + Voice Profile
🚦
05
Route by mode
Draft → queue · Auto → send · Escalate → Joan
📒
06
Activity log
Append row with confidence + outcome
Scope catalog

18 scopes sampled · 0 enabled

Code · TaskChannelDefault Moden8n URLEnabled
CMP-01 Acknowledge inbound complaintEmailDraftemptyfalse
FIN-01 AP Audit & Variance TierInternalAutoemptyfalse
FIN-02 AR GenerationInternalAutoemptyfalse
FIN-02-AMAZON Vendor Central uploadOCRAutoemptyfalse
FIN-03 Partner Price Change Approval GateSlackEscalateemptyfalse
DRV-04 Driver Silence EscalationWhatsAppAutoemptyfalse
DRV-05 Day-of Route SummaryWhatsAppAutoemptyfalse
Confirm pickup completion / photoWhatsAppDraftemptyfalse
Equipment install clean / discrepancyEmailDraftemptyfalse
Tuesday overdue reportEmailDraftemptyfalse
Risk alertsSlackEscalateemptyfalse
+ 7 more scopesall empty triggers, all disabled

Spec drift

Robin's behaviour is documented in Robin Task Scope, but the runtime that actually writes to robin_tasks today is ClawBot + n8n workflows (FIN-01 AP Variance, WF06 CMP Substantive, WF03 Partner Count Chase, WF04 DRV-04 Driver Silence, WF12 FIN-03 Price Gate, Hauling Hub Tickets). The Airtable scope rows are not the source of execution — they describe what should exist.

Live queue snapshot

robin_tasks · what's actually arriving

Sampled 18 most recent rows from appUDQ65M1lSnSM5p/tbl4YywNGbJynrrdk. The mix shows where Robin's runtime would land first.

Status

9 Pending · 5 Auto-Resolved

Pending Review 9 · Auto-Resolved 5 · Approved 2 · Rejected 1 · Snoozed 1. Joan is the human approver loop for everything not auto-resolved.

Category mix

Finance dominates

Finance 7 · Partner 4 · Other 4 · Complaint 1 · Driver 1 · Risk 1. FIN-01 AP Variance and Hauling Hub Tickets together produce ~half the volume.

Producers

n8n + ClawBot

Hauling Hub Tickets 6 · FIN-01 AP Variance 3 · WF10 FIN-01 AP Audit 3 · WF03 Partner Count Chase 2 · WF06/WF04/WF12 1 each. None of these are wired to Robin Task Scope rows.

Target architecture

Robin as a DDD bounded context on AWS

Robin is its own bounded context with its own database. It consumes domain events from R3 (orders, partners, drivers, finance), evaluates active Task Scopes, renders messages, and writes a permanent activity log. n8n stays only as a thin webhook adapter until inbound channels move to native AWS endpoints.

📡
01
Event bus
EventBridge · domain events from R3 services
📥
02
Inbound adapter
SES inbound / WhatsApp Cloud API / Slack Events
🤖
03
Robin orchestrator
NestJS service on ECS · evaluates Task Scopes
🗄️
04
Postgres
robin own DB: scopes, queue, activity, suppression
📤
05
Outbound
SES · WhatsApp · Slack · SQS for retries
👤
06
Joan UI
Hub v2 web · approve / edit / escalate
ConcernTodayAWS target
Task scope storageAirtable tblIuSytm3wQBjxblPostgres robin.task_scope · seeded from Airtable export
Live queueAirtable robin_tasksPostgres robin.task with SQS for delivery retries
Activity logAirtable Robin Activity (4 rows)Postgres robin.activity append-only + S3 archive
Inbound emailn8n Gmail triggerSES inbound rule → SNS → Lambda → orchestrator
Inbound WhatsAppnot wiredWhatsApp Cloud API webhook → API Gateway → Lambda
Inbound Slackn8n Slack triggerSlack Events API → API Gateway → Lambda
Render + tonen8n prompt nodesBedrock (Claude) with Voice Profile from robin.config
Schedule (e.g. Tuesday report)n8n cronEventBridge Scheduler → orchestrator endpoint
Secretsn8n credentials + .envSecrets Manager + IAM task roles (already used by Hub v2)
Approval UIAirtable viewsHub v2 web (hv-hub-v2-web on ECS)
What's needed to make Robin actually run

Concrete checklist

Spec side · Airtable

  • Fill Trigger Condition with a machine-readable predicate per scope (channel + filter), not free text.
  • Pick which 3-5 scopes go live first. FIN-01, CMP-01, DRV-04 already have producers in robin_tasks.
  • Flip Currently Active Mode deliberately — most should start in Draft with Joan in the loop.
  • Move Email Template / Slack Template to versioned strings (Mustache or Liquid) so the orchestrator can render deterministically.
  • Stop using n8n Workflow URL as the wiring field — replace with handler_key pointing to a NestJS handler.

Runtime side · AWS

  • New ECS service robin-orchestrator in the existing hv-hub-v2-development cluster (us-east-2).
  • Dedicated Postgres schema robin on the Hub v2 RDS — one DB per bounded context.
  • SES inbound + WhatsApp Cloud API + Slack Events as the three channel adapters.
  • EventBridge bus hv.r3 for domain events; Robin subscribes by detail-type.
  • SQS robin-outbound + DLQ for delivery retries and idempotency.
  • Bedrock for drafting (Claude) using the Voice Profile + Active Hours from robin.config.
  • Approval surface in Hub v2 web — replace the Airtable view used by Joan.

What we are NOT doing in phase 1

No rebuild of the 6 ClawBot/n8n producers (FIN-01, CMP, DRV, Hauling Hub). They keep writing to robin_tasks via the existing path while Robin's orchestrator is stood up next to them. Once 3-5 scopes are running on AWS end-to-end, migrate producers one at a time — same playbook as BO-26 + Send Approved Tasks.