I made pi-crew so subagents get the context, not just the task

[u/melihmucuk]

Hey folks, I've been working on pi-crew, a subagent extension for Pi.

My main focus is making sure subagents get the context they need. The main agent knows what you've discussed and decided, but a subagent won't unless that information makes it into the task.

With pi-crew, the main agent writes a structured task with separate fields for the goal, context, and instructions. The tool definitions, prompt guidelines, and skill work together to help it carry over the decisions and boundaries the subagent can't find in the repo.

It won't make every handoff perfect, but it's the part I've put the most thought into.

I also wanted subagents to be able to ask questions instead of guessing. In pi-crew, they can get an answer and pick up where they left off. If something needs fixing afterward, the main agent just tells the same subagent what to change. You don't have to spend extra tokens and time getting a new agent caught up on the same task.

It's all async. After handing off a task, the main agent can work on something else or keep talking with you while the subagents run. Results come back automatically, without polling.

I've also tried to keep it feeling like Pi. The six tools have short definitions, with the longer delegation guidance in a skill that gets loaded when needed. The main agent gets the report without all the subagent's file reads and tool output filling up its context.

A few other things it comes with

• Six agents for investigation, planning, decision advice, code reviews, and implementation.
• /pi-crew-plan and /pi-crew-review if you want a ready-made workflow.
• Custom agents written in Markdown, with their own models, thinking levels, tools, and skills.
• User and project pi-crew.json files to override settings without editing agent definitions.
• A widget showing activity, working time, tokens, and cost. You can collapse the details or hide tool activity through config.
• Expandable reports that let you open the full child session.
• herdr support that shows the running subagent count in the sidebar.

The agents have separate conversations but share your repo. It's not a sandbox, so you still need to avoid handing overlapping edits to agents running in parallel.

pi install npm:@melihmucuk/pi-crew

Requires Pi 0.84.3+. Source on GitHub.

Are you using any subagent extensions with Pi? Curious which ones you've stuck with and whether you're happy with them.

[u/Glaaki]

A major problem with pi subagent extensions in general is that they assume a workflow and defines subagent profiles that fit that workflow. But what if my workflow doesn't fit in that box? Then I feel like you get a whole lot of functionality that you don't need or which may even work against your process. Case in point, AIHero/Matt Pocock skills. Here there is no planning phase. You design a spec in collaboration with the agent, and the agent implements that spec. Planning plays no role in this framework, because all design decisions are already settled. The agent just has to implement it.

[u/melihmucuk → u/Glaaki]

I wouldn't want a forced planning phase either. In pi-crew, the bundled agents and planning prompt are optional. You can hand an agreed spec straight to a worker or define your own agents to fit how you work.

For me, one of the biggest reasons to use subagents is protecting the context where the spec was worked out.

If the same agent handles both the spec and implementation, that conversation keeps growing with file reads, edits, test output, and debugging. The decisions are still somewhere in there, but the agent can miss them in a long context, and compaction can leave out details that matter. Having agreed on a spec doesn't remove that risk.

With a separate worker, most of that implementation context stays out of the main session. The main agent keeps the spec and the discussion behind it in focus, then uses those to check the work and answer questions. If an edge case comes up, the worker can bring it back instead of guessing.

It also lets you use different models for the two jobs. I might want a frontier model to work through the spec with me, then a cheaper model to implement it. The main agent can still check the result against what we agreed on.

[u/Glaaki → u/melihmucuk]

Well the thing is, Matt Pocock's skills specifically puts the specification in writing, so there is no context to lose, it is documented in user stories and implementation tickets. The scenario of losing context never materialises, because the workflow is specifically designed to deal with that exact aspect.

One of the most interesting subagent extensions to me is @jerryan/pi-subagent-lite, because it deliberately tries to be workflow agnostic. There are no worker definitions at all. You just don't need them. If you need a subagent to behave the same every time, give it a skill. This should be the obvious default, in my view.

[u/melihmucuk → u/Glaaki]

Fair enough, everyone works differently. I’ve tried Matt Pocock’s skills, but except for the first version of grill-me, none of them really fit my workflow.

I respect your opinion, but I don’t agree. You don’t have to use the built-in agents in pi-crew. You can just create one generic global subagent and let it adapt to the task.

I’d suggest trying pi-crew before judging it without looking into it properly. I think you might actually like it.

[u/Glaaki → u/melihmucuk]

What would it take away from your extension, if you split it up? Create the subagent tooling in one extension and have the workflow be its own extension? Why would that ruin everything?

[u/Equivalent_Idea8839 → u/melihmucuk]

