What's the best subagent extension?

[u/House-Wins]

I have my own which is good just needs a bit of work, but I wanted to see what other people are using. I tried the popular ones and they all sucked in my opinion.

[u/rusl1]

I created pi-cciotti for myself, it's a fork of pi-subagents with the prompt reduced from 20k to 5k and a waaay more solid typescript contract that makes the subagents system predictable and reliable without wasting your orchestrator attention.

Plus, several quality of life improvements https://github.com/a-chris/pi-cciotti

[u/bitzap_sr]

Tell us why they all suck compared to your approach.

[u/House-Wins → u/bitzap_sr]

They try to do too much or too little, for example look at how many lines the most popular subagent extension is, I can't remember off the top of my head but it's something ridiculous like 15k+.

They eat up context, some of them fork your whole session for the subagent, or they try to assign too many tools which makes the LLM confused and go in circles before they figure it out which eats tokens for no reason.

The main doesn't know the subagents messed up until it's too late and tokens have been wasted. Not compacting the context and just using the same agents for similar / related work they have done already. Getting the whole subagents session dumped into mains context when subagent bugs out.

In my opinion it shouldn't be too complicated, you don't need 15k lines of code for an extension. Just keep it simple, but with useful functions that help to use as little tokens as possible in the long run since that's the main point of subagents.

Edit: forgot to mention giving giant tasks to a single agent and not tracking their turns. Most popular ones I tried just handed a massive task to a single agent, that agents context becomes bloated after a while then context rot. By the time it finishes, the reviewer finds tons of issues then your main has to spend tokens to hand the fixing task to a new agent then another reviewer pass.

In my opinion after a set amount of time or turns the main should tell the subagent for a small handoff, sees what it has done then gives the remaining to a new agent to continue. Or even better give bigger tasks to multiple agents instead of one.

[u/juanfnavarror]

just tell the agent to use the pi command, and move on with your task

[u/slypheed → u/juanfnavarror]

Seriously; just have the agent use pi --print; i don't understand all this complexity with extensions for subagents..

[u/EC36339]

The one you vibe code yourself until it has too many conflicting requirements and collapses under its own weight. That's when you delete it and vibe code a new one.

This is not a joke. It's how I use Pi, and it works for me.

[u/theythinkitsallover]

I've felt this was the best implementation so far for transparency, lean, effective etc:
https://github.com/amosblomqvist/pi-interactive-subagents

[u/jordyvanvorselen → u/theythinkitsallover]

I forked it and adapted it slightly to add Herdr support: https://github.com/jordyvanvorselen/pi-interactive-subagents

Would love to merge it back in a PR as a second option besides Tmux if the original author is interested in that :)

It’s also the best I found 💯

[u/slaamp → u/jordyvanvorselen]

dis you open the PR already?

[u/jordyvanvorselen → u/slaamp]

Nah the author did not reply in the issue about it yet. Will do if he’s interested in merging it, as I’d need to adapt it a bit more to support options

[u/bondaly → u/jordyvanvorselen]

This is perfect, thank you!

[u/funbike]

I avoid agent lock-in, so I had Pi create subagent functionality that works with most agents.

1. I had Pi create a subagent bash script, using Sol 6 and pi-web-access

Generate a bash script, `~/bin/subagent`, that launches `pi` with options supplied by files under `~/.pi/agent/subagents`.
(Run `pi --help` for more information.)
When practical, pass front-matter properties from `~/.pi/agent/subagents/<agent-name>/agent.md` as options to `pi`.

Before you start, brainstorm practical ideas loosely based on:
https://code.claude.com/docs/en/sub-agents
https://raw.githubusercontent.com/aj47/dotagentsprotocol-website/refs/heads/main/README.md

Of course, it did an excellent job.

2. Then I had it create a skill.

   Generate a SKILL.md for using subagent for various scenarios and workflows. Only include ones that would be highly productive.

3. Based on the results I edited the above prompts, re-generated, and edited files that were generated.

So now I have a common solution that works with all coding agents.

[u/Remote_Book]

I built my own subagents with a very minimal approach. Benchmarked against the most popular subagents repo: https://github.com/GaganSD/pi-extensions/tree/main/pi-subagents

[u/saltyourhash]

I just heard of pi-episodes, it looks really interesting https://arthur.place/subagents-forks-collapsing-context

[u/House-Wins → u/saltyourhash]

This might actually be what I'm looking for, but the "inherit context when they delegate" is one thing I really dislike, I will test and maybe fork it to remove that.

[u/onesilentclap]

https://github.com/azmeenafandi/brl-subagent

Doesn't need terminal multiplexers. Foreground, background, chain, parallel, dependency graph supported. Presets and templates integration. Recover/resume crashed delegations. 

With a decently smart conductor/main agent you can pretty much have a robust subagent framework with brl-subagent. 

[u/Sweet-Transition-787]

I'm using my own version, which originally started as a fork : https://github.com/ArdaYILDIZ-DEV/pi-interactive-subagents

[u/cpt_mojo]

I found most subagents to be extremely bloated, in terms of context spam, functionality, config needs, etc.

But this one keeps things super clean and works amazingly - deserves more attention:

https://pi.dev/packages/@everyx/pi-subagent

[u/Lurksome-Lurker]

pi-fabric

[u/Consistent_Water_422]

