#268·feynman

Expose Feynman through ACP using the existing Pi RPC runtime

Author: deniial00Created Sep 5, 2026Updated Sep 11, 2026

Motivation

It would be great to use Feynman from ACP clients such as Zed as a dedicated research agent, alongside coding agents, while keeping Feynman's existing researcher/reviewer/verifier/writer workflow intact.

After looking more closely at the current implementation, this may not require a new ACP server inside Feynman at all.

Current architecture

Feynman already uses the Pi runtime directly and bundles the core Pi packages:

  • @earendil-works/pi-agent-core
  • @earendil-works/pi-ai
  • @earendil-works/pi-coding-agent
  • @earendil-works/pi-tui

It also uses Pi APIs such as createAgentSession, SessionManager, and SettingsManager, and its own runtime wrapper already supports Pi's RPC mode:

bash
feynman --mode rpc

The Feynman runtime forwards --mode rpc to the embedded Pi runtime together with the Feynman research extension, prompt templates, system prompt, packages, etc.

So the architecture is already approximately:

Feynman CLI
   |
   +-- Feynman research extension
   +-- Feynman prompts / system prompt
   +-- Pi packages (pi-subagents, pi-web-access, ...)
   |
   +-- embedded Pi runtime
          |
          +-- text / json / rpc modes

This means ACP support could potentially be implemented mostly as a compatibility layer around the existing RPC runtime.

Existing Pi ACP adapter

aadishv/pi-acp already exposes Pi over ACP and is designed primarily for clients such as Zed.

It communicates ACP JSON-RPC over stdio and launches Pi using RPC mode.

Importantly, it already supports overriding the Pi executable through:

PI_ACP_PI_COMMAND

Conceptually this makes something like the following possible:

Zed / ACP client
       |
      ACP
       |
    pi-acp
       |
   Feynman RPC
       |
  embedded Pi
       |
  Feynman research workflow

or potentially:

bash
PI_ACP_PI_COMMAND=feynman pi-acp

Compatibility gaps

This does not appear to work completely out of the box yet.

pi-acp currently launches Pi with arguments such as:

bash
pi --mode rpc --no-themes

Feynman's CLI intentionally validates its own argument set and rejects unknown flags such as --no-themes.

There may also be compatibility details around session loading/resume and any other Pi CLI flags that pi-acp expects to pass through.

Another limitation in pi-acp today is that slash commands provided by Pi extensions are not currently supported. Since Feynman exposes important functionality through its research extension / command set, this likely needs testing as part of the integration.

Possible approaches

1. Make Feynman's RPC entry point compatible with pi-acp

Probably the smallest solution.

Allow/forward the Pi CLI flags needed by pi-acp, or provide a dedicated command intended to behave like a Pi RPC executable while still bootstrapping the Feynman environment.

For example, conceptually:

bash
PI_ACP_PI_COMMAND=feynman pi-acp

or a dedicated entry point such as:

bash
feynman rpc

that accepts the relevant Pi RPC arguments.

2. Add explicit Feynman support to pi-acp

Instead of changing Feynman's public CLI semantics, pi-acp could gain a Feynman mode / configurable argument set that launches:

bash
feynman --mode rpc

without Pi-specific flags that Feynman does not accept.

This might be useful for other Pi-based agent distributions as well.

3. Thin Feynman-specific ACP adapter

If the compatibility differences turn out to be larger, a very small ACP adapter could invoke the existing Feynman RPC runtime rather than reimplementing Feynman's agent/session logic.

This would still reuse the existing Pi RPC transport and Feynman bootstrap path rather than introducing a parallel agent implementation.

4. Native ACP implementation

Still possible, but given that Feynman already has a fully configured Pi RPC runtime, this now seems like the least attractive option unless ACP-specific behavior requires deeper integration.

Expected outcome

Ideally an ACP client should be able to start a full Feynman research session with the same capabilities as the terminal experience:

Zed / ACP client
       |
      ACP
       |
    Feynman
       |
       +-- researcher
       +-- reviewer
       +-- verifier
       +-- writer
       +-- Feynman research tools
       +-- Pi packages

I would be happy to help with implementation, testing, or experimenting with pi-acp compatibility if there is interest in supporting this.