AWS Strands Agents: A Production Engineering Deep Dive

Executive Summary

Strands Agents is an open-source, Apache-2.0 SDK from AWS for building AI agents with a model-driven architecture: you give the agent a model, a system prompt, and a set of tools, and the model itself plans, calls tools, reflects on results, and loops until it has an answer. There is no hand-authored state machine or DAG of “first do X, then do Y.” That orchestration is delegated to the model. The bet behind this design is simple and increasingly correct: as frontier models get better at planning and tool use, your agent gets better for free, with no refactor.

This is not a research toy. Strands powers production systems inside AWS — Amazon Q Developer, Kiro, AWS Glue, VPC Reachability Analyzer, and AWS Transform for .NET all run on it — and it crossed 50 million+ downloads in its first year. As of June 2026 the Python SDK sits at version 1.42.0 (Python 3.10+), with a first-class TypeScript SDK (@strands-agents/sdk, Node 20+) at parity for tools, streaming, multi-agent patterns, and structured output. It is model-agnostic (Amazon Bedrock by default, plus Anthropic, OpenAI, Gemini, LiteLLM, Llama, Ollama, Writer, SageMaker, Mistral, and community providers like vLLM, NVIDIA NIM, Cohere, and xAI), and it ships native Model Context Protocol (MCP) and Agent-to-Agent (A2A) support.

For a platform or DevOps engineer, the value proposition is the deployment story. The same agent code runs locally for development and then deploys, unchanged, to AWS Lambda, Fargate, App Runner, EKS, EC2, Docker, Kubernetes, or — the purpose-built option — Amazon Bedrock AgentCore Runtime, which became generally available in October 2025. AgentCore gives each user session its own Firecracker microVM (kernel-level isolation, up to 8-hour sessions, billing only for active CPU), automatic OpenTelemetry instrumentation, managed memory, and identity integration with Cognito, Entra ID, Okta, and OAuth providers.

This guide is the production playbook: how the agent loop actually works under the hood, the four multi-agent primitives and when to reach for each, how to deploy at scale, how to lock it down, where the money leaks, what to put on a dashboard, and the dozen failure modes that bite teams at 2am. It targets engineers who will operate this in production, not evaluate it from a slide.

Why This Matters

The agent-framework market is crowded — LangChain, LangGraph, CrewAI, Microsoft Agent Framework, AutoGen — and most of them solve orchestration by making you write the orchestration. You define nodes, edges, conditional routing, and retry logic. That works until the underlying model improves. A study cited by the AWS team found that tool-use coordination — deciding when and how an agent invokes tools — accounts for roughly 23% of all developer questions about agents. Frameworks that make you hand-script that coordination are accumulating technical debt against every future model release.

Strands inverts that. The AWS team showed a real before/after: a Sonnet 3.7 agent that reviews CloudWatch alarms across accounts, built the “traditional” way with a graph of pre-defined steps, hit 80.8% output accuracy. The same logic expressed as a model-driven Strands agent with in-loop verification hooks reached a 100% pass rate in Clare Liguori’s evals — and required zero refactoring to swap in a newer model, just a changed model_id and a re-run of evals. When your competitive edge is shipping agent improvements as fast as models improve, premature orchestration is the thing that slows you down.

The stakes are also operational and financial. Agents fail in production for boring, recurring reasons: the context window fills and the agent silently loses critical state; a reasoning loop runs away and burns thousands of dollars in tokens before anyone notices; a tool needs filesystem or shell access and you hand it the keys to the host; or a session crashes mid-execution and “resumes” by repeating destructive work. Each of these has a concrete mitigation in Strands — proactive context compression, iteration and timeout caps, sandboxed Shell execution, durable session managers — but only if you know they exist and configure them. Treating Strands as “just Agent(tools=[...])” is how you end up paging someone. The rest of this guide is about the other 95%.

Core Concepts

Before the deep internals, lock down the vocabulary. These are the load-bearing terms.

Model-driven (or model-first) design. The foundation model is the orchestrator. Instead of you encoding control flow, the model decides which tool to call, in what order, and when it is done. Your job is to define the capabilities (tools) and the intent (system prompt), then let the model reason. This is the single defining idea of Strands.

Agent. The primary object. In Python, Agent(model=..., system_prompt=..., tools=[...]). It bundles a model provider, a tool registry, a conversation manager, and a hook system, then exposes a callable interface: agent("do the thing"). Call it with no model and you get the default — Amazon Bedrock running Claude Sonnet in us-west-2, which requires AWS credentials and model access.

Agent loop (event loop). The recursive cycle at the heart of every agent: invoke the model → inspect the response → if the model requested a tool, execute it and feed the result back → invoke the model again → repeat until the model emits a final answer. Each iteration accumulates context, so the model sees the full history of what it has tried. Covered in depth below.

Tool. A function the model can call. The canonical way to define one is the @tool decorator on a plain Python function; the function’s docstring is what the model reads to decide when to use it. Strands also ships strands-agents-tools (20+ pre-built tools: HTTP, file ops, shell, Python REPL, calculator, Bedrock Knowledge Base retrieval, diagrams, browser automation) and consumes any MCP server as a tool source.

System prompt. Natural-language instructions defining the agent’s role, constraints, and objective. In a model-driven system this is your primary steering mechanism — it does more work than it would in a scripted framework.

Conversation manager. The component that keeps conversation history inside the model’s context window. The default SlidingWindowConversationManager keeps the N most recent messages; SummarizingConversationManager compresses older turns into summaries. As of the 2026 Harness SDK updates there is also an auto context manager that offloads large tool results to external storage and proactively compresses at 85% context usage.

Session manager. The abstraction for persisting and restoring agent state across process restarts (FileSessionManager, S3-backed managers, AgentCore Memory, Valkey/Redis community managers). Critical distinction: this persists conversational state, not execution state — more on that landmine later.

MCP and A2A. MCP (Model Context Protocol) is the open standard that lets an agent consume thousands of external tool servers without bespoke integration. A2A (Agent-to-Agent) is the protocol for agents to call other agents as peers; Strands auto-generates an “agent card” describing an agent’s capabilities for A2A discovery.

Hooks. Lifecycle callbacks that fire at defined points — before/after invocation, before/after each model call, before/after each tool execution. They are how you add observation, metrics, guardrails, and in-loop verification (“steering hooks”) without touching the core loop.

A useful mental model: a scripted framework is a railway — you lay every track and the train can only go where the rails go. Strands is a driver with a destination and a set of vehicles — you specify where to go and what’s available to drive, and the driver picks the route. The trade-off is exactly the one you’d expect: less control over the exact path, far less track to lay, and a driver that gets better every time the model is upgraded.

Architecture Overview

