13 · Robin · Bot Runtime Use Case

Robin's cutover to AWS is live in shadow

Robin is the operations bot for the Amazon R3 program — drivers, sites, partners, finance. The behaviour, tone, and 18 task scopes are still spec'd in Airtable base app6GEKoBtHW1iyu1 (every scope Enabled = false, no n8n Workflow URL). What changed (#259): FIN-01 now writes AWS-only (its Airtable Create Robin Task node was removed) into the shared single-table hv-hub-v2-development-tasks (source = robin, us-east-2). The full cutover is phased — the Hub now reads/acts on Robin in DynamoDB, FIN-01 writes AWS-only, and the pending rows are backfilled; re-pointing DRV/the MCP tool and retiring the Airtable table are still open. Joan reviews with the same 6 source-agnostic actions used for sales.

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

Spec idle · shadow live

Every Task Scope row still has Enabled=false and an empty n8n Workflow URL — the spec tables don't drive execution. The live queue robin_tasks (mostly Finance + Partner) is now read/acted on in DynamoDB (Airtable is historical); only FIN-01 writes each Major event into DynamoDB source = robin (AWS-only, its Airtable node removed).

Why this page

Spec + live runtime

Document what Robin should do (the Airtable spec), what writes into its queue today, and the AWS path it now rides — DynamoDB single-table + the Hub v2 human-in-the-loop review surface, shared with the Maestro sales pipeline.

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 — now mirrored to DynamoDB

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 producers write today (~21 records). Per the robin→DynamoDB migration (#259), FIN-01 now POSTs to /api/queue/ingest with source=robin instead of writing Airtable; the other producers (DRV, the MCP tool) still write Airtable only (an interim n8n bridge mirrors them). The R3 spec tables remain design-only.

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 arrives on a channel.
Email · WhatsApp · cron · OCR
02
Match scope
Channel + Trigger Condition select one of the 18 Task Scopes.
Robin Task Scope
03
Logic Steps
Resolve Context Inputs and run the scope's rules.
Logic Steps · Context Inputs
04
Render
Apply the Email/Slack template under the Voice Profile.
template · Voice Profile
05
Route by mode
Draft → Hub v2 queue · Auto → send · Escalate → Joan, per Currently Active Mode.
Draft / Auto / Escalate
06
Audit log
Write the queue row plus an Audit_Log event with confidence + outcome.
DynamoDB · Audit_Log
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 produces tasks is a set of 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). FIN-01 writes into the DynamoDB single-table (source=robin, via /api/queue/ingest) — AWS-only, its Airtable Create Robin Task node removed. DRV's 3 POSTs and the MCP tool reach DynamoDB via an interim n8n bridge, not yet natively re-pointed (F2). The Airtable scope rows are still not the source of execution — they describe what should exist.

Live queue snapshot

robin_tasks · what's actually arriving

Full table today (21 records in appUDQ65M1lSnSM5p/tbl4YywNGbJynrrdk, read 2026-06-23). the Hub reads/acts on this queue in DynamoDB (Airtable historical); only FIN-01's Major events are written AWS-only to DynamoDB source=robin. The mix shows where Robin's runtime lands first.

Status

12 Pending · 5 Auto-Resolved

Pending Review 12 · Auto-Resolved 5 · Approved 2 · Rejected 1 · Snoozed 1. Joan is the human approver loop for everything not auto-resolved — reviewed in Hub v2 (/joan/ai-tasks), reading the Robin queue from DynamoDB since the #259 cutover.

Category mix

Finance dominates

Finance 10 · Partner 4 · Other 4 · Complaint 1 · Driver 1 · Risk 1. Finance (FIN-01 AP Variance + Hauling Hub) is roughly half the volume.

Producers

n8n workflows

The producers (Hauling Hub Tickets, FIN-01 AP Variance/Audit, WF03 Partner Count Chase, WF06/WF04/WF12) are not wired to Robin Task Scope rows. Of these, FIN-01 POSTs directly to /api/queue/ingest with source=robin, while DRV and the MCP tool reach DynamoDB via an interim n8n bridge.

As-built architecture

Robin on the shared Maestro pipeline (AWS)

There is no dedicated robin-orchestrator ECS service and no Postgres robin schema — Robin rides the same store and review surface as the sales pipeline, distinguished only by the source attribute. Per ADR 0001, the store is DynamoDB and ingestion is Path B (POST /api/queue/ingest). n8n stays as the producer/adapter layer; Bedrock drafting is the sales /generate path (Robin tasks arrive pre-built); Hub v2 is the shared human-in-the-loop surface.

