anomalyco
Feature request: let subagents inherit context
Description
Add a boolean parameter "inherit_context" to "task" tool -- when true, the subagent thread starts with a fork of the main thread instead of an empty one
Optional, fallback to per-agent default if specified, false otherwise
Motivation
Currently, subagents only get the prompt from the primary agent, so it has to be a self-contained description of the task
With a fork, the primary agent doesn't have to perfectly summarize the relevant portion of the context -- fewer output tokens, smaller chance of misunderstanding
e.g. if the main agent implemented a feature and wants the subagent to write some tests, the task prompt doesn't need to contain the feature description, expected behaviour, relevant files etc., "now add tests" is enough
I don't think this is a good way to implement forking. The task tool already has a double classification happening in a single pass, asking it to also choose whether to inherit context is only going to make the Task tool less effective than it already is, and it basically never works properly without direct prompting as it is.
On top of that you have the issue of the subagent having a different tool/system/model setup than the main agent that generated the context, and mixing context from one model to another is always going to produce degraded results. No model improvements will fix that problem.
I would say solve forking at the main agent level, subagents are already fragile enough for the places they are useful, making them a swiss army knife will just make them useless.
double classification
True; maybe instead of adding a parameter to the tool, only add a sub-agent property? I.e. specified agents always inherit the full context, and tool parameters stay the same, so that in the worst case at least nothing breaks
never works properly without direct prompting
I just tested an extreme case -- prompted a read-only primary agent to do an edit: it explored the codebase and then launched about 8 sub-agents; the only problem was exactly the context -- every sub-agent starts by reading the same set of files on its own, which took a while with gpt-5-mini-high
I think if this feature does end up improving accuracy/speed, the rest is a matter of changing the system propmt so that the primary agent is more aggressive with the tool.
mixing context ... is always going to produce degraded results
There is some evidence that switching models between turns actually improves performance: https://www.swebench.com/SWE-bench/blog/2025/08/19/mini-roulette/
I imagine system prompt change between turns is more of a problem, but that's how primary agents work right now anyway, seems to work fine. Maybe something like the plan mode system reminder might help? I.e. you are $subagent; given conversation above between user and $primary, ...
solve forking
I'd say these two are more or less orthogonal; being able to fork the main thread manually is more important IMHO, but I don't see a reason not to have both
subagents are already fragile
My bet is that this agentic "telephone game" flow is exactly the reason they are fragile to the point of being useless
@anuramat, I think you'll find that the default tools in any of these AI client app are a MVP for something like developing the app itself.
Specialized tools, via MCP, such as https://github.com/eyaltoledano/claude-task-master, will be how non-trivial use cases are handled.
You are correct:
My bet is that this agentic "telephone game" flow is exactly the reason they are fragile to the point of being useless
If you don't have core tools like tasks and memory that are fit for (your) purpose, then non-trivial subagents get fragile
For memory, try looking at:
- https://github.com/campfirein/cipher and
- https://github.com/steveyegge/beads
Hopefully that makes your subagent experience in OC less brittle?
@taqtiqa-mark both of these if I understand correctly require the subagent to figure out that he needs to run something; you could add ALWAYS run ... to the prompt, but that sounds like a hack -- hardcoded context injection (the way I see it) would be preferable
also, such "subagents with inherited context" are basically equivalent to the SlashCommand tool in claude code, so maybe that could be implemeneted instead?
I think the problem is that even the credible uses for subagents that I've seen is just a hacky workaround for an inability to have properly structured context. And the solutions around this are either obtusely complicated or don't even make sense.
For example I have a subagent called codebase-locator. It does nothing but search for line numbers and compiles a summary files and lines grouped by keyword in the resulting output. With a fast model like kimi or qwen, it rips through the codebase and scopes the amount of searching the main agent has to do.
But why do I have to call a subagent to get this context in the first place. This is trivial to write, it's just a formatted result of grepping. This could easily be built, and likely cacheable, without ever involving an LLM. And it could easily be executed as a shell command to fill the context window.
In other words, I'd love to see more tools that feed the LLM, rather than more failed attempts to drive/steer the model into multi-turn madness.
I think the problem is that even the credible uses for subagents that I've seen is just a hacky workaround for an inability to have properly structured context.
@Cluster444, I think all the typical workflows would be difficult to implement in OpenCode (as it stands) without a subagent. Looking at apps that implement specific/specialized workflows as a MCP server, and they branch to distinct agents. There may be some other more suited primitive that will emerge, but right now it seems we are "stuck with the army we have".
For example I have a subagent called codebase-locator. ...
Yes, passing in tree-sitter context with the agent Context-Text would be better....
... why do I have to call a subagent to get this context in the first place
Because OC is fresh paint, and some primitives are broken, like an overloaded and implicit @, passing in a list of files as part of the system-prompt, etc., etc.
Or primitives just missing, like /add ... and /drop ....
But, progress isn't easy, see #1990 and #2965 - any input there one way or another is welcome.
@taqtiqa-mark both of these if I understand correctly require the subagent to figure out that he needs to run something
@anuramat, I believe the LLM pretty much figures that out (YMMV). Just be sure to deactivate the default Task, Memory, etc. and the existing code should improve.
Of course to get the most benefit your (sub)agent should conduct its self like it knows about the additional functionality (just behave like a function is there and see how far you get). If the LLM isn't able to work out from the context and prompt what it should use, an intermediate position is to try a different model, and/or add a one liner to the relevant prompt that ignores the hints:
"We track work in Beads instead of <whatever-you-currently-do>. Run \`bd quickstart\` to see how."
More drastically, try a different vendor
@Cluster444 have you tried (in order):
- https://github.com/oraios/serena (not yet for polygot repos, see https://github.com/oraios/serena/issues/208#issuecomment-3393237189)
- https://github.com/wrale/mcp-server-tree-sitter
- https://github.com/nendotools/tree-sitter-mcp
In other words, I'd love to see more tools that feed the LLM, rather than more failed attempts to drive/steer the model into multi-turn madness.
@Cluster444, IIUC, current models are all in the "project-then-recurse" class of algorithms, so until some one comes up with a foundation model outside of that class, I believe you will always get better results by (intelligently) using iteration.
It is early days, so most use of iteration does broken things like Ask the user this list at least 2-3 times, until they say out of scope. :) but that is just because this tech is brand shining new and not well understood.
In other words, I'd love to see more tools that feed the LLM, rather than more failed attempts to drive/steer the model into multi-turn madness.
@Cluster444, IIUC, current models are all in the "project-then-recurse" class of algorithms, so until some one comes up with a foundation model outside of that class, I believe you will always get better results by (intelligently) using iteration.
Not sure I understand the term project-then-recurse. But no I consider this fundamentally a flawed concept. Steering is one of the worst situations to have to been in for an LLM. The more you try to steer, the more bad tokens you have that contributes to more steering. And tool calling is a form of steering, it's basically letting the model self-drive, and they are hilariously awful at it.
The only solution at the moment in opencode is undo & reprompt. Which is fine with fast models, but few are. The longer term solution is to not leave content engineering up to the model.
Bumping this feature. I'd say it's loosely analogous to "fork vs spawn" mechanics in software.
Currently the only mechanism is to "spawn" a subagent with some limited set of context.
Consider this common pattern:
-
An agent (primary build in opencode's caseS) spends 50 turns and builds ~50k context window to digest a codebase, current work, etc.
-
Current is to either then do some subtask with the main agent until context is exhausted. Then one must compact -> recontextualize -> repeat. Or to spawn a subagent, keeping the "main thread" unencumbered with sub-task specific work. The subagent must do it's own recontextualization before proceeding with the work.
So dispatching a subagent via either "fork" or "spawn" modes, at the very least, has strong utility for this speciifc use-case, which in my experience with large projects, would be a huge time-saver and increase accuracy.
There are many other use-cases for forked agents (best-of-N with worktrees, parallel feature builds, builder-reviewer patterns, etc). All benefit from a "baseline agent builds shared global context -> dispatch task specific subagents".
@adrianog to my knowledge they don't but I haven't dived into source for Codex