Agents for Humans: Three Bugs That Only Appeared After Deploying to Amazon Bedrock AgentCore

Quorum's Continuity Agent decides whether a new Baltimore City Council bill is an old issue coming back. It ran without trouble on my laptop. The moment I deployed it to Amazon Bedrock AgentCore Runtime, it failed three different ways, and none of them reproduced locally. Each one cost a deploy cycle to find, and each one is a category of bug worth knowing about before you ship.

Bug 1: cold start blew past the 30 second limit

AgentCore Runtime has a cold start budget. My entrypoint imported Strands, boto3, pydantic and the OpenTelemetry distribution at module load, before the entrypoint function ever ran.

Locally that cost was invisible, because everything was already cached on a warm machine. On a fresh runtime instance, loading all of it cold pushed initialization past the limit before my code was ever invoked.

Fix: every heavy import moved inside the function that needs it. Module load is now 0.3 seconds.

Bug 2: paths assumed my repository layout

Locally, the entrypoint sits one folder below the repository root, so walking up two directories from the file found the data.

AgentCore's direct code deploy puts the entrypoint at the root of its own image. The same path arithmetic walked one directory too high and looked for data in a folder that did not exist.

Lesson: any path built by walking up from the file assumes a directory structure, and a deployment target has no obligation to match your development checkout.

Bug 3: only the entrypoint's folder gets deployed

This was the big one. I assumed everything the entrypoint imports would travel with it. It does not. Direct code deploy packages only the directory that contains the entrypoint, so my agents, features and evaluation packages, the council record corpus and the 237,092 parcel map were never in the image.

Fix: instead of restructuring the whole repository around the packaging rules, I wrote a one way export. A build script reads the real Continuity Agent module, the real prompt and the real labeled pairs, and writes one self contained bundle of about 347 KB. The bundle carries the 50 labeled pairs with their prompts and feature tables.

The deployed endpoint only accepts a pair id from that known set, so it never needs the full corpus. Because the prompt in the bundle is generated from the same source file I evaluate locally, the deployed prompt cannot drift from the tested one.

Making it public, safely

With all three fixed, the runtime answers real calls. The hero pair, bill 26-0148 against bill 23-0411, comes back as a continuation at 0.95 confidence in about nine seconds, with real token usage reported by Amazon Bedrock.

Getting it onto a public website took one more detour. A static page cannot sign an AWS request, so a small Lambda sits in front of the runtime to sign it. Public Lambda function URLs were blocked at the account level, so the working setup is an Amazon API Gateway HTTP API in front of the same Lambda.

Then came rate limits. My first limiter was a counter inside the runtime, and it could never work: AgentCore isolates every invocation in its own execution environment, so in process counters never see each other. The real limits had to live outside the process:

What I took away

Local success tells you your logic works. It tells you nothing about import cost, file layout or what actually gets packaged. On AgentCore, assume a cold, flat, isolated environment, and put anything that must be shared, like a rate limit, outside the runtime.

Anyone can run the deployed agent from the site. Every call returns a new AgentCore session id, so you can see it is not a replay.

Live demo: https://quorum-peach.vercel.app

Code: https://github.com/Rickygole/Quorum

Demo video: https://youtu.be/d4mJJAkWwK8