SoftTech AI Registry
Amazon Web Services · Amazon Bedrock AgentCore

AgentCore Harness — managed agent loop and environment execution

Provides a managed agent execution layer that runs iterative model reasoning and tool execution inside an isolated AgentCore Runtime environment, with built-in shell and filesystem tools, configurable managed and external tools, context and memory integration, execution limits and observability.

Recorded characteristics

Function
AgentCore Harness repeatedly invokes the configured model, executes supported model-selected tools, returns tool results to the model, and continues reasoning/action cycles until completion, intervention, or configured/service limits. Documented loop: the application calls InvokeHarness → the harness establishes or restores session context → the model reasons and selects an allowed tool → the harness executes a supported server-side tool, or pauses and hands an inline-function call to client code → the result returns to the model → the model reasons again and may take further action → execution stops on completion, intervention (for example a Lambda hook deny) or a limit. AWS documents maxIterations as "reasoning/action cycles per invocation". Harness supplies: declarative agent configuration (model, tools, skills, instructions), the managed reasoning/action loop, model configuration, tool orchestration, context management, execution limits, lifecycle hooks, memory integration and automatic observability. AgentCore Runtime supplies the compute, the per-session isolated Firecracker microVM, the Runtime session, networking and filesystem infrastructure. The two are distinct; Harness is backed by Runtime. Built-in tools: "shell" executes bash commands inside the session's Runtime environment (AWS describes the agent writing and executing code; investigation examples include running commands, scripts and tests, installing dependencies, cloning repositories and working with generated artifacts). "file_operations" supports viewing, creating and editing files. The two mechanisms are separate. Tool classes the harness can orchestrate: remote MCP servers, AgentCore Gateway, AgentCore Browser, AgentCore Code Interpreter, inline functions, and the built-in shell and file_operations tools. Browser and Code Interpreter are separate AgentCore capabilities orchestrated by the harness, not native harness browsing or a native harness interpreter. For Gateway and remote MCP, the harness initiates the invocation and the configured target supplies the downstream operation.
Data access
Context: the current model/tool working context within an invocation. AgentCore Memory: managed memory (the default) persists conversation context across sessions; the execution role reads and writes session memory on each invocation. Filesystem persistence: optional service-managed session storage (persists across stop/resume for the same runtimeSessionId, no VPC), or bring-your-own Amazon EFS or Amazon S3 Files access points (VPC required) mounted under /mnt. Runtime state: state surviving within the Runtime session/microVM lifetime. These are separate mechanisms. Data reachable through tools depends on the tools, Gateway targets and credentials configured.
Actions
Can take actions
External actions
Yes
Human confirmation
Conditional
Permission basis
Mixed
Administrative control
Harness creation, update and deletion are control-plane operations governed by IAM (for example UpdateHarness requires bedrock-agentcore:UpdateAgentRuntime). allowedTools scopes which tools the model may select during InvokeHarness (if omitted, all tools are allowed, including the default shell and file_operations). Execution limits: maxIterations (default 75), timeoutSeconds (default 3,600), maxTokens (no default), idleRuntimeSessionTimeout (default 900), maxLifetime (default 28,800 seconds / 8 hours); all optional and also subject to Runtime quotas. Lifecycle hooks (up to 20, configured at create/update time): before_tool_call and other Lambda hooks return allow or deny and are the only hook type that can change loop behaviour; a deny can be returned automatically by the Lambda and is not human confirmation. SNS and EventBridge hooks are non-blocking notifications only, not approval gates. Network: configurable, including VPC mode with customer subnets and security groups. Gateway Cedar policies can gate calls when tools are served through Gateway. Note: allowedTools does not affect InvokeAgentRuntimeCommand, a separate Runtime API with its own IAM action; AWS advises withholding that permission to prevent direct command execution.
Default state
Disabled
Availability
Generally available (AWS: "AgentCore harness is available in GA across all regions shown here"). Preview 22 April 2026; GA 17 June 2026 (dates from the completed investigation; the Preview→GA sequence is not a contradiction). Lifecycle is not downgraded because related Runtime features may separately be in Preview.
Licensing
No separate harness charge; AWS charges for the underlying AgentCore capabilities used (Runtime, Memory, Gateway, Browser, Code Interpreter, observability, storage).
External model or provider
No fixed model or provider. AWS: agents can use any model provided by Amazon Bedrock, OpenAI, Google Gemini, or any LiteLLM-compatible provider, and can switch providers mid-session. The harness is powered by the open-source Strands Agents framework.
Limitations and uncertainty
Human confirmation (conditional): ordinary harness-executed tools do not universally require human confirmation. Inline-function tools pause the loop and return the call to client code, which executes it and returns the result in a later InvokeHarness call on the same session; AWS calls this "the pattern for human-in-the-loop approvals". Whether a human is involved depends on that client configuration. It is not established that every tool requires approval, nor that Harness automatically asks a human before consequential actions. Lambda allow/deny hooks are automated policy decisions, not human confirmation. Permission basis (mixed): documented runtime authority layers include caller/application authority to invoke the harness (IAM SigV4 or inbound OAuth/JWT); the customer-owned harness IAM execution role; environment/tool-specific authority (e.g. InvokeGateway on the execution role); optional Gateway Cedar policies; configured downstream credentials (AgentCore Identity token vault, OAuth providers, API keys, headers); and optional delegated end-user identity via inbound OAuth. Not every harness uses every layer. With SigV4 callers, AWS states the harness does not propagate per-user identity into downstream tool calls; per-user scoping requires inbound OAuth. Default state (disabled, with qualification): the capability does not exist until a harness is explicitly created and configured. Once a harness exists, shell and file_operations are available in every session unless restricted with allowedTools. This is not "shell enabled by default for every AWS customer". Outside action: the harness can invoke remote MCP servers, Gateway targets and other configured services outside the recorded product. Downstream effect is tool-dependent and not necessarily persistent. Persistent change is established within the execution environment where persistent storage is configured; external persistent change is tool-dependent. Shell scope: the shell operates inside the isolated Runtime microVM. Commands run as root (uid 0) within the microVM — root inside the isolated microVM, not over customer infrastructure. Not established: unrestricted host access, arbitrary customer-host execution, unrestricted network or VPC access under every configuration. The direct InvokeAgentRuntimeCommand API is treated as an adjacent Runtime capability, not credited here. Observability: every invocation generates traces, logs and metrics in CloudWatch — model calls, tool invocations, memory operations, shell commands, with timing and payload details; CloudTrail records harness management events and Runtime data events. Not established: human attribution for every downstream action, complete per-filesystem-operation audit granularity, universal downstream logging. Not publicly established: exactly-once semantics after recovery; universal automatic tool retries; duplicate external-side-effect prevention; transaction rollback; exact checkpoint granularity; a native delete action in file_operations; universal external persistent change; a universal downstream credential basis; mandatory human confirmation; native harness scheduling or event triggers (Step Functions can invoke a harness, but that is an external orchestrator); unlimited or background autonomy after invocation (bounded by iteration, time, token and session limits); arbitrary cross-tool composition beyond configured tools, limits and policies. Absence of evidence is not recorded as a negative claim. Verification is partial because the items above remain unresolved in AWS's public documentation.

Evidence