Demo / How it works
How it works
What happens on a call, start to finish, as the demo is built today. Tools retrieve records and calculate policy outcomes. The AI manages the conversation, while configured rules govern escalation and queue selection.
Architecture
Telephony and the AI live in AWS. The customer data lives in Salesforce. Tool results return to the conversation, and the conversation returns control to the contact flow when a call completes or needs a person.
Amazon Connect
- Contact flow and telephony: answers the call, selects the demo scenario from the dialed number, looks the caller up, and plays the greeting in a generative voice.
- AI agent orchestration: the Amazon Connect Customer AI agent (the capability formerly called Amazon Q in Connect) understands natural speech and decides which tool to call.
AgentCore gateway and Lambda tools
- Three tools on AWS Lambda behind an Amazon Bedrock AgentCore gateway, exposed over MCP: find the customer, get prescriptions, find open cases.
- Read-only, fixed query templates. The order-status tool also calculates the on-track or overdue judgment and composes the sentence to speak.
Data sources
- Salesforce: a real org queried live over authenticated API access. Fictional records.
- Policy knowledge base: articles the agent retrieves for refills, controlled substances, shipping, and processing times.
- Simulated carrier: canned tracking status, location, time, and cold-chain reading keyed by tracking number.
Outcomes
- Completed self-service: the agent asks whether anything else is needed, then ends the call.
- Return to flow for escalation: the agent hands back the caller’s identity, type, and intent; the flow picks the queue from configured rules and transfers.
What happens during a call
- The dialed number selects the scenario. Each of the five demo numbers maps to one fictional customer. The flow uses that customer’s phone number for the lookup, not yours, so every call is self-contained.
- The caller is looked up before anything is spoken. The flow searches Salesforce for a contact whose phone number matches, and writes the identity into the conversation session.
- A known customer is greeted formally. “Thank you for calling Acme Pet Pharmacy. Welcome back Ms. Mitchell. How can I help you today?” Title and last name only; the agent never uses a first name.
- The caller says what they need. No menu. The agent understands the request and calls a tool when it needs records.
- The request is resolved or transferred with context. Order and delivery status for an identified caller is answered in the call. Anything else, and any request for a person, returns control to the flow for routing.
How customer records are found
The calling number is matched against the Salesforce contact phone field. In the demo, the calling number is the scenario’s fictional number.
| Result | What the agent does |
|---|---|
| Exactly one match | Recognized. Greeted by title and last name; records are retrieved without asking for a number. |
| More than one match | Not identified. The agent asks only what the call is about, then transfers to a person. Ambiguous callers are never self-served. |
| No contact match | An account phone match is tried. If there is still none, the agent asks whether the caller is a pet owner or a prescriber, asks for the phone number on the account, reads it back for confirmation, and looks it up. After three unsuccessful tries, the call goes to the support queue. |
Locating a record and verifying that the caller is authorized to discuss it are separate operations. The public demo locates the record; a production deployment adds the verification step your policy requires before any account detail is spoken.
What the demo can answer
For an identified caller: order and delivery status, including cold-chain status for refrigerated medication; whether a processing order is on track or overdue, calculated from the order date against the processing-time policy; refills remaining and auto-refill status; and the caller’s open cases by subject. Clinical and dosing questions are directed to the pharmacist or veterinarian. Controlled-substance questions from prescribers go to the prescriber queue.
One call, traced
An example captured during testing of the shipped-order scenario in September 2026. The shipment dates are demo fixtures.
- Caller request
- “Where is Bailey’s insulin order?”
- Tool invocation
get_prescriptionswith the contact id written into the session at the start of the call.- Source result
- Prescription record for Bailey, Vetsulin insulin, status Shipped, tracking number 1Z999AA10123456784. The simulated carrier returns: out for delivery, Atlanta, Georgia, expected today by 7 PM, cold chain normal.
- Business rule
- A tracking number is present, so the tool composes a tracking answer and appends the cold-chain status. No overdue check applies to a shipped order.
- Spoken result
- “Bailey’s Vetsulin insulin shipped on August 30th. It’s out for delivery in Atlanta, Georgia, expected today by 7 PM. The cold chain is normal, so it’s been kept at the right temperature.”
- Outcome
- The agent asks whether anything else is needed, then completes the call. No agent time.
Where the wording is controlled
The order-status tool returns the complete sentence to speak, and the agent is instructed to speak it as returned rather than rephrase it, preface it, or add delivery details. That instruction is part of the agent’s configuration, not a separate speech path, so it is a strong constraint on the model rather than a mechanical guarantee. The judgments that matter, on track versus overdue and normal versus excursion, are calculated in the tool, not by the model.
How routing works
The agent establishes who the caller is and what they want, then returns control. The contact flow chooses the destination from configured rules; the model does not pick a queue.
| If the caller is | The call goes to |
|---|---|
| Asking for a person, an agent, a representative, or a human, at any point | Transfer immediately, with no clarifying questions |
| A prescriber | Prescriber queue |
| A pet owner, or anyone else | Support queue |
| Unidentified or ambiguous | Support queue, flagged as unidentified |
Before a transfer, the flow checks whether an agent is available in the target queue. If one is, the call is transferred with the caller’s identity, type, intent, and a summary attached. If none is, the caller hears a short handoff message explaining what would happen in production, and the call ends. A public caller never waits in an empty queue.
When the system cannot answer
- The number matches more than one record. No identification is attempted; the call goes to a person after one question about the reason for the call.
- The account cannot be found by spoken number. After three tries, the call goes to the support queue.
- The caller cannot be heard. After one unintelligible response the agent asks again; after a second, it says it is having trouble hearing and transfers.
- A refill has no authorizations left. The agent explains that the veterinarian’s authorization is needed and offers to start that or connect the caller.
- The request is outside what the demo answers. Billing, cases beyond a status check, clinical questions, and anything unclear go to the support queue with the stated intent attached.
- A transfer cannot be completed. The caller hears an apology that the call cannot be handled right now, and the call ends.
What changes for your environment
We map your Salesforce objects, configure authenticated access, define caller lookup and verification requirements, connect your policies and queues, and test the target workflows. A production carrier adapter keeps the same tool interface while mapping and validating the selected provider’s responses. The records behind the demo are listed on Data & sources.