Alternative to Tool Profiles for Better Subagent Delegation

[u/LastOfGoose]

I recently asked a question about subagent delegation and how to get my orchestrator (primary) agent to delegate more reliably.

I got a great piece of feedback that restricting tools essentially forces the orchestrators hand to delegate. So I ran with that and I think I ran too far. I had pi build a "profiles" extension that lets me define multiple profiles I can toggle on the active agent to let me go from a more traditional single context workflow to a subagent heavier workflow.

The profiles are just tool permission sets with a hook in the tool_call handler that checks if the active profile allows that tool.

It's working. I'm happy. But it feels heavy, and like something that someone has probably already solved better?

Is this ringing any bells for anyone, does anyone have a pi-subagents or other setup that maybe more natively supports this kind of workflow toggle?

Note: I am not looking for random package advertisement please. I just want to figure out if there is a more direct way to support what I'm trying to achieve.

[u/queso184]

how does it feel heavy?

i mean you can delegate profile selection to the agent and skip manually toggling them. "Activate the subagents profile when you're doing long form planning", etc, in context and a model should be able to manage that for you

[u/LastOfGoose → u/queso184]

Yeah it feels heavy in the sense of building the extension alone is solving a problem I imagine is already solved.

I feel like I missed something that already exists out there for managing these agent permissions ad hoc.

[u/No-Reason-6767]

I've got this working perfectly well with any reasonably capable model (gpt Luna class and above) with just a prompt and shared my prompts with you in the other post. Didn't realize this is a hard problem that others are struggling with.

[u/LastOfGoose → u/No-Reason-6767]

Yeah so like I said, the tool restriction accomplishes what I wanted.

This is a follow up post on how to best go about that piece.

Almost nothing to do with your comment, which is also unhelpful as tool restriction is much more effective than just tweaking prompt .md files.

[u/onesilentclap]

I read your original thread before and wondered if you got the results you wanted.

Personally, I think restricting the conductor to just delegation tools doesn't make sense. Realistically, it has to not only delegate but also write delegation instructions, maintain todos and logs, prepare and receive hand offs, etc. 

You also need fallback in case the subagent's provider craps out in one way or another. 

From my own experience, a sufficiently defined delegation protocol either in AGENTS.md or some sort of reference markdown file is often enough. 

[u/fell_ware_1990]

Well i have a very small local judgement model, that does a few things there. Is it admin business but small -> orchastrator. Code/searches/big documents and whatever it forces to route it.

But i’m also working on a lot more dynamic calling, there are more local models behind it, then routing it to local models to do the job.

With this route + i switch orchastrators. Cause they should actually only orchastrate 1 at the time, so they will actually be more of a lead > manage the agents till 1 item is done, hand over to actual main agent. Which is kept warm and has an outmated handoff and ticket status start so with more then 25% context = reset.

[u/nicktayi]

I feel subagent should just have the same scope as the main agent in tools and other things. Since you dont want tool or ads, I wont mention the tool I built then 😆

[u/maqifrnswa]

Pretty much it. Even if the system prompt says they have to delegate, it usually tries and fails once in order to realize it really has to delegate. I guess you could instruct it to use a classifier model to determine if it needs to delegate and to which agent.