Harness architecture
Strands Agents and UHP
Strands Agents is an open-source Python and TypeScript SDK that owns an in-process model-driven agent loop with lifecycle controls, tools, sessions, context management and multi-agent patterns. It has first-party MCP integration and experimental A2A client/server support, but reviewed primary sources do not establish native UHP adoption, a HarnessRouter backend or UHP conformance evidence.
Status first
Section titled “Status first”Strands Agents is a distinct in-process agent harness SDK, not a UHP implementation. Its own README says to choose Strands when you would otherwise write your own agent loop: the SDK runs inside the application process, without a hosted control plane, and supplies the model/tool loop plus lifecycle, context, session, observability and multi-agent machinery around it.
The latest observed stable SDK releases are Python v1.55.0, published 8 September 2026 at 16:54:53 UTC, and TypeScript v1.17.0, published 8 September 2026 at 16:55:25 UTC. Checked upstream main is e5ebbd67d0968b6839bac92a15108cb7b6a0b25a at this cutoff.
Why Strands matters to harness architecture
Section titled “Why Strands matters to harness architecture”Strands is useful to this site’s harness research because its first-party documentation explicitly treats the agent loop as the orchestration layer between model reasoning and external action. The loop repeatedly invokes the model, executes requested tools, feeds results back into context and continues until a terminal response or another stop condition is reached.
The stable SDK surface includes:
- per-invocation turn and token limits;
- cancellation and explicit stop reasons;
- hooks and retry strategies around model/tool execution;
- structured tools and structured output;
- conversation/context management and session persistence;
- memory and storage integrations;
- model-provider portability;
- streaming, tracing, guardrails and evaluations;
- multi-agent patterns;
- MCP tool-provider integration;
- A2A client/server integration, currently marked experimental by Strands.
Those are harness/runtime responsibilities. UHP instead standardizes the client → UHP server → configured harness boundary. A UHP server could theoretically front a Strands-based runtime, but no reviewed source establishes such an adapter today.
Agent loop versus UHP
Section titled “Agent loop versus UHP”Strands’ native boundary is an SDK object inside a Python or Node.js process. Creating an agent constructs the runtime directly in the application; there is no required Strands-hosted scheduler or control plane.
UHP 2026-08-11 is different in shape: it defines a network-facing execution/lifecycle contract around a complete configured harness. Similar concepts such as messages, sessions, cancellation or tasks cannot be assumed equivalent merely because both systems expose them.
| Layer | Primary job | Verified Strands relationship |
|---|---|---|
| Strands agent loop | Model/tool reasoning loop plus lifecycle/context controls | Native SDK surface. |
| MCP | Agent/harness → external tools and services | Native Python and TypeScript integration. |
| A2A | Agent → agent interoperability | Native client/server code, explicitly experimental. |
| ACP | Editor/client → agent protocol | A community strands-acp catalog integration exists; first-party native ACP is not established by reviewed Strands sources. |
| UHP | Client → UHP server → complete harness | No native adoption established. |
| HarnessRouter | UHP reference implementation → backend adapters | Strands is not in the released ten-backend set at this cutoff. |
MCP integration
Section titled “MCP integration”Stable Strands documentation says both the Python and TypeScript SDKs can connect to MCP servers and use their tools. Python exposes MCPClient as a managed ToolProvider; TypeScript exposes an McpClient. Documented transports include stdio and Streamable HTTP.
The v1.55.0 / v1.17.0 release train also contains a substantial evolving MCP-compatibility bundle: MCP 2.x-compatible behavior behind a flag, server/discover work for SEP-2575, call_tool support for the 2.x path, SEP-2663 task support, list-changed refresh behavior, and MRTR/input-required work across tools, prompts and resources.
These release-note entries are Strands implementation work against evolving MCP surfaces. They do not change the released MCP specification, which remains 2026-07-28 on this site’s current baseline, and they do not add anything to UHP conformance.
A2A integration is first-party but experimental
Section titled “A2A integration is first-party but experimental”Strands ships first-party A2A support in both language SDKs. The Python stable source includes an A2AServer that adapts a Strands agent to A2A and uses the A2A server/task abstractions; TypeScript includes A2A client, server, executor and Express-serving components.
The maturity boundary is explicit. Python logs that Strands’ A2A integration is experimental and subject to frequent breaking changes, while the TypeScript source carries the same experimental warning. Therefore this page records native experimental A2A support, not a blanket production-stability claim.
The Python server also documents a security/concurrency distinction worth preserving: a single reused agent is deprecated for multi-caller use, while agent_factory can create a dedicated agent per A2A context. That is Strands runtime guidance, not an A2A or UHP normative requirement.
ACP boundary
Section titled “ACP boundary”The Strands integrations catalog contains a community package, @ryancormack/strands-acp, described as bridging Strands agents to ACP-compatible orchestration systems. Reviewed first-party Strands SDK source does not establish a native ACP server comparable to its first-party A2A modules.
Accordingly, this guide classifies ACP as community integration evidence, not native Strands protocol adoption. That distinction is the same one used elsewhere on this site for adapters versus upstream-native support.
v1.55.0 / v1.17.0 release boundary
Section titled “v1.55.0 / v1.17.0 release boundary”The 8 September stable train is broader than a protocol update. Material harness-facing work includes:
- session-aware context-manager/storage changes and context offloading/stash support;
- an internal in-process task engine/manager;
- LocalAgent protocol/runtime work;
- MCP task/discovery/2.x compatibility work noted above;
- model cache-configuration expansion;
- cancellation/telemetry and session-replay correctness fixes;
- TypeScript raising its minimum runtime to Node.js 22+.
The Python and TypeScript packages are independently versioned, so v1.55.0 and v1.17.0 are SDK package versions, not UHP, MCP or A2A protocol versions.
Evidence boundaries
Section titled “Evidence boundaries”- Observed Python stable:
python/v1.55.0, published 8 Sep 2026 at 16:54:53 UTC. - Observed TypeScript stable:
typescript/v1.17.0, published 8 Sep 2026 at 16:55:25 UTC. - Checked upstream
main:e5ebbd67d0968b6839bac92a15108cb7b6a0b25a. - Native agent loop: established by Strands README and agent-loop documentation.
- Native MCP tool integration: established for Python and TypeScript.
- Native A2A: established, but explicitly experimental.
- Native ACP: not established; reviewed evidence is a community catalog integration.
- Native UHP: not established.
- HarnessRouter backend support: not present in
v0.15.7’s released ten-backend set. - UHP conformance evidence: none attributed to Strands Agents.
Related pages
Section titled “Related pages”Read Pydantic AI Harness for another SDK/capability-oriented harness, Docker Agent for a runtime that exposes MCP/A2A/ACP and delegates to coding harnesses, harness composition for execution topology, UHP vs MCP and UHP vs A2A for protocol boundaries, and ecosystem for adoption classifications.