Developing and Testing Amazon Connect AI Agents Locally

There's no "Pulse" workshop, here's what's actually real

Searching for a Connect "pulse" workshop turns up nothing in AWS's own catalog, because it isn't a thing AWS runs. What does exist, and what the intent behind that search is probably reaching for, is AWS Workshop Studio's own hands-on labs: "Introduction to Connect Customer" and "Getting Started with Connect Customer" are both real, AWS-authored workshops with step-by-step labs, linked directly from the Connect admin guide.

Those workshops are a good starting point for understanding the console and the flow designer. They are not a substitute for a local development loop, because they still run against a provisioned AWS instance, not your own machine. If you're building the Lambda logic behind an AI agent and want a fast local iteration cycle before you touch that instance, the rest of this guide is the real version of what you were looking for.

• No AWS feature or workshop is named "Amazon Connect Pulse."
• AWS Workshop Studio does run real Connect Customer workshops, hosted in the cloud, not on your machine.
• A local development loop is a separate, narrower thing: testing the Lambda code, not the contact center itself.

What you can actually test on your own machine

Amazon Connect flows reach your own systems through AWS Lambda. Whatever an AI agent does beyond built-in routing, such as checking an order status or deciding how to route a case, that logic almost always lives in a Lambda function, and Lambda functions are ordinary code you can write and run locally.

AWS's own serverless testing guidance recommends exactly this split: run fast unit tests against your business logic locally, and separately verify the full integration in the cloud. For the Connect side specifically, AWS documents the shape of the event your function receives, a ConnectContactFlowEvent with a Details.ContactData object carrying the channel, the contact ID and any attributes the flow set, plus a Parameters object for whatever the Invoke AWS Lambda function block passed in. The official Connect tutorial for this uses a hand-written mock event named exactly for this purpose, so you can write your handler, feed it that shape, and see the output before a flow ever calls it for real.

This is genuinely local and genuinely private, with one caveat: it only stays private as long as your function's own code doesn't call out to AWS or a third-party API. The moment it does, that call needs real credentials and goes over the network, same as it would in production.

• The AI agent's custom logic almost always lives in a Lambda function, which is plain code.
• AWS documents the exact event shape Connect sends to that function, so you can build a realistic test payload.
• A pure unit test of that function's logic runs entirely on your machine, no AWS account required.

What you cannot fake: the flow itself

AWS Lambda ships an official local tool, the AWS SAM CLI's sam local invoke, which runs your function in a Docker container using the same runtime Lambda uses in the cloud. It's genuinely useful, and it's genuinely limited the moment your function calls another AWS service: AWS is explicit that those calls "reach real AWS resources," because there's no local stand-in for IAM evaluation, DynamoDB, or Connect itself running inside that container.

Amazon Connect has no emulator at all, locally or otherwise, for the parts that make it a contact center: the IVR logic, the voice recognition, the chat widget, the queue and routing engine, or any of the newer Agentic Self-Service and Agent Assist behavior. AWS's own serverless testing guide is blunt about this class of problem generally: "you cannot fully replicate a cloud environment locally," and recommends testing the real integration in the cloud rather than trusting a local stand-in for it.

So the honest boundary is: your function's logic, yes, locally. The flow calling that function the way a live contact actually would, no. That half needs a Connect instance, which in practice means a separate, non-production one.

• sam local invoke runs your Lambda code locally, but its AWS calls hit real AWS resources, with real credentials.
• There is no local emulator for Connect's flow engine, IVR, voice recognition or agentic features.
• Testing the actual flow, not just the function behind it, needs a real Connect instance.

Setting up the loop that actually works

A workable local setup looks like three layers. First, write the Lambda handler so the Connect-specific parsing is a thin layer and the real decision-making logic is a separate function you can call directly in a unit test, which is the same "slim handler" pattern AWS recommends for any serverless function, and it pays off doubly here because Connect's event shape is distinctive enough to be worth isolating.

Second, use sam local invoke with a saved ConnectContactFlowEvent JSON file for the fast loop: change code, run the function, read the output, repeat, without waiting on a deploy. For calls to other AWS services inside that function, AWS's guide names two real options if you want to avoid touching live resources during this phase: Moto, a Python library that mocks AWS SDK calls in-process, or LocalStack, a separate tool that emulates services like DynamoDB and S3 so your code runs against something local instead of the real API.

Third, accept that the last mile is cloud testing against a real Connect instance before anything ships. AWS's own advice is to prioritize this over local testing precisely because a local run can pass while the deployed version fails on a misconfigured IAM policy, a Lambda timeout, or a resource-based policy pointed at the wrong instance ARN.

• Separate Connect-specific event parsing from your actual business logic, and unit test the logic directly.
• Use sam local invoke with a saved mock event for a fast local loop.
• Use Moto or LocalStack if you want to avoid live AWS calls during that loop, then test for real in the cloud before shipping.

Credentials for a local test loop

Whatever you test locally that reaches AWS still needs AWS credentials on your machine, and the same account hygiene applies here as anywhere else: use a dedicated test or development AWS account, not production, and sign in through short-lived credentials from IAM Identity Center or an assumed role rather than a long-lived access key pasted into a config file.

If your function also calls something outside AWS, such as a CRM API while you're testing an agent's self-service flow, that API key needs to come from somewhere other than a plaintext file too, whether that's a local secrets manager, your shell's keychain integration, or a short-lived value you fetch for the one test run and then discard.

• Use a separate, non-production AWS account or sandboxed instance for local-to-cloud testing.
• Prefer IAM Identity Center or an assumed role over a long-lived access key on your laptop.
• A third-party API key your test function calls still needs to stay out of plaintext files.

Where Forkbench fits, and where it plainly doesn't

Forkbench is a desktop app for the Mac that runs coding agents, like Claude Code or Codex, in a terminal. If you're using one of those agents to help write the Lambda function behind a Connect AI agent, Forkbench's Vault can hold the AWS credentials or the third-party API key that function needs for a local test run, releasing the value to the one sam local invoke command that needs it rather than letting the agent read it out of a .env file. It can also lock that Thread's folder access with the macOS kernel sandbox so the agent writing your handler can't wander into your SSH keys or other repositories while it works.

Be clear about the boundary. Forkbench has no integration with AWS or Amazon Connect, does not talk to your Connect instance, and does not replace sam local invoke, Moto or LocalStack. It manages what's on your Mac while a coding agent helps you write code; everything about the instance, the flow, and the credentials AWS itself checks happens entirely inside AWS, outside anything Forkbench touches. The folder lock is also opt-in and doesn't restrict the network, so a locked agent can still reach the AWS APIs you've given it credentials for.

• Forkbench's Vault can hold local AWS credentials or test API keys without exposing them to the agent writing your code.
• Its folder lock, opt-in and not a network restriction, keeps that agent inside your project folder.
• Forkbench has no AWS or Amazon Connect integration of any kind.