What Amazon Bedrock AgentCore’s New Capabilities Mean for Your Managed Services Strategy

With recent launches, AWS has made more of the infrastructure necessary for AI agents available as managed services. As a result, many organizations that rely on a Managed Services Provider (MSP) are asking themselves which parts of the provider’s agentic operations platform come from AWS, and what the provider adds to make those capabilities reliable in the customer’s environment.

In June 2026, AWS introduced a wave of launches that covered several parts of that question. The managed agent harness in Amazon Bedrock AgentCore manages orchestration and runtime composition. Amazon Bedrock Managed Knowledge Base helps with ingestion and retrieval infrastructure. Web Search on AgentCore provides managed access to current public information. AWS Context and AWS Continuum point toward deeper organizational and security context, although their current availability differs from the generally available services.

These launches reduce the amount of general-purpose agent infrastructure a provider needs to build and maintain. They leave customer-specific operational knowledge, system integrations, permissions, evaluations, release controls, human escalation, and service accountability in the provider and customer operating model. Understanding this division of responsibility helps organizations evaluate what these launches change and what capabilities an MSP should be able to demonstrate beyond the underlying technology.

What Changed From the First Amazon Bedrock AgentCore Release

Amazon Bedrock AgentCore was already a substantial agent platform before the June 2026 launches. When it became generally available in October 2025, it included modular services for runtime, memory, identity, gateway, observability, browser automation, and code execution. Providers could use those components independently while retaining responsibility for assembling more of the agent loop and operating environment.

AgentCore harness extends that platform by turning more of the common agent loop into configuration. A team declares the model, tools, skills, and instructions, while AgentCore supplies the execution environment, compute, memory, identity, networking, observability, state handling, session isolation, and tool invocation needed to run the agent. When a workflow needs custom orchestration or dependencies, the harness can be exported to code and operated on the same AgentCore foundation. An MSP can use the managed configuration for common requirements and retain custom code where the customer’s workflow, control model, or integration requires it.

The other launches expand the managed portion of adjacent workloads:

• Managed Knowledge Base covers more of the infrastructure required to connect agents to enterprise content.
• Web Search removes the need to integrate a separate public search provider.
• AWS Context and Continuum (both coming soon) extend the direction into organizational relationships and security operations.

Less Platform Engineering, More Customer-Specific Work

The immediate benefit for an MSP is reduced repeated platform engineering. The provider can spend less time recreating common agent infrastructure for each use case and direct more effort toward the customer’s operating environment.

AgentCore harness addresses the agent loop itself. It manages session state, context handling, execution isolation, tool use, failure recovery, memory, and observability. A provider can standardize those capabilities across operational workflows while preserving an export path for cases that need custom orchestration. That can shorten the path to a working agent, although production readiness still depends on how the provider configures, tests, and operates the resulting system.

Managed Knowledge Base reduces the infrastructure required to ground agents in enterprise content. It handles ingestion, managed vector storage, synchronization, storage optimization, hybrid retrieval, ranking, and multi-step agentic retrieval. Runbooks, architecture records, service documentation, and historical operating material can be made available without requiring the provider to run a separate vector database and retrieval stack for the same purpose.

The remaining work determines whether that content improves operational decisions. The provider and customer still choose the sources, define synchronization expectations, resolve conflicting guidance, maintain permissions, and evaluate retrieval against real tasks. A managed index can return content efficiently, but it's the operating model that determines whether the content is current, authorized, and appropriate for the incident or change under review.

Web Search removes another integration project. Before the managed service, adding public search to an AgentCore-based system required an external provider, separate authentication and billing, result handling, and additional security reviews. Web Search returns ranked results with snippets, source information, and publication dates through AgentCore, without needing third parties.

Its useful role in cloud operations is external context. An agent could retrieve a recent vendor advisory, public vulnerability report, service announcement, or documentation update. It still needs customer integrations to determine which software is deployed, what changed before an incident, which resources are affected, and what the current telemetry shows. Public information and environment evidence should remain distinct inputs, with clear rules for how each can influence a recommendation or action.

These new capabilities also change the cost composition. AgentCore harness has no separate charge, but customers pay for the underlying services they consume. Runtime, models, memory, Gateway, Policy, Web Search, evaluations, observability, storage, and retrieval can all contribute to the bill. A provider may reduce custom development and maintenance while taking on new usage-based costs, integration work, evaluation workloads, and operational oversight.

A useful cost model therefore includes more than engineering hours. It should account for AWS consumption, the volume and duration of agent work, evaluation and logging, human review, and the operational outcomes the service produces. Metrics such as Service-Level Objective (SLO) attainment, incident resolution, recommendation quality, and successful remediation can complement labor-based measures without assuming that every managed-services contract should adopt the same commercial model.

The Responsibilities AWS Leaves With the Provider and Customer

There are still several production responsibilities that belong to the application owner. Those responsibilities are also the areas where a managed services provider’s operating discipline becomes visible and makes a difference.

AgentCore harness authenticates callers and isolates execution, but it treats authenticated invocation input as trusted. The application owner remains responsible for input validation, prompt-injection defenses, IAM controls, session-to-user mapping, network configuration, trusted skill and instruction sources, and the security of commands executed in runtime sessions.

Tool access requires equally deliberate design. Harness includes built-in tools and can connect to MCP servers, AgentCore Gateway, Web Search, browser automation, and code execution. If the allowedTools setting is omitted, all configured and built-in tools are available for model selection during harness invocation. AgentCore Gateway can provide policy-backed access to tools, but the provider must decide which tools belong behind that control point, which identities may call them, which arguments are acceptable, and what should happen when a call is denied.

Enterprise knowledge has a similar responsibility split. Managed Knowledge Base supports retrieval with an access control list, including real-time permission checks for supported connectors. However, the calling application must authenticate the user and pass verified identity context. S3 and custom connectors rely on customer-provided ACL metadata rather than a live permission system.

A provider that connects runbooks, incident records, architecture documents, and cost data must therefore show how identity travels through the workflow. It should also show how source permissions are tested, how stale content is identified, and how retrieval failures are distinguished from missing or unauthorized information. Without this, an agent may produce an apparently well-grounded answer from incomplete evidence and lead users astray.

Evaluation and release management are part of the managed service as well. AgentCore provides traces, evaluations, optimization features, immutable versions, named endpoints, controlled experiments, and rollback mechanisms. Those capabilities support a release process, but they do not define the provider’s acceptance criteria. The MSP still needs representative operational tasks, expected outcomes, unsafe-action criteria, approval rules, and escalation paths that reflect the customer’s systems and risk profile.

This is where managed services offerings can be compared from a useful perspective. The relevant differences include the quality and recency of operational context, the systems and tools the agents can reach, the rigor of the evaluation set, the boundaries around automated action, the release and rollback process, and the ownership model when a recommendation or remediation is wrong.

Where AWS's Platform Ends and the Provider's Work Begins

A provider review should connect each AWS capability to the work required in the customer’s environment. The following matrix can be used in an architecture review, service review, or provider evaluation. It summarizes where AWS's platform capabilities end and the provider's operational responsibilities begin, so you can make sure the MSP is doing their side of the work instead of blindly relying on AWS's building blocks.