What I Learned Building AI Agents in Amazon Connect: A Walk Through the AWS Workshop

Picture a human agent on a live call. The customer asks a simple question about their bill. The agent now has six things open: the CRM, the billing system, a knowledge article, the case list, a notes field, and the call itself. They say “let me check that for you,” and then there is silence for ninety seconds while they read and click and switch tabs.

The customer hears silence. The agent feels the pressure. And none of that time went into actually helping anyone — it went into fetching.

That fetching time is what Amazon Connect’s AI agents are aimed at. Not replacing the person on the call, but removing the search-and-switch work from the middle of it. Two days ago I finished the AWS self-paced workshop Amazon Connect AI Agents, which is where AWS teaches this whole surface — agent assistance and customer self-service both.

This post is my field report from that workshop, written for developers who are deciding whether to spend the time on it.

1. What you will get from this post

Three things:

What each of the four tracks gives you — Foundation, the Agent Assistance track, the Self-Service track, and the additional AI agent capabilities module.
What I actually built — the agent-assistance setup, which is the part I got most out of.
Whether finishing it is worth your time, answered honestly rather than as an advertisement — including the naming, since Amazon’s own words for these parts are easy to mix up and everything else gets clearer once they are straight.

This is a field report, not a replacement for the workshop. I am not going to reprint the lab steps here. What I can give you is the shape of the thing, so you know what you are walking into and what to pay attention to when you get there.

Architecture diagram:

flowchart TD
    A["Customer<br/>voice or chat"] --> C
    B["Human agent<br/>in agent workspace"] --> C
    C["Connect assistant<br/>the interface"] --> D
    D["AI agent<br/>orchestration + reasoning"]
    D --> E["Knowledge base<br/>policies, how-to articles"]
    D --> F["1p MCP tools<br/>Customer Profiles, Cases"]
    D --> G["3p MCP tools<br/>Salesforce, ServiceNow, your API"]
    D --> H["Flow modules as tools<br/>your existing business logic"]

Everything below is a variation on this diagram. The tracks differ mainly in who is standing at the top of it.

2. Module 1 — Foundation: the account you build everything on

The Foundation module is the one people are tempted to skip, and then regret skipping.

It gives you the working base: a Connect instance, the domain and knowledge-base plumbing that the later tracks assume, and the security profiles that decide who and what can do things. None of it is glamorous. All of it is assumed by every module that follows.

The reason skipping hurts is structural rather than pedagogical. The later tracks do not re-create these resources — they attach to them. So if your knowledge base does not exist, or your security profile does not grant what a later step needs, the failure shows up three modules later as an AI agent that returns nothing, and you will spend your debugging time in the wrong place entirely.

My honest advice: do Foundation slowly, and keep a note of every resource name you create as you go. When a later track asks you to pick a knowledge base or a security profile from a dropdown, you want to already know which one is yours and what is in it.

There is also a practical reason to pay attention here. This workshop runs in your own AWS account. The resources you create in Foundation are the ones you will need to clean up afterwards, so knowing what you made is not just a learning aid, it is your teardown list.

3. Module 2 — the Agent Assistance Track

This is the track I spent the most time on, and the one I would send a colleague to first.

Who it is for: the human agent is still on the call. Nobody is being replaced. The AI does the fetching and the paperwork while the person keeps the relationship.

The system AI agents you get out of the box

The workshop introduces the pre-built agents rather than making you build each from scratch, which is the right call — you learn the shape faster, and you can customise later. The ones worth knowing:

Answer Recommendation — proactive. It listens to the conversation and pushes a suggested answer at each turn, with links to the source articles, without anyone asking.
Manual Search — on demand. The agent types a question in natural language and gets an answer back. Nothing appears unless it is asked for.
Note Taking — drafts the interaction notes so the agent is not typing a summary while half-listening to the next thing the customer says.
Case Summarization — automated case documentation, for the same reason.
Email agents — overview, recommendation, and draft generation for the email channel.

The proactive-versus-on-demand distinction is the one that actually changes behaviour on the floor, and it is worth thinking about before you switch things on. Proactive recommendations save time when they are right and cost attention when they are wrong. On-demand search never interrupts, but it only helps agents who remember to use it. Most teams end up wanting both, with the proactive one tuned conservatively.

Where the answers come from

