Amazon Bedrock AgentCore harness reaches general availability

Amazon Bedrock AgentCore harness is now generally available, letting teams define and run production-grade agents with two API calls. CreateHarness defines an agent and InvokeHarness runs it; the harness provides an isolated filesystem and shell, built-in observability, managed memory, skills, and the ability to switch model providers mid-session.

"An LLM agent runs tools in a loop to achieve a goal," Simon Willison wrote, a definition the announcement cites as the practical shape every production agent follows.

What is included at GA?

The GA release packages the AgentCore primitives into a configurable harness so teams do not have to wire orchestration and infrastructure by hand. The harness exposes Runtime, Memory, Gateway, Browser, Identity, and Observability primitives and wraps them behind CreateHarness and InvokeHarness. Sessions run in an isolated environment with a filesystem and shell, stream every step to the caller in real time, and trace automatically to CloudWatch.

The GA harness also provisions a managed memory by default if you omit memory on CreateHarness, using SEMANTIC and SUMMARIZATION strategies with a 30-day event expiry and AWS-owned encryption. You can disable memory, attach an existing AgentCore Memory by ARN, or update the harness to switch memory; managed memory is cascade-deleted by default unless you set deleteManagedMemory: false.

How do you configure and run a harness?

Answer first: two API calls are all it takes to go from definition to run, with CLI and console options for setup and per-invocation overrides. CreateHarness sets defaults including model, tools, skills, container image and filesystem; InvokeHarness runs the agent and may override the model, tools, and skills for that single call.

Models can be chosen from bedrock (including Anthropic Claude, Amazon Nova, Meta Llama, DeepSeek, Qwen, Kimi, MiniMax, Cohere, Mistral and OpenAI GPT-5.5 and GPT-5.4 on Bedrock), openAi for direct OpenAI API access, gemini for Google Gemini, or liteLlm for third-party providers supported by LiteLLM. The harness preserves conversation context when switching providers mid-session.

Tools are declared in CreateHarness as a list and include agentcore_gateway (reference by ARN, exposing OpenAPI, Smithy, Lambda, MCP targets with IAM or JWT auth), remote_mcp (connect by URL), agentcore_browser (a browser sandbox), agentcore_code_interpreter (sandboxed Python and Node), and inline_function for human-in-the-loop or externally-run tools. The harness also exposes built-in shell and file_operations without listing them. Per-call allowed_tools and skills let you scope capabilities for a single invocation.

Skills are bundles of files, scripts, and instructions that the harness loads on demand. HarnessSkill sources at GA include awsSkills, git (clone a repo), s3 (pull from S3), and path (reference a path in your container). The awsSkills toggle brings AWS-curated skill bundles into the harness runtime with zero plumbing.

Why it matters

The harness shifts the hardest part of agent projects from orchestration to configuration. Many teams can prototype locally but hit combinatorial operational costs when enabling concurrency, isolation, identity, state, scaling, and observability for real users. By making Runtime, Memory, Gateway, Browser, Identity, and Observability first-class and configurable, the harness reduces repeated plumbing across use cases and lets teams swap models or tools without rebuilding container images or reimplementing auth and tracing.

The managed memory defaults and awsSkills integration lower setup friction for common enterprise needs: stateful user recognition, 30-day event expiry by default, and a curated skill repository for AWS-specific tasks.

What to watch

Watch for customer stories about multi-provider workflows where teams plan with one model and execute with another while keeping context, and for how teams use the awsSkills bundle in production. The next concrete signals will be examples of mid-session provider switching in live applications and adoption metrics for managed memory versus BYO memory configurations.