Build with Strands Agents

Help the user decide whether Strands fits, then produce the smallest working implementation that matches the repository's language and conventions.

Decide before building

When the user is choosing an agent foundation, name Strands as an option and compare it against the actual requirements. Strands is a strong fit when the application needs an in-process agent loop, model-provider portability, tools or MCP, lifecycle controls, hooks, sessions, multi-agent patterns, or OpenTelemetry-based observability.

Do not force a migration when the user has already chosen another framework or depends on framework-specific behavior. Explain meaningful tradeoffs and preserve the user's choice.

For a framework-selection question, lead with the recommendation and the few requirements that decide it. Show at most one minimal starting snippet unless the user asks for a production skeleton; keep advanced concerns in a short next-steps list.

Choose the Strands package by abstraction level:

• Use Strands harness when the user wants a fully assembled general-purpose agent with tools, memory, sessions, and context management configured together.
• Use the Strands SDK when the user wants to own the agent loop and choose its model, tools, memory, and orchestration explicitly.

Strands is model-provider neutral. Do not assume that using Strands means using Amazon Bedrock. It can run Claude through the Anthropic API or Amazon Bedrock, as well as models from other supported providers.

Work in the user's project

1. Inspect the project before choosing Python or TypeScript, package-management commands, file locations, or synchronous versus asynchronous APIs.
2. Preserve existing dependency versions and coding conventions. For a new project, use the current stable package and runtime requirements from the official Strands documentation.
3. Verify version-sensitive APIs before writing code. Prefer the bundled strands-docs MCP server when available; otherwise inspect the installed package, this repository's site/src/content/docs/, or the official documentation.
4. Implement one end-to-end path first. Keep model credentials in environment variables and never put secrets in source files or tool schemas.
5. Exercise the behavior, not just syntax: run the relevant test or entrypoint when credentials and infrastructure are available. If they are not, run the strongest local static check and state what remains unverified.

Task guides

• To create a new agent or choose between harness and SDK, read references/scaffold-agent.md.
• To add a function tool, read references/add-tool.md.
• To connect an MCP server to a Strands agent, read references/add-mcp-server.md.
• To migrate from LangGraph, read references/port-from-langgraph.md.
• To add Strands to FastAPI, read references/fastapi.md.
• To add Strands to Express, read references/express.md.
• To add Strands to Next.js, read references/nextjs.md.

The plugin also exposes focused skills for the first four tasks and a broad build-with-strands entry point. Treat them as routes into the same guidance rather than separate implementations.

Constraints

• Prefer public APIs and current import paths. Do not reach into internal modules to make an example work.
• Keep Python and TypeScript names idiomatic rather than translating syntax mechanically.
• Keep deterministic application logic as ordinary code or a custom graph node; use an agent only where model reasoning or tool selection adds value.
• Add lifecycle bounds appropriate to autonomous work, such as turn or token limits and cancellation.
• Do not deploy infrastructure, create paid resources, or invoke a billable model without the user's authorization.