AWS AgentCore: What Amazon Bedrock AgentCore Actually Takes Off Your Plate - I
Part 1: Amazon Bedrock AgentCore turns most of the agent harness into managed services, but the honest scorecard shows four covered, two partial, and one component no hyperscaler can sell ...
You built the harness that prevents production agents from burning tokens and deleting databases, and then AWS turned a large fraction of it into a config file. The pieces that still page you at 3 a.m. are the ones no platform can own.
In this article: You will audit Amazon Bedrock AgentCore against the seven components every production agent harness needs, map those results onto five structural patterns, and see what “rent the substrate” still leaves on your plate. By the end, you will know what to take from the platform, what still fails without your judgment, and why the seam between your loop and AWS’s services is the skill that transfers when frameworks churn.
Part 1 of “Harness Engineering on the Hyperscaler,” a 12-part guide to building production agents on Amazon Bedrock AgentCore while keeping the loop, the judgment, and the security model yours.
Agents fail in the harness, not the model. AWS turned most of that harness into managed services. Here is the honest scorecard, including the two components no hyperscaler can sell you.
Agents do not fail in the model; they fail in the harness. The runaway loop that burned through a weekend of tokens was due to a missing stopping condition. The agent that deleted a production database was unscoped. A lesser model in a well-built harness routinely beats a stronger model in a bad one, which is why the harness, not the model, is the variable you engineer.
So you built one: context compaction, plan-step validators, a memory tier you can reason about, sandboxes, OpenTelemetry on every model call. That work is what most separates a demo from a system.
Then AWS shipped Amazon Bedrock AgentCore and turned a large fraction of it into a config file.
This is the honest audit of that fact. Not the marketing story where the platform solves everything, and not the reflexive story where anything managed is a toy. Hold AgentCore up against the seven components every production harness implements, mark each covered, partial, or untouched, and watch the untouched ones carefully. Those are the ones that page you at 3 a.m.
Three ways to get a harness
There are exactly three ways to end up with a production agent harness, and they differ in what you own.
Build it. You write the loop, context manager, validators, memory, sandbox, and traces. Maximum control, maximum surface area, and every component is yours at 3 a.m. Walk this path at least once; you cannot evaluate a managed component you have never had to build.
Rent the loop. You hand the whole agentic cycle to a vendor. Anthropic’s Managed Agents is the cleanest example: agent, environment, session, then a server-side loop observed through an event stream. You configure the harness rather than code it.
Rent the substrate. You keep the loop in your own framework and rent everything around it. Reasoning cycle, stopping conditions, and validators stay in your process under your tests. Hosting, isolation, memory, tool discovery, auth, and traces are provided by the platform.
AgentCore is the sharpest instance of the third path. The AgentCore SDK is explicitly framework-agnostic. Runtime is a Starlette server that calls your async function and does not care what is inside it. Docs name LangGraph, Strands, CrewAI, and Autogen without owning any of them. The design bet is that you bring the loop. The interesting engineering is the seam.
The right column is not leftovers. It is the control set whose absence causes the failures you already lived through.
A runaway loop is a stopping condition in your loop, not AWS’s. Context rot is a context manager, and AgentCore has no opinion about it. Memory poisoned by a hostile web page is a write-time validator; no managed memory service will write that rule for you.
The partials are further along than many expect. The policy authorizes actions in Cedar under English rules. Evaluations run thirteen LLM judges against live traffic and put scores next to latency graphs. Neither existed a year ago. Both still need you: Policy enforces your rules (AWS does not know your 40 percent discount needs a director), and Evaluations ships the judge, not the verdict, the human agreement check, or the promotion threshold.
Honest summary: AgentCore is very good at infrastructure, increasingly good at the machinery around judgment, and structurally incapable of supplying judgment itself. That is the correct division of labor.
If you are a paid subscriber, thank you. Your support makes this work possible.
If you are a free subscriber and find these articles useful, please consider upgrading. A paid subscription is $80 per year or $8 per month.