A Strands agent has four cooperating subsystems — the model provider (inference), the tool registry (actions), the conversation manager (context), and the hook system (extensibility) — orchestrated by the event loop. Here is the end-to-end request path through a single agent:

                        ┌──────────────────────────────────────────────┐
   User / caller        │                 STRANDS AGENT                │
        │               │                                              │
        ▼               │   ┌────────────────────────────────────┐     │
  agent("prompt") ──────┼──▶│         EVENT LOOP CYCLE           │     │
        │               │   │   (event_loop_cycle, recursive)    │     │
        │               │   └────────────────────────────────────┘     │
        │               │        │            ▲             │          │
        │               │        ▼            │             ▼          │
        │               │  ┌──────────┐  ┌──────────┐  ┌──────────┐    │
        │               │  │  MODEL   │  │  HOOKS   │  │   TOOL   │    │
        │               │  │ PROVIDER │  │ (before/ │  │ REGISTRY │    │
        │               │  │ (Bedrock,│  │  after)  │  │ @tool/MCP│    │
        │               │  │ Anthropic│  └──────────┘  └──────────┘    │
        │               │  │  OpenAI) │        │             │         │
        │               │  └──────────┘        │             │         │
        │               │        │             │             │         │
        │               │        ▼             ▼             ▼         │
        │               │  ┌────────────────────────────────────┐     │
        │               │  │      CONVERSATION MANAGER          │     │
        │               │  │  (sliding window / summarize /     │     │
        │               │  │   auto-compress @ 85% context)     │     │
        │               │  └────────────────────────────────────┘     │
        │               │        │                                     │
        │               │        ▼                                     │
        │               │  ┌────────────────────────────────────┐     │
        │               │  │   SESSION MANAGER (optional)       │     │
        │               │  │   persist → S3 / AgentCore Memory  │     │
        │               │  └────────────────────────────────────┘     │
        │               └──────────────────────────────────────────────┘
        │                                  │
        ▼                                  ▼
   final response  ◀──────────  OTEL spans → CloudWatch / X-Ray / Jaeger

Walk the path. A caller invokes agent("prompt"). The message is appended to conversation history, and the conversation manager applies its strategy to keep history within the context window. The event loop then runs one cycle: it calls the model provider, which returns either a final answer (stop_reason="end_turn") or a tool-use request (stop_reason="tool_use"). On a tool-use request, the loop looks the tool up in the registry, executes it (firing before_tool/after_tool hooks), appends the tool result to history, and recurses — calling the model again with the enriched context. This continues until the model emits end_turn, hits a configured iteration/timeout cap, or raises an unrecoverable error. Throughout, OpenTelemetry spans are emitted for every model call and tool execution, and — if a session manager is attached — state is persisted as messages are produced.

The crucial architectural property is context accumulation: every loop iteration adds to the same growing message list, so the model always reasons over the complete trajectory of what it has attempted. That is what enables multi-step reasoning, but it is also the source of the cost and context-overflow problems addressed later.

Deep Technical Breakdown

The event loop, precisely

The loop is implemented in event_loop_cycle() (Python: src/strands/event_loop/event_loop.py). Each invocation of the cycle executes a single conversational turn and does the following, in order:

1. Initialize cycle state and metrics, and create an OpenTelemetry span for the turn. An invocation_state dictionary is threaded through every recursive cycle of a single agent(...) call; its request_state sub-dictionary is user-accessible, and setting request_state["stop_event_loop"] = True halts recursion after the current tool execution — a clean kill switch for custom control logic.
2. Run model inference via _handle_model_execution(), which wraps the call in a ModelRetryStrategy (exponential backoff on throttling).
3. Process the stop_reason. This is the branch point. end_turn → return the final message. tool_use → enter tool execution. max_tokens → recover the partial message (recover_message_on_max_tokens_reached() appends explanatory text to keep history valid) and raise MaxTokensReachedException rather than continuing on a truncated context.
4. Execute tools (on tool_use) via _handle_tool_execution(), then call recurse_event_loop() to continue the cycle with the tool results in context.
5. Finalize metrics and close the span — even on failure, via tracer.end_span_with_error().

Two behaviors matter operationally. First, tool failures do not terminate the loop: an errored tool returns its error message to the model, which can then retry or change approach. This is resilience by default, but it is also how a poorly-described tool causes a runaway loop — the model keeps trying. Second, structured output is enforced in-loop: if you declare a structured_output_model and the model emits end_turn without calling the generated schema tool, the loop appends a “force” message and recurses to make the model comply.

Cancellation, concurrency, and async

agent.cancel() sets an internal signal checked at loop checkpoints (before and between tool invocations); the agent returns stop_reason="cancelled" and the signal auto-clears so the agent is immediately reusable. It is thread-safe and idempotent. You can also pass an external AbortSignal/cancelSignal into invoke()/stream(); Strands composes it with its internal controller via AbortSignal.any(), so client-disconnect timeouts and UI “Stop” buttons both work. One caveat that bites people: cancellation between tools is automatic, but mid-tool cancellation is cooperative — a long-running tool that doesn’t forward the signal or poll cancelSignal.aborted runs to completion before the agent resumes cancellation handling.

Since 1.0 the entire stack is async-capable. Tools and model providers run without blocking, and stream_async() emits every event — text deltas, tool usage, reasoning steps — in real time with built-in cancellation. Parallel tool execution is configurable (max_parallel_tools).

Context management — the part that controls your bill

This is where the 2026 Harness SDK updates changed the defaults meaningfully. Historically Strands only compressed context reactively, when a ContextWindowOverflowException fired — which meant the agent ran at the ragged edge of its context limit, starving output tokens and degrading quality. The new auto context manager (now the recommended default) does three things proactively: large tool results are offloaded to external storage and replaced with a truncated preview; old messages are compressed into structured summaries rather than dropped; and compression fires at 85% context usage to stay ahead of overflow. On AWS’s own code-investigation benchmarks this cut token cost by 55% while accuracy went from 68% to 98%. For agents where the model should decide what to keep, context_manager="agentic" gives the model tools to summarize, truncate, or pin specific messages — trading tokens for judgment. Rule of thumb: start with auto; switch to agentic when you must protect specific context across very long conversations.

Model providers

The provider interface is pluggable and swappable in one line. BedrockModel (default) uses the Bedrock Converse API under the hood — which is why any Bedrock model that supports tool use and streaming works. AnthropicModel hits the Anthropic API directly. There are first-party providers for OpenAI, Gemini, LiteLLM (a gateway to many providers), Llama API, Ollama (local dev), Writer, SageMaker, and Mistral, plus community providers for vLLM, NVIDIA NIM, Cohere, xAI, Fireworks, MLX, SGLang, and llama.cpp. Critically, in a multi-agent system different agents can use different providers — a cheap fast model for routing, a frontier model for the hard reasoning step.

Multi-agent primitives

Strands 1.0 introduced four ways to compose agents. They are not mutually exclusive — swarms can contain graphs, graphs can orchestrate swarms, and any agent can be wrapped as a tool.

