Expose Junior as a remote ACP agent

[sentry-junior]

Expose Junior over remote Agent Client Protocol (ACP) so external clients can use it as a hosted coding agent. Intent is client-facing access (for example Zed or a T3-style chat UI), not local stdio and not Junior-to-Junior delegation.

Current behavior

• Junior already has durable Conversations, mailbox turns, and conversation-only API turns via api-turns with publishExternally: false (packages/junior/src/chat/api-turns/work.ts, packages/junior/src/api/conversations/routes.ts).
• Local CLI turns use runLocalAgentTurn() (packages/junior/src/chat/local/runner.ts) and are not an ACP surface.
• There is no ACP agent endpoint, session mapping, or remote transport today.
• Related but separate: #530 covers Junior-to-Junior ACP delegation with durable resume/replay. This issue is the external-client agent surface.

Gap

ACP clients speak JSON-RPC session lifecycle (initialize, session/new, session/prompt, session/update, session/cancel, optional load/resume). Junior has durable agent execution, but no remote ACP gateway, so editors and chat clients cannot attach to hosted Junior as an agent.

ACP documents remote agents over HTTP or WebSocket, and still marks full remote support as work in progress (introduction, Streamable HTTP/WebSocket RFD). Most shipping client integrations today are local stdio agent launches (for example Zed's agent registry / agent_servers path). Remote-capable clients exist or are emerging, but compatibility is uneven and should be treated as a first-class unknown for the MVP.

Intent

In the ideal end state, a person can point an ACP-capable client at hosted Junior and run agent work there: start a session, send prompts, stream progress/tool activity, cancel, and reconnect. Junior remains the durable runtime and tool/credential boundary. The client remains the UI.

Proposed MVP

Preserve this as the working MVP shape from product discussion:

1. Remote-only transport

   • No stdio agent mode in MVP.
   • Prefer Streamable HTTP from @agentclientprotocol/sdk first; add WebSocket only if a target client requires it.
   • Authenticate the connection (bearer / existing viewer or personal-token style auth).

2. ACP session → Junior Conversation

   • session/new creates a durable Conversation owned by the authenticated actor.
   • session/prompt enqueues work through the shared mailbox/worker path with publishExternally: false.
   • Stream assistant text, status, and tool start/finish as session/update.
   • Return a normal ACP stop reason when the Turn completes.

3. Reconnect basics

   • Sessions must outlive a dropped HTTP connection.
   • MVP should support reattach + enough replay/resume to continue a session after disconnect.
   • Full v2 stream resumability can wait if v1 load/resume is enough for the first client.

4. Cancellation

   • session/cancel must stop the active Turn and complete the prompt with cancelled.

5. Sandbox-first coding model

   • MVP keeps Junior's existing sandbox/tool runtime.
   • Treat client cwd as session context, not host filesystem control, unless/until we explicitly bridge client fs/* + terminal capabilities into Junior tools.
   • Do not accept arbitrary client-launched MCP servers in MVP without a trust model.

6. Validation target

   • One real remote ACP client path, even if experimental.
   • Plus a protocol-level integration test using the official TS SDK HTTP client/server pieces.
   • Explicitly document which clients were tried and what failed (transport, auth, capabilities, filesystem assumptions).

Likely non-goals for MVP

• Local junior acp stdio process for editors
• Junior-to-Junior delegation semantics from Implement Junior-to-Junior ACP delegation with durable resume/replay #530
• Full client-workspace filesystem/terminal takeover
• Client-supplied MCP server execution
• Pixel-perfect support for every ACP client on day one

Open questions

• Which first external client is the acceptance target: Zed remote ACP, a T3/T3 Code-style UI, JetBrains, or a thin custom web client?
• Can we reuse dashboard/API auth and conversation APIs directly, or does ACP need a dedicated route + event bridge?
• How much session/load / session/resume is required before the first client feels usable?
• Do we share protocol/transport code with Implement Junior-to-Junior ACP delegation with durable resume/replay #530, or keep client-facing ACP and Junior-to-Junior delegation as separate adapters over the same Conversation runtime?

References

• ACP intro: https://agentclientprotocol.com/get-started/introduction
• ACP overview: https://agentclientprotocol.com/protocol/v1/overview
• ACP session setup: https://agentclientprotocol.com/protocol/session-setup
• ACP prompt turn: https://agentclientprotocol.com/protocol/prompt-turn
• Remote transport RFD: https://agentclientprotocol.com/rfds/streamable-http-websocket-transport
• TS SDK HTTP example: https://github.com/agentclientprotocol/typescript-sdk/blob/main/src/examples/http-server.ts
• Editors/agents directory: https://zed.dev/acp
• Related internal issue: Implement Junior-to-Junior ACP delegation with durable resume/replay #530

Requested by David Cramer.

--

View Junior Session [Sentry]