On September 9, 2026, AWS once again brought its open-source "Strands Agent Harness SDK" to the fore. The pitch is that developers can build agents and deploy them to any environment. But Strands Agents itself is not new—it was first released on May 16, 2025, and had already been used in production by services like Amazon Q Developer and AWS Glue.
What's changed this time isn't a new codebase but a clearer articulation, through the term "agent harness," of the scope Strands is meant to cover. It isn't a thin library that merely calls a model. It's the foundation that executes tools, passes along history, and decides whether to continue or stop processing. In other words, the freedom to run anywhere comes bundled with the responsibility of managing, on your own, the boundary between the model and the real world.
What's New About the 2026 "Harness"
In its 2025 announcement, AWS described Strands Agents as a model-driven, open-source SDK. Its minimal configuration consists of a model, tools, and a prompt. The SDK calls the model, passing descriptions of the necessary tools along with conversation history. Once the model selects its next action, the SDK executes the tool and feeds the result back into the next call. This repetition forms the agent loop.
The current public repository houses both Python and TypeScript versions side by side. The Python version requires Python 3.10 or later, and the TypeScript version requires Node.js 20 or later; both support MCP, streaming, multi-agent configurations, and structured output. It's released under the Apache License 2.0 and isn't restricted to AWS-only deployment.
So what the 2026 naming signals isn't a break from the past but a verbalization of roles. In a single API call, processing ends the moment the model's response is received. The harness handles everything outside that: what to show the model next, which operations to permit, and how to recover from failure. That layer doesn't disappear even as model performance improves.
The Agent Loop the SDK Handles
Strands' official documentation explains that the harness repeatedly calls the model, executes tools, adds results to context, and decides whether to continue processing. The SDK includes hooks and memory features. Beyond session management, it also provides components for evaluation and observability. Developers combine these pieces to build a runtime environment suited to their own use case.
The defaults deserve attention too. Strands doesn't add tools automatically—capabilities like file operations, external APIs, or database updates must be selected and passed in by the user. Conversation history also isn't retained indefinitely; the default management approach keeps recent history while discarding older entries. Proactive context compression only kicks in when automatic settings are chosen. If you're building a long-running agent, you need to design what gets remembered, what gets discarded, and which state can be trusted upon resumption.
Safety follows the same pattern. You can insert validation before and after processing, and even build in a pause for human approval. But simply adopting the SDK doesn't automatically make a tool with elevated permissions safe. Separating reads from writes, placing deterministic validation around dangerous operations, and running in isolated environments when necessary—if you're operating the harness yourself, managing this boundary in code falls to you.
Same Strands, Different Party in Charge
With the Strands Agent Harness SDK, users choose both the agent loop and the deployment target. With AgentCore Harness, AWS manages the Strands-based loop and underlying infrastructure operations, and when configuration alone isn't enough, you can export to Strands code.
| Comparison Axis | Strands Agent Harness SDK | Running the SDK on AgentCore Runtime | Amazon Bedrock AgentCore Harness |
|---|---|---|---|
| Agent loop | User configures via code | User's Strands code | AWS-managed, Strands-based |
| Deployment and infrastructure | User chooses and operates the environment | Uses AWS's runtime infrastructure | AWS-managed |
| Method of change | Change code and configuration | Update code and redeploy | Manage settings, versions, and named endpoints |
| Custom control | Widest scope | Maintained on the code side | Export to code when configuration falls short |
| Primary operational responsibility | User designs permissions, isolation, state, and monitoring | User designs the loop; AgentCore handles infrastructure | AWS manages infrastructure, versions, and endpoints; user defines tool permissions and business rules |
This table, based on official documentation as of September 22, 2026, is organized not by performance or price but by who bears responsibility for what. Since AgentCore Harness also runs on Strands Agents, the two aren't unrelated competing products. A middle-ground configuration—running the public SDK on AgentCore Runtime—is also an option.
AgentCore Harness comes with versions that can't be changed after creation and named endpoints, which can be rolled back to an earlier version. It can also be invoked from Step Functions. AWS describes this as letting you run production agents without managing infrastructure yourself, but that doesn't mean costs disappear. There's no separate charge for the Harness itself; instead, you're billed for whichever AgentCore features you actually use.
The Reality Behind "Any Model, Any Cloud"
The current README lists Amazon Bedrock, Anthropic, OpenAI, and Gemini as the primary supported destinations, while remaining open to other model providers and custom connections. The 2025 announcement stated that the premise was models supporting reasoning and tool use. "Any model" here doesn't mean that every model works identically out of the box without configuration.
The default path also warrants scrutiny. Both the Python and TypeScript versions default to Amazon Bedrock as the model provider, so starting out of the box requires AWS credentials and access rights to Claude Sonnet. Switching to a different provider reduces your dependence on AWS, but you'll need to absorb the differences in authentication, billing, response formats, and tool invocation yourself.
Freedom of deployment likewise doesn't mean AWS shoulders the operational burden. The 2025 announcement showed both a configuration where the agent loop and tools share the same environment and an example splitting the loop onto Fargate while placing tools on Lambda. Separating them makes it easier to draw permission boundaries, but it also creates the need to design communication, authentication, and retry logic for failures. The more flexibility you gain, the more decisions you have to make.
The Choice Comes Down to Responsibility, Not Flexibility
If you want custom stopping conditions, validation, and context management to be a competitive advantage for your product, there's good reason to choose the public SDK—you can swap models and deployment targets while retaining fine-grained control over the loop's details. It also suits teams that already have their own runtime infrastructure and monitoring in place.
On the other hand, if a standard loop suffices and you'd rather offload version management, endpoints, evaluation, and rollback to a managed service, AgentCore Harness reduces the number of operational items you need to handle. And when you hit the limits of configuration, there's a path to move into Strands code. You don't need to predict every future need up front and treat this as an either-or decision from day one.
The deciding factor isn't "can it run anywhere" but rather: who stops a failed operation, who restores the state, and who rolls back a change? Strands doesn't fix that answer to AWS. But it also won't let you leave that answer vague.