Strands harness: AWS's open-source AI agent, explained

What is the Strands harness?

The Strands harness is described by its own docs as "a state-of-the-art, fully assembled agent harness." The idea is that you get an optimized agent in a single import instead of assembling one piece by piece. In Python that is pip install strands-harness then create_harness(); in TypeScript it is npm install @strands-agents/harness then createHarness(). You give it a task and it runs.

It is the batteries-included front door of a wider open-source toolkit from AWS called Strands Agents. The harness sits on top of an older, lower-level piece: the Strands Agents SDK, which AWS first open-sourced in May 2025 and which already runs inside production AWS systems like Amazon Q Developer and AWS Glue. The harness-sdk repo shows the traction: 7.8k stars and 1.2k forks at the time of writing, all under Apache 2.0.

The important framing is what the harness is not. It is not a hosted product, not a chatbot you sign into, and not a customer-facing agent you drop onto your website. It is code you install and run in your own process, on your own infrastructure. That distinction shapes everything below.

First, what is an agent harness?

If the word "harness" is doing a lot of work and you are not sure what it means, you are not alone. Strands' own docs give the cleanest one-liner I have read: "A language model can answer questions. An agent can do things. The agent loop is what makes that difference possible."

A plain large language model only knows what its training covers. The moment a task needs something outside that (reading a file, hitting an API, running a command) the model has to reach into the world. The agent loop is the orchestration layer that lets it: invoke the model, check whether it wants to use a tool, run the tool, feed the result back, and repeat until the model has a final answer.

A "harness" is the scaffolding wrapped around that loop: the system prompt, the set of tools, how context is trimmed when it grows, how memory persists between runs, and how errors get caught. You can write all of that yourself, and plenty of people do. The whole reason a product like the Strands harness exists is that the boring, load-bearing parts of that scaffolding are the same for almost everyone, and getting them right is fiddly.

