I hope they'll do the same and eventually add native support for ACP (https://agentclientprotocol.com/get-started/introduction) which, on the contrary, I use quite.
Then again, I don’t even know if general adoption is what Pi/Earendil is going for.
Pi’s agent is supposed to be simple, and a simple ACP agent is like a couple hundred lines of code. Making a system that allows UI plugins is way harder.
Also not sure if you’ve seen but you can get ACP from Pi with https://github.com/svkozak/pi-acp It bridges Pi’s RPC mode to ACP, works okay but not amazingly. My thinking level selector in Zed has never worked with it but everything else I use has worked (I’m sure other things don’t but I must not use them).
About what Pi/Earendil is going for, I can't really say but a while ago they created quite a stir in the Pi community for adding a trust system[0] which for many (me included) went against the loudly advertized "yolo" phylosophy, at that time I speculated it was a move to make it more palatable for the general population (whatever that actually means), so I'll stay optimist for ACP adoption for now.
[0]: https://pi.dev/docs/latest/security#understand-project-trust
I'm not so sure about this move, or the general inclusion of code mode in the core editor as one of pi's main selling points was its minimal nature.
Though as time progresses, they are probably going to do the same with sub-agents.
There are a lot of ways to implement sub-agents, and it's not something I need the harness to be opinionated about.
I know builtin tools support opt-out, but it's more bloat. It's also more complexity for the agent to understand when you use it to build extensions for itself.
Imagine a world where you could:
* Configure your favorite harness/chat client with any OpenAPI spec for an API that supports Oauth2.
* The harness would walk you through the Oauth flow and securely store the token.
* And then insert some tools for discovering the API methods and making requests in to the context.
* The agent could then formulate a request, call the request tool, and the harness would 1) makes sure it's allowed to make a request to that API, and 2) insert the Auth Token into the request.
It would be basically exactly the same way MCP is setup today, except all you would need is an OpenAPI spec. You wouldn't have setup a server for a janky new standard that's half implemented slightly differently by every harness/chat client.