AWS Bedrock AgentCore Makes the Agent Session a Cloud Resource
Amazon's own release notes require a calendar correction before the analysis starts.
The large Amazon Bedrock AgentCore bundle did not suddenly become generally available in July. Web Search reached GA on June 16. Harness, Managed Knowledge Base, recommendations, batch evaluations, A/B testing, and the Policy integration with Bedrock Guardrails followed on June 17. July brought the operational follow-through: higher Runtime quotas, a four-region expansion for core capabilities, a once-per-minute gauge for active sessions, and per-agent CloudWatch span destinations for newly created runtimes.
That sequence is more revealing than a one-day launch headline. June assembled the stack. July made clear what AWS intends to operate at cloud scale.
The important unit is no longer the model request. It is the agent session: an isolated environment with state, files, memory, tools, credentials, retrieval, policy, traces, evaluations, and side effects. AWS can now provision that session, count it, meter its compute, govern its entry points, compare versions, and keep it alive for hours.
This is AgentCore's strategic move. AWS is turning agent execution into a managed cloud resource in the same way earlier cloud platforms turned servers, queues, and functions into resources. The convenience is substantial. So are the architectural consequences. Model choice can remain flexible while the operational system around the model becomes deeply AWS-shaped.
AWS groups most of the platform changes under June in the AgentCore release notes. The dated launch pages make the sequence more precise.
| Date | What changed | Status | Why builders should care |
|---|---|---|---|
| June 16 | AgentCore Web Search | GA | Current web grounding becomes a managed Gateway connector rather than a separately operated search integration. |
| June 17 | Harness, Managed Knowledge Base, recommendations, batch evaluations, A/B testing, and Guardrails in Policy | GA | Execution, enterprise retrieval, governance, and the improvement loop become one composable platform. |
| July 1 | Runtime quotas and four-region core-capability expansion | Available | Default active-session capacity rises to 5,000 per account in N. Virginia and Oregon and 2,500 per account in other supported regions; InvokeAgentRuntime reaches 200 transactions per second per agent, per account. |
| July | ActiveSessionCount in CloudWatch | Available | Concurrent sessions become visible for alarms, quota planning, incident response, and FinOps. AWS does not state the exact day. |
| July 20 | Unified span destination for newly created Runtime agents | Default for new agents | Spans can land beside each agent's logs instead of in one shared group, improving per-agent access, encryption, and export boundaries. |
| July 30 | Bedrock Agents Classic new-customer cutoff and model-catalog freeze | Scheduled | Harness becomes the practical forward path for new managed-agent deployments, even though existing Classic workloads have no migration deadline. |
This table is a status map, not a claim that the entire AgentCore catalog is now GA. Failure, Intent, and Trajectory Insights remain previews, as does AgentCore Payments. Evaluations had already reached GA in March. Higher quotas establish capacity ceilings; they do not prove latency, reliability, or outcome quality.
The four-region expansion did not produce module parity. AWS's current region matrix lists Runtime, Gateway, Identity, Built-in Tools, and Observability across 20 regions including GovCloud, while Harness, Memory, and Optimization cover 15 commercial regions. Web Search remains a us-east-1 exception.
The correction matters because it changes the article from a feature roundup into a platform read. July's quota increase raised InvokeAgentRuntime to 200 transactions per second per agent, per account. The regional expansion and ActiveSessionCount gauge showed that the June stack was ready to carry larger populations of agents.
AWS's current July release notes add another operator-facing change. Starting July 20, newly created agents in supported regions send spans to their own CloudWatch log group by default; older agents stay on the shared aws/spans destination unless opted in. The feature requires CloudWatch Transaction Search, logs:PutResourcePolicy on the execution role, and ADOT 0.18.0 or later. Per-agent telemetry boundaries make access control, encryption, export, and cost attribution cleaner. Together with the session gauge, this is a platform preparing for fleets rather than isolated demos.
AgentCore Harness creates an isolated, stateful microVM for each session. It can provide a filesystem and shell, memory, browser and code-interpreter access, Gateway or MCP tools, skills from Git or S3, S3 Files or EFS mounts, versioned endpoints, and CloudWatch traces. Builders can bring containers or use managed deployment paths.
The architecture is easier to understand as three planes rather than a bag of features.
The model and instructions can move. The production session binds execution, authority, evidence, and billing into the AWS control plane.
At the left is portable behavior: model, instructions, tool descriptions, skills, and domain logic. Some of that can be exported or represented in portable formats.
It then crosses the governed choke point—Identity, Gateway, Policy, and Guardrails—before reaching the managed session at the center. The session binds microVM lifecycle, filesystem, state, memory, versions, metrics, and traces. This is where AgentCore creates most of its operational value.
At the right is the execution receipt: configuration, model, tool scopes, sources, approvals, external mutations, cost, and rollback outcome. The deterministic rail beneath the session owns approvals, retries, timeouts, and compensation around effects in the world.
This connects with RohitAI's earlier argument that live agent sessions are becoming infrastructure. A client protocol can make a session shareable across interfaces. AgentCore goes deeper: it makes the server-side session an SRE, security, and billing object.
The managed harness is attractive because it owns the repetitive machinery around the agent loop: model calls, tool execution, context management, state recovery, and session isolation. AWS says customers can define an agent through configuration and later export to Strands when custom orchestration is needed.
The default operating envelope is generous. According to the Harness cost-control documentation, one invocation can run for 75 reasoning-and-action cycles, last 3,600 seconds, and use an unspecified number of model tokens unless the builder sets a cap. An idle microVM stays warm for 900 seconds by default, and a session can live for eight hours.
Those defaults favor a successful demo. Production systems need a narrower contract.
An agent allowed 75 reasoning-and-action cycles is not merely patient. Each cycle can lead to more model work, tool use, retries, or external effects. The harness cannot infer the right maximum from your business process.
The controls I would set before the first production canary are straightforward:
Harness removes undifferentiated loop engineering. It does not decide how much authority a loop should receive.
Harness supports Bedrock, OpenAI, Google Gemini, and LiteLLM-compatible providers. A builder can switch providers between turns while retaining conversation context. That is genuine flexibility.
It is also easy to overread.
Changing the model does not move the session filesystem, AgentCore Memory, IAM roles, Secrets Manager references, Gateway targets, Cedar policies, CloudWatch evidence, endpoint versions, quota alarms, or cost-allocation tags. Exporting orchestration code does not export those operational dependencies either.
The model is becoming a replaceable component while the cloud control plane becomes the durable system. Lock-in has moved upward from the inference endpoint to the execution substrate.
Put Harness, Gateway, Identity, Policy, retrieval, and CloudWatch at the center. This minimizes platform plumbing and fits teams already governed through AWS accounts, IAM, and operational tooling.
Hold prompts, tool contracts, state transitions, eval cases, and business rules behind an adapter while using AgentCore for isolated execution, identity, policy, and telemetry. This is the strongest default for serious teams.
Choose this when compute location, unusual orchestration, cross-cloud recovery, or audit requirements outweigh the convenience of a managed stack. Expect to operate more of the hard parts yourself.
Thoughtworks reaches a similar conclusion in its Technology Radar assessment: use the managed runtime for isolation, security, and observability, while keeping orchestration outside the black box where portability matters. That boundary is more useful than a vague claim of being model agnostic.
RohitAI's OpenAI Skills analysis made the same distinction from another direction. A procedure can travel as a skill. Its authority—credentials, policies, network access, approvals, and audit—does not travel with it.
AWS charges no separate orchestration fee for Harness. The AgentCore pricing page is explicit: customers pay for the underlying resources.
That wording is accurate and psychologically dangerous. A free coordinating layer can cause paid services to call one another repeatedly.
The correct ledger is broader than model tokens:
Cost per accepted task
runtime compute + peak memory + model tokens + Gateway and Policy + retrieval + Guardrails + evaluation + telemetry + retries + human recovery
“Accepted” is doing important work there. A cheap run that produces a wrong answer, unsafe mutation, or manual cleanup is not a cheap outcome. This is the same budgeting shift RohitAI described in OpenAI's agentic rate-card analysis: agent economics are a routing and control problem, not a token-price lookup.
July's ActiveSessionCount metric should become the top of that ledger. Pair it with per-session CPU and memory usage, tool calls, retrieval calls, evaluation spend, retries, and whether a human accepted or repaired the result. That lets teams allocate concurrency and money to outcomes instead of activity.
AgentCore now offers two managed retrieval paths with different jobs.
Managed Knowledge Base launched with six connector types—S3, SharePoint, Confluence, Google Drive, OneDrive, and web crawler—and a managed multimodal index. Regional support differs: AWS documents the service in eight regions, while GovCloud supports only S3 and omits ACL filtering, service-managed models, agentic retrieval, and AgentCore Gateway integration. Standard retrieval costs $1 per 1,000 calls. Web Search costs $7 per 1,000 queries, is currently available only in us-east-1, and returns up to 25 results.
Those are not interchangeable context sources. The sensible default is a retrieval policy:
At list price, Web Search is seven times standard Managed Knowledge Base retrieval and 1,400 times an ordinary Gateway call. The larger cost may still be the downstream context: more snippets create more model tokens, more opportunities for indirect prompt injection, and more evidence the agent must reconcile.
Retrieval should therefore be evaluated as context admission control. Measure freshness, citation correctness, source diversity, grounded-task completion, downstream turns, and cost per accepted task. RohitAI's Nemotron 3 Embed analysis explains why retrieval quality belongs in agent economics rather than in a separate RAG dashboard.
No independent head-to-head benchmark currently establishes AgentCore Web Search relevance, coverage, or minutes-level freshness against Google, Bing, OpenAI, or specialist search APIs. AWS's “tens of billions” scale and freshness claims are vendor claims until reproduced.
AWS has assembled useful controls: Gateway authentication, AgentCore Policy, Bedrock Guardrails, Identity, Secrets Manager references, ACL-aware retrieval, CloudTrail, and CloudWatch. Their value depends on composition.
Two documentation details expose the problem.
First, AWS says a Runtime can be restricted to accept calls only from its Gateway. For IAM runtimes, current guidance is to allow the Gateway execution role in the Runtime resource policy, deny other principals, and harden that role's trust policy with source-account and source-ARN conditions. For JWT runtimes, builders can use an allowed workload configuration tied to the Gateway. The Runtime target guide states the reason plainly: Gateway policy, Guardrails, interceptors, and unified observability are useful only if callers cannot bypass the Gateway and invoke Runtime directly.
Second, Managed Knowledge Base ACL awareness is not authorization. The service filters results against identity context supplied by the application, but it does not authenticate that end user. If an application lets a caller spoof an email or group context, the retrieval layer will faithfully apply the wrong identity.
The security pattern is paired control:
Guardrails-in-Policy also has a narrower surface than the brand name suggests. At the research cutoff it was available in five regions and supported content filters, prompt-attack detection, and sensitive-information safeguards. For HTTP Runtime targets, builders must provide a request-and-response schema before Gateway can apply Guardrails.
Interactive Runtime shells deserve special attention. The shell guide allows up to ten active shell sessions per Runtime, with access to the container filesystem and configured Runtime credentials. CloudTrail records the API event, but AWS says it does not retain terminal input and output. Support access should be narrow, time-bounded, and supplemented with workload-level command auditing.
AgentCore's optimization loop is compelling: analyze production traces, recommend changes to system prompts or tool descriptions, run batch evaluations, and compare two live variants. Recommendations are LLM-generated and require review. A/B testing requires an already deployed AgentCore Gateway plus online evaluation configuration, assigns variants stickily by Runtime session ID, and reports means, confidence intervals, percentage change, and a significance flag when the p-value falls below 0.05.
The statistical machinery does not define success for you.
An agent can improve an LLM evaluator score while making more expensive tool calls, taking longer, exposing more data, or causing harder-to-reverse side effects. Sticky routing keeps one session on one variant; it does not make a write safe.
For consequential agents, the rollout ladder should be:
This is the second-order risk in managed optimization: once a cloud platform makes experiments easy, teams may run more of them than their side-effect model can safely support.
The Step Functions integration is one of the most architecturally honest parts of the release. It lets teams sequence or parallelize Harness calls and wrap them with approvals, error handling, and conditional routing.
That is an admission worth embracing. Probabilistic agents should usually occupy the smallest useful reasoning step inside a deterministic workflow.
Use the agent to interpret a document, choose among bounded tools, draft a plan, or diagnose an exception. Use Step Functions—or an equivalent workflow engine—to own deadlines, retries, idempotency, approval gates, conditional branches, compensation, and final status.
The resulting authority envelope is easier to reason about:
Trigger → bounded agent step → evidence check → human or policy gate → external action → receipt → compensation if needed
That structure also makes scheduled and event-driven agents safer. RohitAI's authority-envelope analysis of standing automations applies directly: define who can trigger the workflow, which credentials and tools it receives, what it may emit, and how long its authority survives.
AWS renamed the old managed orchestration product Bedrock Agents Classic. On July 30, accounts without Agents activity in the preceding 12 months lose CreateAgent and InvokeInlineAgent access, and the Classic model catalog freezes. Allowlisted customers can keep running Classic with no announced end-of-life date.
The timing is hard to miss. Harness reached GA on June 17. Classic maintenance mode was announced at the end of June. The new-customer gate closes at the end of July. AWS explicitly describes Harness as the closest AgentCore analogue to the old managed experience.
This makes the GA wave partly a replacement event.
Existing Classic users should not panic-migrate, but they should inventory the parts that do not map cleanly: stage-specific prompt overrides, action groups, knowledge-base attachment, memory assumptions, multi-agent patterns, IAM roles, and model dependencies. AWS's own comparison says some Classic behaviors require a different AgentCore design or custom orchestration.
The useful migration test is not “does the prompt run?” It is “does the new system preserve authority, state, evidence, cost, and failure behavior under production load?”
AWS is not alone in assembling these primitives. Google's Gemini Enterprise Agent Platform combines runtime, sessions, memory, identity, registry, gateway, evaluation, and optimization. OpenAI's Agents SDK update adds a model-native harness, controlled sandbox execution, files, tools, and durable state patterns. Microsoft is building a similar production-agent layer in Foundry.
The market is converging on a common stack:
runtime + session state + memory + tools + identity + gateway + policy + telemetry + evaluation + optimizer
That convergence produces three less obvious consequences.
First, cloud differentiation moves above the model. Model catalogs overlap and provider switching becomes easier. IAM depth, enterprise data access, workflow integration, observability, procurement, and the operating model around the session become the durable advantage.
Second, FinOps expands from tokens to concurrency. Active sessions, peak memory, retrieval decisions, retries, evaluation sampling, and human recovery matter as much as the selected model. I expect active-session budgets to become a normal team-level control, much like serverless concurrency limits.
Third, the most valuable governance artifact will be an execution receipt. Raw traces are too large and too implementation-specific. A receipt should record the human or workload principal, session and endpoint version, model, tool scopes, retrieved evidence, approvals, external mutations, cost, and rollback outcome. That compact artifact can support audit, incident response, and replay across agent frameworks.
My strongest prediction is a two-layer architecture. Serious teams will keep domain orchestration, tool contracts, eval cases, and decision logic portable, then rent execution, identity, policy, and telemetry from a cloud control plane. The boundary will never be perfect. It will be much healthier than treating “any model” as proof that the whole workload can move.
No. Official dated AWS pages place Web Search GA on June 16 and Harness, Managed Knowledge Base, recommendations, batch evaluations, A/B testing, and Policy integration with Bedrock Guardrails on June 17. July added higher Runtime quotas, a four-region expansion for core capabilities, ActiveSessionCount, and per-agent span destinations for new Runtime agents.
There is no separate Harness orchestration charge. You still pay for underlying Runtime compute and memory, models, Gateway, retrieval, Policy, Guardrails, evaluations, CloudWatch, storage, and network usage. “No Harness fee” is not the same as a free agent workload.
Yes. AWS documents support for Amazon Bedrock, OpenAI, Google Gemini, and LiteLLM-compatible providers, including switching providers between turns while retaining session context. Operational state and governance remain in AgentCore unless you deliberately externalize them.
No. AWS explicitly says ACL-aware filtering is not an authentication or authorization boundary. The application must authenticate the user and provide verified identity context. Supported connectors can perform additional real-time ACL checks, but that does not replace upstream identity controls.
No. At the July 20 research cutoff, the connector was documented only in us-east-1. AWS says queries stay within AWS rather than being sent to a third-party search engine, but that should not be generalized into same-region processing for callers elsewhere.
Existing workloads keep working, and AWS has announced no end-of-life date. The reason to start planning is strategic: on July 30, accounts without Agents activity in the preceding 12 months lose CreateAgent and InvokeInlineAgent, the Classic model catalog freezes, and AWS says no new features are planned. Test migration behavior rather than rushing a prompt-for-prompt port.
AWS has assembled enough of the agent stack that the model call is no longer the best unit of analysis.
The managed object is the session: isolated compute, state, tools, retrieval, identity, policy, evidence, experiments, and effects. June made the listed execution, retrieval, governance, and optimization components generally available. July made the operating model more scalable and measurable. The Classic cutoff makes AgentCore the forward path for new AWS-managed agents.
For builders, the bargain is clear. AgentCore can eliminate a large amount of platform work and place familiar AWS controls around production agents. In exchange, operational gravity shifts toward AWS even when the model can change.
Use that gravity deliberately. Keep domain behavior portable where it matters. Close every policy bypass. Route retrieval by evidence need. Measure accepted outcomes instead of activity. Put probabilistic reasoning inside deterministic rails. Record what authority each session received and what it changed.
The companies that do those things will gain from the managed stack without confusing convenience with control.