AgentCore harness and AgentCore Runtime

AgentCore harness and AgentCore Runtime solve different parts of the same problem. This page explains the conceptual difference and provides a feature-by-feature comparison to help you choose between them.

Conceptual difference

AgentCore Runtime is a serverless hosting environment. You bring agent code - written in any framework or no framework - wrap it with the AgentCore SDK’s BedrockAgentCoreApp entrypoint, package it into an ARM64 container, push it to Amazon ECR, and deploy. The orchestration loop is yours. To use any other AgentCore primitive (Memory, Gateway, Browser, Code Interpreter, outbound Identity), you call it from your code, typically through the AgentCore SDK. Runtime provides the infrastructure - isolation, scaling, sessions, auth gating, and observability plumbing - while the agent logic is code you write.

AgentCore harness is a managed agent harness - the orchestration loop itself is provided, powered by Strands Agents. You declare what the agent is (model, system prompt, tools, memory, limits) as configuration, and AgentCore runs the loop. Most features are a single config field: switching a model or adding a tool is a config change, not a redeploy. The harness is a managed abstraction that runs inside Runtime - CloudTrail records harness operations under AWS::BedrockAgentCore::Runtime.

For nearly every feature, the pattern is the same:

Harness - configuration, no code.

Runtime - you write code, usually with the AgentCore SDK plus your framework.