Routes by sender and kind
Routes hot-reload from config. Text, image, and audio can land on different backends without restarting the live process.
AI messaging concierge · live on GCP
Every message gets a front door.
frontdesk is an always-on routing and assistant layer for incoming WhatsApp and SMS: it verifies origin, routes by sender and message kind, drafts useful replies, files business-card submissions, and leaves a dashboard trail when something breaks.
fd-router :8787 · signed forwards
WhatsApp verifiedwa-baileys resolves sender identity, downloads media, and forwards through the router.
TextNow claim activeY/N replies are captured only when verdict.js sees deterministic approval language.
account-assistant :8788Gmail, Drive, Calendar, Contacts, vision, transcription, and admin tools behind the chat loop.
card-intake :8090Business card image plus voice memo becomes extracted fields and a Google Sheet row.
observability append-onlymessages.ndjson, error-events.ndjson, wa-events, status, health, and a two-box dashboard over tailnet.
What it actually does
Trust boundaries
Origin-bound secrets, HMAC signed forwards, replay windows, admin-only WhatsApp origin, and write opt-ins keep transports separated.
Files cards cleanly
Card photos and voice notes are paired, processed, extracted, transcribed, and appended to a Sheet with a reply back to the sender.
It is an operations surface, not just a bot.
The repo includes a WhatsApp broker, TextNow keeper, router, account assistant, card-intake Python service, tutor loop, owner alerts, web push fallback, dashboard, GCP ingress, health monitoring, and runbooks.
Live message archive
Inbound and outbound messages are appended for dashboard review without turning logs into the primary data model.
Failure codes
Router, transport, assistant, card-intake, tutor, alert, and claim failures emit structured codes for a single error stream.
Two-box dashboard
GCP serves the public dashboard and proxies the home box over tailnet, degrading clearly if the office box is unreachable.
Human control
Claims are candidacy, not capture; a free-text reply falls through unless it cleanly matches the expected approval vocabulary.
Message paths are explicit
Inbound archive
The router records inbound messages after transport verification so the dashboard can show what arrived, from which origin, and where it was forwarded.
Health model
Broker status, assistant health, card-intake status, process lists, cost estimates, and error events are separate signals instead of one vague “bot up” light.
GCP front door
The public dashboard is served from the GCP box and reaches the home services through tailnet, keeping the home machine off the public internet.
Implementation inventory
The product is intentionally composed of small services. That keeps each failure mode inspectable: transport, router, assistant, card intake, dashboard, alerts, and health all have their own surfaces.
Transport layer
WhatsApp and TextNow are treated as interchangeable doors into the same router, with origin bound by which secret authenticated.
Backend layer
Account assistant and card-intake keep their own logic. The router forwards, signs, archives, and gets out of the way.
Operator layer
Dashboard pages read status, messages, process health, and append-only error streams instead of relying on one console log.
Safety layer
Claims, replay windows, per-origin HMAC secrets, and admin-origin checks prevent a convenient chat surface from becoming an unsafe write channel.