Amazon Bedrock AgentCore
AWS
At its New York Summit on June 18, AWS made the Amazon Bedrock AgentCore harness generally available, and the pitch reduced agent development to two API calls. CreateHarness defines an agent, InvokeHarness runs it, and a production-grade agent stands up in minutes.
The model is important, but it is not the hardest part of building and running agents at enterprise scale. A single developer can stand up a working agent on a laptop in an afternoon. The work multiplies the moment that agent has to serve more than one user, because concurrency, isolation, identity, state and scaling all arrive together. With the harness, AWS is turning that plumbing into a managed service customers configure rather than build, which moves the operational layer of every agent onto AWS.
Before explaining why the harness matters, let me dissect what it assembles. It pulls the existing AgentCore primitives into one managed unit rather than leaving a team to connect them by hand. The Runtime isolates each session, the Memory persists context across turns, and the Gateway exposes tools. The Identity vault holds credentials, and the Observability layer traces every step. In this model, the foundation model provides the reasoning while the harness provides the runtime, memory, identity and tool access required to execute the work.
Customers declare the model, the tools, the skills and the instructions, and AWS assembles and runs the loop. Several pieces are new at general availability. Memory now provisions automatically when a harness is created, so an agent recognizes a returning user without a second setup call. A single toggle loads an AWS-curated catalog of skills with no network fetch, and every step of an invocation streams back in real time and traces to Amazon CloudWatch.
The capability customers asked for most is model switching inside a session. A team can plan with Claude, write code with another model and summarize with Gemini, and the conversation keeps its context across the handoffs. The model becomes a field set per call. Everything that gives the agent continuity stays on AWS, the memory, the gateway and the identity vault that holds the API keys.
The convergence across the major clouds makes this more than an AWS launch. At Cloud Next in April, Google announced the rebrand of Vertex AI as the Gemini Enterprise Agent Platform. It ships a managed Agent Engine, Sessions and Memory Bank, observability and one-command deployment through its Agent Development Kit. Microsoft moved the next generation of its Foundry Agent Service to general availability in March. It expects its hosted agents, with sandboxed sessions and filesystem access, to reach general availability by early July.
A closer look at the three announcements shows the providers converging on the same core capabilities, runtime, memory, tools, grounding, identity, observability and governance. All three vendors are moving in the same direction. The durable hold on an enterprise customer sits in the operational layer beneath the agent, not in the foundation model the agent calls.
AWS supports the point with adoption numbers. It reported that tasks performed by agents on AgentCore grew 15 times in six months, and it named Nasdaq, Visa and Experian among customers scaling agents in production.
Though the harness supports flexibility at the model layer, it also creates a retention mechanism at the operational layer. Enterprise buyers should evaluate that tradeoff early. Customers can swap the model, but the memory, gateway, skills catalog and identity vault remain AWS services. An agent built this way is portable in its model and tied to AWS in everything else.
To address portability, AWS provides an exit. A single CLI command exports a harness as Strands-based code. The company describes this as a move from configuration to code rather than an architecture change. The exported agent still runs on the same AWS compute and primitives. Strands is the only export target at launch, and the Claude Agent SDK is listed as coming soon.
Pricing is another area enterprise buyers need to evaluate carefully. There is no charge for the harness itself, but customers still pay for the underlying services that power it. Runtime compute bills by the second, the gateway bills by invocation, memory bills by event and retrieval, and observability bills at standard CloudWatch rates. That aligns with consumption-based pricing, but it makes forecasting harder. Google's multi-meter billing model has already shown how quickly agent pricing can become difficult to predict. Evaluations and optimization are meant to keep an agent improving on live traffic, and both are new enough that their behavior at scale is unproven.
The due diligence that matters here narrows to two questions. The first one is about ownership. Which parts of an agent are genuinely the customer's own work, and which are wrappers around AWS primitives that stop functioning once the agent leaves? Configuration blurs that line, making it harder to see where proprietary logic ends and the managed service begins.
The second question is cost predictability under production load. What happens when an agent's tool calls or retrievals double, given that each meter bills independently? A workload that looks cheap in a pilot can move in ways a flat per-seat license never would. Memory is the component to watch most. The context an agent accumulates over months is both the reason it becomes useful and the switching cost that grows the longer a team stays.
In summary, the AgentCore harness is a strong piece of engineering. More importantly, it shows the enterprise agent market moving from model selection to operational control. AWS has simplified the work of building agents while making the surrounding runtime, memory, identity, gateway and observability layers more strategic and harder to replace. That calculus is the one every enterprise buyer will carry into the next budget cycle across AWS, Google and Microsoft.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。