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.

Rick Hightower

Cover image for “What Amazon Bedrock AgentCore Actually Takes Off Your Plate” by Rick Hightower

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.

Three paths to a production harness: build everything yourself, rent the full agentic loop from a vendor, or rent the substrate while keeping the loop in your own process.

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

Mindmap of the seven-component AgentCore scorecard: context manager is untouched, memory tools and observability have managed depth, validators and recovery are partial, and coordination leaves policy on your side.

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.

Five structural harness patterns scored against AgentCore: isolation is full, progressive disclosure mechanical enforcement and integrated feedback are partial, and spec-first is not for sale.

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.

Sequence of two frameworks sharing one AgentCore substrate: the Claude Agent SDK query loop and a DeepAgents graph both call Runtime Memory Gateway and traces, teaching the loop-versus-substrate boundary.

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

Split between infrastructure AgentCore sells well and judgment that stays yours: sandboxes memory Gateway traces and policy machinery on one side, stopping conditions context manager domain schemas rubrics and threat models on the other.

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.