Skip to content

Take Strands harness to production

Strands harness returns a plain Strands Agent, so taking it to production is not a separate story: deploying, observing, and securing a Strands harness agent are exactly the Strands Harness SDK’s run guides, applied to the agent the factory hands you. This page points to those guides and calls out the few things specific to Strands harness’s defaults.

Because Strands harness returns an ordinary Agent, every deployment target in the deploy guides works with it unchanged: build the agent with create_harness() where the guide builds one with Agent().

Two of Strands harness’s defaults write to the local filesystem, which matters when the deployment target has ephemeral storage. Sessions and long-term memory default to directories under ./.agent. On a container or serverless target, point session={"dir": ...} and memory={"dir": ...} at durable storage (a mounted volume, or a backend you supply through memory={"stores": [...]} or a session manager) so state survives past a single instance.

Strands harness builds a standard Agent, so the Strands Harness SDK’s telemetry works unchanged: traces, metrics, and logs flow the same way they do for any Strands agent. Follow observe your agent; there is nothing Strands harness-specific to wire up. To evaluate quality, the Evals SDK tests and scores Strands harness runs like any other agent.

The Strands Harness SDK’s safety guides apply directly: guardrails, PII redaction, and trusted message history all work on a Strands harness agent.

Two Strands harness defaults deserve a security decision before you ship. First, the programmatic_tool_caller runs model-authored code in Monty, which isolates the code but not the tools it calls; if the agent handles untrusted input, run it inside an SDK sandbox, or drop the tool. Second, the default agent can run shell commands and edit files; gate what it does with interventions and confine what it can reach with a sandbox.