Strands Agents has published harness-sdk, an Apache-2.0 monorepo that packages the agent loop most teams end up hand-rolling: turn limits, token budgets, cancellation, stop reasons, tools, structured output, MCP, multi-agent patterns, memory and sessions, model portability, streaming, guardrails, tracing, and evals. The pitch is blunt. Choose Strands, the README says, “when you would otherwise write your own agent loop.” It runs in your process with no hosted control plane.
That last clause is the interesting one. The past two years of agent infrastructure have mostly been a race to host the loop. Managed runtimes, hosted control planes, orchestration services that keep your agent state on someone else’s servers. Strands is betting a meaningful slice of production teams want the opposite: a library they import, a process they own, a stack they can read. The repo is explicit that there is no hosted control plane. Your agent runs where your code runs.
The on-ramp is a single call. create_harness() in Python, createHarness() in TypeScript, and you get what the project calls “an optimized agent with benchmarked defaults for the model, tools, memory, sessions, and context management.” Install lines are pip install strands-harness and npm install @strands-agents/harness. The README’s example prompt is a nice tell about intended use: “Find the slowest test in this repo and explain why it’s slow.” This is a coding-agent-shaped default, not a chatbot.
Two layers, one repo
The structure matters more than the marketing. There are really two products here. The harness is the batteries-included agent: one call, benchmarked defaults, a configuration reference documenting every default you can override. The SDK underneath is the raw material: the agent loop, model providers, tools, memory, sessions, hooks. You start at the harness, then “drop down to the SDKs below when you want to own the agent loop.”
That two-tier design is the right shape for where agent tooling is in 2026. The hard part of shipping an agent is rarely the loop itself. It is everything around the loop: what happens when the model calls a tool you did not expect, how you cap spend before a runaway turn burns your budget, how you trace a decision after the fact, how you evaluate whether a prompt change made things better or worse. Strands puts those in the box. Turn limits, token budgets, cancellation, and stop reasons are first-class, not bolted on. Hooks let you intercept any step to log, validate, or redirect it. Guardrails catch mistakes before they run, and steering handlers let agents correct themselves.
Model portability is claimed as first-class: Amazon Bedrock, Anthropic, OpenAI, and Gemini, plus Ollama and custom providers. The README’s framing is the standard one, “swap backends when you scale; your code stays the same.” Anyone who has migrated a production agent between providers knows the real cost sits in tool-call formatting, streaming semantics, and structured-output quirks, not the client constructor. The test of this claim is not the provider list. It is whether the same harness behaves identically when you point it at a different backend. That is a claim worth benchmarking rather than trusting.
The MCP bet, and the eval gap
The repo leans hard on MCP, listing it alongside streaming, multi-agent patterns, and structured output as built in. That is the correct default. MCP has become the connective tissue for tool use, and an SDK that treats it as an afterthought is asking you to write glue. The TypeScript side also advertises Zod-typed tools and structured output, which is where type-safe tool schemas stop being a nicety and start preventing whole classes of runtime failure.
The inclusion of evals in the same SDK is the detail more teams should notice. Evals are usually a separate vendor, a separate pipeline, a separate bill. Shipping tracing and evals next to the loop means the feedback signal lives with the thing being measured. Whether the built-in evals are good enough to replace a dedicated tool is unknown from the README alone, and the project does not publish numbers. That is a gap. “Benchmarked defaults” is a strong phrase with no benchmark attached. Which models, which tasks, what scores. Until that is public, treat the defaults as reasonable starting points, not validated ones.
What it means for builders
The strategic read is that agent infrastructure is commoditizing downward into libraries. The control plane was never the moat; the loop was never the moat. The moat is the eval suite you built for your specific task and the tool integrations that encode your domain. An SDK that hands you the loop, the memory, the guardrails, and the tracing for free is telling you where the value is not.
Strands is not alone in this. The repo sits in a crowded field of agent frameworks, and its differentiator is the no-control-plane stance plus the harness-plus-SDK split. What to watch: whether the benchmarked defaults get published with real numbers, whether the Python 3.10+ and Node.js 22+ requirements hold as the SDKs mature, and whether the cross-SDK governance docs in team/ actually keep the Python and TypeScript surfaces in sync. The README welcomes doc PRs alongside code. For a project this young, the commit graph will say more about its trajectory than the tagline does.