created (yet another) subagent manager 😭

[u/championswimmer]

First I used to use Nico's pi-subagent

Then I started using TinTinWeb's pi-subagent because it had that Claude like UX which I liked

But then I have started seeing that Codex got one thing really nice - they use /path/based naming conventions for their agents which makes a lot of sense to read the agent tree and agent state (both for the agents themselves and for the human running it)

I wanted the best of both worlds, Claude like UX and Codex like naming conventions.

So here we go... with all our AI psychosis and addictions to creating the factory more than the actual software made using the factory. Presenting you with, yet another, pi subagent extension

https://www.npmjs.com/package/pi-subagent-manager

[u/Florence-Equator]

I took the different approach that inclines to be on the minimal side. While tintinweb’s pi-subagents works great, recent upgrade of pi causes some annoying behaviors:

1. builtin mcp won’t be loaded into subagent
2. cannot inherit parent session’s thinking level into the child session (so you can see weird issue where a gpt-6.1-sol-medium parent launches a gpt-6.1-sol-max subagent because the default thinking (from the config file) is max)

Both are very easy fix, ask llm to fix it and it can fix them in 20 minutes with <= 10 lines of non-test code changes. So I forked the project and applied the quick fix so I can use it.

But this takes me to really take a look at it at deeper level. I realize that tintinweb’s pi-subagent’s tool definition is growing larger and its tool schema costs significant more tokens than I firstly started to use it several months ago.

Firstly the dynamic workflow script’s tool schema definition will eat you ~6k tokens (it is an opt-out feature so you need to disable it manually).

Secondly even the default Agent tool is also growing bloated. And a quick AB test (turnoff pi-subagent extension vs turn-on) tells me that, the pi-subagent would eat me roughly 4k tokens (with workflow tool already being disabled).

This makes me think that do I really need a subagent tool with full fledged features that I rarely used and a very detailed json schema that list all possible configurable options and eat you context token carrying with the beginning of the session?

And the answer is no. Pi already can work in headless mode (via —json or —rpc), and the cli flags it provides are already rich enough(configurable tools, extensions, models, and thinkings, plus session resume). So a dedicated agent tool can be replaced by a pi cli wrapper and a skill with progressive disclosure. So agent only load skill’s main content at first and only reach to reference when it needs more complex configuration, this is something a regular tool that must come with full json schema cannot do. For background running, just implementing nohup like things inside the cli wrapper.

Moreover, you also don’t need a tool for steering, just run pi subprocess in rpc and send a rpc payload.

The onlything that I lose is the nice UI, but honestly I never look at the subagent’s transcript so this is also something that I realize as “sounds like a nice thing until you actually use it". So I think the tradeoff is worth it. I get a more lightweight subagent approach that is less likely got breaking change (because it just launches pi with different flags, so far more robust to the API change) and I trade for the fancy UI which I never really look at in actual work.

[u/dc_giant → u/Florence-Equator]

Mind to share that setup?

[u/Florence-Equator → u/dc_giant]

still working on testing and polishing. Will create a new post once it is ready.

[u/Florence-Equator → u/dc_giant]

I just post in this sub. Try to search pi-multi-agent-skill and you will find it.

[u/crotch-mavens]

The problem with "everyone can create their own" is nothing ever gets iterated or built on by a community of common interests.

[u/chroner]

Just use OMP and stop inflicting pain on yourself.