Telephony AI with Amazon Bedrock: How to Recover Missed Orders by Avoiding Dead Air

When callers hit dead air, you lose orders, how an AWS + Bedrock telephony AI host answers the phone

AWS cites a vendor stat: “Restaurants miss an average of 150 phone calls per location every month, and about 60 percent of those are customers trying to place an order or book a table.” Whether you treat that exact figure as gospel or as industry color, the point is clear: missed calls cost revenue and create friction. The sample stack from AWS shows a practical pattern for answering voice calls with a real‑time AI agent and routing orders into the same backend staff use, without dragging people off the floor.

What you’ll get from this walkthrough

A concise architecture that separates telephony, agent runtime, and backend so each layer can be scaled or swapped independently.
How to avoid “dead air” with warmup and session mapping so callers hear a near-instant response.
Operational constraints you must design for (session limits, costs, privacy, fallbacks) and a pilot checklist you can run this week.

High‑level architecture

The stack is three logical layers:

Telephony layer, PSTN ingress via Amazon Chime SDK Voice Connector, a SIP gateway that bridges SIP/RTP into the agent media format, and a phone number you publish to customers.
Agent layer, Amazon Bedrock AgentCore Runtime runs a conversational agent in an isolated microVM per call. AgentCore Gateway exposes backend services as named tools using the Model Context Protocol (MCP).
Backend layer, API Gateway and AWS Lambda functions implement menus, carts, orders, and location logic. DynamoDB persists state.

How a live call flows (practical sequence)

A PSTN call arrives at the Chime Voice Connector and is routed to a SIP media application that steers the call to your SIP gateway.
The SIP gateway (sample uses drachtio on ECS/Fargate) handles SIP signaling and RTP audio and opens an authenticated WebSocket to the AgentCore Runtime so the agent receives and returns media.
While the phone rings, a Lambda pre-warms an agent session by rendering system prompts, opening the Nova 2 Sonic stream, and running tool discovery. All of this ties to a session identifier so the warmup attaches to the eventual audio connection.
When the call is bridged and the agent begins receiving audio, Nova 2 Sonic streams transcription and TTS bi-directionally. The agent invokes MCP tools (menu lookup, cart update, place order) through the AgentCore Gateway.
Tool calls may be asynchronous. The agent and the Nova stream must handle interruptions and partial answers. During long tool operations, the agent sends periodic silent frames to keep the Nova session alive.
Orders and session metadata are saved to DynamoDB tables (Customers, Orders, Menu, Carts, Locations) and can be referenced on returning calls when the session identifier matches.

That pre-answer warmup is the single most important operational trick. It shifts latency off the live audio path so callers don’t experience cold-start dead air.

Warmup timing, race conditions, and failure modes

Warmup assumes there’s enough ring time to prepare the agent. If the call is answered immediately, the agent may still be cold. Therefore:

Instrument and measure warmup success rate, in other words how often the session identifier from the warmup maps to the later audio connection.
Set sensible timeouts and retries for pre-warm calls. If warmup fails, play a brief welcome and transfer to a human or voicemail instead of silence.
Log and alert on warmup failures so you can tune prompt rendering time, tool discovery, or concurrency limits.

Key building blocks (short reference)

Amazon Bedrock AgentCore, runs each call in an isolated microVM to limit cross-call contamination and provide tracing/observability (see Amazon Bedrock AgentCore docs).
Amazon Nova 2 Sonic, real-time bidirectional audio for low-latency transcription and TTS. The Nova 2 Sonic user guide documents session-continuation patterns and an 8-minute streaming limit you must plan around.
Model Context Protocol (MCP), lets the agent discover and invoke named backend tools without hardcoding endpoints or auth details into prompts.
Telephony stack, Amazon Chime SDK Voice Connector for PSTN, a SIP gateway on ECS/Fargate for SIP→WebSocket media bridging, and a Network Load Balancer for signaling.
Backend, API Gateway + Lambda for business logic, DynamoDB tables (Customers, Orders, Menu, Carts, Locations, carts use TTL), and Amazon Location Service for geocoding and drive times.
Security & monitoring, CloudWatch for logs and alerts; AWS KMS for encryption; Parameter Store or Secrets Manager for prompts and secrets.

Session identity and privacy: the hashed phone approach (and how to do it safely)

The sample computes a session identifier by hashing the caller’s phone number with a secret stored in Systems Manager Parameter Store so the system can recognize returning callers without persisting raw phone numbers. That reduces PII surface, but important caveats apply:

This is recognition, not identity verification. It helps personalize experiences but does not prove the caller’s identity.
Use a keyed HMAC (for example, HMAC‑SHA256) with a secret kept as a SecureString in Parameter Store or in AWS Secrets Manager. Rotate the secret on a schedule and document the rotation procedure.
Protect against brute-force or mapping attacks by rate-limiting lookups and treating the hashed identifier as sensitive data, including log redaction and restricted IAM access.

Important operational constraints you must design around

Nova session limit, the Nova 2 Sonic user guide documents an 8-minute streaming connection limit. Implement session continuation or renewal to avoid mid-call cutoffs.
Warmup reliability, pre-warming while the phone rings avoids dead air but depends on consistent ring time and a reliable warmup path. Measure warmup latency and success rate.
Costs, the two largest recurring items are PSTN per-minute charges (toll-free numbers are pricey) and baseline compute (always-on Fargate tasks). Use local DID numbers, scale Fargate down outside business hours, and set Cost Explorer budgets before you start.
Observability, track warmup success rate, time-to-first-word, tool timeouts, handoff rate to humans, and Nova stream errors in CloudWatch. Instrument request IDs end-to-end so audio, agent decisions, and backend tool calls can be correlated for debugging and audits.
Compliance, recording laws, consent, PCI if you take payments by phone, HIPAA for health-related orders, and data residency rules vary by jurisdiction. Consult legal counsel and design retention and consent flows accordingly.