That is the spectrum. A raw model call answers but cannot act. Building with an SDK (Strands' own, or something like the OpenAI Agents SDK or Claude Agent SDK) gives you total control but leaves you wiring every piece. The harness is the middle: you start from tuned defaults and override only what your use case actually needs.

What you get out of the box

Run create_harness() with no arguments and you get a fully functional agent. What makes the defaults interesting is that AWS says every one of them is overridable, and what you get back is a standard Strands Agent with no hidden wrapper. Here is what ships by default:

The system-prompt philosophy is the part I would not gloss over. "Confirm before anything irreversible, verify before finishing" is exactly the discipline that separates an agent you can trust on real work from one that confidently does the wrong thing. It is the same lesson I learned the hard way running AI on live support queues: the failure mode is never "the bot did nothing," it is "the bot did something wrong, fast." Baking that caution into the default prompt is a good call.

Bring your own model

The feature people latched onto is model portability. The docs put it plainly: "the model is one object you hand to the agent; the rest of your code stays the same." Swap global.anthropic.claude-sonnet-5 for an OpenAI or Google model and nothing else changes.

This matters more than it sounds, and the community reaction on the Hacker News launch thread made the case better than the marketing did:

"This is the very reason why I avoid to use native harness. They are optimized for the economic benefit of the provider, not for mine."

jorgeleo, Hacker News

That is the real argument for a model-agnostic harness. A coding agent tied to one lab has an incentive to burn more of that lab's tokens. An open harness you own does not. It is the same reason teams get nervous about lock-in when they compare Cursor against Windsurf or weigh up Codex alternatives: the model you like this quarter may not be the one you like next quarter, and you want to move without a rewrite.

The "28% cheaper" claim, examined

Now the number everyone repeated. The official launch post leads with "frontier performance with 28% lower token cost," measured as an average across six benchmarks against other harnesses running the same models. AWS also says that on Terminal-Bench 2.1, using Anthropic's Fable 5, the harness cost 77% less than Claude Code and scored higher. The stated mechanism is unglamorous and believable: truncate tool results over a threshold, compact the context when it gets too full, and cache the reused parts of each request.

Here is where I would slow down. The same HN thread that praised the model-agnostic design also poked a hole in the benchmark framing:

"Terminal Bench 2.1 is saturated. Many token saving techniques would save money and score basically the same running Fable 5 against Terminal Bench 2.1... This is at least the fourth time I've seen a project hit front page with a 'save money with same score on saturated benchmark' claim."

seizethecheese, Hacker News

That is a fair critique. A single saturated benchmark is a weak place to hang a cost claim. But the underlying point that the harness, not just the model, drives your bill is real, and another commenter backed it with a concrete data point:

"Fable 5 on Claude Code scored 61.8% at a cost of $248.05 while Fable 5 on OpenCode beat it at 66.3% at $73.42. The same model, the same benchmark; only the harness is different with a ~5 point difference in accuracy while costing significantly less."

CharlieDigital, Hacker News

Same model, same benchmark, one is a third of the cost and slightly more accurate. That is the whole thesis of why a harness is worth caring about. My takeaway: the "28% cheaper" headline is directionally right and the mechanism is sound, but I would run it against my own tasks before I put the number in a budget. Benchmark savings and production savings are not the same currency.

The rest of the Strands toolkit

The harness is one of several surfaces AWS shipped, and a few are worth knowing about if you go deeper:

• The Strands Harness SDK is the lower level: you own the loop, turn any function into a tool with a @tool decorator, and connect MCP servers when you need external tools.
• Strands Shell is a Bourne-compatible shell that runs inside your own process, giving an agent grep, sed, jq, and curl "without fork, exec, or a raw syscall," so you declare exactly which directories and credentials it can touch.
• Strands Evals is a Python-only SDK with 25+ built-in evaluators to score an agent, diagnose the failing step, and simulate multi-turn conversations before you ship.
• Strands Labs is the experimental arm, and its robotics project puts 70+ robots behind one interface for natural-language control, which is a genuinely different use case from the coding-agent stuff.

There is also a strands CLI (@strands-agents/cli) for prototyping an agent from the terminal, all living in one harness-sdk monorepo after the org restructured around the launch.

Where the harness fits, and where it does not

I want to be fair here, because the harness is good at what it is for. If you are a developer building a custom agent (a research agent, an internal automation, a coding assistant) and you want to own the loop, dodge model lock-in, and deploy on your own infrastructure, the Strands harness is one of the cleaner options I have seen. It runs anywhere a Linux container runs, from your laptop to ECS.

But "you deploy on your own infrastructure" is also the catch, and the sharpest line in the whole launch thread named it:

"I'm more and more hesitant to use third party harnesses. It's so easy to take opencode or pi and build my own for exactly what I want that I'm seeing projects like this to be noisy and less valuable over time."

pizzuh, Hacker News

The harness saves you the wiring, but it does not save you the ownership. You still pick the model, connect the tools, host the container, watch the bill, and maintain the thing as models and APIs change. For a builder, that is the job and the fun. For a support lead or an ops manager who just wants tickets resolved or blog posts written, it is a full engineering project standing between them and the outcome.

That build-versus-hire split is the honest way to decide. If the goal is a specific job done rather than a system built, you want the teammate, not the toolkit.

Try eesel

The clean way to think about it: the Strands harness is infrastructure, and eesel is the employee. AWS gives builders the loop, the tools, and the model wiring to assemble an agent. eesel AI is an AI teammate platform where you hire ready-to-work teammates for specific jobs, each one arriving with the skills, integrations, and company context for its role. The current roster is an AI helpdesk teammate that joins your existing support queue and an AI blog writer that researches and drafts long-form posts. There is no loop to wire and no container to run: the helpdesk teammate trains on your past tickets and help center, and you can simulate it against historical tickets before it ever answers a customer.

If the harness caught your eye precisely because you like living in a terminal, eesel has a surface for that too. The eesel CLI puts the same teammate in your terminal: npx @eesel/cli init sets up an agent, connects a helpdesk, uploads knowledge, and wires automations without opening the dashboard. It is deliberately not a separate product, so anything you set up in the CLI shows up in the dashboard and the other way around. And because every command prints JSON, a coding agent like Claude Code, Cursor, or Codex can drive a whole workspace setup for you, then hand the running teammate back. It is the same agentic, scriptable ergonomics that make the Strands harness appealing, pointed at a job that is already done for you.

On cost, eesel is usage-based and billed per resolved ticket with no per-seat fee, so the price scales with work done rather than seats filled. You can start free, and the CLI will even spin up an anonymous workspace with no account to test against. If your actual goal is resolved tickets or published posts rather than a framework to maintain, that is the shorter path.