Most teams that pilot an agent framework rebuild the same five things by hand: per-session isolation, credential brokering, tool registration, durable memory, and tracing. They do it because they assume adopting an agent platform means handing over the reasoning loop. Amazon Bedrock AgentCore does not work that way.
AgentCore is a set of composable managed services that sit around your agent rather than inside it: Runtime for isolated serverless hosting, Gateway for turning APIs and Lambda functions into governed tools, Identity for inbound and outbound authorization, Memory for short-term and long-term context, Observability for traces and metrics, plus built-in tools like code interpretation and browser access. Per the AWS Bedrock AgentCore documentation, the services can be adopted individually and work with frameworks including Strands Agents, LangGraph, and CrewAI. Your planning loop stays yours.
That distinction matters because of the failure pattern enterprise teams keep reporting. Model-level benchmark scores look fine, then the multi-step agent breaks in production on tool calls, long contexts, and handoffs. NIST's Generative AI Profile names the risk categories that show up in exactly those places, including confabulation, information integrity, data privacy, and risks arising from value-chain and third-party components [1]. None of those are prompt problems. They are operating-layer problems.
This article covers what each AgentCore service actually solves, a build-versus-configure decision table, a production readiness checklist, two code examples, and an FAQ. If you are earlier in the journey, our agentic AI approach and agent governance solution pages cover the surrounding operating model.
The Layer Your Agent Demo Was Missing
A demo agent needs a model, a prompt, and two tools. A releasable agent needs an answer to a different set of questions. Which identity did the agent act as when it called the billing API? What happens when two users hit the same process and one of them triggers model-generated code execution? Where is the trace that shows why turn seven produced a wrong refund amount?
Every one of those questions is answered by plumbing, not by reasoning quality. That is the category AgentCore occupies. It is closer to an application platform for agents than to an agent builder, which is why it composes with frameworks you already use instead of replacing them.
The practical implication is sequencing. You do not need to adopt AgentCore as a bundle. Pick the service that unblocks the thing currently stopping your release, which in most enterprises is the security review of tool access. Then add services as the operating requirements appear. If the reasoning loop stays in a portable framework, you keep the valuable part of the system independent of the plumbing underneath.
Runtime: Session Isolation You Should Not Hand-Roll
AgentCore Runtime provides serverless hosting for agents and tools with session isolation, support for long-running executions, and framework and model agnosticism, per AWS documentation. Read that as three operating guarantees: you do not own the container lifecycle, a session has a boundary, and a multi-minute agent trajectory does not get amputated by a function timeout.
Compare that to what teams build themselves. The Lambda pattern is fast to stand up and runs into two walls: the execution duration ceiling and statelessness that pushes all session continuity into an external store you now design and operate. The ECS or Fargate pattern removes the timeout but hands you the full ops surface, concurrency model, warm-pool economics, and the per-session boundary itself.
That boundary is the part worth being opinionated about. When an agent executes model-generated code or parses tool output inside a shared process, you have created a lateral-movement path between users and tenants. Per-session isolation is a security control, not a convenience feature, and it is one of the few controls that is genuinely painful to retrofit after launch.
Runtime does not solve everything, and it is worth saying plainly what it will not fix. It will not repair a planning loop that loops forever, it will not shrink an unbounded tool surface, and it will not supply the evaluation gates that decide whether a new prompt version is releasable.
| Dimension | Lambda | ECS / Fargate | AgentCore Runtime |
|---|---|---|---|
| Session boundary | You build it in external state | You design and enforce it | Managed per-session isolation |
| Long trajectories | Constrained by function timeout | Supported, you own scaling | Long-running execution support |
| Ops ownership | Low, with hard limits | High: images, scaling, patching | Low, managed hosting |
| Framework choice | Any, you wire it | Any, you wire it | Framework and model agnostic |
| Still your job | Memory, tracing, tool auth | Memory, tracing, tool auth, isolation | Planning loop, evals, tool scoping |
Gateway and Identity: Where Tool Governance Actually Lives
AgentCore Gateway converts existing APIs, Lambda functions, and services into agent-callable tools with a managed MCP-compatible interface, discovery, and access controls, per AWS documentation. The value is not the protocol translation. It is that tool access becomes a reviewable surface with one chokepoint instead of per-team integration code scattered across repositories.
The Model Context Protocol specification revision 2025-06-18 is what makes this a tractable engineering target rather than a per-team opinion. An MCP server that requires authorization is treated as an OAuth 2.1 resource server, clients discover authorization server metadata rather than hard-coding endpoints, and resource indicators bind a token to a single server so it cannot be replayed against another [3][4]. If your current rollout hard-codes endpoints and reuses one token everywhere, you are not behind on tooling, you are behind on the published target state.
AgentCore Identity matters in both directions. Inbound: who is permitted to invoke this agent, and with what entitlements. Outbound: credential brokering so the agent calls downstream systems with a scoped delegated identity instead of a shared service account that nobody can revoke without an outage. The MCP security guidance is explicit that passing a user token straight through to a downstream API should be prohibited, because the downstream service cannot tell whether the agent was authorized to act in that context, which is the classic confused-deputy setup [5].
Beside Gateway you need registry discipline. Maintain a reviewed list of approved servers and tools with a named owner, data classification, and the pinned protocol revision each server supports, and block unregistered servers at both the network and client layer [5]. Our agent protocols solution covers the registry and version-negotiation mechanics in more depth.
Tool definitions are where governance becomes concrete. Narrow schemas do more for safety than any system prompt instruction:
{
"name": "lookup_invoice_status",
"description": "Return payment status for one invoice. Read-only.",
"readOnly": true,
"inputSchema": {
"type": "object",
"properties": {
"invoice_id": { "type": "string", "pattern": "^INV-[0-9]{8}$" },
"detail_level": { "type": "string", "enum": ["summary", "line_items"] }
},
"required": ["invoice_id"],
"additionalProperties": false
}
}Three things are doing work here: a regex-bounded identifier instead of a free-text string, an enum instead of an open parameter, and additionalProperties: false so a model cannot smuggle extra fields into the call. The readOnly flag gives your orchestration layer something to branch on when deciding whether a confirmation gate is required.
Memory and the Context You Did Not Mean to Persist
AgentCore Memory splits context into short-term session memory for multi-turn continuity and long-term memory for facts, preferences, and summaries that survive across sessions, per AWS documentation. The split is useful engineering. It is also a governance fork that teams walk past.
Short-term session context is transient working state. Long-term memory is a data store. It carries retention obligations, access-control obligations, deletion obligations, and discovery exposure. Decide what the agent is permitted to write before you enable it, not after a privacy review asks where a customer's health detail came from.
There is also an injection boundary running directly through memory. Text that arrives from a retrieved document or a tool response and gets written into long-term memory will be replayed into future prompts. If it is stored as instruction-shaped content, you have built a persistence mechanism for prompt injection. Treat all tool and resource output as untrusted data and never as instructions, and enforce that boundary in the orchestration layer rather than hoping the model ignores it [5].
Four design rules make long-term memory defensible:
- Namespace per user and per tenant so a retrieval path can never cross a tenant boundary by accident.
- Keep an allowlist of memory-writable fields rather than letting the agent decide what is worth remembering.
- Record provenance on every long-term write, including source document, tool name, and session ID, so a bad fact can be traced and removed.
- Set retention and deletion on write, not as a quarterly cleanup job.
Our analysis of durable state for long-running agent workflows goes further into the durability and replay side of this problem.
Observability: Trace Coverage Before Release Confidence
AgentCore Observability provides traces, metrics, and logs for agent sessions with CloudWatch integration and support for OpenTelemetry-compatible telemetry, per AWS documentation. The managed part saves plumbing work. The part that decides whether your telemetry is useful is attribute standardization.
OpenTelemetry's semantic conventions for generative AI define consistent names and attributes for model, agent, and tool-execution spans, events, and metrics, so traces emitted by different frameworks and vendors correlate in a single backend [6]. Without that, a LangGraph trace and a Strands trace describe the same model call with different field names, and your dashboard becomes a translation project. With it, one query answers "which tool is driving latency" across every agent in the estate.
One caveat worth building into your plan: the GenAI conventions are published as an evolving specification area, so verify attribute stability against the current specification page before you standardize dashboards, alerts, and SLOs on specific names [6]. Pin the convention version you build against, the same way you pin a protocol revision.
The coverage bar to aim for: every model invocation, every tool call with its arguments, every memory write, and every agent-to-agent handoff appears on a single trace, with token, latency, and error metrics attached to the same trace. That is what lets a quality regression resolve to a specific tool change or context change instead of a vague sense that the agent got worse [1]. Our AgentOps observability solution describes the instrumentation and review loop we build around this.
- Generative risk vocabulary
- NIST AI 600-1 enumerates generative-specific risks including confabulation, information integrity, data privacy, and value-chain risk, giving evaluation scope a named basis
- [1]
- Four-function cadence
- AI RMF 1.0 organizes work as Govern, Map, Measure, and Manage, so evaluation becomes scheduled re-measurement rather than a launch-time task
- [2]
- Telemetry spec is moving
- OpenTelemetry GenAI semantic conventions are an evolving area, so verify attribute stability before standardizing alerts
- [6]
AgentCore or Self-Managed Harness: The Decision Table
The real choice is not AgentCore versus open source. It is AgentCore services wrapped around your own framework code, versus a fully self-managed harness on Lambda or ECS with a framework such as Strands Agents or LangGraph plus components you assemble yourself.
Be honest about lock-in by locating it precisely. If your reasoning loop lives in a portable framework and your telemetry follows OpenTelemetry conventions, your exit cost sits in the plumbing layer: hosting, credential brokering, and tool registration. That is replaceable work. The expensive, product-defining assets (prompts, tool contracts, evaluation sets, memory schema) stay yours.
The cost model difference is the one teams underestimate. Managed per-session and per-request charges are visible in the bill. Always-on container capacity plus the engineering time to build isolation, credential brokering, memory durability, and tracing shows up as headcount and schedule, which rarely gets compared against the managed line item. Pull current figures from the AWS pricing pages for AgentCore, Lambda, and Fargate rather than from a blog post, including this one.
| Dimension | AgentCore | Self-managed harness | Recommendation |
|---|---|---|---|
| Session isolation | Managed per-session boundary | You design and test it | AgentCore unless isolation is already solved |
| Tool governance | Gateway chokepoint, discovery, access control | Per-team integration code | AgentCore Gateway: adopt first |
| Inbound/outbound identity | Managed auth plus credential brokering | Custom OAuth plumbing per server | AgentCore Identity, no token passthrough [5] |
| Memory durability | Short-term plus long-term stores | Your own store and schema | Either, if provenance and retention are enforced |
| Trace coverage | Managed traces with CloudWatch | You instrument and host | AgentCore, pinned to GenAI conventions [6] |
| Portability | Framework-agnostic agent code | Fully portable, more to operate | Keep the reasoning loop framework-portable |
Production Readiness Checklist and the Permission Scope Most Teams Get Wrong
Here is the gate list we hold agents to before promotion. The point of the evidence column is that each control produces an artifact somebody can read in a review, not a verbal assurance in a standup.
| Control | Evidence artifact | Owner | Release gate |
|---|---|---|---|
| Scoped tool permissions | IAM policy diff, no wildcards | Platform security | Blocking |
| Argument validation | Schema test suite results | Agent team | Blocking |
| Human approval on writes | Confirmation gate test transcript [5] | Product owner | Blocking |
| Trace coverage | Sampled traces with model, tool, memory, handoff spans [6] | SRE | Blocking |
| Evaluation gates | Regression, safety, cost, latency report [1] | Eval owner | Blocking |
| Rollback path | Rehearsed rollback log | Release manager | Blocking |
Permission scope is where the most common failure hides. A policy written during the prototype survives into production because nothing ever broke:
# BAD: prototype policy that reached production
statement {
effect = "Allow"
actions = ["dynamodb:*", "s3:*"]
resources = ["*"]
}
# FIXED: resource-scoped, condition-constrained, read-only default
statement {
effect = "Allow"
actions = ["dynamodb:GetItem", "dynamodb:Query"]
resources = ["arn:aws:dynamodb:us-east-1:111122223333:table/invoices"]
condition {
test = "StringEquals"
variable = "aws:PrincipalTag/agent"
values = ["invoice-assistant"]
}
}Writes get a separate role, a separate statement, and a confirmation gate in the orchestration layer. Our read, reversible write, irreversible write tier model explains how to classify each tool so this split is mechanical rather than a judgment call per tool.
The evaluation suite that gates promotion should be graded, not monolithic: deterministic unit checks on tool argument construction and schema validity, trajectory-level checks on whether the agent reached the goal within acceptable steps, and regression sets built from real production failures, with held-out sets kept out of prompt and tuning loops [1]. No promotion unless the regression suite, safety checks, and cost and latency budgets all pass, with evaluation artifacts, dataset versions, and model and prompt versions recorded as the evidence package [1]. Then re-measure on a schedule under the Measure and Manage functions rather than treating evaluation as a launch activity [2].
Frequently Asked Questions About Amazon Bedrock AgentCore
Is AgentCore tied to Bedrock models or Amazon frameworks?
No. Per AWS documentation, the services are framework and model agnostic and work with frameworks including Strands Agents, LangGraph, and CrewAI. Verify the current support matrix in the AgentCore documentation before you commit, since the list expands.
Can I adopt only Gateway?
Yes. The services are composable and designed for individual adoption. Gateway plus Identity is the most common first slice because tool authorization is usually what the security review is blocking.
Does Gateway replace my existing MCP servers?
It fronts them. Gateway gives you one authenticated, audited entry point with scope mapping from enterprise identity to tool permissions, which is the pattern the MCP security guidance points toward [5]. Your servers still need a pinned protocol revision and a named owner in the registry.
Where does AgentCore Memory end and my data platform begin?
Memory holds conversational context and agent-scoped facts. Systems of record stay in your data platform, accessed through governed tools. If an agent is writing authoritative business state into long-term memory, you have a data architecture problem wearing an agent costume.
What does AgentCore not do?
It does not write your planning loop, choose your tool boundaries, build your evaluation sets, or decide what the agent is allowed to remember. Those remain product decisions.
Do agents built on general-purpose models trigger EU AI Act duties?
Potentially, and the duties follow the role you hold (provider, deployer, importer, distributor) rather than the team you sit in. Under Regulation (EU) 2024/1689, Chapter V obligations for providers of general-purpose AI models applied from 2 August 2025, and the bulk of the Annex III high-risk regime applies from 2 August 2026 [7]. Many enterprises use ISO/IEC 42001 as the management system that produces the required records [8], and the European Commission's General-Purpose AI Code of Practice is a voluntary route for demonstrating Chapter V compliance [9].
Your Next Working Session
Inventory every tool your agent can call. For each one, assign a named owner and a read-or-write classification, then delete or scope down anything holding wildcard resources or actions. That exercise usually takes an afternoon and typically removes more risk than a month of prompt hardening.
Then start tracking one metric this week: the percentage of agent sessions with complete trace coverage across model, tool, memory, and handoff spans. If that number is below 100, your incident reviews are guesswork.
The demo was never the hard part. The operating layer around the loop is what separates a convincing prototype from an agent you can release, and AgentCore is a credible way to buy most of it instead of building it. If you want help with the evaluation and release side, start with our agent release gate approach and the AgentOps observability solution.
References
[1]NIST, "AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile," 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
[2]NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)," 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
[3]Model Context Protocol, "Specification (revision 2025-06-18)," 2025. https://modelcontextprotocol.io/specification/2025-06-18
[4]Model Context Protocol, "Authorization," 2025. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
[5]Model Context Protocol, "Security Best Practices," 2025. https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices
[6]OpenTelemetry, "Semantic Conventions for Generative AI," 2025. https://opentelemetry.io/docs/specs/semconv/gen-ai/
[7]EUR-Lex, "Regulation (EU) 2024/1689 (Artificial Intelligence Act)," 2024. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202401689
[8]ISO, "ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system," 2023. https://www.iso.org/standard/42001
[9]European Commission, "General-Purpose AI Code of Practice," 2025. https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai