Field Desk

Field Desk is an AI service desk that lives in your customers' texts. RCS and WhatsApp on AWS End User Messaging, Bedrock-grounded answers, and instant technician dispatch.

Comment

Field Desk, the AI dispatcher that texts back and never improvises

Your customers already text. Field Desk answers them on RCS and WhatsApp, works the problem from your own playbooks with Amazon Nova Pro, and dispatches the right on-shift technician over WhatsApp, all on one live case across three AWS Communication Developer Services. The AI is smart and still on a leash. It proposes, your business approves, and deterministic code decides what actually goes out.

Deploy it in one click. Launch Stack buttons stand up the full serverless stack with CloudFormation and AWS CDK, permission boundaries and alarms included, in minutes.

Built to grow. Knowledge-base-grounded live suggestions, geo routing and urgency scoring are already deployed, ready for the next proof run.

Inspiration

Service businesses live in the gap between "it's broken" and "it's fixed." A homeowner's AC dies on a hot afternoon, or a colocation customer needs remote hands at 2 AM. The customer calls, waits, repeats the story, and the technician with the right skill hears about the job last. Generic chatbots don't fix this, because a business can't let a model improvise repair instructions to its customers.

We wanted an agent a service business can onboard from its own documents, that meets customers on the messaging channels they already use, and where the business approves every step the agent is allowed to send. The model drafts and proposes, the business approves, and deterministic code decides what actually goes out.

What it does

Field Desk is an AI field service desk that lives in your customers' texts.

  1. Onboard. A CLI uploads a business's documents into an Amazon Bedrock Knowledge Base on Amazon S3 Vectors. The demo ships two synthetic verticals, residential HVAC and colocation/data-center support, each with its own knowledge base and playbooks.
  2. Agent drafts, admin approves. Amazon Nova Pro drafts cited playbook steps from the knowledge base. Structural checks verify them, and nothing reaches a customer until an admin approves it. Drafts are invisible to the live desk.
  3. Customer reports a problem. A customer texts over RCS or WhatsApp. New customers are greeted with "Hi, thanks for reaching Field Desk." and returning customers with "Welcome back to Field Desk."
  4. One approved step. Nova Pro (Bedrock Converse, forced tool call, strict schema) proposes a step. Deterministic policy.verify accepts it only if it's an approved, read-only registry step. On RCS the reply carries three buttons (Fixed, Still broken, Send a technician), and an Amazon SES continuation email follows.
  5. Skill-based dispatch. A "Send a technician" tap sends a WhatsApp job offer to an on-shift technician with the right skill. The technician replies ACCEPT, the case is assigned, the customer is notified on RCS, and the technician gets a WhatsApp confirmation.
  6. Customer closes the loop. A case closes only on the customer's confirmation. Silence never closes a case.

How it uses AWS CDS (called at runtime)

  • AWS End User Messaging RCS. SendRcsMessage for replies with challenge-bound buttons. Inbound messages and delivery receipts arrive through SNS.
  • AWS End User Messaging Social (WhatsApp). SendWhatsAppMessage for guest intake replies, technician job offers and ACCEPT confirmations. Inbound ON, ACCEPT and guest reports flow through the same ingress path.
  • Amazon SES. SendEmail for continuation emails from a DKIM-verified domain.
  • Three CDS services on one case. On the recorded live loop, RCS, SES and WhatsApp all did real work on a single case, from report to technician ACCEPT.

How we built it

  • Architecture. Customer → AWS End User Messaging (RCS / WhatsApp) → KMS-encrypted SNS → SQS with DLQ → ingress Lambda (SNS signature check, MessageId dedupe, immutable record) → DynamoDB + stream → desk agent Lambda → Amazon Bedrock (Nova Pro, Knowledge Base grounded) → policy.verify → reply via End User Messaging and SES. An EventBridge sweep recovers unfinished work.
  • Design principle. The model may propose, policy.verify decides, only approved registry steps can be sent, and only code writes case state.
  • Infrastructure as code. Six AWS CDK (Python) stacks, plus one-click CloudFormation Launch Stack buttons in the README. A clean create and teardown was verified in us-west-2.
  • Guardrails. An IAM permission boundary on every app role, 14 CloudWatch alarms, an AWS Budgets alarm, per-sender cooldowns, daily model-call and send caps, and at-most-once send claims written before every send.
  • Tests. Product, DynamoDB Local and CDK suites, plus an end-to-end harness that runs the real ingress and desk handlers on simulated signed provider events for both verticals on every PR in GitHub Actions.

