I appreciate their reluctance towards MCP, but /something/ is better than nothing.
It’s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI.
We use these hugely successful technologies in spite of their flaws because they’re widely compatible and easy for the end user.
That’s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time.
And I’d much rather have the broad MCP ecosystem that we have now than seven or eight different “optimal” ways of plugging in an LLM to something useful.
Agreed. I personally don't use any MCP but I think it was a good move.
I hope they'll do the same and eventually add native support for ACP (<a href="https://agentclientprotocol.com/get-started/introduction" rel="nofollow">https://agentclientprotocol.com/get-started/introduction) which, on the contrary, I use quite.
Arguably, adopting ACP might even help Pi’s case, in that it could escape the terminal interface into one of many wrapper GUIs. TUIs inherently tend to limit your userbase to those who know what a terminal is… And given OpenAI’s latest product announcement [0] in response to Meta’s, the trend seems to be to attempt an expansion of customers to the general population, away from just developers and maybe “business” people.
Then again, I don’t even know if general adoption is what Pi/Earendil is going for.
I’m not sure; the integrated GUI seems like a major differentiator for them.
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
<a href="https://github.com/svkozak/pi-acp" rel="nofollow">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).
_fw · · focus · HN ↗
It’s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI.
We use these hugely successful technologies in spite of their flaws because they’re widely compatible and easy for the end user.
That’s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time.
And I’d much rather have the broad MCP ecosystem that we have now than seven or eight different “optimal” ways of plugging in an LLM to something useful.
alexfortin · · focus · HN ↗
I hope they'll do the same and eventually add native support for ACP (<a href="https://agentclientprotocol.com/get-started/introduction" rel="nofollow">https://agentclientprotocol.com/get-started/introduction) which, on the contrary, I use quite.
msdz · · focus · HN ↗
Then again, I don’t even know if general adoption is what Pi/Earendil is going for.
[0] <a href="https://news.ycombinator.com/item?id=49896604">https://news.ycombinator.com/item?id=49896604
everforward · · focus · HN ↗
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 <a href="https://github.com/svkozak/pi-acp" rel="nofollow">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).