01
n8n producers
FIN-01 writes AWS-only today; DRV (3 POSTs) and the MCP tool reach DynamoDB via an interim n8n bridge (#259 F2).
FIN-01 · DRV · Hauling Hub · MCP
02
Ingest
POST /api/queue/ingest with source=robin (idempotent, Path B).
POST /api/queue/ingest · source=robin
03
Pre-built content
Robin tasks arrive ready via /ingest (FIN-01 renders them upstream in n8n); the consumer's Bedrock drafting is the sales /generate path.
Path B · pre-built
04
DynamoDB
Item lands in the shared single-table hv-hub-v2-development-tasks.
DynamoDB · single-table
05
Hub v2 HITL
Joan reviews with the 6 source-agnostic actions (reads come from DynamoDB since the #259 cutover).
Hub v2 · QueueActionsService
06
Audit + alerts
Audit_Log (bot event stream revived, #239) · Sentinel V2 → #hv-alerts.
Audit_Log · Sentinel V2
ConcernLegacy (Airtable era)As built on AWS
Task scope storageAirtable tblIuSytm3wQBjxblStill Airtable (design-only spec; not yet a runtime store)
Live queueAirtable robin_tasksDynamoDB authoritative for the Hub; FIN-01 writes AWS-only to DynamoDB source=robin (#259, Airtable node removed)
Ingestionn8n writes Airtable directlyFIN-01 → POST /api/queue/ingest (AWS-only, idempotent); DRV + MCP still Airtable, bridged to DynamoDB (F2)
Activity / audit logAirtable Robin Activity (4 rows)Audit_Log bot event stream revived (#239) after going dark 2026-03-12
Render + tonen8n prompt nodesRobin content rendered upstream in n8n (pre-built /ingest); the consumer's Bedrock drafting serves the sales /generate path
Review actionsAirtable patches (the 422-prone path)QueueActionsService · 6 source-agnostic actions (#221 closed)
Approval UIAirtable viewsHub v2 web at hubv2.apphappenventures.com (/joan/ai-tasks); reads from DynamoDB since the #259 cutover
Sendn8n Gmail per-rep/approved hard-gated to source=sales → Robin is never auto-sent
ObservabilitynoneSNS maestro-alerts + Sentinel V2 poller → Slack #hv-alerts
Secretsn8n credentials + .envSecrets Manager + IAM task roles (shared with Hub v2)
HV Hub v2 system architecture
Animated · interactive — Robin rides the same store and review surface as the sales pipeline: the middle Hub row and the shared DynamoDB task store. Open full ↗
Status of the cutover

Done · and what remains

Already live — F0 (#259)

  • POST /api/queue/ingest accepts source=robin with no code change — verified live (item visible in the GSI, actionable).
  • FIN-01 writes AWS-only — its Airtable Create Robin Task node was removed; each Major event POSTs /api/queue/ingest with source=robin (onError: continue, idempotent).
  • The 6 reviewer actions + undo are source-agnostic via QueueActionsService (operate by PK) — closes the old Airtable 422 (#221).
  • /approved is hard-gated to source=sales — Robin tasks are never auto-sent.
  • The Hub has All / Sales / Robin source pills (#219); sourceWorkflow filters per bot.

Still open — F1–F4 (#259)

  • Cleanup: the Airtable read branch (source=='robin'→ROBIN_TABLE, the rollback path behind ROBIN_QUEUE_FROM_DYNAMO=false) can be deleted now that reads default to DynamoDB.
  • F2: re-point DRV (3 POSTs) + the MCP tool robin_tasks_create to /api/queue/ingest.
  • Done: the pending Airtable robin_tasks rows were backfilled into DynamoDB (idempotent, airtableRecordId kept as correlator).
  • F4: retire the remaining Airtable robin_tasks writes (DRV, MCP) and leave the table as a historical archive — FIN-01's Airtable write is already removed.
  • The F0→F1 validation gate needs a real Major event, rare today because Total Estimate Cost=0 on ~55% of invoices (price book unpriced). The 18 Task Scope rows stay Enabled=false design-only; the Contact Governor gate applies once Robin becomes sendable.

What this phase did NOT touch

No rebuild of the n8n producers (FIN-01, CMP, DRV, Hauling Hub) — they keep generating tasks into Airtable. FIN-01 now writes AWS-only into the DynamoDB single-table via /api/queue/ingest; DRV and the MCP tool still write Airtable (mirrored to DynamoDB by an interim n8n bridge). The migration is moving the store and the review surface, not the generators — same incremental playbook as the sales cutover.