Building a Post-Delivery Care Agent on AWS CDS: Hackathon Engineering Notes

We built this project for the AWS Communication Developer Services (CDS) Agentic AI Partner Hackathon, whose deadline was 28 October 2026, 1:00 PM PT. Between 7 and 28 October two engineers wrote 263 commits across the project’s branches. We did not submit the entry. Below is what we built, why, and which parts are still a prototype.

The general architecture behind it, without the hackathon specifics, is in Building production agentic AI with AWS CDS and AgentCore.

What this is — An unsubmitted hackathon prototype for a fictional appliance and furniture store called HomeNest. The committed configuration runs in dry run: the agent works each case end to end and records what it would send, without sending. The voice support line has been run on a live Amazon Connect development instance. No real customer has used it, and we report no business outcome.

The problem we picked

Our proposal started as an EV-ownership agent: service reminders over RCS, booking on WhatsApp, a confirmation by SES. We changed domain before writing code. The built project is post-delivery care for appliances and furniture.

The reason was the shape of the work. After a washing machine arrives, the store already knows what was bought, when it arrived, and what usually goes wrong with it. What it lacks is someone to check in, walk the customer through an error code one step at a time, ship a missing part once a photo shows what arrived, and book a technician when the fix fails. That is repetitive, it has real data behind it, and most of it is reads, which is where we think agents should start.

Channels, and why each one

The hackathon centres on End User Messaging SMS/RCS, End User Messaging Social (WhatsApp), and Amazon SES. We used all three, plus Amazon Connect for voice and web chat.

The agent picks only from channels that are switched on and that the customer has consented to.

Where the agent sits

There are two agents, and they share one case record in DynamoDB:

• The text agent is a Strands agent on Amazon Bedrock AgentCore Runtime, using Claude Haiku 4.5 on Amazon Bedrock by default.
• The voice agent is an Amazon Connect AI agent. It reaches the same actions through AgentCore Gateway, which presents a Lambda function to Connect as MCP tools.
• AgentCore Memory keeps each customer’s contact preferences between orders.

The agent does not receive raw channel events. The path is:

1. A store event arrives on a signed webhook, or a delivery event lands on an EventBridge bus.
2. An SQS FIFO queue holds it, with one message group per case, so two turns never run on the same case at once.
3. A dispatcher takes a one-time claim on the turn, sets the follow-up timer in EventBridge Scheduler, and invokes the agent on AgentCore Runtime.
4. The agent gets only the tools its playbook allows and a cap on model calls per turn.
5. Replies, bounces, complaints, and failed deliveries come back on one SNS topic. A reply queues the next turn. An opt-out word withdraws consent for that channel. A failed delivery is recorded so the agent tries another channel.

Tool boundaries

Five playbooks run in the same agent: delivered, delivery failed, payment failed, return requested, and negative review. Each has its own prompt and its own short list of allowed actions.

The limits live in code that both agents call through, not in the prompt: consent and opt-out, offer caps, a refund ceiling, a photo before any part ships, one of each part per order, and the number of follow-ups. A refund is a request. A support lead grants or declines it in the operator console, once, and the agent tells the customer on its next turn.

Security, consent, and failure handling

• Never contacting a customer twice. Queues, topics, and timers all deliver at least once. A send is written to the case before it goes out and removed if delivery fails, so a retry sees it and stops.
• Not retrying a turn that may have spoken. A turn that fails inside the agent runtime is logged and raises an alarm, and the follow-up timer picks the case up later. It is not retried automatically.
• Knowing who is calling. A caller’s number finds their order, but numbers can be forged. A caller found by number must give the delivery ZIP code before the agent tells them anything beyond how to fix the product. The address is never read out.
• Naming the case on a call. A case ID is built from the order number and could be guessed, so the voice agent gets a one-call token that works for one case and expires after two hours.
• Links as credentials. A link the agent sends works once, for 24 hours, on one case. Photos go to a private bucket and are deleted after 30 days.

What broke — An agent that said it did something it did not. Connect reported a tool that answered with an error as a success, and the voice agent told a caller a guide was on its way when nothing had been sent. The fix was in the instructions and in the tool answers: the agent now reads the error inside a tool’s response and never says something was sent, shipped, or booked until the response shows it.

What was built and tested

Built and tested, per the project README on 28 October 2026:

• The text agent, the channel code, the operator console, and a local demo.
• The support line: answered by the AI agent in the Nova Sonic voice, caller recognised by number, guided through a fix, handed to a person on request. Run on a live development instance and with scripted conversations.
• Unit and stack tests across the Python packages and the CDK app, run in CI.

Not yet:

• Texts from the deployed agent on the support line. SMS is not configured there, so guides go by email.
• Email through Connect, built but not run on a live instance.
• A stronger caller check than the delivery ZIP code.
• Evaluations and the cost stack, listed as not built in the design document.
• Live sends on the messaging channels outside dry run. We have not confirmed approved registrations for this project.

What production would need

1. Channel registrations approved for the store’s own use case, per channel.
2. A caller identity check stronger than a ZIP code.
3. An evaluation suite with authorization, prohibited-action, and injection cases as release gates. The architecture guide lists a starter set.
4. Cost controls: a budget per environment, and alarms on model calls per case.
5. A security review of the console, the webhook, and the link tokens.
6. Retention rules for transcripts, photos, and memory that match a privacy notice.

Reproduce this — The project repository is private. The pieces of its design that generalize are in the reference normalizer from part 6 of the CDS series: five synthetic channel events and an assert-based test you can run with Python 3.12 and no dependencies.

What to Do This Week

1. If you are scoping a post-purchase agent, list the store events that should open a case (delivered, delivery failed, payment failed, return requested, bad review) and the one action each may take without a person.
2. Write the limits a customer cannot argue away (refund ceiling, parts per order, follow-up count) as code checks before you write a prompt.
3. Decide how a caller proves who they are before the agent says anything about the order.

What This Post Doesn’t Cover

A judging outcome, because the entry was not submitted. Source code, because the repository is private. Latency, cost per case, or resolution rates, because we have not measured them on real traffic.

Frequently asked questions