Strands Agents harness-sdk: an in-process agent loop for Python and TypeScript

What Strands Agents replaces, and who ends up writing that code

Most teams that ship an AI agent start with a loop they wrote themselves: call the model, inspect the response for a tool call, run the tool, append the result, call the model again. That loop is short. The code around it is not. Turn limits, token budgets, cancellation, stop reasons, retries, streaming, session persistence, tool schemas, MCP connections, tracing and evaluation hooks all accumulate around the same twenty lines, and each one is written by someone who would rather be working on the product.

The README frames Strands Agents as exactly that replacement: "Choose Strands when you would otherwise write your own agent loop." The project is a Python and TypeScript SDK, not a service. It runs in your process with no hosted control plane, which is the design decision that shapes everything else. There is no dashboard to log into, no agent ID to register, and no vendor-side state to reconcile. You get the harness and you operate it.

The intended reader is a backend or platform engineer who is comfortable owning deployment, credentials and observability. If your team expects to configure agents through a web UI, this is not that product, and the README does not pretend otherwise.

The agent loop, hooks and the pieces around them

The core object is an Agent. You construct it with a model provider, a list of tools and whatever configuration you need, then call it with a prompt. The loop runs until the model stops asking for tools or a limit fires. The README points to lifecycle controls as a first-class concept: turn limits, token budgets, cancellation and stop reasons. Those are the knobs that decide when an agent gives up, and having them in the SDK rather than in your wrapper code is the main structural difference from a hand-rolled loop.

Hooks are the second mechanism. The README states that the agent loop traces every decision by default and that hooks let you "intercept any step to log it, validate it, or redirect it." That is an interposition point rather than a plugin system: you are not adding capabilities to the loop, you are observing and optionally altering what it is about to do. Guardrails and steering handlers sit in the same area, and the README describes steering handlers as letting agents correct themselves instead of failing silently.

Around the loop, the SDK covers tools and structured output, MCP, multi-agent patterns, memory and sessions, model portability, streaming, guardrails, tracing and evals. That list is long, and the honest reading is that the SDK is broad rather than deep in any one area. Model portability is the part with the clearest claim: first-class support for Amazon Bedrock, Anthropic, OpenAI and Gemini, plus other providers and custom ones, with the stated goal that swapping backends leaves your code unchanged.

The monorepo layout reflects the split. strands-py/ holds the Python SDK, strands-ts/ the TypeScript one, site/ the Astro/Starlight documentation, strands-mcp/ an MCP server, and team/ the governance documents, tenets and design proposals. The two SDKs are released separately, with tags like python/v1.54.0 and typescript/v1.15.0, so a Python feature and its TypeScript equivalent do not necessarily land together.

Installing Strands Agents and running a first agent

Both SDKs default to the Amazon Bedrock model provider. The README is explicit that you need AWS credentials configured and model access enabled for Claude Sonnet before the first call will work. The quickstart guide linked from the README covers Anthropic, OpenAI, Gemini, Ollama and other providers if you would rather not start on Bedrock.

The Python SDK requires Python 3.10 or newer. The README gives a two-package install, the SDK itself plus a tools package:

pip install strands-agents strands-agents-tools

With those installed, the README's example constructs an agent with a calculator tool and asks it a question. The agent decides whether to call the tool, and the answer comes back as the return value of the call:

from strands import Agent
from strands_tools import calculator

agent = Agent(tools=[calculator])
agent("What is the square root of 1764")

If that runs without an authentication error, your Bedrock setup is correct. If it fails on credentials or model access, fix that before writing any tool code, because every later example inherits the same dependency.

The TypeScript SDK requires Node.js 20 or newer and installs from npm:

npm install @strands-agents/sdk

The TypeScript example is slightly different in shape: the agent is invoked with await and the result is logged rather than returned directly.

import { Agent } from '@strands-agents/sdk'

const agent = new Agent()
const result = await agent.invoke('What is the square root of 1764?')
console.log(result)

