Exploring Agent Role Using ACP Protocol

Summary

ACP looks worth supporting, but I’d treat it as a new live protocol layer for Traces, not a replacement for the current file/db adapters.

ACP
ACP is an open client↔agent protocol built around JSON-RPC sessions. The client initializes capabilities, creates or loads a session, sends prompt turns, and receives streamed session/update notifications for message chunks, tool-call lifecycle, plan updates, and status changes. It also has session/list and session/load, so a client can discover prior sessions and replay them, not just drive live chat. As of March 16, 2026, the docs describe stdio JSON-RPC as the primary transport and mark remote HTTP/WebSocket support as WIP; they also deprecate “session modes” in favor of session config options. Sources: Introduction, Overview, Architecture, Session Setup, Session List, Prompt Turn, Tool Calls, Agent Plan, TypeScript SDK.

How it fits Traces
Your current CLI architecture is storage-reader based: adapters parse local files/SQLite into Traces events, then expose discovery, content loading, subscriptions, and current-session hints. That’s visible in docs/cli.md, adapter.ts, and docs/adding-agents.md. ACP actually maps onto that contract pretty cleanly:

getTraces() -> ACP session/list
getTraceContent() -> ACP session/load and rebuild the transcript from replayed updates
subscribe() -> live session/update
getCurrentTraceHint() -> active ACP session id/path if the runtime exposes it

So I would add an AcpAdapter family beside the current file parsers, not instead of them. That gives Traces one generic integration for any ACP-compatible agent, and the ACP registry already overlaps heavily with your world: Codex CLI, Claude Code, Cline, OpenCode, Amp, Gemini CLI, Pi, etc. See Registry.

Recommendation

Build a generic ACP transport plus adapter, behind a feature flag, and start read-only with initialize, session/list, and session/load.
Keep file-based adapters as fallback. ACP only helps when the agent exposes ACP or Traces is in the session path.
Preserve ACP-native data instead of flattening too aggressively. Your current event model in types.ts only has six event kinds, so plan updates, approval requests, command updates, and config changes would get lost. I’d store raw ACP envelopes alongside normalized Traces events.
Do not treat ACP slash commands as the main Traces hook. Your current share-to-traces skill/env-hint flow still matters until Traces is actually acting as an ACP client or proxy; see docs/adding-agents.md and share.ts.
If you later make Traces an ACP client, use ACP session setup to attach a Traces MCP server. That is the cleanest way to let any ACP agent query prior traces or publish to Traces without bespoke per-agent setup, and it matches the MCP direction you already called out in docs/git-integration.md.

Net: ACP should become a first-class adapter/input protocol for Traces, and eventually the standard way Traces injects its own MCP capabilities into agent sessions. I would not rewrite the existing adapter stack around it yet, but I would absolutely prototype a generic ACP-backed adapter next.

Since existing agents we support already support ACP, how would we use those integrations?

Should we consider ourselves an ACP client?

This is alos interesting: https://docs.openclaw.ai/tools/acp-agents

Keep riffing on this, I'm trying to develop a mental model for ACP with Traces.

I’m checking the ACP and OpenClaw docs directly so I can tighten the mental model around who is the client, who owns the session, and how Traces would sit in that graph.

Short Answer
Yes, but only in the cases where Traces actually owns or can attach to the ACP session.

The key mental model is: ACP is not a global discovery bus for agents. It is a client-to-agent session protocol. So “Codex/Claude/OpenCode support ACP” means Traces can talk to them through ACP if Traces launches them, or if there is a shared ACP bridge/backend/session store. It does not mean Traces can automatically inspect sessions another client already owns.

What Traces Would Be
I’d treat “ACP client” as a role, not Traces’ whole identity.

Today, Traces CLI is mostly a post-hoc importer over agent storage: adapter.ts, docs/cli.md.
If Traces starts calling initialize, session/list, session/load, session/new, or session/prompt, then that subsystem is an ACP client.
Separately, Traces should still think of itself as an MCP provider. ACP is how Traces talks to the agent runtime; MCP is how the agent runtime talks to Traces tools/data. ACP’s architecture docs explicitly frame MCP that way.

So the clean model is:

ACP: Traces -> agent session
MCP: agent session -> Traces tools
Traces store/UI: normalized history, sharing, replay, search

That also means OpenClaw is a useful analogy. It uses ACP as a session router/broker: it binds threads to ACP sessions, resumes them with session/load, and controls them with /acp ... commands. That is a strong example of “ACP client as control plane,” not just “ACP client as editor UI.”
Source: OpenClaw ACP Agents

How I’d Use ACP In Traces
I would use ACP in three distinct modes:

ACP import mode: read-only ACP client. Use session/list and session/load to import exact session history. This is the safest first step.
ACP live-follow mode: for sessions Traces owns, map session/update directly into trace events instead of polling files.
ACP host mode: optional later. Traces launches sessions with session/new/session/prompt, handles permissions, and injects a Traces MCP server into the session.

That maps very cleanly onto your current adapter contract:

getTraces() -> session/list
getTraceContent() -> session/load
subscribe() -> session/update
getCurrentTraceHint() -> exact ACP session id instead of today’s heuristics in share.ts

That said, ACP does not replace file adapters. It complements them.

If Zed/OpenClaw/some other client owns the ACP session and exposes no shared backend/store, Traces still needs file/db adapters.
If there is a bridge or shared store, ACP becomes the better source of truth.
OpenClaw’s docs are useful here because they make session ownership explicit: runtime backend, bound session key, resume id, host-side execution.

Important Nuances

