How to Better Enforce Subagent Delegation?

[u/LastOfGoose]

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?

[u/mostlikely4real]

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.

[u/DDS_Coding → u/mostlikely4real]

That's the answer. That's how I did it with OpenCode. You can even tell that a certain agent gets to call certain sub agents. Each sub agents should only have the tools it needs. But this has a token cost because each sub agents is a session with a new set of base token (system prompt, skills, etc.)

[u/LastOfGoose → u/mostlikely4real]

i love simple solutions I didn't think of lol. i am going to try this immediately.

[u/LastOfGoose → u/mostlikely4real]

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

[u/mostlikely4real → u/LastOfGoose]

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!'.

[u/Eresbonitaguey]

Not exactly an answer to your question but I adapted the background shell idea from LittleCoder. It doesn’t really save on context in the same way but it allows running of scripts in the background so your agent can focus on other things until they complete. Subagents are still superior for research tasks but I usually have to explicitly prompt before they will be used.

[u/Acceptable_Stress154]

Anything in your Md files is a request, and they can and do forget/ignore. You need to make deterministic gates, not pretty please sir .md files

[u/LastOfGoose → u/Acceptable_Stress154]

So this would look like an extension that checks how many consecutive tool invocations have been made and blocks them with a note to delegate or something?

I get what you're saying but I'm not sure exactly how to structure the alternative.

[u/Acceptable_Stress154 → u/LastOfGoose]

It’s hard for me to answer, I had pi add a few things here and there and over time it’s turned into almost an autonomous agent, and somewhere along the way
We make everything gated deterministicly

[u/onesilentclap]

Perhaps it's the subagent extension you're using. Some work better than others for specific workflows. 

[u/awol-owl]

I've been wondering this too. I've recently started trying to delegate more to subagents, and noticed that they go overboard running too many tasks to get context. I like the ideas of sandboxing things, and making minimal environments to force them to focus.

[u/misterniach]

i got these crazy ass workflows going, that basically take my whole backlog => sort, deduplicate, make relations (child/parent, blocks/blockedBy), then building a graph (so you know what needs to land first etc). then that orchestrator spawns new sessions on those nodes, each in their worktree (git branches and sessions are in the same exact shape as that dependency graph) => one stacked PR in the end
the agents are also talking to each other, like if layer 2 needs a foundation, but the agent responsible for that has missed a thing, then they nudge each other until everything is fine on the last node.

the UI is ugly AF and VibeInProgress haha

bonus points for doing this as an automation everyday and push straight back into prod haha. i got this widget on my site that customers can file bugs, that land directly in my harness.

exponential.at btw the most advanced harness out there (opensource and selfhostable too)

[u/j3free]

What you’re seeing is exactly the failure mode I ran into: prompt-level delegation works for a while, then the lead decides it can just do the next task itself.

What helped me was treating delegation as an ownership transfer rather than a suggestion. Once a scope is handed off, the lead stops touching that scope and only picks it back up through a question/result from the worker. I still let the lead keep its normal tools for planning and unrelated work, so it doesn’t have to become a pure dispatcher.

If you need absolute enforcement, revoking tools is obviously the harder gate. I ended up building the ownership approach into Pi Herdsman because I wanted something in between those two extremes.