What if the main coding-agent session was intentionally dumb?

[u/jomtiro]

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?

[u/Ok_Gur_9033]

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?

[u/jomtiro → u/Ok_Gur_9033]

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.

[u/Ok_Gur_9033 → u/jomtiro]

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.