Challenges

  • Keeping the model advisory but still useful. In live runs, the verifier rejected a model proposal and the approved registry step or a neutral reply went out instead, exactly as designed.
  • Stale buttons dropped a reply. Buttons bound to an old prompt version failed after a rollout. We rolled back and fixed forward so a reply with no valid buttons goes out as plain text.
  • One missing "+". EUM Social rejects bare-digit destinations. Sending E.164 with the leading plus fixed it, and an end-to-end test now catches it before any provider call.
  • SES permissions surfaced one at a time. In the sandbox, SES also authorizes against the recipient identity, which we reproduced and fixed.
  • Our own guardrails blocked a deploy. The permission boundary went over IAM's 6,144-character limit. We collapsed it without dropping a single deny.
  • Opening WhatsApp to judges safely. Unknown senders enroll as guests in one create-only transaction, capped per day, and guest cases never page a technician.
  • One-click deploy in a second region. Nova Pro needed the cross-region inference profile in us-west-2, so we switched to it with matching IAM grants and re-proved the flow end to end.

Accomplishments

  • A full live loop on one case: RCS report → Nova Pro proposal verified against the registry → RCS step with three buttons plus SES email → Still broken → Send a technician → WhatsApp job offer → ACCEPT → customer notified on RCS.
  • WhatsApp open intake from non-enrolled numbers proven live, with greetings, approved steps and no technician paged.
  • The first model-drafted playbook approved on the live registry and served to a customer without a redeploy.
  • Recorded live on Oct 28, 2026: a first-contact WhatsApp guest greeted and helped, and a returning RCS customer welcomed back and dispatched to a technician who accepted over WhatsApp.
  • Reproducible one-click deployment with permission boundaries and green CI.

What we learned

Agentic doesn't have to mean unsupervised. Letting the model propose and having code verify against business-approved steps gave us an agent that's genuinely useful and safe to put in front of real customers.

Honest limitations

  • The RCS agent is in Testing status, so only invited tester phones can use it. WhatsApp is the judge path.
  • SES is in the sandbox, outbound only.
  • All businesses, sites, customers and technicians in the demo are synthetic.
  • WhatsApp replies are text only. The Fixed, Still broken and Send a technician buttons are RCS-only.
  • Knowledge-base-grounded live suggestions, geo routing and urgency scoring are deployed but not yet proven live.

What's next

True multi-tenancy, SES production access with inbound email, a hosted technician console, and live proof of the knowledge-base suggestion, geo routing and urgency paths.

Try it

Send a WhatsApp message to +1 415-644-8208 describing a field problem, such as "furnace runs but no heat" or "central air conditioner runs but no cold air." Field Desk greets you and replies with an approved, read-only check. Guest cases never page a real technician. Full judge instructions are in the README's "Judge interaction" section.

Disclosures

  • Imported baseline. The product baseline was developed by Jaiven Spence inside the submission period and imported unchanged. Provenance is in docs/import/.
  • AI assistance. Built with OpenAI Codex, Anthropic Claude (Claude Code) and xAI Grok under human direction and review.
  • Voiceover. The narration uses an AI voice clone of Erik Jones's own voice.
  • Libraries. boto3/botocore, cryptography, AWS CDK and pinned dependencies, installed rather than vendored.
  • Demo data. All businesses, sites, people and documents are synthetic.

Team

Erik Jones and Jaiven Spence, Jacobian Engineering (AWS Partner Network).

Built with

Python, AWS Lambda, Amazon DynamoDB, Amazon SQS, Amazon SNS, AWS KMS, Amazon EventBridge, Amazon Bedrock (Nova Pro), Bedrock Knowledge Bases, Amazon S3 Vectors, AWS End User Messaging (RCS), AWS End User Messaging Social (WhatsApp), Amazon SES, AWS CDK, Amazon CloudWatch, GitHub Actions

Built With

Share this project:

Updates

Submission history