Amazon Connect Flows Grow a Tool Belt: MCP Tools, Case-Aware Waiting, and Emails That Can Pause
Amazon Connect flows can now call MCP tools, wait on Cases and external tools, and pause emails. Here is how to architect with that in practice.
Most Amazon Connect flow work eventually hits the same wall. The flow needs data that lives somewhere else, so you write a Lambda. The flow needs to wait for a human or a back-office system to finish something, so you build a workaround out of callbacks and queues. The contact is an email that cannot be resolved until someone else replies, so an agent either burns their session holding it or closes it and loses the thread. Four changes that landed in Amazon Connect Customer between October 30 and November 3, 2026 attack exactly those problems, and together they shift flows from routing scripts toward orchestrators of work that spans systems and time.
What changed
The headline item is the External Tool block in contact flows (November 2). Flows can now invoke Model Context Protocol (MCP) tools through Amazon Bedrock AgentCore Gateway, reusing the same tools already configured for agentic experiences, instead of writing a Lambda function for each integration. AWS's own examples are retrieving CRM case history or banking transaction details mid-contact. It is available in nine regions, including N. Virginia, Oregon, Canada (Central), Frankfurt and London, and it requires Amazon Bedrock AgentCore Gateway.
The Wait block was extended the same day: a flow can now wait until an Amazon Connect Cases field meets a condition, or until an External Tool invocation completes — previously it could only wait on Lambda. When the condition is met, the flow resumes and can route on the result. AWS illustrates it with holding a flow until a refund status field on a case updates.
Email pause and resume, announced November 3, lets agents pause an email in Agent Workspace or the CCP while waiting on information or approval, take other contacts in the meantime, and resume later. Paused time is tracked separately and excluded from active handling time, supervisors can monitor paused emails in real time, and flows can automatically resume or transfer emails paused beyond a configured threshold.
Underpinning all of it, flow versioning and aliasing arrived October 30: immutable versions of flows and flow modules, with aliases that queues, quick connects and phone numbers point to. Promoting or rolling back is now a single alias update, in all regions where Amazon Connect Customer is offered.
One tool layer for flows and AI agents alike
The MCP change has a consequence worth planning around: the same tool can now serve a deterministic flow and an AI agent. Historically those were two integration stacks. Agents (human or AI) got API access through whatever the desktop or the agent framework used; flows got Lambdas. Every new system of record meant two builds, two credential stories and two places to fix when an API changed.
One pattern that avoids that duplication: expose each system of record once, as MCP tools behind AgentCore Gateway, and let both layers consume them. For example:
- A "get case history" tool backed by Salesforce, ServiceNow or Zendesk, called by a flow before routing to decide whether this is a new issue or the third contact about an open one — and called by an agentic experience later in the same contact to summarise that history.
- A "get recent transactions" tool backed by a core banking or billing platform, used by a flow to verify identity context and by an agent experience to answer balance questions.
- A "create follow-up task" tool writing into the CRM, invoked by a flow on disconnect so the record exists even when the agent forgets.
Design the tools like good Lambda contracts: narrow inputs, structured outputs the flow can branch on, and errors it can handle gracefully. Commodity lookups stop being one-off functions and become a shared, governable tool catalogue.
Hold for the back office: Cases plus Wait
The Wait extension turns Cases from a record-keeping system into a coordination mechanism. Many contact centers run an awkward pattern today: an agent promises a refund or an approval, the back office works it in another system, and the customer calls back repeatedly because nothing reconnects the two. With a flow that can wait on a Cases field, the journey can be designed as one thread instead:
| Step | What happens |
|---|---|
| 1 | Customer contacts about a refund; agent works the contact and updates the case |
| 2 | Flow parks in Wait, watching the refund status field on the case |
| 3 | Back office processes the refund and sets the field to approved or denied |
| 4 | Flow resumes, branches on the field value, and routes accordingly — outbound notification, a specialist queue, or a survey |
The same shape works for approvals, document verification and parts dispatch: anywhere the contact center is blocked on a state change that Cases can represent. Because Wait can also pause on an External Tool invocation, the state change does not have to originate in Cases itself — an external system can be the thing being waited on, with the case field as the record of the outcome. Keep waits purposeful, though: a waiting flow is an open commitment to the customer, so pair every Wait with a timeout branch and a fallback route rather than letting contacts sit indefinitely.
Email as blended back-office work
Pause and resume fixes a measurement problem as much as a workflow one. Emails that wait on a customer, a carrier or an approver have always inflated handling time and discouraged agents from picking them up. Now the pause is explicit: the agent takes other contacts, the paused time is excluded from active handling time, and supervisors can see the paused inventory in real time instead of discovering it in a weekly report.
For example, a claims team could set a pause policy where emails waiting on third-party documents are paused with a reason, and a flow automatically resumes or transfers anything paused beyond the team's chosen threshold — so paused work cannot quietly become forgotten work. The policy decisions (who may pause, for what reasons, and what the threshold is) matter more than the mechanics; agree them with your workforce and QA teams before enabling it broadly.
Rollout notes and cautions
Sequence the adoption. Versioning and aliasing is the safety net for everything else, so adopt it first: publish immutable versions, point queues and phone numbers at aliases, and make "promote the alias" your release step. Only then add External Tool calls and Wait branches, where a bad promotion is more likely and a one-step rollback is worth the most.
Check region coverage per feature before designing around it. The External Tool block launched in nine regions and email pause and resume in ten, while versioning and aliasing is available in all Amazon Connect Customer regions — a design that works in N. Virginia may need adjusting elsewhere. The External Tool block also depends on Amazon Bedrock AgentCore Gateway, so the gateway, its tool configurations and its permissions become part of your contact-flow estate and deserve the same change control. Finally, MCP tools are still integrations: monitor their latency and failure rates, because a flow that branches on a tool result is only as reliable as the tool.
Keep exploring
The full release records, with sources and availability notes, are in the Amazon Connect release intelligence section. The individual updates: External Tool block in flows, Wait block for Cases and external tool events, email pause and resume and flow versioning and aliasing. AWS's announcements: Connect flows MCP tools (opens in a new tab), Wait block Cases and tool events (opens in a new tab) and pause and resume email (opens in a new tab).