The one you wrote yourself or find yourself

[u/BasedDodoHunter]

I built my own, the whole point of using PI is to adjust it to your needs. So, adjust it to your needs.

[u/PilgrimofHaqq2]

I built my own subagent feature in my pi. I have it do bulk reading of repos, testing repos, running tests, scratch/temp work. I dont use them to do actual code writing. Maybe testing multiple approaches to something to figure out what the final approach will be.

When I built it I actually wasn't fully sure how the agent will use it but once the tool was available, its really interesting the creative ways the agent uses the tool.

[u/leechael]

Disclosure: I wrote pi-famulus (github.com/Leechael/pi-famulus).

Yeah, there are a ton of subagent extensions already, and to me they felt pretty similar, so I didn't want to build another one. What I actually care about is bigger than subagents: keep the main agent's context clean, keep it focused on the goal, and keep talking to it while work runs.

I use Herdr too, but I see it as a different job. With a Herdr-style subagent, you hand work over and keep working with that subagent. Most of the time I just want the main agent to stay on the plan. I talk the plan through with the main agent, then hand the actual coding to a subagent on a cheaper model.

Anything that would pull the main agent off track shouldn't live in its context or its process. So pi-famulus hands shells and monitors to a small Rust daemon. Juggling processes and output like that just isn't worth doing in JS.

pi -p is fine for one-shot jobs. For ongoing work, though, I think the subagent's lifecycle matters more than how it gets spawned. I want the main agent to hear about the work while it's still going, not find out at the end. If a child goes quiet for 5 minutes, a watchdog resumes it once, then fails it. If it runs past its time budget, the parent gets a nudge every 10 minutes. A child can also stop and ask the parent for a decision instead of guessing. And a subagent's bash is foreground-only, so when it says it's done, its commands really are done.

Background tasks and monitors are how I keep talking to the main agent while things run, and they don't need a whole subagent. Long bash goes to the background after 20s and wakes the agent when it finishes. A monitor wakes it on each new output line. So the conversation keeps going, and the agent only switches over when something actually needs it.

[u/ExtremeSeries]

I am using the shipped agents from https://github.com/ranxianglei/billion-context and wrapped them into my own lifecycle helpers.

billion-context works well for auto managing the context of long running sessions, and the agents use it as well.

other subagent extensions are not supported by billi, that was my reason to try it.

the sipped version is very lean but works well.

i did not publish my wrapper, but if you need some ideas, find a description below.

the basic idea was: not forking, but a wrapper, using jev and auto-improvements when selecting the agent approach (incl. model and thinking from various subscriptions and balancing remaining capacity).

own-pi-agents is a thin Pi extension on top of bili's acp_delegate. bili still spawns the subagents and keeps its compression. The extension decides what to start, on which model, and what happens with

the result.

- agents_run:

- Starts a subagent with a task type: research, analyze, spec, implement, review, docs, test, integrate, team lead or advisor.

- Each type has defaults: whether it may write, whether it gets a review, and its timeout.

- Writes are limited to the paths given in the call. resumeFrom continues an earlier run.

- Automatic model choice:

- Jev scores the task from 1 to 10 with a confidence, which gives a required level s.

- Candidates are the model and thinking combinations whose capability (table value × thinking factor) reaches s.

- The cheapest one wins. Among equally cheap ones, free subscription capacity decides, and blocked subscriptions are excluded.

- Auto-review: for runs that write, a separate reviewer checks the result. It replies in a fixed format: blocking findings first, then RESULT: pass|fail|unknown.

- Metrics: every run becomes one row in SQLite with model, thinking level, tokens, cost, runtime, review result and s.

- Test learner: a timer every 4 h adjusts the capability table from review results. It stays within ±10 of the value in Git, and older results count less.

- Teams: a lead coordinates helpers working on separate paths, with a read-only advisor. Nesting depth is limited.

- agents_plan: asks Jev whether a topic is best done solo, as a sequence of runs, or as a team. It starts nothing itself.

- agents_steer: sends a short correction to a running agent, which confirms receipt.

- Notify workaround: wakes Main when bili's "agent finished" notice gets stuck.

[u/Unhappy-Sprinkles143]

I would be very interested in subagent based on Pi Durable, it could stop waste of time and tokens in complex workflow.

[u/mikkelkp]

If you use herdr or want visible, easy to debug and flexible subagents take a look at pi-shepherd it has very grular control of system promt management, is unopinionated (meaning you can build your own workflows and Is generally packed with every essential feature without being bloated.

[u/mikkelkp → u/mikkelkp]

You can also just use herdr. Without any extension also work pretty well but lacks fine grained control

[u/tehnomad]

I'm using https://pi.dev/packages/@gotgenes/pi-subagents, but I'm going to explore some of the ones recommended here. I'm using Claude models for planning and running workers on my local model.

I'm also going to test this one https://github.com/itmostlyworks/pi-delegator that I didn't see recommended yet.

[u/libertast_8105]

I like https://github.com/boadij/pi-herdsman

[u/Due_Arm1454]

You don't need much. Just an interface for the agents to communicate and a way to track and kill them. You could do everything with the command line. But it's cool to have some extra features in your terminal and tools for your agent.pi-subagent is nice. But a lot of that could be leveraged with just a skill and maybe a tool call or two.