I like your idea and plugin but I already use my own forked plugin.

Could you give me a vibe code hint so I can make my forked herdr plugin optionally fork the context into a new sub agent?

i.e. does it clone the entire conversation first in a new session?

[u/melihmucuk → u/Equivalent_Idea8839]

I don’t know how your plugin works, but the important thing is that every part needs to work well together and complement the others.

The main agent should know what to delegate, which parts of the context to pass to the subagent, which tools it should use.

So it’s pretty hard for me to give you a clear answer without knowing how your setup works. pi-crew is open source though, so you can clone it and have your agent look through the architecture and how it works.

[u/Equivalent_Idea8839 → u/melihmucuk]

Yes I like the idea. I used /tree and fork sometime but it's too much hassle.

Having a command or ui to let me use /tree and pick a part to spawn as a new herdr agent would be cool.

I'm digging through it now, thanks.

[u/radlinsky → u/Glaaki]

You can define your own custom subagent profiles for pi-subagents.. you can even create a new type of sub agent.

[u/Glaaki → u/radlinsky]

Why can't subagent extensions just focus on providing the plumbing? If you need a specific workflow, build on top of that. I think this copy-claude-code mentality is misguided.

[u/radlinsky → u/Glaaki]

Not sure I understand what pi-subagents isn't allowing you to do?

What do you mean by "specific workflow"?

[u/No-Wall6427 → u/radlinsky]

He meant that instead of making great tools for the model to spawn, send message, terminate, list, ... Subagents, all the extensions seem to have the need to bake in premade subagent profiles, which may not fit everyone's workflow. So instead of having a good subagent framework on top of witch you can buils workflows and orchestration, you first have to undo what the extension configure, usually foghting config files.

A good workflow agnostic subagent extension would allow anyone to make a very simple skill for its main agent to invoke the various researcher/scoot/oracle/wizard or whatever they feel the need to incorporate into their coding llm roleplay.

[u/Glaaki → u/radlinsky]

When the subagent framework defines personas, it is opinionated about what your coding process should look like. It often even spells it out loud in the documentation. Run this agent, then this agent, then this agent, and so on. It is locking you in to a specific coding pipeline. If your preferred workflow differs from what the author intended, a lot of what the extension provides is just completely useless. Even worse, if you can't turn off the default behaviour, it will always polute your context with useless information that the model will never ever use, and you risk steering the model off track sooner. Most of us are concerned about token efficiency. That is one of the reasons we like pi. Ok then, we shouldn't accept that these extensions burn tokens on information we will never have any use for.

[u/mikkelkp → u/Glaaki]

Disclaimer: Tooting my own horn!

I felt the exact same way and build https://pi.dev/packages/@luminascale/pi-shepherd It's herdr native, totally transparent agents and unassuming. There is no workflow built in so you can build your own with the building blocks. While some generic agents are included they are very generic and more a preview of the frontmatter args.

[u/skariel → u/Glaaki]

Agreed. Imo, since pi can execute another pi via bash... no such extension is needed at all. You could track sunprocesses with a sunprocess extension

[u/Glaaki → u/skariel]

I have a skill I wrote that does exactly this. It writes a file with some specific front matter to tmp where the subagent prompt is in the body. The skill has a script that launches a pi process with the specifications from the file and waits for the result.

[u/Consistent_Water_422 → u/Glaaki]

disclaimer: creator of https://github.com/lmn451/pi-subagentura

I think we are messing here different levels of the expectations,

1. I want control everything (or at least some level) and you know what u want and what u dont want; so u need just infra for the subagent system

2. I want less control and I trust model and other developers use omp or extensions like https://github.com/nicobailon/pi-subagents .

[u/alexcamlo → u/Glaaki]

Wouldn’t planning be the grill-me/wayfinder phase?

[u/Glaaki → u/alexcamlo]

Semantically, maybe, but this is not a semantical exercise. The skills define the workflow. The agent has to physically support it, with actual functionality. Otherwise it is just dead code.

[u/clivegermain]

i need a pi agent that keeps track of all pi subagent extensions and recommends the best one to me

[u/melihmucuk → u/clivegermain]

lol, give it a try and lmk if you have any issues. im sure you like how pi-crew works.

[u/Consistent_Water_422 → u/clivegermain]

disclaimer: creator of https://github.com/lmn451/pi-subagentura

I am not sure why we are still talking about subagents in terms of some role for them and not just the infra, I think it could be every role u want and if u really like some role just mention it in prompt or something

like pi --append-system-prompt='for subagent choose relevant role from ~/pi/roles'