Amazon Bedrock AgentCore and related suite

Amazon Bedrock AgentCore and related suite: full feature and capability survey

2026-05-17 · agentic-ai tools-infrastructure governance-policy memory-context mlops-deployment · medium · source → · wiki →

key claims

Amazon Bedrock AgentCore is best understood as an execution and control-plane layer for arbitrary agent code, because Runtime hosts any framework and model while Amazon Bedrock Agents remains a narrower managed orchestration abstractionAWS (n.d.)AWS (n.d.)
AgentCore Runtime provides lightweight virtual machine (microVM) session isolation, eight-hour execution windows, protocol support for MCP and A2A, persistent storage options, streaming, and built-in auth hooks for hosted agent workloadsAWS (n.d.)AWS (n.d.)AWS (n.d.)Firecracker (n.d.)
Gateway plus Policy function as the suite's tool-governance surface, because AWS documents target translation, semantic tool discovery, interceptor-based authorization, and Cedar, a language for writing authorization policies, as the pre-execution policy layer at the agent-to-tool boundaryAWS (n.d.)AWS (n.d.)AWS (n.d.)Cedar (n.d.)
AWS documents AgentCore Memory as short-term event memory plus long-term extracted records, not as an explicit semantic, episodic, and procedural taxonomy, and that design is still more operationally explicit than Bedrock Agents memory because it separates event capture, extraction strategy, namespace scoping, retrieval, and encryption choicesAWS (n.d.)AWS (n.d.)AWS (n.d.)AWS (n.d.)AWS (n.d.)
AgentCore Identity gives agents first-class workload identities, supports both user-delegated and autonomous OAuth 2.0 patterns, and automatically manages refresh-token reuse, which makes it the suite capability most directly aligned with regulated-enterprise machine-identity requirementsAWS (n.d.)AWS (n.d.)AWS (n.d.)Research (2026)
Observability, Browser, and Code Interpreter move AgentCore beyond pure orchestration into managed operational infrastructure, because AWS couples trace and metric collection with isolated browser automation and sandboxed code execution under the same control stackAWS (n.d.)AWS (n.d.)AWS (n.d.)AWS (n.d.)
Strands Agents is optional rather than mandatory, and its open-source authoring model pairs naturally with AgentCore because AWS positions AgentCore as a runtime and governance substrate for Strands and other frameworks alikeStrands (n.d.)AWS (n.d.)
The current GA boundary covers the core service family but not every adjacent surface, because AWS documents core AgentCore as GA while still marking Registry, Optimization recommendations, and managed session storage as previewNew (2025)AWS (n.d.)AWS (n.d.)

Research Question

What is the complete set of features, functions, and capabilities offered by Amazon Bedrock AgentCore and its related suite, including AgentCore Gateway, AgentCore Memory, AgentCore Identity, and the Strands Agents Software Development Kit (SDK), and how do those capabilities support the deployment and operation of production Artificial Intelligence (AI) agents at enterprise scale in a regulated environment?

Findings

Executive Summary

Amazon Bedrock AgentCore is a production-agent platform layer that adds runtime isolation, tool governance, machine identity, memory services, and operational observability around arbitrary agent code rather than replacing agent frameworks with a single managed abstraction. The suite's core services, Runtime, Gateway, Memory, Identity, Observability, Browser, Code Interpreter, and Policy, are documented as generally available from 2025-10-13, while Registry, Optimization recommendations, and managed session storage remain preview on the current public pages. For regulated enterprises, AgentCore directly covers runtime isolation, workload identity, tool authorization, observability, and private-network deployment, but it does not remove customer responsibility for consent mapping, retention policy, sensitive-data hygiene, and policy design.

Key Findings

Amazon Bedrock AgentCore is best understood as an execution and control-plane layer for arbitrary agent code, because Runtime hosts any framework and model while Amazon Bedrock Agents remains a narrower managed orchestration abstraction.
AgentCore Runtime provides lightweight virtual machine (microVM) session isolation, eight-hour execution windows, protocol support for MCP and A2A, persistent storage options, streaming, and built-in auth hooks for hosted agent workloads.
Gateway plus Policy function as the suite's tool-governance surface, because AWS documents target translation, semantic tool discovery, interceptor-based authorization, and Cedar, a language for writing authorization policies, as the pre-execution policy layer at the agent-to-tool boundary.
AWS documents AgentCore Memory as short-term event memory plus long-term extracted records, not as an explicit semantic, episodic, and procedural taxonomy, and that design is still more operationally explicit than Bedrock Agents memory because it separates event capture, extraction strategy, namespace scoping, retrieval, and encryption choices.
AgentCore Identity gives agents first-class workload identities, supports both user-delegated and autonomous OAuth 2.0 patterns, and automatically manages refresh-token reuse, which makes it the suite capability most directly aligned with regulated-enterprise machine-identity requirements.
Observability, Browser, and Code Interpreter move AgentCore beyond pure orchestration into managed operational infrastructure, because AWS couples trace and metric collection with isolated browser automation and sandboxed code execution under the same control stack.
Strands Agents is optional rather than mandatory, and its open-source authoring model pairs naturally with AgentCore because AWS positions AgentCore as a runtime and governance substrate for Strands and other frameworks alike.
The current GA boundary covers the core service family but not every adjacent surface, because AWS documents core AgentCore as GA while still marking Registry, Optimization recommendations, and managed session storage as preview.
For financial-services-style deployments, AgentCore provides most required technical controls but still leaves critical governance work to the customer, especially around delegated-user mapping, memory-retention policy, sensitive-field handling, and approval logic.

Assumptions

This item treats "regulated environment" as a technical-control question about identity, audit, encryption, network isolation, and retention, because AWS documentation addresses those controls directly while not providing legal compliance determinations.
This item treats the current public documentation set as the operative truth for service availability, even if additional private roadmap information exists outside the public pages.

Analysis

AWS is not presenting AgentCore as one more agent framework. It is presenting AgentCore as the missing operating layer that lets teams keep their preferred framework while AWS supplies the harder production surfaces: runtime isolation, token custody, tool gateways, and telemetry. A plausible rival interpretation is that Amazon Bedrock Agents already covers production needs, but that interpretation fits only when a team is comfortable with the managed orchestration model and does not need arbitrary frameworks, external-model flexibility, or a first-class Gateway and Identity layer. The more important limitation is not missing runtime capability but the remaining customer work at the governance boundary: AWS gives the building blocks, yet the customer still has to define who may delegate to whom, how long memory should persist, and what fields may safely enter metadata, prompts, or logs.

Risks, Gaps, and Uncertainties

The current public Memory pages do not provide the same explicit retention-time documentation that Bedrock Agents memory does, so regulated data-lifecycle conclusions remain partly inferential.
Preview surfaces such as Registry, Optimization recommendations, and managed session storage could change materially before their eventual GA behavior and pricing settle.
Because execution-role credentials are reachable inside the microVM, runtime security depends heavily on least-privilege role design and trusted code inside the session.
Memory poisoning and prompt-injection mitigation remain customer obligations, which means service adoption does not by itself create a complete safety case for autonomous agents.

Open Questions

When Registry and Optimization reach GA, will AWS keep them modular or move toward a more opinionated bundled control-plane offering?
Will AWS add explicit long-term memory retention and expiry controls comparable to the documented retention window in Bedrock Agents memory?
How much of the delegated-identity and approval model can be standardized across multi-agent chains without forcing application teams back into custom orchestration code?