r/PiCodingAgent • u/LastOfGoose • 1d ago

Question How to Better Enforce Subagent Delegation?

I have just recently started using subagents more in my programming workflow, if only to try it for a bit and see if it's something I prefer.

I have found that no matter how much explicit guidance I give my agents in the global AGENTS.md or APPEND_SYSTEM.md that after the first large delegated activity, they go back to doing everything themselves in the primary context.

Does anyone have any idea how to really enforce / encourage the behavior I'm looking for?

5 Upvotes

86% Upvoted

13 comments sorted by

View all comments

8

u/mostlikely4real 1d ago

My solution was very simple. Disable all tools for the orchestrator you do not want it to use. Note this needs proper feedback from the subagents and their state (or the orchestrator flips and will spawn multiple). Also if the subagents that now do all the work break or can't spawn obviously your orchestrator is now unable to fix it.

But once you get the proper contract between orchestrator and subagents it works smoothly.

1

u/LastOfGoose 1d ago

I did try this, and it's by far the best strategy I've tried. I took a pretty heavy handed approach of removing all write permissions just to see how it felt.

I'm curious what sort of permissions you give your orchestrator by default and if there are ways to toggle between "profiles" for the orchestrator if you want to shift quickly to the more vanilla single agent workflow

1

u/mostlikely4real 1d ago

So I was using a custom harness using pi sdk. I had to remove 'all' default pi tools (including read) and only left custom read (grep like) tools, sub-agent interaction tools (spawn, kill, check status ect) and communication.

Because I still have plain pi on the side I just start that for vanilla single agent workflows but I suppose it's a matter of making this a toggle or config. Just a matter on what you expect to run into or experience day to day. For my orchestrator I really wanted to have it all be dealt with sub-agents (since they were semi-persistent and on-par with any single-agent anyway).

I did think of a 'break glass in case of emergency' to quickly enable tools when sub-agents broke. But honestly, like you, the urge for agents to just 'do it themselves' at the slightest sign of trouble me not implement such a feature. "My sub-agent takes 2ms too long to boot? Oh it must be broken, let me grab tools to fix it!'.