[Parked pending adopter demand] Evaluate a Strands Agents adapter

Summary

Investigate and, if validated, design an adapter for Strands Agents (AWS's open-source, MCP-native agent SDK): Strands tool definitions → SelectableItem catalogs and agent conversation/session state → ContextItems — following the established adapter pattern.

Priority: P3 · Confidence: Low (framed as a design-proposal/investigation)

Why this matters

The adapter roster (CrewAI, Pydantic AI, smolagents, Agno, plus tracked LangChain/OpenAI-SDK/LlamaIndex/ADK work) determines who can adopt contextweaver in five minutes versus an afternoon. Strands Agents is a model-driven, MCP-friendly framework with growing enterprise usage; because it leans on MCP for tools, its users are disproportionately likely to hit the many-tools problem this library solves. Evidence of demand is incomplete, hence investigation-first rather than committing to build.

Current evidence

• No Strands references anywhere in the repo (verified by search).
• The adapter pattern and its costs are well-established (adapters/agno.py as the most recent template; shared-toolkit refactor tracked in #454).
• The integration request template (.github/ISSUE_TEMPLATE/integration_request.yml) exists, but no user has yet requested Strands — part of why confidence is Low.

External context

Strands Agents is an open-source Python agent SDK from AWS with first-class MCP tool support and a tools-as-decorated-functions model. Its MCP-native posture means some Strands users may be served by the MCP adapter path already — the investigation should determine whether a dedicated adapter adds enough over "point contextweaver at the same MCP servers."

Proposed implementation

Investigation phase:

1. Survey the Strands tool/session APIs: what shapes exist for tool metadata and conversation history; how stable are they.
2. Determine overlap: for a Strands agent using only MCP tools, does adapters/mcp.py + the gateway already cover the need? Identify what's unique (native @tool functions, session/state objects).
3. Gauge demand: discussions, any inbound requests, ecosystem signals; record findings here.
4. Decision gate: write the go/no-go with rationale. If go → design doc per the sibling-adapter conventions (plain-dict path, guarded imports, [strands] extra, floor pin), then implement as a follow-up.

AI-agent execution notes

• Inspect first: adapters/agno.py and adapters/crewai.py (pattern + cost baseline), adapters/mcp.py (the overlap question), #454 (build on the shared toolkit if landed).
• Research against official Strands documentation/repo; verify API shapes from source, not blog posts.
• Deliverable is the written assessment in this issue; implementation only after the decision gate.
• Do not add the dependency anywhere during investigation.

Acceptance criteria

• A written assessment covering API shapes, MCP-path overlap, demand signals, and maintenance cost.
• An explicit go/no-go recommendation; if go, a follow-up implementation issue with the design.

Test plan

Investigation phase: none beyond research validation. Implementation phase (if any): mirror the sibling adapter test suites (wire-shape fixtures, no live SDK for the dict path).

Documentation plan

If implemented: docs/integration_strands.md + README row + AGENTS.md module map. If declined: a brief note in docs/ecosystem.md or the FAQ pointing Strands users at the MCP path.

Migration and compatibility notes

Not expected to require migration.

Risks and tradeoffs

Each adapter is permanent maintenance surface against a moving framework — the explicit decision gate exists to avoid speculative cost. The "no adapter needed; use MCP" outcome is a perfectly good result and should be documented rather than treated as failure.

Suggested labels

integration, investigation, agents

Start by reading adapters/agno.py and adapters/crewai.py for the established adapter pattern, then inspect adapters/mcp.py and issue #454 for overlap and shared-toolkit context. Verify Strands APIs from its official documentation and source, and assess demand signals. Done means a written API, MCP-overlap, demand, and maintenance assessment with an explicit go/no-go recommendation and a follow-up design issue if appropriate.