What Amazon Bedrock AgentCore Actually Takes Off Your Plate
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: the context manager and the judgment around it.

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.
You built the harness that keeps production agents from burning tokens and deleting databases, then AWS turned a large fraction 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.
Agents do not fail in the model; they fail in the harness. The runaway loop that burned a weekend of tokens was 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 most of what 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 instead of coding 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 come from 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 scorecard
| Harness component | What AgentCore ships | What stays yours |
|---|---|---|
| Context manager | Nothing | Selection, compaction, eviction, and token budget |
| Memory | Short-term events (actors, sessions, branches) plus long-term strategies (semantic, summary, user-preference, episodic) | Working memory, retrieval scoring, write deduplication, write-time validation |
| Validators | Partial: Policy compiles natural-language rules to Cedar; log or enforce mode | Schemas, business rules, plan-step contracts, domain rules |
| Tools | Gateway (APIs, Lambda, MCP), Code Interpreter, Browser | Descriptions, exclusion clauses, structured errors, permission policy |
| Observability | OpenTelemetry (auto when hosted) plus Evaluations (13 LLM judges at session, trace, and tool-call level) | Span design, judge calibration, golden set, dimensions, promotion thresholds |
| Recovery | Partial: session-isolated microVMs, lifecycle states, clean failure boundaries | Retry policy, idempotency, checkpointing, escalation |
| Coordination | Runtime per agent, serve_a2a, A2A protocol surface |
Delegation policy, handoff schemas, task state machine |

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. Policy authorizes actions in Cedar from 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.
The patterns, not the services
A service catalog is not an architecture. Score the same platform on five structural patterns.

Isolation is the strongest showing. Every session runs in a dedicated microVM with isolated CPU, memory, and filesystem; Code Interpreter is sandboxed execution as an API call. Structural controls outside the model are the only enforcement that holds, sold by the hour.
Progressive disclosure is partial. Gateway centralizes tool discovery; deciding what the agent sees, and when, is still your design.
Mechanical enforcement is second-strongest. Identity's requires_access_token decorator hands credentials to the tool at call time, so the model cannot leak a token it never held. Policy extends that idea to actions in Cedar, with log mode before enforce. The rules remain yours; most enforcement you need is domain enforcement.
Integrated feedback is most of a loop. Evaluations closes measurement: judges, sampling, scoring, dashboards, CI gate. It does not decide what good means, whether the judge agrees with humans, or which threshold fails the build.
Spec-first is not for sale. No hyperscaler will move your intent into version-controlled specifications before application code. Disciplines do not have SKUs.
When you evaluate any agent platform, run this five-line check before a single feature page.
Two loops, one substrate
Wire the same services into two frameworks and the seam becomes visible.

The Claude Agent SDK runs the Claude loop in your Python process. A single async query() generator handles reasoning, tools, permissions, hooks, sessions, and subagents. Components are internalized: you do not see the context manager until you need a hook.
LangChain DeepAgents is the opposite temperament. create_deep_agent surfaces the harness as constructor args: model, tools, system_prompt, middleware, subagents, skills, memory, backend, checkpointer, store. It runs on LangGraph; ChatBedrockConverse keeps the stack on AWS.
Neither is better. They distribute the same seven components differently. Running both against one substrate teaches the loop-versus-substrate boundary. Frameworks churn; that boundary does not. Everything here is Python: AgentCore SDK is Python-only, DeepAgents is Python-first.
The agent worth building against
One concrete example: a market-intelligence agent. It monitors competitors with a managed browser, cross-checks an internal catalog through Gateway tools, analyzes in a sandboxed code interpreter, remembers analyst preferences and findings across sessions, fans research over A2A, and ships a weekly .xlsx report.
It is not a coding agent. It is long-running, asynchronous, outcome-shaped work that touches the catalog, and every page it reads is untrusted input. That property makes it the right vehicle for a security thread: browser opens the injection surface, memory creates the write path, and a poisoned competitor page can corrupt a report three sessions later unless you break the chain hop by hop.
Landscape, briefly
Google has Vertex AI Agent Engine; Microsoft has Azure AI Foundry Agent Service. All three hyperscalers arrived at the same conclusion: the harness is infrastructure, infrastructure is a market, and the loop belongs to the customer.
AgentCore earns deep treatment because it is the most composable (Memory without Runtime, Gateway without either) and genuinely framework-agnostic. On GCP or Azure the scorecard still transfers: different SKUs, same right-hand column.
Do this today
- List the seven harness components for your current agent and mark each built, rented, or missing.
- For every rented row, write one sentence on what still stays yours: stopping conditions, domain rules, golden sets, write-time validation.
- Run the five-pattern check on any platform you are evaluating.
- Name the exact boundary where platform services would plug into the loop you already use, without owning that loop.
- Map one production failure from the last quarter to the scorecard's right-hand column, not to "the model was wrong."
What you own

The hyperscaler is selling infrastructure, and it is selling it well. Take it. There is no medal for hand-rolling a sandbox; AWS's microVM is better isolated than the container you were going to run.
What is not for sale is the judgment: stopping conditions, schemas that reject a bad plan step, the context manager that decides what the model sees, the rubric and golden set that answer whether any of this was correct, and the threat model that assumes the web page is lying. AWS will sell you a policy engine and thirteen judges. It cannot sell you the policy or the verdict. Those were always the engineering. The platform just removed the scaffolding that was hiding them.
This is Part 1 of "Harness Engineering on the AWS AgentCore Hyperscaler," a 12-part guide to building production agents on Amazon Bedrock AgentCore while keeping the loop, the judgment, and the security model yours.