Amazon Bedrock AgentCore is AWS's "agentic platform for building, deploying, and operating highly effective agents securely at scale using any framework and foundation model." That last clause is the key to where Claude fits: AgentCore is deliberately model-agnostic. AWS's own docs list supported models as "any foundation model in or outside of Amazon Bedrock including OpenAI, Google's Gemini, Anthropic's Claude, Amazon Nova, Meta Llama, and Mistral models" — Claude appears mid-list, one option among peers. If you arrive expecting an Anthropic-flavored product, recalibrate: this is an AWS product that happens to run Claude well.
The service roster
AgentCore is not one service but a family — Harness, Runtime, Memory, Gateway, Identity, Code Interpreter, Browser, Observability, Payments, Evaluations, Optimization, Policy, and Registry — designed to work together or independently. You can adopt Gateway alone to turn existing APIs into agent tools, or go all-in with the Harness running the whole loop. Three services matter most for Claude users:
Harness is the managed agent loop: one API call, and AWS runs the reasoning-and-tool-execution cycle inside an isolated microVM per session, with filesystem and shell access. When you don't specify a model, the Harness defaults to Anthropic's Claude Sonnet 4.6 on Amazon Bedrock (global.anthropic.claude-sonnet-4-6) — so Claude is the default engine, even though it is not architecturally privileged.
Gateway converts APIs, Lambda functions, and existing services into MCP-compatible tools, and can connect to pre-existing MCP servers. Registry catalogs agents, MCP servers, tools, and skills across an organization.
How Claude is selected and configured
The Harness follows a config-based model: defaults are set at creation (create-harness with model, system prompt, tools, memory, and limits), and overridden at invocation — invoke_harness accepts model, systemPrompt, and tools, and the CLI takes flags like --model-id, --max-iterations, --skills, and --allowed-tools. Claude models are picked via bedrockModelConfig.modelId, and notably the model can be switched between turns of the same session — even across providers — with context carrying over. A word of caution: AWS's own examples mix dated and dateless model-ID forms inconsistently; the current Bedrock convention for the newest Claude generation is the dateless form (for example anthropic.claude-sonnet-5), so check the Bedrock model catalog rather than copying example IDs.
A companion field, bedrockModelConfig.apiFormat, selects the protocol: converse_stream (the Bedrock Converse API, the default) or responses / chat_completions — OpenAI-compatible APIs served by the bedrock-mantle endpoint, which AWS notes "supports a different set of models and capabilities."
There is also a third route: liteLlmModelConfig with a provider-prefixed ID such as anthropic/claude-sonnet-4-6 plus an apiKeyArn. That means calling Anthropic's first-party API from inside AgentCore, with the API key stored in AgentCore Identity's token vault. AWS's docs emphasize that the harness pulls the key at invocation time and "your agent code never sees raw credentials."
What this means for your architecture
Choosing AgentCore means choosing AWS's agent abstractions: AWS runs the loop, AWS defines the tool and memory interfaces, and Claude is a swappable engine underneath. That is genuinely useful for organizations standardizing agents across multiple model vendors, and the microVM-per-session isolation is a real operational win. But teams wanting Anthropic's agent stack — the Claude Agent SDK's hooks and subagents, Anthropic's Agent Skills, or the MCP connector on the Messages API — should note those come through different doors: the Agent SDK works against Bedrock directly (see running the Agent SDK on Bedrock), while Anthropic's MCP connector and Agent Skills are not available on Bedrock at all, only on the Claude API, Claude Platform on AWS, and Foundry's Hosted-on-Anthropic deployments.
One governance note worth flagging to your privacy team: AWS's AgentCore documentation states that "AgentCore may use and store your content to improve your service experience or performance," adding that such improvements are for your use of AgentCore and not for other customers. Review that language against your data-handling requirements.
Where to go next
If you are weighing AgentCore against other agent paths on AWS, read the Bedrock Agents Classic migration picture and Agent SDK vs. Managed Agents. The platform overview covers the broader Bedrock context.