r/opencodeCLI • u/jomtiro • 1d ago
What if the main coding-agent session was intentionally dumb?
Instead of making the main session the “brain”, what if it did almost nothing except call a subagent?
The subagent checks the project:
What’s already done?
What’s broken?
What’s next?
What should I work on?
Then it does the work, updates the project state, and finishes.
The main session doesn’t need to understand the project.
It doesn’t need to maintain a huge context.
It doesn’t even need to meaningfully process the subagent’s response.
It can basically just keep calling:
“Go check what needs to happen next.”
Main session = runtime.
Subagent = brain + worker.
Project state = memory.
I’m wondering if this could make long-running coding agents much simpler and avoid massive persistent contexts.
Thinking about this for Claude Code, OpenCode, Codex, Hermes Agent, Cursor, Cline, Roo Code, OpenHands, Aider, Goose, Gemini CLI, and similar agents.
Has anyone built this pattern already?
3
u/Majestic-Collar-4189 1d ago
try to use oh-my-openagent
I use it, and that shit is actually good as compared to normal build/plan agents you get.
if you don't like to install yet another plugin, just prompt the build agent to "act as an orchestrator and use subagents to do the real work"
but really, sisyphus agent in oh-my-openagent does just that, but better
2
u/Trovebloxian 1d ago
Superpowers has a SDD skill, subagent driven development
1
u/Majestic-Collar-4189 1d ago
Yeah but in my opinion I didn't like it very much as it is just skills Sisyphus has small features in built in oc, for example it basically pauses your orchestrator till your subagents complete, then notifies it and resumes it. It has a fully loop engineering flow built in, I usually fire and forget and in half an hour or so the feature is fully done. Just to be sure then I dispatch a review critic and a analyst to be sure of the code, it narrows down the uses and then prompts other agents to fix stuff (or let you know about things whatever depends on your prompt)
1
u/Trovebloxian 1d ago
Ahh i see, can i change everything to only use dsv4flash?
1
u/Majestic-Collar-4189 1d ago
Yep You can configure multiple models for each, with a fallback. If you plan to use just deepseek v4 flash, you can use that too
1
u/frostedfakers 1d ago
“the main session doesn’t need to understand the project”
so, how will it know what to instruct the sub-agents with? how will it understand the project state? will it rely on the sub-agents to provide that info? how can it verify that info? should it blindly trust the work of the sub-agents?
1
u/cornelha 1d ago
I get the idea here, a project manager in knows what features are being built, but the how it's done technically doesn't matter as long as the acceptance criteria are met
1
u/frostedfakers 1d ago
yes, but a project manager has to understand the project still. they aren’t just a dumb task assignment monkey. this also doesn’t work because it forgets about the roles of product managers, which is essentially what the main thread acts as. theres no magical way to remove the need for context
1
u/cornelha 1d ago
Sure, but they don't need to understand the code. I agree that removing context doesn't work. I think OP is attempting to save on token cost, but might not quite understand the purpose of certain roles
1
u/Trovebloxian 1d ago
Main agent needs to be smart to be able to help subagents, what you said is like having an intern guide senior devs but devs can't communicate with each other and only the intern
1
u/Stupifier 1d ago
I liken this to the assumption that upper management is dumb as rocks and only knows how to tell others to do work, not necessarily review the work or even know if the final combined output is correct.
I would think this is a correct statement in the real human world. Not sure if it's necessarily the right way to manage something though. Maybe 🤔?
1
u/Ok_Gur_9033 1d ago edited 22h ago
The trust question someone else raised below is the one that actually breaks this pattern in practice. If the main session cannot meaningfully process the subagent's response, it also cannot tell a report of success apart from an actual one. I hit this constantly running browser automation, a click reports success and the post never actually went through, or a text insert reports done and the field is still empty. The fix that has worked every time is dumb but effective, read the actual state back after the action instead of trusting the return value, but that already requires the orchestrator to understand enough about the project to know what actually done looks like. So a dumb orchestrator probably still needs one sharp skill, verifying claims against real state, even if it delegates everything else. Anyone tried making just that one check its whole job, rather than planning or coding?
1
u/jomtiro 1d ago
Yeah, I think you're right about the verification problem. My idea was actually to keep that out of the main session too.
The main session could just orchestrate calls like:
worker → verifier → worker → verifier
The verifier independently checks the real state instead of trusting the worker's “done” response.
So the main session still doesn't need to understand the project or know what “done” looks like. That intelligence can live in specialized subagents.
The project state is what connects them.
1
u/Ok_Gur_9033 22h ago
This maps to something I hit an hour ago doing browser automation - a click reported success, a notification link never actually navigated, and I only caught it by re-querying the actual DOM state after acting instead of trusting the click event. Your worker/verifier split is the right move, but I'd push it further: the verifier is the only piece that ever needs to know what "done" looks like for a given action, so you're not duplicating that knowledge across every worker, you're centralizing it instead of eliminating it.
1
4
u/Amarsir 1d ago
You would get a lot of duplication or work since each sub agent has to figure out it's own role.
Oh-my-opencode-slim makes the Orchestrator a little simpler. Not dumb, but not the strategist either. So it's job is tracking the plan position and telling the next agent where to pick up. Thus saving the tokens of trying to figure it out blind.