SDK Language
Both / Not language-specific
Problem Statement
Strands has no way to expose an agent to a code editor. The Agent Client Protocol is the standard for that link. It has official libraries in five languages and is implemented by Zed, JetBrains AI Assistant, several VS Code extensions, four neovim plugins, Emacs, Qt Creator, Visual Studio, Obsidian, and Jupyter.
Every framework Strands is compared against has closed this gap:
| Framework |
ACP support |
| Mastra |
@mastra/acp |
| Koog (JetBrains) |
agents-features-acp |
| LangChain / LangGraph |
Deep Agents ACP |
| Pydantic AI |
pydantic-acp |
| LlamaIndex |
workflows-acp |
| fast-agent |
fast-agent-acp |
| Strands |
none owned by the project |
It's also relevant inside AWS's own product line: Amazon Quick Desktop's "Coding Agents" feature is an ACP client, and its documented integration path is registering an external ACP agent (e.g. Kiro CLI) under Settings → Capabilities → Coding Agents. A Strands agent exposed over ACP would be usable from Quick the same way.
Proposed Solution
An acp module in the SDK, following the precedent set by a2a and MCP: both ship in core with their protocol SDK as an optional peer dependency (strands-ts/src/a2a, strands-py/src/strands/multiagent/a2a), so agents that don't use the protocol pay nothing.
I've already built and released a TypeScript bridge, ryancormack/strands-acp (this isn't feature complete yet, I built it because I wanted to orchestrate a Strands Agent from Quick), covering streaming, tool calls, session resume, and tool-call approval via session/request_permission (a rejection is returned to the model as a tool error rather than ending the turn, verified by integration tests against a real Strands Agent).
The harness SDK already made this possible outside of the framework. So the open question isn't whether this is buildable outside the SDK. It's whether ACP should be a framework capability (first-party, Python parity, one thing users can rely on) or stay a one-person community package.
The one concrete SDK gap: nothing describes what a tool does, so ACP tool kinds are currently inferred by pattern-matching tool names (file_read → read, apply_patch → edit). Tool-kind metadata on tool definitions would fix that and helps any UI integration, not just this one.
Use Case
- Running a Strands-built agent inside the editor its author already works in (Zed, VS Code, JetBrains, neovim), with tool calls and approvals surfaced in the editor's own UI, instead of a bespoke chat UI or a terminal script.
- Orchestrating Strands Agents from Quick Desktop over an open standard
- Forward looking and having the ability to offer ACP over HTTP from Bedrock AgentCore Runtime
Alternatives Solutions
Keep it a community package (@ryancormack/strands-acp). This works today and costs the SDK nothing, at the cost of no Python and "Strands supports ACP" meaning one contributor's package rather than a framework guarantee.
Additional Context
No existing ACP issue or PR on this repo. Checked issues, PRs, and checked the source. strands-acp is already a featured integration in the Strands catalog (site/src/content/catalog/strands-acp.yaml, added 2026-07-18); its description there ("interoperability with ACP-compatible orchestration systems") doesn't accurately describe the protocol and is worth fixing separately.
SDK Language
Both / Not language-specific
Problem Statement
Strands has no way to expose an agent to a code editor. The Agent Client Protocol is the standard for that link. It has official libraries in five languages and is implemented by Zed, JetBrains AI Assistant, several VS Code extensions, four neovim plugins, Emacs, Qt Creator, Visual Studio, Obsidian, and Jupyter.
Every framework Strands is compared against has closed this gap:
@mastra/acpagents-features-acppydantic-acpworkflows-acpfast-agent-acpIt's also relevant inside AWS's own product line: Amazon Quick Desktop's "Coding Agents" feature is an ACP client, and its documented integration path is registering an external ACP agent (e.g. Kiro CLI) under Settings → Capabilities → Coding Agents. A Strands agent exposed over ACP would be usable from Quick the same way.
Proposed Solution
An
acpmodule in the SDK, following the precedent set bya2aand MCP: both ship in core with their protocol SDK as an optional peer dependency (strands-ts/src/a2a,strands-py/src/strands/multiagent/a2a), so agents that don't use the protocol pay nothing.I've already built and released a TypeScript bridge, ryancormack/strands-acp (this isn't feature complete yet, I built it because I wanted to orchestrate a Strands Agent from Quick), covering streaming, tool calls, session resume, and tool-call approval via
session/request_permission(a rejection is returned to the model as a tool error rather than ending the turn, verified by integration tests against a real StrandsAgent).The harness SDK already made this possible outside of the framework. So the open question isn't whether this is buildable outside the SDK. It's whether ACP should be a framework capability (first-party, Python parity, one thing users can rely on) or stay a one-person community package.
The one concrete SDK gap: nothing describes what a tool does, so ACP tool kinds are currently inferred by pattern-matching tool names (
file_read→read,apply_patch→edit). Tool-kind metadata on tool definitions would fix that and helps any UI integration, not just this one.Use Case
Alternatives Solutions
Keep it a community package (
@ryancormack/strands-acp). This works today and costs the SDK nothing, at the cost of no Python and "Strands supports ACP" meaning one contributor's package rather than a framework guarantee.Additional Context
No existing ACP issue or PR on this repo. Checked issues, PRs, and checked the source.
strands-acpis already a featured integration in the Strands catalog (site/src/content/catalog/strands-acp.yaml, added 2026-07-18); its description there ("interoperability with ACP-compatible orchestration systems") doesn't accurately describe the protocol and is worth fixing separately.