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:
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:
Conceptually this makes something like the following possible:
Zed / ACP client
|
ACP
|
pi-acp
|
Feynman RPC
|
embedded Pi
|
Feynman research workflow
or potentially:
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:
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:
PI_ACP_PI_COMMAND=feynman pi-acp
or a dedicated entry point such as:
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:
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.
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-tuiIt also uses Pi APIs such as
createAgentSession,SessionManager, andSettingsManager, and its own runtime wrapper already supports Pi's RPC mode:The Feynman runtime forwards
--mode rpcto the embedded Pi runtime together with the Feynman research extension, prompt templates, system prompt, packages, etc.So the architecture is already approximately:
This means ACP support could potentially be implemented mostly as a compatibility layer around the existing RPC runtime.
Existing Pi ACP adapter
aadishv/pi-acpalready 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:
Conceptually this makes something like the following possible:
or potentially:
Compatibility gaps
This does not appear to work completely out of the box yet.
pi-acpcurrently launches Pi with arguments such as: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-acpexpects to pass through.Another limitation in
pi-acptoday 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-acpProbably 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:
or a dedicated entry point such as:
that accepts the relevant Pi RPC arguments.
2. Add explicit Feynman support to
pi-acpInstead of changing Feynman's public CLI semantics,
pi-acpcould gain a Feynman mode / configurable argument set that launches: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:
I would be happy to help with implementation, testing, or experimenting with
pi-acpcompatibility if there is interest in supporting this.