The assistant pulls from two different kinds of source, and understanding why it needs both is the thing that made the rest click for me:

The knowledge base answers “what is the policy?” — refund windows, escalation rules, how-to articles. General truth, the same for every caller.
1p MCP tools answer “what is true for this caller?” — Customer Profiles for account history and payment methods, Cases for what has already been raised. Amazon Connect ships a built-in MCP server covering Connect, Customer Profiles, Cases, and Assistant APIs, and it needs no extra configuration.

A knowledge base alone gives you a system that quotes policy correctly at a customer whose situation it knows nothing about. Tools alone give you account facts with no idea what the company’s rules are. You want both, and the AI agent’s job is to combine them.

The governance layer

The workshop is good about not leaving this to the end, and neither should you:

Security profiles decide which tools a given AI agent may invoke. They are created in the Connect admin console and assigned to the agent during configuration.
User confirmation can be required per tool. The agent explains what it is about to do and waits for a human to approve before doing it. This is how anything that moves money stays safe.
AI guardrails constrain what the model is allowed to say, independent of what it is allowed to do.

Three separate controls, three separate failure modes covered. Worth internalising as a set.

4. Module 3 — the Self-Service Track

Who it is for: nobody human is on the line. This is the customer talking directly to an AI agent over voice or chat.

Agentic self-service versus the bot you already know

If you have built an intent-based bot before, the difference is worth stating precisely, because it is not just “the model is better.”

An intent-based bot matches an utterance to a predefined intent and then follows a fixed path. Every branch was drawn by a human in advance. If the customer’s situation does not fit a branch, the bot has nowhere to go.

An orchestration AI agent plans instead. It looks at the request and the tools it has, makes a plan, calls a tool, reads the result, and then decides what to do next based on what it learned. AWS’s own worked example makes this concrete: an agent handling a facilities request checks for duplicate tickets first, then classifies the problem, then creates the work order — and it reasoned its way to that order rather than being wired into it.

The whole thing stays as one continuous conversation until the issue is resolved or handed off.

sequenceDiagram
    participant C as Customer
    participant A as Connect assistant
    participant O as Orchestration AI agent
    participant T as Tools - KB and MCP
    participant H as Human agent

    C->>A: "I was charged twice this month"
    A->>O: forward with conversation context
    O->>T: look up account and recent transactions
    T-->>O: two charges, same amount, 3 days apart
    O->>T: search knowledge base for duplicate-charge policy
    T-->>O: eligible for automatic refund under 50
    O->>C: "I can refund the duplicate charge. Shall I?"
    C->>O: "Yes please"
    O->>T: issue refund - confirmation required
    T-->>O: refund created
    O->>C: confirms, gives reference number
    Note over O,H: If policy did not cover it,<br/>hand off to H with full context

The three things that make it shippable

Reasoning is the interesting part. These three are the part that decides whether you can actually put it in front of customers:

Confirmation before action. Reading data is one thing. Creating a work order, issuing a refund, or changing an account is another. Configure those tools to require confirmation and the human — the customer, in this case — stays in control of the decision.
Guardrails. Separate from tool permissions. These constrain the language, not the actions.
A clean hand-off to a human, carrying context. This is the one I would watch hardest. If the hand-off drops what the customer already said, you have not built self-service — you have built an IVR that wastes two minutes before transferring, which is worse than the IVR you had.

Where Lex still fits

Not everything should be open-ended. Collecting a policy number is a solved problem and a fixed flow does it faster and more reliably than a reasoning model. Use Lex for the deterministic parts, the AI agent for the parts you cannot draw in advance.

5. Module 4 — additional AI agent capabilities

This module is what turns a demo into something you could actually operate. Four additions:

Third-party MCP servers. You register them through Amazon Bedrock AgentCore Gateway, which turns APIs, Lambda functions, and remote services into standardised tools any AI agent can use. Salesforce, ServiceNow, your own internal system. This is the difference between an assistant that knows about Connect and one that knows about your business.

Flow modules as tools. You can take an existing Amazon Connect flow module — logic you already wrote, tested, and trust — and expose it as a tool the AI agent can invoke. You are not rewriting your business rules in prompt form. You are reusing them. For anyone maintaining a real contact centre, this is the most reassuring feature in the whole product.