Note the package name: the npm package is @strands-agents/sdk, while the Python distribution is strands-agents. The repository root package.json is private and only wires up workspaces and scripts, so installing from the repo root is for contributors, not for consumers.

Where the in-process design costs you

Running the harness in your process means you own everything the process needs. Credentials, network egress, retries against provider rate limits, and the compute that keeps a long-running agent alive are all yours. The README says there is no hosted control plane, which is a feature until you want one: there is no shared place to see agents running across services, and no vendor-side kill switch for a runaway loop.

Model portability has a practical ceiling. The SDK supports many providers, but the default is Bedrock and the README's own quickstart assumes AWS credentials and Claude Sonnet access. Teams on a provider outside the first-class four should read the model providers documentation before assuming parity, because tool-calling behaviour and structured output support differ by provider, and the SDK can only expose what the provider offers.

The two SDKs are not a single artifact. They are released under separate version tags, and the monorepo's own package.json scopes its build, test and lint scripts to strands-ts. A team that needs both a Python service and a TypeScript front end is maintaining two dependency lines and reading two READMEs, and the README does not promise that a feature in one SDK exists in the other.

Finally, this is the wrong tool if your agent must run somewhere other than a Python 3.10+ or Node.js 20+ process. There is no other runtime in the repository.

Strands Agents versus LangGraph, and what the difference actually is

The comparison people search for is Strands Agents versus LangGraph, and the distinction is mostly about who defines the control flow. LangGraph's model is a graph you author: nodes, edges and state transitions that you draw and the runtime executes. The shape of the computation is explicit in your code, and the model is one kind of node inside it.

Strands takes the model-driven route the README names in its subtitle. You give the agent a model, tools and limits, and the model decides the sequence of tool calls. Your code sets the boundaries (turn limits, token budgets, hooks, guardrails) rather than the path. That is less code for open-ended tasks and less predictable for workflows where the steps are known in advance and must happen in order.

If your problem is genuinely a fixed pipeline with a couple of model calls in it, a graph runtime expresses that more directly than an agent loop does. If your problem is a task where you cannot enumerate the steps ahead of time, the graph becomes a thin wrapper around a loop you are writing anyway. The README's own framing, that you should choose Strands when you would otherwise write your own agent loop, is the cleanest test: if you are not writing a loop, you may not need this.

Maintenance, versioning and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-08-27, which is recent enough that the project is being worked on. That date is the only maintenance signal available here; the README does not publish a support policy or a release cadence.

Versioning is per language. The most recent releases listed are python/v1.54.0 and typescript/v1.15.0, both on 2026-08-27, with typescript/v1.14.0 a week earlier. The Python line has moved much further, which is worth knowing if you plan to use both: the numbers are not comparable across the two SDKs, and a TypeScript user cannot infer maturity from the Python version. Upgrade cost is the usual one for a fast-moving SDK. The monorepo's team/ directory holds compatibility guidelines and design proposals, so the project does document its process, but the README does not promise API stability guarantees.

The licence is Apache-2.0, with the text in LICENSE.APACHE and a NOTICE file at the repository root. Apache-2.0 permits commercial use and modification and includes an express patent grant, and it requires that you preserve the licence and notice files and state significant changes. That is a description of the licence text, not legal advice; if you are redistributing the SDK inside a product, have your own counsel read the NOTICE and the licence together.

Editorial conclusion

Adopt Strands Agents if you are building an agent that runs inside your own Python or TypeScript process and you want the loop, tools, MCP, sessions, streaming and tracing in one SDK rather than assembled from parts. Skip it if you need a hosted control plane, a visual builder, or a non-Python and non-TypeScript runtime, because the monorepo ships only those two SDKs. Before committing, verify three things in your own environment: that your AWS credentials and Claude Sonnet model access work, since both SDKs default to Amazon Bedrock; that your Python is 3.10 or newer or your Node.js is 20 or newer; and that your chosen model provider appears in the model providers documentation, because the README only names Bedrock, Anthropic, OpenAI and Gemini as first-class.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes