At AWS Summit New York on June 17, AWS quietly dropped the “preview” label from the managed agent harness in Amazon Bedrock AgentCore. That one status change matters more than most of the Summit headlines: it means you can now go from zero to a production-grade AI agent in minutes using a config file instead of hand-rolled orchestration code. Here’s what actually changed, what’s still gated, and two things AWS buried in the footnotes.
The Managed Harness: From Orchestration Code to YAML #
The core of the GA announcement is the AgentCore managed harness. Before this, deploying to AgentCore Runtime meant building your own agent loop in a containerized application — managing session state, retries, and tool invocations yourself. Now you declare what your agent does, and AgentCore handles the rest.
Your configuration looks roughly like this:
model: anthropic.claude-sonnet-4-5
instructions: |
You are a helpful assistant that answers questions
using up-to-date web knowledge.
tools:
- name: web_search
type: builtin
source: agentcore-web-search
memory:
short_term: true
long_term:
strategies: [summary, semantic]
Three CLI commands later — agentcore init
, agentcore test
, agentcore deploy
— and you have a running agent in AWS with session isolation, built-in observability, and eight-hour execution windows. Swapping models is a one-line YAML change. Adding a new tool is the same. The harness stitches together compute, identity, memory, and networking without you touching any of that infrastructure.
This is a meaningful shift. Eight-hour execution windows are industry-leading — Azure Container Apps default to 30 minutes, Google Cloud Run caps at 60. For long-running agentic tasks, that gap matters.
Web Search Is Now GA — With a Compliance-Friendly Guarantee #
Web Search on AgentCore Gateway is also GA as of June 17. It’s a fully managed tool that grounds your agent in current web knowledge — built on Amazon’s own search infrastructure, the same stack powering Alexa+ and Amazon Quick.
The enterprise angle that makes this interesting: zero data egress. Your agent’s queries stay inside your AWS VPC perimeter. That matters if you’re operating under data residency requirements or can’t send queries to an external search API. You pay only for Gateway data transfer — no per-search fee.
In practice: your agent sends a natural-language query, gets back snippets, source URLs, and publication dates, and reasons over that to produce a grounded, citable response. For most teams that previously reached for a third-party web search API, this is a cleaner integration path with fewer compliance headaches.
The Two Things AWS Buried #
AWS’s Summit coverage was understandably upbeat. Two items that deserve more prominence:
ARM64 containers are required. No exceptions. AgentCore Runtime runs on AWS Graviton. If you have existing x86 Docker images you want to migrate to AgentCore, you need to rebuild them for ARM64. Multi-arch builds with docker buildx --platform linux/arm64
are straightforward, but it’s friction that isn’t front-and-center in the GA announcement. Greenfield projects won’t notice. Migration projects will.
The pricing model has 12 components. AgentCore bills Runtime, Gateway, Memory, and additional services across five different billing patterns — per-session active consumption, per-request, per-record, pass-through for underlying model costs, and free/preview for some features. Web Search carries no search cost, but Gateway data transfer is not free. If you’re moving workloads from simple Lambda-based agents to AgentCore at scale, model the cost first. The per-session active consumption on Runtime can surprise teams used to Lambda’s per-invocation model.
What’s Still Preview #
Three capabilities AWS announced or highlighted at Summit are not GA:
Insights— the agent session analytics dashboard for tracking failures, intent, and trajectory across hundreds of sessions. Currently preview; don’t build production monitoring SLAs around it yet.Payments— per-task billing that lets your agents pay for external services. Still preview.** AWS Context**— the knowledge graph service that maps relationships across your organizational data for agents. Announced at Summit, not yet available.
Filesystem persistence and the Browser capability are also limited preview within Runtime. Regional availability at launch covers four regions: us-west-2, us-east-1, eu-central-1, and ap-southeast-2. Most of APAC and large parts of Europe aren’t covered.
Where AgentCore Fits the AWS Stack #
Worth stepping back: AgentCore is a platform, not a framework. You write your agent logic using whichever framework you prefer — Strands (AWS’s own open-source agent SDK), LangGraph, CrewAI, the Claude Agent SDK — and AgentCore provides the managed environment to run it. Strands has the tightest integration with native AgentCore Runtime support, but it’s genuinely framework-agnostic.
The full AWS agentic stack emerging from Summit NYC: Kiro (spec-driven IDE) → Strands (agent framework) → AgentCore (managed agent platform) → AWS Context (coming: knowledge graph) → AWS Continuum (security framework with STRIDE threat modeling). Each layer is optional, but they’re designed to compose. If you’re building AWS-native agents in 2026, this is the stack AWS wants you to use.
The managed harness going GA is the most significant maturity signal yet. If you’ve been waiting for the right moment to move agent infrastructure off your own servers and onto AWS, that moment just arrived — with the ARM64 rebuild and the pricing spreadsheet as the price of admission.