• Agents-as-Tools (hierarchical delegation). A specialist agent is wrapped in @tool and handed to an orchestrator. The orchestrator’s model calls it like any function and never relinquishes control. This mirrors a manager consulting specialists. It is the workhorse pattern — clean, debuggable, and the default choice for “one coordinator, several experts.”
• Swarm (emergent collaboration). Agents hand off to one another autonomously — researcher → architect → coder → reviewer — with the framework managing handoffs, shared conversation history, and timeouts. The path is emergent, decided by the agents. Use it for collaborative, open-ended problems where you can’t pre-specify the route.
• Graph (deterministic routing). A directed graph (DAG or cyclic) where agents, custom nodes, or nested swarms/graphs are nodes, executed by edge dependencies with one node’s output feeding the next. Edges can carry conditional handlers for dynamic traversal, and cycles enable retry/escalation loops and human-in-the-loop gates. Use it when you need approvals, quality gates, or business rules enforced in a specific order. Per-node and whole-graph wall-clock timeouts are configurable; note nested orchestrators run under their own timeout config.
• Workflow (task pipeline). A developer-defined task graph with explicit dependencies and automatic parallelization of independent steps — classic ETL/pipeline shape, but with agents as the steps. Best for fixed, repeatable processes (data pipelines, employee onboarding) where efficiency and determinism win.

Both Graph and Swarm support sharing state across all agents via the invocation_state parameter.

Step-by-Step Implementation

Start with the environment. Strands needs Python 3.10+; for the default Bedrock provider you also need AWS credentials and model access enabled for Claude Sonnet in your region.

python -m venv .venv && source .venv/bin/activate
pip install 'strands-agents>=1.42.0' strands-agents-tools

# Default provider is Amazon Bedrock — configure AWS creds and enable model access
aws configure          # or use an instance/role profile
# Enable model access for the Claude Sonnet model id you intend to use, in your region

1. A real single agent with a custom tool

The docstring is not documentation — it is the model’s only signal for when to call the tool. Treat it as a prompt.

from strands import Agent, tool
from strands.models import BedrockModel

@tool
def get_order_status(order_id: str) -> dict:
    """Retrieve the current fulfillment status of a customer order.

    Use this when a customer asks about an existing order's shipping,
    delivery date, or whether it has been dispatched. Requires the
    order_id (format: ORD-XXXXXX). Do NOT use for refunds or returns.
    """
    # Replace with a real datastore/API call.
    return {"order_id": order_id, "status": "shipped", "eta": "2026-06-27"}

# Pin the model explicitly in production — never rely on the default in prod.
model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    temperature=0.3,
    max_tokens=2000,
    top_p=0.8,
)

agent = Agent(
    model=model,
    system_prompt=(
        "You are a customer support assistant for an e-commerce store. "
        "Answer order questions using the tools provided. If you lack the "
        "order_id, ask for it. Never invent order data."
    ),
    tools=[get_order_status],
)

result = agent("Where is my order ORD-489210?")
print(result.message["content"][0]["text"])

2. Production-hardened configuration

Defaults are tuned for development convenience. Before production, cap the loop, manage context, and constrain tools.

from strands import Agent
from strands.models import BedrockModel
from strands.agent.conversation_manager import SlidingWindowConversationManager

model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    temperature=0.2,
    max_tokens=2000,
)

agent = Agent(
    model=model,
    system_prompt="...",
    tools=[get_order_status, process_refund],     # explicit allow-list, never load-all
    conversation_manager=SlidingWindowConversationManager(window_size=20),
    # Newer SDKs: prefer context_manager="auto" for proactive 85% compression.
)

# Stream for low-latency UX in web apps
import asyncio
async def run(prompt: str):
    async for event in agent.stream_async(prompt):
        if "data" in event:
            print(event["data"], end="", flush=True)

asyncio.run(run("I need a refund for ORD-489210"))

3. Agents-as-tools (hierarchical delegation)

from strands import Agent, tool
from strands_tools import retrieve, http_request

@tool
def research_assistant(query: str) -> str:
    """Answer research questions with citations from trusted sources."""
    specialist = Agent(
        system_prompt="You are a research specialist. Always cite sources.",
        tools=[retrieve, http_request],
    )
    return str(specialist(query))

@tool
def math_assistant(problem: str) -> str:
    """Solve quantitative problems step by step."""
    from strands_tools import calculator
    specialist = Agent(
        system_prompt="You are a precise mathematics specialist.",
        tools=[calculator],
    )
    return str(specialist(problem))

orchestrator = Agent(
    system_prompt=(
        "You are a coordinator. Route research questions to research_assistant "
        "and quantitative questions to math_assistant. Synthesize their answers."
    ),
    tools=[research_assistant, math_assistant],
)

print(orchestrator("Find the 2025 EV market growth rate and project 2027 volume."))

4. Deterministic Graph with a quality gate

from strands import Agent
from strands.multiagent import GraphBuilder

extractor = Agent(system_prompt="Extract structured fields from the input.")
validator = Agent(system_prompt="Validate the extracted fields. Reply PASS or FAIL with reasons.")
reporter  = Agent(system_prompt="Produce the final report from validated fields.")

builder = GraphBuilder()
builder.add_node(extractor, "extract")
builder.add_node(validator, "validate")
builder.add_node(reporter,  "report")

builder.add_edge("extract", "validate")
# Conditional edge: only proceed to report if validation passed
builder.add_edge("validate", "report",
                 condition=lambda state: "PASS" in state.results["validate"].text)

graph = builder.build()
graph("Process this insurance claim: ...")

5. Deploy to Amazon Bedrock AgentCore Runtime

AgentCore is the purpose-built path. Wrap the agent in BedrockAgentCoreApp, expose an entrypoint, and let the CLI handle packaging, the container build (via CodeBuild — no local Docker required), deployment, and automatic OTEL instrumentation.

# main.py
from strands import Agent
from strands.models import BedrockModel
from strands_tools import calculator
from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

