Switchboard: AI change workflows on AWS
A synthetic customer-change demo on AWS: an AI investigator gathers evidence, application code enforces approval, and signed test events check delivery.
Checking a customer change before applying it
Switchboard is a synthetic customer-change demo I designed, built, and deployed on AWS. A fictional customer asks to change where their system receives event notifications. Sending those events to the wrong destination could expose data or interrupt a service.
I built a Python and LangGraph investigator that checks customer records and policies and prepares a report with supporting evidence. Application code controls approval, execution, and delivery verification.
The company records and customer systems are fictional. Investigations call a real model through Amazon Bedrock, and delivery checks send signed synthetic events between controlled AWS endpoints.
Giving the investigator evidence and limited authority
The agent retrieves tickets, customer records, integrations, and policies through tools that check the employee’s role and customer assignments. Employee identity comes from trusted application context, outside the model’s tool arguments.
The model returns a structured report. A separate model call reviews its policy interpretation, and application code checks its evidence references and proposed change against the records. One revision is allowed; a report that still fails validation is not published.
This gives the model room to investigate while keeping authorization and changes in application code. A policy blocker is a valid investigation result; a failed provider call is an operational failure.
Approval applies to a specific change
Require another authorized employee to approve.
A proposal for the fictional production environment requires approval from a different technical lead assigned to that customer. Execution rechecks permissions, approval, the change window, and the configuration version. A change made since investigation can invalidate the proposal.
Save the change and its receipt together.
The integration update and execution receipt commit in one DynamoDB transaction. A repeat returns the saved receipt. Delivery verification checks the active destination and version, then validates the receiver’s event ID and payload hash.
A delivery timeout stays inconclusive because the event may have arrived. Failed or uncertain delivery requires manual intervention; the proposal does not authorize automatic rollback.
Recovering work after partial failure
Step Functions coordinates the workflow, SQS delivers investigation jobs, and DynamoDB saves progress and results. The application stores the job before dispatch, so a failed workflow start leaves work that retry or maintenance can recover.
Workers use leases to prevent active duplicates from starting another investigation. Saved validated output can be reused after proposal publication fails. A crash before that checkpoint can still repeat a model call. Queue delivery is at least once, so the application makes business effects idempotent.
Callbacks use saved action receipts, and maintenance recovers missed callbacks. The browser can reload a saved run URL and restore its state. These recovery paths address different failure points rather than treating every error as a reason to restart the whole workflow.
Deployment and diagnosis were part of the build
The Next.js site and FastAPI API run on Lambda behind CloudFront. AWS SAM and CloudFormation define deployment; releases check live website and API behavior and restore the previous deployment if health checks fail.
CloudWatch alarms cover function errors, queue age, dead-letter messages, and failed or timed-out workflows. X-Ray traces and structured logs support diagnosis without adding model prompts or customer records to trace attributes. The public architecture document links these decisions to their implementations.
What the demo demonstrates, and its limits
The result is a public, inspectable workflow from investigation through approval, execution, and delivery verification. Each visitor gets an isolated workspace and chooses from three built-in fictional employee profiles. Alex, an implementation engineer, handles Acme requests; Priya, a technical lead, reviews eligible Acme proposals; Ben, a support specialist, investigates Globex requests with limited access. The demo uses these prepared profiles without work-account sign-in. Switching profiles keeps the same visitor workspace, and the server checks the selected role and customer assignments before each action.
The repository includes deterministic tests and evaluation scenarios. Their presence does not establish a measured model pass rate. This demo demonstrates controlled AWS integration over synthetic data; it provides no evidence of client production use or operator outcomes.
Try Switchboard to follow a valid change through approval or investigate an unsafe destination. The source repository makes the authorization, receipts, retry paths, and tests available for review.
Looking for a senior frontend engineer?
I help product teams build and improve React and TypeScript applications, from complex interfaces to reliable releases. I’m open to remote roles and contract work.