Many ACP integrations are not “native agent speaks ACP directly”; some are via adapters/bridges. The ACP agents page currently lists things like Codex CLI via Zed’s adapter, Claude Agent via Zed’s SDK adapter, and Pi via a pi-acp adapter. So ACP gives you a common session model, not necessarily a uniform install/runtime story.
ACP slash commands are not the main Traces integration point. ACP slash commands are agent-advertised to the client. Traces features like “search prior traces” or “share this trace” fit better as MCP tools or client-side UI, not ACP slash commands.
As of March 16, 2026, ACP still says to design around stdio; Streamable HTTP is still draft. So I would build local/host-side ACP support first.

What I’d Recommend

Add an ACP-backed adapter layer without removing file adapters.
Start with read-only initialize + session/list + session/load.
Store raw ACP envelopes alongside your normalized trace events; your current event model in types.ts is too narrow for plans, approvals, diffs, command availability, and richer tool lifecycle.
If that works well, add live-follow for Traces-owned ACP sessions.
Only after that consider full “Traces as ACP host/client UI” with permission handling and MCP injection.

Net: yes, I think Traces should become an ACP client in a scoped way. Not because ACP replaces your adapter architecture, but because ACP can become a new session source and a better control-plane primitive than parsing everybody’s private storage forever.

Sources: ACP Introduction, ACP Overview, ACP Architecture, ACP Initialization, ACP Session Setup, ACP Session List, ACP Tool Calls, ACP Slash Commands, ACP Agents, OpenClaw ACP Agents

Yeah, what if we wanted to become an agent ourselvs.

I’m checking the ACP “agent” side specifically so I can answer this as an architecture decision, not just a role label.

Yes. If Traces became an ACP agent, the cleanest mental model is not “Traces is now another Codex clone.” It’s “Traces exposes a session runtime that other ACP clients can talk to.”

ACP’s agent role is pretty concrete: the client launches the agent subprocess over stdio, calls initialize, then session/new or session/load, then session/prompt, and the agent streams session/update notifications for text, plans, tool calls, command availability, and permission requests. Sources: Initialization, Session Setup, Prompt Turn, Tool Calls, Slash Commands, Transports.

The important distinction is this:

MCP server means “agents can use Traces as a tool/data source.”
ACP client means “Traces can drive other agents.”
ACP agent means “other clients can drive Traces.”

Those are separate roles. Traces can do all three.

What “Traces as an ACP agent” could mean
There are three viable versions:

Trace analyst agent
This is the smallest, cleanest version. A client connects to Traces and asks:

“What prior traces touched this file?”
“Summarize the reasoning behind this commit.”
“Find similar sessions for this bug.”
“Generate a handoff from the last 3 traces in this repo.”

That is a real ACP agent, but specialized. It does not need to be a full coding harness.

ACP proxy/router
This is the most strategic version. Traces is both:

an ACP agent to the outside world
an ACP client to Codex/Claude/OpenCode/etc upstream

So the flow becomes:

Editor/OpenClaw/Zed -> Traces ACP agent -> upstream ACP agent

In that model, Traces can:

choose which real harness to run
inject Traces MCP tools/context into the session
record exact ACP events instead of scraping files later
enforce permission/policy/logging centrally
map every ACP session directly to a Traces trace/share URL

This is the OpenClaw-style pattern, just with Traces as the coordinator instead of OpenClaw. Source: OpenClaw ACP Agents

Full native coding agent
Traces owns the model/tool loop itself and speaks ACP directly to clients. This is the biggest scope by far. It means you are building agent runtime behavior, not just trace infrastructure.

What I would recommend
If you want Traces to “become an agent,” I would not start with the full native agent. I’d start with the proxy/router shape.

That gives you the strongest upside:

one stable ACP surface for clients
compatibility with existing ACP agents you already support
exact trace capture from live session updates
easier context injection than today’s adapter/skill/env-hint approach
a path to make Traces the control plane for multi-agent sessions

Concretely, that would look like

Add traces acp serve as a stdio ACP agent entrypoint.
Implement initialize, session/new, session/prompt, and session/update streaming first.
Persist raw ACP envelopes, not just the current flattened event model in types.ts. Plans, permissions, command lists, and richer tool lifecycle will otherwise be lost.
For each Traces session, optionally spawn an upstream ACP agent and bridge updates through.
Always inject a Traces MCP server so the upstream agent can query prior traces, related code history, and share/publish tools. That aligns with the MCP direction already noted in docs/git-integration.md.
Keep file/db adapters as fallback for runtimes Traces did not launch.

The key product question
Do you want Traces to be:

a memory/tool for other agents, or
the runtime boundary that users actually talk to?

If it’s the first, MCP server + ACP client is enough.
If it’s the second, ACP agent makes sense, and the proxy/router version is the highest-leverage first move.

Net: yes, Traces could absolutely become an ACP agent. The most sensible first version is not “build our own coding model runtime,” but “become a trace-aware ACP session broker that fronts existing agents and makes Traces first-class inside every session.”

Please look at :

https://agentclientprotocol.com/get-started/introduction
https://agentclientprotocol.com/protocol/overview

This feels like a protocol we should support or leverage in some way for sure for Traces in our CLI. Give me an overview of ACP and suggest how we should be using it in our adapter architecture.

I’m reviewing the ACP docs you linked and the Traces adapter architecture in the repo so I can ground the recommendation in how the CLI actually works today.

I’ve got the ACP protocol shape. Next I’m mapping it onto Traces’ existing adapter model so the recommendation is concrete rather than generic.

The key distinction is becoming clear: ACP is for live client↔agent interaction, while Traces adapters today are retrospective file/database readers. I’m checking the skill/setup side too, because that’s where ACP could overlap most cleanly.

I’ve got enough to make a recommendation. ACP is useful here, but mostly as a new live integration layer, not as a replacement for Traces’ current file-based ingestion.