agent = Agent(
    model=BedrockModel(model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0"),
    tools=[calculator],
    system_prompt="You are a helpful assistant.",
)

@app.entrypoint
def handler(payload):
    return agent(payload.get("prompt")).message["content"][0]["text"]

if __name__ == "__main__":
    app.run()

pip install bedrock-agentcore-starter-toolkit
# Configure with an execution role ARN; the runtime auto-instruments OTEL
agentcore configure --entrypoint main.py -er arn:aws:iam::<acct>:role/<AgentCoreExecRole>
agentcore launch         # builds via CodeBuild, deploys, creates DEFAULT endpoint
agentcore invoke '{"prompt": "What is the square root of 1764?"}'

One gotcha to pre-empt (it cost more than one engineer an afternoon): the AgentCore execution role does not automatically get permissions to reach Gateway or Memory. You must add bedrock-agentcore:ListGateways, bedrock-agentcore:GetMemory, bedrock-agentcore:PutEvents, and related actions explicitly, or the agent fails with access-denied when listing Gateway tools or loading Memory sessions.

6. Deploy to AWS Lambda (short-lived / event-driven)

For stateless, short-duration agents, Lambda is the cheapest path. Package the SDK in a layer or container image, expose via Function URL or API Gateway. Keep state in DynamoDB/S3 if needed, since invocations are stateless.

# lambda_handler.py
from strands import Agent
from strands.models import BedrockModel

agent = Agent(model=BedrockModel(model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0"))

def handler(event, context):
    prompt = event.get("prompt", "")
    return {"statusCode": 200, "body": agent(prompt).message["content"][0]["text"]}

Production Architecture

Running Strands at enterprise scale is a question of where the loop runs and where state lives. The SDK is deliberately deployment-agnostic; the architecture decisions are yours.

Compute topology. There are three honest choices. AgentCore Runtime is the default for new builds that need per-user isolation, long sessions, and managed memory/identity/observability — each session gets a Firecracker microVM (its own kernel, memory space, and network namespace), sessions live up to 8 hours, and you pay only for active CPU, which matters because agents spend 30–70% of wall-clock time in I/O wait on model and tool responses. Containers on Fargate/EKS suit interactive, streaming, high-concurrency services where you want control over the runtime and networking, or where you’re standardizing on Kubernetes anyway. Lambda fits short, event-driven, stateless invocations within the runtime limit. The same agent code targets all three.

High availability. For container deployments, run the agent service across multiple AZs behind an ALB, with the model provider (Bedrock) already being a regional, multi-AZ managed service. The agent process is effectively stateless between requests if you externalize session state — which you must for HA, because in-process history dies with the instance.

Multi-region. Bedrock model availability and model IDs differ by region, so a multi-region deployment pins region-appropriate inference profiles and replicates session state (S3 cross-region replication or a global datastore like DynamoDB global tables). Cross-region inference profiles can also absorb regional capacity pressure for Bedrock.

Multi-tenancy. This is where AgentCore earns its keep: microVM-per-session isolation means tenant A’s agent state and tool execution cannot leak into tenant B’s, even under a prompt-injection attempt that tries to read the filesystem. On self-managed compute you must enforce tenant isolation yourself — separate execution roles, separate session namespaces, and sandboxed tool execution (see Strands Shell below).

Durability — read this carefully. Strands persists every message as it happens (not periodic checkpoints), which is great for conversational continuity. But conversation restore is not execution resume. If an agent crashes on step 5 of a 10-step tool sequence and you re-initialize it with the same session_id, Strands restores the message history — but the event loop starts a fresh inference cycle. The model sees the conversation and may repeat work, skip steps, or take a different path; there is no replay of tool executions, and Graph failures reset to the beginning. For workflows with side effects (payments, provisioning, emails), make your tools idempotent and add your own execution-state tracking. Do not assume the framework guarantees exactly-once completion — none of the major frameworks do.

Security Considerations

A model-driven agent is, by construction, a system that decides at runtime to execute code and call APIs based on untrusted natural-language input. The threat model is real: prompt injection that redirects tool use, over-broad tool permissions, secret leakage into traces, and tenant cross-contamination.

Authentication & identity. On AgentCore, use AgentCore Identity, which integrates with Cognito, Microsoft Entra ID, Okta, and OAuth providers (Google, GitHub), supporting OAuth tokens, API keys, and IAM roles. Put a real authorizer in front of the agent endpoint — a Cognito User Pool with JWT validation is the well-trodden path. Store client secrets in AWS Secrets Manager, never in environment variables.

Authorization (IAM) — least privilege, specifically. “Use IAM” is not a security control; scoping is. The agent’s execution role (Lambda role, Fargate task role, or AgentCore execution role) should grant only the exact actions on the exact resources the agent needs. For a Bedrock-backed agent that reads one Knowledge Base and writes one S3 prefix, that means bedrock:InvokeModel (and bedrock:InvokeModelWithResponseStream) scoped to the specific model inference-profile ARN, bedrock:Retrieve on the one Knowledge Base ARN, and s3:PutObject on arn:aws:s3:::my-bucket/agent-artifacts/* — and nothing else. Explicitly deny iam:PassRole except to the intended execution role. On AgentCore, remember to add the bedrock-agentcore:* Gateway/Memory actions the deployment tooling does not add for you.

Tool sandboxing. When the agent needs shell/filesystem access, do not give it the host. Strands Shell is the open-source answer: a secure execution environment with sub-millisecond startup where you declare exactly which paths and commands the agent can reach, and everything else is invisible — only bound paths exist in the agent’s virtual filesystem. Layer it on top of AgentCore’s session-isolated microVM for defense in depth. The principle: the agent should see two directories, not your root filesystem.

Guardrails. Strands integrates with Amazon Bedrock Guardrails for automated content filtering, PII detection/redaction, and denied-topic enforcement on both inputs and outputs. Use them as an automated output-sanitization layer rather than relying on prompt instructions alone, which are bypassable. Always validate user input before it reaches the agent, and sanitize outputs for sensitive data.

Secrets in telemetry. Traces capture prompts, tool arguments, and model parameters — which is exactly where PII and secrets leak. Configure trace attribute filtering to exclude sensitive fields, and never log raw credentials. Strands supports structuring and redacting logs; use it.

Compliance. For SOC 2 / PCI / HIPAA / GDPR workloads, the OTEL trace and CloudWatch log trail is your audit evidence — it records which tools the agent invoked, with what arguments, and what it returned. Pair that with microVM isolation (data-residency and tenant-isolation arguments), Bedrock’s in-region processing, and Guardrails PII redaction. The audit trail is not optional in regulated industries; design it in from day one.

Performance Optimization

Latency. The dominant latency cost is model inference, and the loop multiplies it — every tool round-trip is another full model call. Three levers: (1) Stream with stream_async() so the user sees tokens immediately instead of waiting for the full response — this is a perceived-latency win even when total time is unchanged. (2) Reduce loop iterations by writing better tool docstrings (so the model picks the right tool first try) and consolidating chatty tools into fewer, higher-value calls. (3) Right-size the model per step — use a fast model (Nova, Haiku-class) for routing and a frontier model only for the hard reasoning, which a multi-agent design lets you do per-agent.

Throughput. Enable parallel tool execution (max_parallel_tools) so independent tool calls in one turn run concurrently. For Graph and Workflow patterns, independent nodes parallelize automatically — structure your task graph so non-dependent work fans out. On Bedrock, watch for throttling; the SDK’s ModelRetryStrategy handles transient throttles with exponential backoff, but sustained load needs a provisioned-throughput or cross-region inference strategy.

The bottleneck nobody profiles: context size. Every tool invocation sends the entire accumulated context (system prompt + all prior messages + all prior tool results) to the model — this is by design, for coherence, but it means a 5-tool-call request pays the full input-token cost five times. As conversations grow, both latency and cost grow with them. The auto context manager’s offload-and-compress behavior is the highest-leverage performance change you can make: AWS’s benchmark showed it not only cut cost 55% but improved accuracy to 98%, because the model wasn’t drowning in stale context. Measure tokens-per-request and watch it climb over a session; that climb is your latency and cost curve.

Cost Optimization

Agent costs are dominated by model tokens, and the model-driven loop is a token amplifier. The levers, in rough order of magnitude:

• Context compression (biggest lever). The auto context manager cut token spend by ~55% on AWS’s own benchmarks by offloading large tool results to storage and summarizing old turns. This is a one-line change and it is the first thing to turn on.
• Cap the loop. Runaway loops are the classic production cost spike — the model decides it needs “just one more tool call,” indefinitely. Set hard iteration and execution-time limits and a per-request token budget. When you consistently hit the iteration cap, that’s a signal your tools aren’t returning enough per call, or the task exceeds a single agent’s capability.
• Model tiering. Don’t run a frontier model for trivial routing decisions. Amazon Nova models generate at fractions of a cent per thousand tokens and 200+ tokens/sec; use them for orchestration and reserve premium models for the steps that need them. A multi-agent design makes this per-agent.
• AgentCore’s I/O-wait billing. Because agents idle 30–70% of the time waiting on the model, AgentCore charging only for active CPU makes that idle time effectively free — a real saving versus paying for an always-on Fargate task that’s mostly blocked on I/O. The trade-off: AgentCore’s pricing (requests, session time, tokens, tool calls) is harder to predict at scale, so model it against your actual traffic before committing.
• Hidden AWS costs. The usual suspects apply — cross-AZ data transfer between your agent compute and dependencies, NAT gateway egress for outbound tool HTTP calls, CloudWatch ingestion for high-volume traces (sample at 1–10%, not 100%), and idle provisioned-throughput Bedrock capacity. Trace storage in particular can surprise you; index 1% of traces at no cost in X-Ray Transaction Search and raise it only where you need depth.

Monitoring & Observability

An agent is a black box between “user sent message” and “agent returned answer”: how many model turns, which tools fired, what failed, how many tokens, what it cost. Strands makes this observable through native OpenTelemetry instrumentation — traces, metrics, and logs in a standard format that exports to CloudWatch, X-Ray, Jaeger, Grafana Tempo, Datadog, Langfuse, or W&B Weave.

Traces. A trace is one end-to-end request; spans are the steps — each model call and tool execution becomes a span enriched with model parameters (temperature, top_p, max_tokens), token usage, and tool arguments/results. Enable with the strands-agents[otel] extra; on AgentCore Runtime, instrumentation is automatic (the runtime adds ADOT for you). For non-runtime deployments, add aws-opentelemetry-distro to requirements.txt and run under opentelemetry-instrument. Correlate multi-turn sessions by setting OTEL baggage: baggage.set_baggage("session.id", session_id).

The Golden Signals, mapped to agents:

• Latency — end-to-end request duration and per-model-call duration. Alert on p99 end-to-end breaching your UX SLO (e.g. >10s for interactive). A rising per-call latency usually means context bloat.
• Traffic — sessions/sec and requests/sec. Use for capacity planning and to catch abuse spikes.
• Errors — tool error rate, model throttle rate, and ContextWindowOverflowException / MaxTokensReachedException counts. Alert when tool error rate exceeds a few percent, or on any sustained throttling.
• Saturation — tokens per request and loop iterations per request. These are the agent-specific saturation signals. Alert when iterations-per-request consistently approaches your cap (runaway risk) or when tokens-per-request trend up over a session (cost/latency creep).

Dashboard layout. One row of Golden Signals (latency p50/p99, request rate, error rate, token rate). One row of agent internals (iterations per request histogram, tool-call distribution by tool name, throttle/retry counts). One row of cost (tokens by model, estimated cost per request, trace ingestion volume). On AgentCore, the CloudWatch GenAI Observability dashboard gives session count, latency, duration, token usage, and error rates out of the box.

Alerting thresholds that won’t page someone for nothing. Don’t alert on a single tool failure (the loop recovers). Do alert on: error rate >5% over 5 minutes; sustained Bedrock throttling >1 minute; iterations-per-request hitting the cap on >1% of requests; and any spike in ContextWindowOverflowException (means your conversation manager is mis-sized).

Troubleshooting Guide

Problem	Symptoms	Root Cause	Solution
Wrong tool selected or tool ignored	Agent answers without calling the obvious tool, or calls the wrong one	Vague/short tool docstring — the model uses the docstring to decide when to call	Write descriptive docstrings stating exactly when and why to use the tool; use specific names (calculate_shipping_cost, not calc)
Runaway reasoning loop	Token cost spikes, latency balloons, agent never finishes	Model keeps deciding it needs “one more” tool call; lenient dev defaults	Set hard iteration cap, execution-time timeout, and per-request token budget; investigate tools that return too little per call
ContextWindowOverflowException	Request fails mid-conversation on long sessions	Conversation history exceeded the model’s context window	Use SlidingWindowConversationManager (size it down) or the auto context manager with proactive 85% compression
MaxTokensReachedException	Truncated/aborted response	Model hit max_tokens mid-generation; loop refuses to continue on truncated context	Raise max_tokens; reduce input context; the SDK preserves history integrity but won’t proceed truncated
Token cost far higher than expected	Bill grows with conversation length; tool calls send huge payloads	Full context (system + all messages + all tool results) is re-sent on every tool invocation by design	Enable auto/summarizing context manager; tier models; cap loops; offload large tool results
Session “resume” repeats destructive work	After a crash/restart, agent re-runs payments/provisioning	Conversation restore ≠ execution resume; loop restarts fresh on same session_id	Make tools idempotent; track execution state yourself; don’t rely on framework for exactly-once
Corrupted session data under load	Intermittent state loss with concurrent requests	FileSessionManager is not thread-safe; concurrent writes to same session_id collide	Use an S3-backed or custom DB session manager; add your own locking for concurrent recovery
AgentCore “access denied” on Gateway/Memory	Agent can’t list Gateway tools or load Memory sessions	Execution role lacks bedrock-agentcore:* permissions; deployment tools don’t add them	Add bedrock-agentcore:ListGateways, GetMemory, PutEvents, etc. to the execution role
Tool can’t read AgentCore credentials	get_workload_access_token() returns None inside a tool but works outside	Request-scoped ContextVar shifts when the Strands agent invokes the tool (3LO flow breaks) — SDK issue #946	Pass tokens explicitly into the tool, or use the documented global-variable workaround until patched
Bedrock throttling under load	Intermittent failures, latency spikes, retry storms	Exceeding Bedrock account/region TPS quota	ModelRetryStrategy backs off automatically; for sustained load use provisioned throughput or cross-region inference profiles
Mid-tool cancellation doesn’t stop	”Stop” pressed but a long tool keeps running	Cancellation between tools is automatic, but mid-tool is cooperative	Forward cancelSignal/AbortSignal into the tool’s downstream API calls or poll cancelSignal.aborted
Default model not found / region error	Agent errors on first call with no model specified	Default is Claude Sonnet on Bedrock in us-west-2, needs creds + model access	Configure AWS creds, enable model access, or pin BedrockModel(model_id=..., region=...) explicitly
Graph node never executes	A branch of the graph is silently skipped	Conditional edge handler evaluates false, or nested orchestrator timeout misconfigured	Verify edge condition logic against actual node output; set explicit per-node and graph timeouts

Common Mistakes

• Treating docstrings as documentation. The docstring is the tool-selection prompt. Roughly 70% of first attempts fail on poor tool naming/descriptions. Spend real effort here.
• Relying on defaults in production. The dev defaults (lenient loop caps, default model, sliding-window-only context) are for fast iteration. Pin the model, cap the loop, and configure context management explicitly before shipping.
• Loading all available tools. Hand the agent an explicit allow-list. Every extra tool is more for the model to confuse and more attack surface.
• Over-engineering with multi-agent. More agents means more coordination overhead, not automatically more capability. Start single-agent; add agents only when single-agent complexity becomes unmanageable. And if there’s no tool calling at all, you’re over-engineering — use a plain model call.
• Assuming session persistence = durability. Restoring the conversation doesn’t resume execution. Design idempotent tools and your own execution-state tracking for anything with side effects.
• Skipping integration tests because “LLMs are unpredictable.” Exactly why you test — with multiple phrasings that should trigger the same tool path. Capture successful interactions as regression golden paths before production.
• Letting traces leak secrets. Prompts and tool arguments land in spans. Filter sensitive attributes and sample volume, or you’ll both leak PII and overpay for CloudWatch ingestion.
• Ignoring the per-tool-call context cost. People are shocked their bill scales with conversation length. It’s by design; manage it with context compression, don’t discover it on the invoice.

Best Practices Checklist

• Pin an explicit model_id, temperature, and max_tokens — no default-model reliance in prod.
• Provide an explicit tool allow-list; no load-all.
• Write tool docstrings as prompts: when to use, when not to, argument formats.
• Set hard iteration cap, execution-time timeout, and per-request token budget.
• Enable auto (or summarizing) context management; verify behavior under long sessions.
• Externalize session state (S3 / AgentCore Memory / DB) — never rely on in-process history for HA.
• Make all side-effecting tools idempotent; track execution state independently of conversation state.
• Sandbox shell/filesystem tools (Strands Shell) with explicit path/command allow-lists.
• Scope the execution IAM role to exact actions on exact ARNs; deny iam:PassRole broadly; add AgentCore Gateway/Memory permissions if used.
• Put an authorizer (Cognito/OAuth JWT) in front of the agent endpoint; secrets in Secrets Manager.
• Attach Bedrock Guardrails for input/output filtering and PII redaction.
• Enable OTEL (strands-agents[otel] / ADOT); export to CloudWatch/X-Ray; set session.id baggage.
• Build dashboards for the agent Golden Signals incl. tokens-per-request and iterations-per-request.
• Sample traces (1–10%), filter sensitive attributes, and budget CloudWatch ingestion.
• Run evals (output, trajectory, chaos, red-team) in CI before promoting; capture golden paths.
• Pin SDK versions (strands-agents, strands-agents-tools) and test model upgrades behind evals.

Alternative Approaches

Framework	Orchestration model	Best when…	Trade-offs
Strands Agents	Model-driven; the LLM plans and routes	You’re on AWS, want minimal orchestration code, and want the agent to improve as models improve	Less explicit control over exact path; full-context-per-call cost; durability is conversational, not execution-level
LangGraph	Graph-based; you define nodes/edges/state explicitly	You need precise, deterministic control over every step and complex stateful workflows	More boilerplate; risk of refactoring debt when models improve; orchestration you maintain
LangChain	Chains + agent abstractions, large integration ecosystem	You have existing LangChain integrations or need its broad connector library	Heavier abstractions; weaker native distributed tracing/metrics than Strands’ OTEL-first design
CrewAI	Role-based crews of agents with assigned goals	You want an opinionated multi-agent “crew” mental model out of the box	Less low-level control; another framework runtime to operate
Microsoft Agent Framework	Workflow + durable task extension (Azure)	You’re on Azure and need durable execution semantics as a platform service	Durable execution is an Azure service, not a framework primitive; platform lock-in, cost/latency at scale
Bedrock Agents (managed)	Fully managed, console-configured agents	You want a no-code/low-code managed path for simpler use cases	Less flexibility and portability than the open-source SDK; AWS-managed black box

Decision guidance: choose Strands when you’re building on AWS, value velocity and model-portability, and are comfortable letting a strong model drive. Choose LangGraph when you need to pin down every step deterministically and have complex branching state you must control. They aren’t mutually exclusive — you can wrap a LangChain chain as a Strands tool. And note AgentCore Runtime hosts any of these frameworks, so the runtime choice and the framework choice are separable.

Industry Use Cases

• Startups — Ship an agentic feature in days instead of weeks; the <10-line agent loop and one-line provider swaps let a small team iterate fast and switch models as cheaper/better ones appear.
• Enterprises — AWS itself runs Amazon Q Developer, AWS Glue, and AWS Transform for .NET on Strands; the .NET modernizer uses multiple specialized agents to analyze legacy apps and execute code transformations at scale via AgentCore + AWS Batch.
• SaaS — Smartsheet built context-aware assistants on Strands for its conversation memory and dynamic tool registration; the model-driven design keeps the assistant flexible as the product grows.
• FinTech — Trading-platform support scaled on Strands; multi-agent swarm/consensus patterns (with low-cost Nova models) add redundancy so a weak response is out-voted or retried automatically.
• Healthcare / Life Sciences — Protein-research copilots orchestrate embedding search, vector DB lookups, and LLM summarization as agents-as-tools inside a single AgentCore runtime, with SageMaker endpoints as tools.
• AI Platforms / Security — Offensive-security teams scale autonomous pen-testing with Strands + Claude + Bedrock Guardrails; infra-drift-detection products (Jit) use Strands for its native AWS integration and built-in security posture.

Future Trends

The direction is legible from the 2026 releases and the team’s own roadmap signals. The runtime is commoditizing. AWS’s stated bet is that deploying an agent will soon feel as mundane as deploying a Lambda, with the hard part being building one worth deploying; AgentCore (Runtime, Memory, Gateway, Identity, Observability) plus an 800+-agent Agent Marketplace is that commoditization in motion. Context management and durability are the live frontiers. The Harness SDK’s auto-compression (55% cheaper, more accurate) and Strands Shell (sandboxed execution) shipped in 2026; expect execution-level durability — true resume, not just conversation restore — to be the next gap frameworks race to close. Evaluation moves left. Strands Evals 1.0 added chaos testing and red-teaming; agent CI/CD with automated trajectory evals and adversarial testing is becoming table stakes, not a nicety. Steering hooks over rigid graphs. AWS’s own finding that in-loop verification hooks beat pre-defined graph workflows (100% vs 80.8% accuracy) points toward “model-driven with guardrails” displacing “developer-defined DAG” as the dominant production pattern. Cross-framework interop via A2A and MCP continues to standardize, so the agent, the tools, and the runtime increasingly decouple — you’ll mix a Strands orchestrator, an MCP tool server, and a LangGraph sub-agent without friction.

Key Takeaways

• Strands is model-driven: you supply model + prompt + tools, and the LLM orchestrates. This minimizes orchestration code and lets your agent improve as models improve — the core reason to pick it over graph-first frameworks.
• The agent loop (event_loop_cycle) is recursive and context-accumulating: model → tool → model, until end_turn. Understand stop_reason handling, because cost, latency, and runaway-loop risk all live there.
• The single highest-leverage production setting is context management. The auto manager cut tokens ~55% and raised accuracy to 98% on AWS benchmarks — turn it on first.
• Pick the right multi-agent primitive: Agents-as-Tools for delegation (the default), Swarm for emergent collaboration, Graph for deterministic gates, Workflow for parallel pipelines.
• Deploy unchanged to Lambda, Fargate, EKS, or AgentCore Runtime. AgentCore (GA Oct 2025) gives microVM isolation, 8-hour sessions, active-CPU billing, and auto-OTEL — the default for new isolated/long-running builds.
• Security is scoping, not “use IAM”: least-privilege execution roles on exact ARNs, sandboxed tools (Strands Shell), Bedrock Guardrails, an auth layer, and trace redaction.
• Durability is conversational, not execution-level. Make side-effecting tools idempotent and track execution state yourself; don’t expect exactly-once completion.
• Observe with OTEL → CloudWatch/X-Ray. Watch tokens-per-request and iterations-per-request — the agent-specific saturation signals that predict your bill and your pages.

FAQ

1. Is Strands production-ready, or still a preview? Production-ready and at 1.x (1.42.0 as of June 2026, marked Production/Stable on PyPI). It powers Amazon Q Developer, Kiro, AWS Glue, and AWS Transform for .NET internally, with 50M+ downloads. The 1.0 release in mid-2025 added the multi-agent primitives, durable session management, and A2A support that production needs.

2. Do I have to use AWS or Amazon Bedrock? No. Bedrock is the default provider, but Strands is model-agnostic — Anthropic API, OpenAI, Gemini, LiteLLM, Llama, Ollama, Writer, SageMaker, Mistral, and community providers (vLLM, NVIDIA NIM, Cohere, xAI). Being Apache-2.0 open source, you can run agents on-prem or in other clouds.

3. What’s the difference between Strands and Bedrock AgentCore? Strands is the open-source SDK (the agent framework — how you build the agent). AgentCore is AWS’s managed serverless runtime (where the agent runs). They’re complementary and separable: AgentCore runs Strands, LangGraph, CrewAI, or custom agents; Strands deploys to AgentCore or to Lambda/Fargate/EKS/EC2.

4. How does Strands keep an agent from looping forever and burning tokens? It doesn’t by default — dev defaults are lenient. You configure hard iteration caps, execution-time timeouts, and per-request token budgets. Setting request_state["stop_event_loop"] = True also halts recursion. Monitor iterations-per-request; consistently hitting the cap signals tool or task-decomposition problems.

5. Why is every tool call sending the full conversation to the model? By design. The model-driven loop passes the complete context (system prompt + all messages + all prior tool results) on each tool invocation so the model has full information for coherent decisions. The cost trade-off is real; mitigate with the auto/summarizing context manager, model tiering, and large-tool-result offloading.

6. What conversation manager should I use in production? Start with the auto context manager (offloads large tool results, summarizes old turns, compresses proactively at 85% usage). Use SlidingWindowConversationManager with a sized window for simple bounded sessions, SummarizingConversationManager for long support sessions, and context_manager="agentic" when the model must protect specific pinned context.

7. How do I choose between Agents-as-Tools, Swarm, Graph, and Workflow? Agents-as-Tools for hierarchical delegation (one orchestrator, several specialists) — the default. Swarm for emergent, collaborative problems where the path can’t be pre-specified. Graph for deterministic routing with approval/quality gates and conditional/cyclic flows. Workflow for fixed, repeatable pipelines with parallelizable independent steps. They compose.

8. Is the TypeScript SDK at parity with Python? Largely yes for core capability — @strands-agents/sdk (Node 20+) supports tools (Zod-typed), MCP, streaming, multi-agent patterns, and structured output. Python remains the most mature with the broadest provider and tool ecosystem, so check provider/tool coverage for your specific needs.

9. How does Strands handle a crash mid-execution — will it resume safely? Cautiously. It persists every message, so it restores conversation state on restart — but that’s not execution resume. The loop restarts a fresh inference cycle and may repeat or skip steps; there’s no tool-execution replay, and Graphs reset to start. Make tools idempotent and track execution state yourself for side-effecting work.

10. Is FileSessionManager safe for production? No, not under concurrency — it isn’t thread-safe and concurrent writes to the same session_id can corrupt data. Use an S3-backed or custom database session manager (or AgentCore Memory) for production, and add your own locking if multiple workers can recover the same session.

11. How do I add observability without a third-party APM? Strands is OTEL-native. Add the strands-agents[otel] extra (or aws-opentelemetry-distro/ADOT for non-runtime deploys) and export to CloudWatch GenAI Observability and X-Ray. On AgentCore Runtime, instrumentation is automatic. Use OTEL baggage (session.id) to correlate multi-turn sessions.

12. What exactly should I alert on? Error rate >5% over 5 min; sustained Bedrock throttling >1 min; iterations-per-request hitting the cap on >1% of requests; spikes in ContextWindowOverflowException; and p99 end-to-end latency breaching your interactive SLO. Don’t alert on single tool failures — the loop recovers from those.

13. How do I prevent prompt injection from abusing tools? Defense in depth: explicit minimal tool allow-list; least-privilege execution-role IAM scoped to exact ARNs; sandboxed tool execution via Strands Shell with bound paths/commands; Bedrock Guardrails on input/output; input validation before the agent; and microVM session isolation on AgentCore so a compromised session can’t reach others.

14. How do I scope the IAM role correctly? Grant only the actions the agent uses on the specific resources it touches — e.g. bedrock:InvokeModel on the exact inference-profile ARN, bedrock:Retrieve on one Knowledge Base ARN, s3:PutObject on one prefix — and deny iam:PassRole except to the execution role. On AgentCore, also add bedrock-agentcore:ListGateways/GetMemory/PutEvents, which the tooling won’t add for you.

15. Can different agents in one system use different models? Yes, and you should. In multi-agent designs, route with a cheap fast model (e.g. Nova/Haiku-class) and reserve a frontier model for the hard reasoning step. Workflows can mix providers across agents freely — a major cost lever.

16. How does Strands compare to LangGraph for complex workflows? LangGraph gives you explicit, deterministic control by making you define the graph — powerful but accumulates refactoring debt as models improve. Strands delegates routing to the model; AWS found in-loop steering hooks beat a pre-defined graph (100% vs 80.8% accuracy) on one task. Choose LangGraph for strict step control, Strands for velocity and model-portability.

17. What does AgentCore actually cost? It bills on requests, session time, tokens, and tool calls, and only charges for active CPU — which is efficient because agents spend 30–70% of time in I/O wait. The downside is opacity: it’s cheap for small projects but hard to predict at scale. Model it against real traffic before committing, and watch session-time charges for long-lived sessions.

18. How do I give an agent safe shell/filesystem access? Use Strands Shell — an open-source sandboxed execution environment with sub-millisecond startup where you declare exactly which paths and commands are reachable; everything else is invisible to the agent (only bound paths exist in its virtual filesystem). Layer it on AgentCore’s session-isolated microVM for defense in depth. Never hand the agent raw host access.

19. How do I test an agent in CI when LLM output is non-deterministic? Test behavior, not exact strings: run multiple phrasings that should trigger the same tool path, and assert on tool selection and trajectory. Use Strands Evals (output, trajectory, tool-usage, chaos, and red-team evaluators) with LLM-as-judge scoring, capture successful runs as regression golden paths, and gate promotion on evals — including a model-upgrade eval pass.

20. When should I NOT use Strands? When there’s no tool calling at all (a plain prompt→completion) — you’re over-engineering; call the model directly. When you need strict, audited, deterministic step-by-step control with no model latitude (a rigid graph framework or Step Functions may fit better). When your stack is deeply invested in another framework’s integrations and the migration cost outweighs the benefit — though you can often wrap that framework as a Strands tool instead.

---

SEO Metadata

SEO Title: AWS Strands Agents: Production Engineering Deep Dive

Meta Description: A principal-engineer guide to AWS Strands Agents in production — agent loop internals, multi-agent patterns, AgentCore deployment, security, cost, and observability.

URL Slug: aws-strands-agents-production-deep-dive

Primary Keyword: AWS Strands Agents

Secondary Keywords: Strands Agents SDK, Strands agent loop, Strands multi-agent patterns, Bedrock AgentCore, model-driven agents, production AI agents AWS, Strands vs LangGraph, Strands Agents tutorial, agents-as-tools, Strands observability OpenTelemetry

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Is AWS Strands Agents production-ready?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Strands is at version 1.x (1.42.0 as of June 2026, marked Production/Stable on PyPI) and powers production systems inside AWS including Amazon Q Developer, Kiro, AWS Glue, and AWS Transform for .NET, with over 50 million downloads. The 1.0 release added multi-agent primitives, durable session management, and Agent-to-Agent (A2A) support needed for production."
      }
    },
    {
      "@type": "Question",
      "name": "What is the difference between Strands Agents and Bedrock AgentCore?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Strands is the open-source SDK you use to build an agent. AgentCore is AWS's managed serverless runtime where the agent runs. They are complementary and separable: AgentCore can host Strands, LangGraph, CrewAI, or custom agents, and Strands agents can deploy to AgentCore, Lambda, Fargate, EKS, or EC2 unchanged."
      }
    },
    {
      "@type": "Question",
      "name": "Do I have to use Amazon Bedrock with Strands Agents?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Bedrock is the default provider but Strands is model-agnostic, supporting Anthropic, OpenAI, Gemini, LiteLLM, Llama, Ollama, Writer, SageMaker, Mistral, and community providers like vLLM and NVIDIA NIM. As Apache-2.0 open source, agents can run on-premises or in other clouds."
      }
    },
    {
      "@type": "Question",
      "name": "How do I stop a Strands agent from looping forever and burning tokens?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Development defaults are lenient, so configure hard iteration caps, execution-time timeouts, and per-request token budgets before production. You can also halt recursion by setting request_state['stop_event_loop'] = True. Monitor iterations-per-request; consistently hitting the cap signals tool or task-decomposition issues."
      }
    },
    {
      "@type": "Question",
      "name": "Which multi-agent pattern should I use in Strands?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Use Agents-as-Tools for hierarchical delegation (the default), Swarm for emergent collaboration where the path can't be pre-specified, Graph for deterministic routing with approval and quality gates, and Workflow for fixed parallelizable pipelines. The patterns compose — swarms can contain graphs and any agent can be wrapped as a tool."
      }
    },
    {
      "@type": "Question",
      "name": "Does Strands resume safely after a crash?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Only partially. Strands persists every message and restores conversation state on restart, but conversation restore is not execution resume — the loop restarts a fresh inference cycle and may repeat or skip steps, with no tool-execution replay. Make side-effecting tools idempotent and track execution state yourself for exactly-once behavior."
      }
    },
    {
      "@type": "Question",
      "name": "How do I add observability to a Strands agent?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Strands is OpenTelemetry-native. Add the strands-agents[otel] extra (or aws-opentelemetry-distro/ADOT for non-runtime deployments) and export traces and metrics to CloudWatch GenAI Observability, X-Ray, Jaeger, or Datadog. On AgentCore Runtime, instrumentation is automatic. Use OTEL baggage to set session.id and correlate multi-turn sessions."
      }
    },
    {
      "@type": "Question",
      "name": "When should I not use Strands Agents?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Avoid it when there is no tool calling at all (a plain prompt-to-completion call is simpler), when you need strict deterministic step-by-step control with no model latitude (a rigid graph framework or Step Functions may fit better), or when migration from a deeply integrated existing framework outweighs the benefit — though you can often wrap that framework as a Strands tool instead."
      }
    }
  ]
}

Strategic Internal & External Linking

External (authoritative, link out): the Strands Agents documentation at strandsagents.com (agent loop, multi-agent, deploy, observability guides); the AWS Open Source Blog “Introducing Strands Agents 1.0”; the AWS ML Blog “Strands Agents SDK: A technical deep dive”; the Amazon Bedrock AgentCore developer guide; and the strands-agents GitHub org (sdk-python, tools, evals, samples).

Internal (cross-link within supraj.dev): a Bedrock AgentCore deep dive; an MCP servers explainer; an EKS-vs-Fargate-vs-Lambda deployment comparison; an IAM least-privilege guide; an OpenTelemetry/CloudWatch observability post; and any Anthropic-SDK or agentic-CLI build write-ups for the “build your own tools” angle.