Fine-grained tool control. Per tool, you can override input values with JSON path expressions, filter the output down to what is relevant, and set the confirmation requirement. Useful in practice because raw API responses are usually too big and too noisy to hand to a model unfiltered.

Observability. This is the part I would not skip. You get hand-off rate, tool selection accuracy, parameter resolution accuracy, and tool invocation success rates, plus LLM-as-a-judge evaluation of whether responses were faithful, complete, and helpful. You can also set rules that flag interactions for review automatically — low sentiment, repeated escalations — and alert on conditions like a hand-off rate creeping past a threshold.

An AI agent you cannot measure is an AI agent you cannot improve. Those metrics are how you find out that your knowledge base has a gap, or that one tool’s description is confusing the model into picking it at the wrong moment.

6. What I actually built: an agent-assistance setup

This is the part I care about most, so let me be specific about what I did and what surprised me.

My goal was narrow: give a human agent everything they need without them leaving the workspace. No tab switching, no “let me check that for you.”

The agent-assistance build

I claimed a phone number, built a contact flow, and connected it to the Connect assistant, with transcript enabled. Then I called it: the flow routed to a human agent in Agent Workspace, the Connect assistant showed up inside that workspace, and it started surfacing suggestions pulled straight from the live conversation between me and the agent — no polling, no manual search, just answers appearing as the call went.

The self-service build

Same account, a second contact flow. This one drops an Amazon Lex bot into the flow’s Conversational AI block, so the call connects straight to the AI agent — no human agent involved, unless the conversation needs to escalate, in which case the flow transfers to a live agent with the transcript intact.

What actually took the time

None of the above is prompt engineering. It’s console work: claim a number, wire a flow, point it at a knowledge base and a security profile, turn on transcript, test. The Foundation module’s setup — the knowledge base, the security profiles, the MCP access — is what gives the assistant anything useful to say. Skip it, like I nearly did, and the assistant loads on the call but has nothing to suggest.

7. Is the workshop worth finishing?

Yes, with caveats. Concretely, what you get:

The vocabulary, correctly. This sounds minor and is not. Once you know that the Connect assistant is the interface and the AI agent is the thing that reasons, the AWS documentation becomes readable. Before that, it reads like it is describing three overlapping products.
The whole surface, not one demo. Most tutorials show you either agent assist or self-service. Seeing both, and seeing that they are the same machinery pointed at different people, is what makes the design decisions make sense.
Where the safety controls live, before a client asks. When someone asks “can it issue refunds without approval?” you want to already know the answer is a per-tool confirmation setting, not go and find out.
Your own account, at your own pace. You can stop, break something, and look at what happened. That is the actual value of self-paced over a guided session.

The caveats, plainly:

It runs in your own AWS account. Leave time at the end to tear resources down, and check the Amazon Connect pricing page before you start so nothing surprises you.
It moves fast through the Foundation module. Slow down there anyway.

8. What I would watch in production

The workshop gives you a working system. Running one is a different problem. Five things I would watch:

Content quality gates everything. Before you tune a single prompt, audit whether your articles are self-contained. Every hour spent restructuring source content pays back more than an hour spent on prompt wording.
Hand-off context is the failure customers notice. They will forgive a bot that cannot help. They will not forgive repeating themselves to the human it transferred them to.
Confirmation before action is not optional for anything that moves money or changes an account. Decide this once, as policy, rather than per tool under deadline pressure.
Watch the observability metrics from day one. Hand-off rate and tool selection accuracy tell you where the system is struggling well before a complaint does.
Check quotas and cost behaviour before rollout, not after. The service limits page exists for a reason.

9. What’s next

Two things I want to try.

First, pointing this at a real client knowledge base rather than workshop content. Workshop content is clean by construction. Real documentation is a decade of articles written by different people to different standards, and I suspect the honest answer to “how good is retrieval?” is really “how good is your last ten years of writing?”

Second, wiring a third-party MCP server through AgentCore Gateway to something that is not AWS-native. The first-party tools are excellent and they cover Connect’s own world. Most contact centres live half outside it. That integration is where I expect the interesting problems to be, and it is probably the next post.

Sources on Amazon Connect AI agent concepts and naming, referenced in section 7:

Sources on self-service and orchestration, referenced in section 4:

Sources on tools, permissions and guardrails, referenced in sections 3, 5 and 8:

The workshop itself:

Amazon Connect AI Agents workshop