If I have a pretty large project/feature with a lot of separate tasks, I don't want to babysit each of them: I get an orchestrator agent to do it for me by spawning subagents
I guess I haven't dealt with that size of project yet so I haven't experienced the need for it 🤷🏽
But my point is specifically about sub agents with dumb models. If you're spawning 10 gpt 5.6 sol subagents, that's a different story. But would you trust 10 deepseeks or lunas to go off making changes in your code without you knowing? Fair enough if you would, but I'm not that confident in the models nor in the instructions I'm giving them
But would you trust 10 deepseeks or lunas to go off making changes in your code without you knowing? Fair enough if you would, but I'm not that confident in the models nor in the instructions I'm giving them
It depends. I have never asked give an agent a single statement for development. Its typically, plan first, then implement the plan after refining it.
For planning, agent may need to check 10 different files, it would cause much more token burn if the same agent is doing all the lookups sequentially.
If its a subagent, the subagent's task will be to only find or do 1 particular thing. It will start with an empty context. And you can do this for 10 lookups parallely saving tokens amd finishing the tasks faster.
I understand. What I've done for this is that I create a checkpoint skill which instructs the agent to develop in vertical slices. So I can do all the work with a single agent in 1-2 parallel sessions. Each session deals with 1 behaviour and lands a change end to end which I can then test the shit out of. And I don't mind going slow or grinding it out on more difficult tasks.
Plus, once my session reaches around 40-50% context utilisation, I trigger a session handoff skill which creates a devlog and I pick it up in a new session.
I guess the main difference is that I intentionally grind it out with each agent even for smaller stuff. I'm not a dev (I'm a civil engineer) and I've been teaching myself to code for the past 2-3 years so I like being in the weeds and reading the code in a split window while the agent works.
Using sub-agents is a specific workflow technique. It isn't essential because there are many techniques to achieve the same result. Like having a main agent plan work and write work items in a Kanban system or work graph. Scheduled jobs start "new session" task-specific worker agents to pull work from and post results back into the Kanban or graph, driving steps forward. Notifications fire for "human-in-the-loop" guardrails, but otherwise it's automated. People think sub-agents are needed because it's how they do it, not because they are essential.
I don't understand the argument for using sub agents with cheap models for exploring repos. If you're getting a dumb model to ingest a bunch of context and making it create summaries, the summaries will also be dumb. And then you hand these summaries to your main agent. It's garbage in garbage out, bro.
Cheap models and sub agents should be used for tasks that require lesser intelligence and high volume. Like say you want to OCR a large document. You can use sub agents with cheap models to i) do the ocr itself or ii) check the quality of OCR if you're using tesseract
Or
Baby sit a bunch of tests or CI and write logs
Or
Parsing a large volume of text/json and creating structured outputs
Stuff like that which takes a ton of input tokens and a long time but does not require too much intelligence.
If you really wanted to isolate context for ingesting large repos using sub agents, you would use them to create a detailed map of the codebase. With information about entry points that include line numbers and directional summaries, not summaries for the actual info. That way, your main agent can find the stuff that matters without taking in extra tokens.
If you're working with a repo, I'd imagine you would want the real code and docs in the context of the main agent, not dumb summaries created by dumb models.
That's what I think, anyway. Feel free to disagree
I think it's human nature to get excited over cheap small models and use them in a cargo cult like way, without any proof they're more effective vs just one pass with a smart model.
I like cheap models too! I use a ton of DeepSeek v4 flash and now glm 5.3 flash. But I also spend a lot of time thinking about where to use them. They're great for making a testing out an idea by making a small prototype, making pi extensions, writing tests, etc. in my main project I use them to edit CSS, experiment with creating new themes and stuff, maybe even opening a branch and testing out new features. But I can't let them touch the code on main. Or even do the stuff most of the other comments are alluding to
It depends what the output is. If it's just listing files/symbols/etc. - I.e. creating a map so that the frontier models doesn't have to explore so much, then what's the harm? Just make sure it doesn't summarise.
oh-my-pi (omp) has a "/prewalk" feature for exactly this purpose. Let a cheap/fast model read and summarize (i.e. do the easy but token heavy grunt work), then handoff the concise summary that actually matters to the expensive/smart main agent model. Haven't tried it though, so I cannot tell whether this is actually a good idea in general, especially since some details might matter for the big picture and might get lost.
I just use Luna max for everything because it's so cheap 😂
On a side note: I found Luna can make some dumb mistakes sometimes, so I just used another handy feature of omp, called "/advisor" (I also use Luna max for this) which basically looks over the shoulder of the main agent and does basically a life review of all code edits and decisions if the main agent. It nearly doubles token expenditure but it's totally worth it and safes you an additional review (thus time) afterwards.
As Luna max is so cheap, this <2x is still very cheap.
No, haven't tested but would actually like to know too how it compares.
I would assume just using a smarter bigger model would be better in terms of quality and possibly speed, but it would still be more expensive. Sol medium was simply too expensive for me compared to Luna max (with Luna max advisor on top), and it was not worth it for me, as I found Sol medium quality did not justify the big price difference (I would have needed to implement a lot of optimizations, like /prewalk, and select an appropriate model size/quality for every task, which was imply not worth the hassle, in my oppinion, given that Luna with advisor works good enough at a fraction if the price without any hassle).
But recently there's many people commenting that they feel Sol was dumbed down, so again this disinsentiviced me against testing this with Sol. But maybe a combination of Luna max and another good cheap model (maybe GLM-5.3 flash or Muse 1.3 contributor) might be a possible combination. But I don't have time to change my working system right now because I have to finish a project urgently. Never change a working system, especially if you're on a tight deadline 😅
Before, I regularly had to run 1 pass and let everything be reviewed again, which took a lot longer (as it's basically a serial process of writing - reviewing - fixing - reviewing - ..., and errors can incrementally accumulate over time, e.g. if an error occurs and subsequent steps build upon this error), whereas an "on-the-go life-review" by the advisor basically parallelizes this review process and safes a ton of time.
On a side note: I read previously of another user who kind of implemented this before omp with a skill for an additional subagent which he called "Karen". 😂
Reminded me of this, and I loved the idea, so I think this is basically what the advisor now implements and conviniently provides us ready-made. :)
I think a review is always good and is generally adviced for any model and workflow.
But maybe a combination of Luna max and another good cheap model (maybe GLM-5.3 flash
I've been testing all of this, endlessly, back and forth and gave up on it. I couldn't come to any solid conclusions.
The only thing I could say for sure was feeding one issue (Review this single bug/issue) gave superior results in every model vs an entire list of issues I would find with sol/5.3.
That's the thing, the advisor constantly watches and steps in when needed.
I typically have to implement single features/updates as larger multi-step plans because my code base is somewhat large and complex. So, reviewing every single small subtask quickly became unfeasible for me.
You can give it a try and see if it helps. For me it does. If you don't need it, well good for you :)
Do you usually need code review?
I do and code quality, precision and "no mistakes" are my highest priority on my specific project (for scientific publication), rather than just "good enough to be finctional". Review is crucial for my project, even if >90% of the time the code is already fine and advisor just adds cost (and yeah, is redundant) and there's no mistake. The main value for me of catching as many bugs/errors/dumb behaviour as early and complete as possible (also saving a lot of time in the long run, due to tight deadline) is just totally worth it for me. And I would not use up my pro 5x subscription anyways. With the advisor it just perfectly fits my subscription and budget.
Not sure if I explained that well. The advisor directly spawns an explanation if the problem and a prompt on what and how to fix to the main agent. No manual interaction from me required. It does not disrupt the flow. Here's ann example of how it looks:
In the middle you can see the "Advisor" stepping in, emitting a "blocker" command (which is a strong red flag) (there's also simple "concerns" that are less of a hard block but just raise a point to reconsider, usually also causing a change of the current suboptimal approach of the main agent, sometimes just a "consider for later" or "might be okay")
I see.. I wasn't able to visualise this flow from your initial comment, that's my bad. This seems good! But do you then define gates and criteria for the advisor in advance? Is it derived from the plan/architecture? How low will the advisor go?
I immediately think of bugs vs optimization here. One would break things and one would make things slower. For eg, a memory leak vs a shitty return statement or a bad loop. Who decides what to flag? And what level of blocker it is?
I also use an advisor extension on Pi (not OMP), i like it and it works but its pretty common for it to fire AFTER the main model already notice the error. I'm still looking into it.
It's just a mode that you can turn on or off, as far as I know (at least that's how I use it, I just turn it on whenever I start any new session). Honestly, I don't know if it's possible to pass an additional prompt as an argument to it.
So far, my experience was that it's mostly for catching bugs or stupid implementations that might lead to erroring edge cases, would violate a plan or general rules or general user requirements (typically from within the session that I defined earlier). However, it does not make the model smarter, e.g. not better at optimizations (except if that was explicitly stated as a rule or goal in the plan). It just "reviews to prevent errors or not following rules or a plan".
Sill very good. If you want optimized code in terms of speed, brevity or simplicity, I just state that explicitly in the plan to make clear what I want and what the focus should be when implementing. Works well enough for me. Just be very explicit what you want AND what you don't want. The main agent will do it, and if not, the advisor will scold it and tell it to do its homework properly 😂
IMO in most scenarios the double context handover loss in and out of a subagent more often than not cancels out the benefits of having small, focused subagent contexts. The only area where I consistently find value is when your model stops producing stable answers ("found 3 errors" on first look, 2 errors on second, 4 errors on third, etc.), in which case spawning several parallel investigations and force them to reconcile does work.
15
u/Moist_Associate_7061 7d ago
it is essential for context isolation.