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 (https://agentclientprotocol.com/get-started/introduction) which, on the contrary, I use quite.

Hah, it's the complete opposite for me :D. In Claude Code I disabled all sub-agents stuff, disabled nearly all tools but Bash, Edit, Write and WebSearch and replaced WebFetch with my own tool that doesn't summarize anything because the results were always worse with sub-agents, they always lack the necessary context and weaker models summarize bad. I also replaced the system prompt with my own that cuts a LOT of tokens, agents don't need a 10k+ system prompt anymore.

I did the same, also, the fact the tools evolve so fast, I dont want to waste time on a particular one while it might be obsolete next week. So either it works now, other I pick something else.

oh-my-pi is a fork of Pi that adds a lot of this stuff

https://github.com/can1357/oh-my-pi

I haven't tried it much though, can't vouch how well it works.

It's actually the main reason I chose Pi.

I did create some extensions where it spawns sub agents for specific tasks, especially when I want to keep the context clean or when I really want to offload a piece of work to a cheaper model. And for that I have a high degree of control over, I know which model is being used for each subtask.

I find Claude Code too unwieldy for my tastes. Pi's philosophy of being very light on features nut highly flexible for customization, clicked very well for the way I work.

Some things are impossible to just tack on or work around though, like MCP, while other things, can be done by just composing stuff.

Like sub-agents, you could just instruct pi/any harness with a user prompt/system prompt to start new invocations of itself, if you share what the exact command is, and pi or any other harness will do their own poor man's version of sub-agent via standard unix programs.

We will write about it. The best way to think about it is that codemode solves a different problem than bash in that bash is a way for the agent to run a particular tool: running bash.

Codemode is a way for the LLM to orchestrate harness level tools. The reason this happening now, is because the models by the labs are increasingly trained on this. Codex for instance in responses lite requires codemode to even perform parallel tool calling.

From my understanding, code mode came about due to some agents not having access to a shell.

Pi doesn't even support a permissions model. It's extremely barebones, you're expected to customize basically everything.

I happen to think codemode is useful, but not the full answer. I have a long and skewed history with chaining things in MCP and built a dozen or so enterprise ones (see https://taoofmac.com/space/blog/2026/04/29/2341 for notes) and it all falls back into the trade-off between agent scope/context and tool coverage: If you are using a coding agent it will have no trouble sorting out any tool regardless of how many are exposed (it's just a matter of either progressive tool disclosure or good tool metadata, since the coding agent will just go at it and expend whatever tokens are needed), whereas in a "normal", limited, scoped agent that has only a few things it needs to do (like handling a ticketing system) codemode is pretty much overkill.

Pi is primarily a coding agent, so yeah, code mode makes sense, but I've found that better MCP design saves everyone a lot of trouble and would also probably have improved the thing's reputation overall (I personally am not fond of the line protocol, would rather have protobuf and more typing, but it is what it is).

> Normally if LLMs want to compose multiple operations, they have the perfect tool for this: bash, or whatever other OS shell is available.

I many scenarios, e.g. running the harness server-side, as is the case for chat interfaces, you don't really want to expose OS shell access as that opens up a huge security attack surface.

Cloud products based orchestrations with proper security mechanisms configured, don't have shell access and should only communicate over proper network mechanisms.

Rootless immutable containers without shell access, or SaaS products from multiple vendors with WebAPIs as the only touch point.

You can turn those tools off. In fact, that is what I am doing right now in https://github.com/rcarmo/piclaw until I am positive the new MCP stuff has full parity with the MCP adapter I've been shipping for the past six months or so.

I'm actually pretty happy that they did it, since 90% of what I have to integrate in enterprises is MCP-driven (it's a security and auth boundary that has become pretty much mandatory for any third-party agents wanting to reach into corporate data) and this lets me use Pi directly. Am just being cautious about the first version, because, well... it's a first version, and I like my tools stable.

(I actually played around with the idea of using QuickJS myself for codemode, but since I rely on Bun that gives me the ability to use other things... never got around to do it though.)

To be clear: absolutely not the plan and nothing is loaded by default that was not loaded before.

Have a go at https://github.com/rcarmo/memento, I would appreciate Claude testers since I mostly use Codex. Just trying it and filing an issue about what doesn't work would be great...

Theres transport and context management. A cross agent status cache with semaphore over a testing harness driving a browser that can rewind and retry is much easier for agents to drive from mcp than selenium or whatever is fashionable these days. Didn't replace unit testing per se but to rca and fix it's a much better tool.

It's exactly that, but I don't see the issue. API+Docs under a single URL looks like a win for me. It also warrants a new name.

In enterprise integrations, that is just not an option. MCP has pretty much taken over there.

There is a MCP SEP that outlines multiple ways, that I hope will sooner or later be accepted: https://github.com/modelcontextprotocol/modelcontextprotocol...

While we are waiting on that to become stabilized, we implemented a inspired/co-evolved way to do that in our tool[0], where you mark individual fields in the request/response schema as being file payloads, so that file exchange can be properly orchestrated by the harness and doesn't pollute the context. We just do inline base64 uploads of the required payloads, which in practice we've seen to work quite will until ~100MB files (which is otherwise also the size limit we usually recommend for file processed).

It's annoying that it's not stabilized yet, but for most bigger customers we've seen, they implement 80% of the MCP servers they connect in-house, so doing adjustments to the tool surface, and metadata has been less of a pain for them than we expected.

[0]: https://erato.chat/docs/features/mcp_servers#file-support

I have had to hack a couple of workarounds in https://github.com/rcarmo/memento to do uploads, and there's a draft going around, but the general practice in enterprise MCPs seems to be to do it "out of band" and have MCP tools to hand-over storage handles/URLs so the MCP server can do the imports itself "safely".

Most people using pi probably know. MCP is “model context protocol”, a protocol by which models can connect to apis and services and conversely a way to expose those apis and services so they can be used by llms and agents. https://modelcontextprotocol.io/docs/2026-07-28/getting-star...

1. The first paragraph has a callback and link 2. You're not the intended audience of the post most likely

It's just like API-s, but with built in documentation.

MCP is the NIH non-standard version of OpenAPI.

How on earth does the article no address the title? Literally the first paragraph basically "spoils" the entire article and you have your answer, then you can continue reading for more justification of why it was like X before but now it's like Y.

Author of the post here: I don't think it's a good idea to put your clanker to a PR and then try to explain it. That's because you are then reading a derivative work of a derivative work instead of going to the source.

If we fail to explain it, then we need to do a better job explaining it :)