Pilot metrics and recommended SLOs (start here)

Before you scale, measure these and set preliminary SLOs you can tighten over time:

Time-to-first-word (95th percentile), aim to keep this low. As a starting target, measure and try to approach ≤ 2 seconds for warmed sessions.
Warmup success rate, target ≥ 99% for production; track reasons for failures.
Transcription quality, measure word error rate (WER) on representative 8 kHz PSTN audio for your menu and local accents.
End-to-end order commit latency, measure from call answer to order saved in DynamoDB. Target < 5 seconds for typical cases, and define sensible timeouts for slow tool calls.
Escalation rate, percent of calls transferred to humans; use this to gauge scope and agent design quality.

Pilot checklist, five things to test this week

Transcription WER on representative phone audio, include accents, background noise, and menu terms.
Warmup success rate and ring-to-answer timing, how often does pre-warm attach to the live session?
End-to-end latency including async tool calls and perceived delay by callers, listen to recorded sessions in test mode.
Handoff and fallback behavior, successful transfers, voicemail capture, and human call-back flows.
Cost per recovered order under a small traffic profile, tag resources and create a Cost Explorer budget alarm before you deploy.

Deployment notes and the sample repo

A complete sample implementation and deploy scripts are available on GitHub. The repository includes CDK stacks, Docker builds, preflight checks, deploy scripts, and cleanup scripts. Example quick commands shown in the sample:

git clone https://github.com/aws-samples/sample-restaurant-telephony-ai-host-using-amazon-bedrock-agentcore-nova-sonic.git
cd sample-restaurant-telephony-ai-host-using-amazon-bedrock-agentcore-nova-sonic
./scripts/preflight-check.sh
./scripts/deploy-all.sh –deploymentPrefix qsr-tel

Deploying the sample prints a friendly test message, for example: “Your telephony agent is live at +1XXXXXXXXXX. Dial to test.” Use the provided cleanup scripts (./scripts/cleanup-all.sh –dry-run and ./scripts/cleanup-all.sh) to teardown resources and release the phone number when you’re done.

Prerequisites to verify before you deploy

An AWS account and CDK bootstrapped for your target region.
Amazon Bedrock model access for Amazon Nova 2 Sonic in the region you deploy (request via the Bedrock console if needed).
Amazon Chime SDK PSTN audio access and a phone-number quota (you may need to request a number increase).
Node.js 24.x+, AWS CLI v2 configured, git, and necessary IAM permissions for deployment.
Recommended starting region: US East (N. Virginia, us‑east‑1), confirm AgentCore/Nova availability for your region first.

Run the repo in a disposable test account, inspect scripts before you deploy, and tag resources and set a budget alarm to avoid surprise charges.

Illustrative ROI example (very rough, for scoping only)

If a location misses 150 calls/month, average order value is $20, and you can recover 10% of missed order value with automation, recovered revenue ≈ 150 × $20 × 0.10 = $300/month before deducting model, PSTN, and compute costs. Use this as a sanity check; run a pilot to measure real recovery and compute the break-even point.

Where this pattern shines, and where it doesn’t

Use it when you want a low-friction voice channel that plugs into existing order systems and when you want to iterate on agent behavior without changing telephony plumbing. It’s less suitable when you need guaranteed, auditable compliance at the call level without legal review, when call volumes are extremely spiky without planned quotas and autoscaling, or when transcription accuracy on local accents must be proven first.

Credits and where to look next

The sample stack, deploy scripts, and walkthrough were produced with contributions from Sergio Barraza, Salman Ahmed, and Ravi Kumar. The GitHub repository contains everything you need to bootstrap a test deployment and to inspect implementation details before you pilot.

Key takeaways, quick Q&A

Can this replace human staff entirely on phone orders?

No. It can automate many routine ordering and reservation calls and reduce missed orders, but you should plan human escalation for complex cases, identity‑sensitive transactions, and verification flows. Run a pilot to measure automation coverage and escalate rates before scaling.
How does the system recognize returning callers without storing phone numbers?

The sample hashes the caller’s phone number with a secret stored in Systems Manager Parameter Store to compute a session identifier. Use a keyed HMAC (for example HMAC‑SHA256), rotate the secret, and treat the identifier as sensitive data. This approach enables recognition, not identity proofing.
What are the most important operational constraints?

Plan for Nova 2 Sonic’s documented streaming limit (8 minutes), warmup/cold‑start behavior, PSTN toll‑minute costs (toll‑free numbers are expensive), baseline compute for always‑on Fargate tasks, and regional quotas for Bedrock/Nova and Chime. Verify quotas and measure transcription quality on your audio profile.
Where should I start if I want to try this?

Request Bedrock Nova 2 Sonic access in your target region (us‑east‑1 recommended), ensure Chime PSTN access, clone the GitHub sample, run the preflight checks, and deploy the demo with the provided scripts. Execute the cleanup script after testing and use a separate test account to bound cost and risk.
What should I measure before promoting to production?

Transcription accuracy (WER) on real PSTN audio, warmup success rate, time‑to‑first‑word, end‑to‑end order commit latency, concurrency limits under expected load, escalation/handoff success, and cost per recovered order under your traffic profile.