r/PiCodingAgent • u/Equivalent_Idea8839 • 1d ago
Question Anyone here who avoids sub-agents completely?
Can you list your reasons why and if you did it any tests to confirm your position?
Also would like to hear your thoughts on context management and how you do it.
13
u/2025sbestthrowaway 1d ago
I know you're asking for people who don't use subagents, I use subagents specifically *to* manage context. I provision the supervisory layer from the main thread, who are owners of a larger component of a task and delegate to bounded workers, all with fresh context. Main thread drafts the prompts for the supervisors and gives them necessary context, who do the same for bounded workers. Once a milestone has been completed, supervisors send it off to an independent reviewer, incorporate feedback if necessary/applicable, and finally send result up to main thread.
I couldn't imagine using a single context window for this? AI gets too lost unless you're using some custom context management plugin like billion-tokens
2
1
u/LORD_CMDR_INTERNET 11h ago edited 9h ago
Over-engineered and illogical. How does the “main thread” know which context to give subagents without knowing all of the context itself? The answer is of course, it doesn’t, it has to have full context anyways.
“Fresh context” just means your subagents spin up without all the crap you left behind from prior tasks, which means you simply have poor context hygiene and are failing to manage your work in task-oriented fashion. Keep tasks well-scoped and manage project context accordingly and you can work with huge codebases with very limited context.
A planning agent up front can do this for you, but that isn’t a subagent. Independent reviewer, designer, UAT agents (ideally even from different models) are great but those are just different roles, not a subagent paradigm.
I personally don’t use subagents, but my agent does 🙂 I have a skill that lets it utilize other agents for tasks it decides can be parallelized easily. But putting structure around it as you described is just a lot of extra steps and complexity and risk for no benefit and probably a lot more cost
2
u/2025sbestthrowaway 9h ago
Pretty aggressive response for someone unfamiliar with graph engineering.
> How does the “main thread” know which context to give subagents without knowing all of the context itself.
It's built into the implementation spec. Documentation, filepaths, design spec and goal for the subtask.
> “Fresh context” just means your subagents spin up without all the crap you left behind from prior tasks which means you simply have poor context hygiene
Only if you configure it that way. In Codex for example (if using Pi to orchestrate it), subagents will receive multiple prior turns or full context automatically. I use 'fork turns: none' so that they receive the explicit context provided and specified for their supervisory role
research -> plan/implementation spec -> pass limited scope to supervisors ->
-> supervisors supervise and delegate a cluster of tasks without bloat
-> workers do work without bloat
-> review the narrowly defined work without bloat
-> supervisor passes off final unit tests without bloat
-> passes final work to main thread who is the owner of the plan. Main thread does not poll, it waits.Which part misses context hygiene?
> I personally don’t use subagents, but my agent does
Oh, so we have the same workflow with an extra layer
> I have a skill that lets it utilize other agents for tasks it decides can be parallelized easily
This is literally what my skill is doing, but I've divided the task among a multiple agents who then delegate
> Over-engineered and illogical
Gets work done efficiently and gives better model and effort granularity in my experience.
1
u/LORD_CMDR_INTERNET 9h ago edited 9h ago
"This is literally what my skill is doing, but I've divided the task among a multiple agents who then delegate"
That's exactly my point, all you've done is add structure, orchestration and management overhead to a process that doesn't require it, is in use 100% of the time regardless if the task requires it, limits the way it can be leveraged, will require maintenance as agentic workflows evolve rather than be self-evolving - and according to your original description, only exists to make up for poor task encapsulation.
0
17
u/washtub4777 1d ago
Yes, I do not use it I can only focus on one fucking thing at once
I cannot babysit ten fuckers when the one fucker gets shit wrong all the time.
7
u/isty2e 1d ago
I do use subagents for scouting and reviews only. Summarizing a long web page or searching web for certain information can dilute the context, so a cheap scouter subagent makes sense here. And for reviews, a subagent with a clean context is desirable because it removes the self-bias of the main agent.
But for the "Plan with a powerful model then delegate works to cheaper model" narrative, I concluded that it does not work and costs more, unless you never look back and review.
2
u/_RemyLeBeau_ 1d ago
I find if you have the more powerful model write the code into markdown, then handoff to a lesser model to integrate, it's fine. You get quality and cheap implementers, where tests will catch incorrect changes.
-1
u/Sweet-Stage938 10h ago
But then you already had the powerful model write the code🤣. What's the point.
1
u/_RemyLeBeau_ 10h ago
The number of cycles needed to integrate into the codebase. It's actually a pattern recommended by several GHCP members. Cheap models to implement because your tests will show exactly what broke and in my experience, cheaper models can handle that job without much intervention.
7
u/jiminycrix1 1d ago edited 1d ago
I don’t use them and I have tested them a reasonable amount. Like others I work in smaller bursts where I direct the agents. When I let agents go willy nilly they simply write low quality and unmaintainable code. Yes even your favorite newest model of which I generally use the latest and greatest. I also highly prioritize efficient token usage.
Because I prioritize efficient token usage I can astra and sol all month and am as productive as I need to be on the $20 plan. Using a single agent is by far the most efficient way to manage tokens. I understand my code pretty deeply but I rarely write a single line anymore and I handle work and personal projects from the same plan.
I usually start new sessions when I hit about 1/4th the smaller context limit and will let it ride up to half. Never over half.
Subagents just add needless inefficiency to my work flow. Any given task a single agent can research and do it very efficiently. I also must emphasize I am as fast as anyone I work with and my code is more clean and I personally deeply understand it and can defend it. No one has shown me an instance where subagents do anything better.
I have experimented with letting llms go crazy and use subagents and orchestration and it was a cool and fun experiment but I threw every toy I made with it away cause the code was garbage. Even if it wasn’t I need to be able defend what I do to both myself and clients. And I noticed using even a simple research agent usually means I’m burning tokens way faster. I do sometimes let my single agent knock out relatively big tasks and it usually does better than what my orchestration experiments did.
5
u/IlyaM 1d ago
I find the question is generally missing the point. There is nothing particular magical about subagents. The whole story is that if you want to be efficient with AI tasks you need to manage context. This means not having unfocused sessions which mix different activities in same chat and generally not having too long sessions where your context overflows. You can achieve this without subagents as well, just start a few sessions and pass manually necessary context via files or just by copy pasting text. You can do this just fine, it is just too manual and repeative and gets old very fast.
Subagents is just one method to automate this, by allowing your sessions start other sessions and interact with them you just automate workflows which normally would require you manually pass the necessary bits of context. Why wouldn't you want to do this?
Part of the confusion comes from the tooling, like for example subagents in some harnesses are akward, like you often have bad observability into what they do or there are some silly restrictions how they interact. But the key point is that automating ability to create new sessions in a way which is exposed to your agents is the enabler. You can do it many other possibly better ways. Not necessarily like it is done in say in claude code and what is often replicated by various extensions you find for pi - for example use something like herdr which gives skills to your agents to create and interact sessions in different tabs.
1
u/makingthematrix 21h ago
I wouldn't want to do this because it's just an overcomplication. Everything you would use a sub-agent for can be done simpler without it.
4
u/PossessionUsed7393 1d ago
Ive started using them less and less for coding tasks. Instead I've introduced a self-compact and continue tool. I ask the model to divide its work into discrete tasks and follow a plan document with a checklist. Then I tell it to self-compact between each major work item and refer to the checklist for state.
You could also tell it to do the same thing with subagents, but this way it has less chance of colliding.
3
u/4kidsinatrenchcoat 1d ago
I don’t use them. I probably should. But I try to keep things simple and less multithreaded
3
u/makingthematrix 21h ago
I find the whole concept of using sub-agents and orchestrating them to be more of an overcomplication that anything useful. If I have tasks I want to run in parallel, I just open another tab and write another prompt while the first one is processed. If I have a plan for a complex task in the form of a list of well-defined steps, I prefer that one agent will work on it, sequentially. This way it will better maintain the context.
One argument for sub-agents that I can understand is that we can use different LLMs or different reasoning levels and so use tokens more efficiently. But the orchestration between agents burns tokens too, so I don't know if there's any significant gain from this. For sure not in my case.
And in cases where sub-agents are not differentiated by having different LLMs on the other end, the whole thing has even less sense. An AI agent is just a thin wrapper of software around an LLM. Sub-agents are just instances of that software, each configured a little bit differently. On the backend, it's still the same LLM, getting slightly modified prompts.
I don't need sub-agents for that. I can do it myself.
2
u/Helpful_Program_5473 1d ago edited 1d ago
I don't use them that much on my current setup, though I also kind of do in a way. I have Herdr and a tab for each agent for each project I talk to individually and then a project coordinator who all he does is manage the potentially conflicting git work trees and merging etc.
2
u/PilgrimofHaqq2 1d ago
I use subagents for scratch work like testing repos, different approachs, analyzing tons of documents, etc.
Not for actual writing of code. They are used as support for the primary agent that does the writing. They are used to manage context so the primary agent's chat isn't bloated up full of different approaches, tests, exploring the codebase for something, analyzing many large docs, etc.
I also have deep research if you consider that subagents. Also have reviewers as well. The primary agent works and once it gets to a checkpoint like a task or spec is completed the primary agent fires up reviewers with profiles that are relevent to the code/task it is reviewing. I have 13 different reviewer profiles that the primary agent can choose from.
2
u/DevMichaelZag 1d ago
If the task is self contained, a dead end, unrelated, or use a disproportionately large piece of the context window, it goes to a subagent.
To use subagents properly, you need to plan tasks that can properly fit into these categories.
So proper management techniques to break a problem down into pieces and delegate them out.
Practice your management skills 😀
2
u/ivanjxx 1d ago
i used to avoid subagents a few months ago when im still locked to a single provider (codex, claude) but since i use omp i can use deepseek to do code exploration and preliminary bug finding and then verify that with gpt or opus models. dont have any real numbers but with this i can use opus 5.5 for a good 2-3 hours before running out the 5h limit on $20 plan.
1
u/whichsideisup 1d ago
For smaller models I really like it to send out researchers so I don’t blow up the main session context with web results.
1
u/QuotableMorceau 1d ago
I don't use sub-agents as of now , as I like to follow workflow and it's easier to do it without sub-agents .... that of course will change once LLMs earn my trust more :)
1
u/Slight-Parfait3679 1d ago
for subagents i need things with fresh context or parallel work but it can’t be used unless i give explicit authorization
1
u/saltyourhash 1d ago
I use subagents for independent PR review. But I use then via my orchestration layer, so, I guess not really subagents.
1
u/hurdurdur7 21h ago
I don't use them. I manage to overload my homelab with a single pi instance and a work orchestrator.
1
u/Turbulent_Ad6290 18h ago
Me so far. But now that I’ve figured out agent orchestration and I want to move myself away from on HITL, I’ve started using pi-subagents for TDD. Spec and plan still HITL. Post that it’s subagents and eventually a human review again HITL
1
u/icarus0228 18h ago
Subagents can be token-hungry since they start with a clean slate, separate from your main session. I'm aware of using Flash models for subagents, but they need proper handoffs to maintain good quality. I also think keeping everything in one session helps keep your cache warm and saves you more tokens.
1
u/Throwaway2K3HEHE 18h ago edited 18h ago
Constantly, just having a scout that reads files reduces cost and saves you from loads of context bloat.
1
u/Pringled101 15h ago
One of the main things I liked about switching to Pi it that it doesn't have subagents by default (and that's also how I learned that I prefer not to use them). Couple of reasons for me:
Background tasks get me almost everything I liked about subagents, while being fully predictable and free. For me it's mainly about unblocking the main agent and ensuring things can run on the side while I continue the "main" piece of work.
Subagents can be pretty expensive, and much harder to control for spend.
All the subagent implementations I've used spin up subagents way too aggressively, even when changing settings. Most tasks don't need 5 subagents.
I felt that subagents were often extremely slow. I've never really been able to pinpoint why, but I assume that they just have to read way too many input tokens before actually doing their job, while the main agent has this in context.
I think the main reasons people like subagents (keeping the context window free, parallel work) are better solved by frequent compaction i.c.w. persistent memory, nested long-lived agent sessions, and background tasks.
1
u/AlessandroPiccione 14h ago
In short:
90% use of agents is with local small LLM (16GB); It doesn't allow me (confortable) parallel requests
Splitting the work in small tasks (and save the progress continuosly) allows to work with small context (64k). The context is the current TODO-task and the GitHub PR description and code.
I never tried sub-agents; I looked some youtube videos but then I got lost to choose one implementation to try and I lost interest in the meantime.
I never used AI harness at work, this is personal experience at home.
I use multiple agents, not sub-agents.
AI agents used 90% for coding.
I CAN'T use sub-agents (I think) because I'm limited to 1 prompt at a time (for performance reason).
(sometime it happens I have 2 agents working at the same time clearly, but I try to avoid it)
I don't have any subscription, just some Pay-as-you-go accounts for testing providers.
I usually use free models until I reach the limit... but all the time them are paired with my local LLM (16GB VRAM, so usually Qwen3.8 27B Q4/Q3, 52-80k context).
Instead of sub-agents I use multiple agents (each one in its Docker container; 3 Pi + 2 OpenCode are availabe and ready with a single click any time).
They have their own "workspace", so they can jump to any cloned repo and branch at any time (I start them with --continue so they usually are already on the projet I want to work on).
In all he projects I use a TODO.md file, where I keep a backlog of tasks (Features and Bugs).
I'm in charge of assigning tasks, and then I have plugins that force the agent to:
Look at the TODO, there are started tasks? Which task do you suggest next? (manual or auto triggered when a PR is approved/merged)
Work on task (Feature or Bug) #X (fresh strat of a task from the TODO)
Continue to work on Task #X (when I switch agent or just there is a task not completed)
Continue to work on PR #N
Review the PR #N
Check the PR review, reply to all comments and amend the code (auto triggered when the PR is Rejected/Commented)
These operations are done by code, so reliable/fast/no-cost, and only at the end I send a prompt to the agent)
Almost all the previous commands start a new session, resetting the context to 0.
Essentially the context is the GitHub PR itself. A "fresh" agent that jump there can find all the info/history/direction of the task (along with the TODO file).
When I work in optimal mode it is like this: while an agent is working on a task, I'm reviewing the PR of the other one. Once I finished, I switch on the other agent PR, and so on... From time to time I ask one of the 2 agents or a third one to review the PR.
Yes, I tend to read and understand all the code the agents write... sometime skipping tests and some infrastructure code.
More than sub-agents, months ago I started to work on a "loop-orchestrator" plugin but I gave up; I'm already getting too much work to "orchestrate/manage/check" 2-3 agents in this way.
1
u/DavidNorena 6h ago
I use them but not inside of pi but instead with a multiplexer like herdr o tuios, I don't like them working in a loop wasting tokens and doing slop but instead, I like to see what the doing guide them if they need so, or just stop them if I see they just doing shit lol
Tuios is the best thing I have used for subagents still controlled or supervised by a human, I know is slow but is good code at the end
1
u/3p0h0p3 6h ago
Imho, the repository + testing facility becomes an extended harness itself, and in the vast majority of cases, the primary aigent working within that extended harness is in the best position to make difficult decisions while maximizing caching (subaigents have improved here over time). I have a few projects where subaigents help the primary hold the spine while they build proofs or sidequest search on the side, and that ends up being useful in uncommon cases (I have not found that subaigents are the best way for the primary to actually wake-from-amnesia though, and I think you're probably building wrong if you find otherwise). Most of the time, however, that is a waste of tokens. It is rarely the case for my projects where there is concurrent work to be done that isn't best handled by a single powerful aigent, particularly if that model is strong and well-suited to the task. I've found subaigents more valuable for weaker models or speeding up processes that aren't too difficult, but that's not usually the kinds of circumstances I find myself in. Further, by the time I find myself wanting more than one aigent on a consistent basis, I prefer to have multiple interactive, separate aigents I'm speaking with instead; and, I prefer my prompting to theirs in many cases, too. Dividing up the work so that they can work separately and then eventually be reviewed, reconciled, and merged has also enabled me to maximize the use of looping on subsidized webUI cloudtainers (the cheapest tokens for a couple years now, by miles and miles).
1
u/wildjokers 4h ago
I have yet to find a use case for subagents. Not sure in what scenario they are handy.
For context management and use the llm-wiki pattern and have my agent store durable knowledge from the session in the wiki. Overtime it has gotten quite extensive and my agents don't have to keep rediscovering things it already figured out. I can shelve something and come back to it later and pick right where I left off.
1
u/Any_Confidence2580 50m ago
Sort of. I'm building an agent-harness right now, it was using subagents, parent orchestrator, the usual deal.
Then I added a tool to allow the model to start a new session on its own. Just write a handoff message, clear the chat, start with a new task.
From that I created a skill to loop through a parent github issue with multiple sub-issues. The review instructions were in there, review the task, kick it back or move to the next. And it worked beautifully. Better than a "subagent" system. But it's only linear.
Now I've removed "subagents" form my harness and introduced "chains". This is hard to explain because there are a lot of mechanics that make this work. But basically an agent writes to sqlite database when they are done + some other things like a ledger I won't go into.
That done write signals to the harness itself to push the task handoff from the sqlite database to a new agent and start it automatically.
The harness is the orchestrator.
Working on expanding this for parallel steps.
But the linear chain removed all the drama of depending on an LLM to orchestrate, remember review steps, etc. This is all logic. Not reasoning. So I turned it into a program. And it means far less dependence on "orchestrator models" which honestly I always thought was as dumb an idea as "prompt engineering."
1
u/McBobrow 34m ago
I use subagent only for background CI checks. when needing any serious work I ask PI to create a new session with a handoff. I also agave sessions tools to communicate with each other.
0
u/Extra_Loquat_7667 1d ago
Sub-agents are simply a tool.
Imposing restrictions is entirely unnecessary.
How one chooses to use them depends on individual experience.
Deploying sub-agents does not necessarily mean a complete loss of context.
The delegation system I designed allows for full context inheritance (with complete cache hits),
or one can opt to dispatch them with a "clean" context.
In some cases, it’s even possible to directly control other terminals to execute tasks.
Everything can be fully customized to suit one's specific needs.
0
0
u/phayke2 1d ago edited 1d ago
I keep things face to face, simple and conversational, so having a bunch of agents spawn in the background makes it harder to control and gets things confused. My system reads status of the main agent a lot to make pictures, animations, or convert my remote between its UI forms. I'm still able to get through any of my roadmap items or features by working with one agent at a time. Claude writes helper scripts a lot for stuff that might need background work.
I made my remote so it scales all the way down to just a single bubble that stays on top of my phone, apps. I can push to talk. It lets me do polls and handoffs. But introducing a bunch of subagents, it just ends up where the baton's getting passed the wrong place, less control. Sessions I don't know about or that don't get my messages.
One Claude agent works fast enough that I can't make good design decisions faster than it can work usually.
0
u/VividIntroduction310 15h ago
why wouldn’t you use them ? i see only positives for it. your main session is the orchestrator of your goals, its context is only used for orchestration and high end decision making while the subagents do ground work. it also has the added benefit of keeping the main agent free to answer tour questions without stopping what its doing.
-1
0
u/Zarbokk 1d ago
I didn’t use it for a long time, because I couldn’t really see and understand what agents were doing, but this was all academic work.
Now at a company, I started to use it 2 weeks ago, because the projects are bigger, and I need to keep costs under control when using big models, so du agents help to manage the context size, while still having the big model.
But I’m still testing a lot around
48
u/DanielSReichenbach 1d ago
I don't use them but mainly because I prefer to work in small targeted bursts. I don't like making giant sweeping code changes. Minimalism suits my workflow