You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Allow the LLM to create subagents at runtime via the task tool #47751
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem
Subagents currently have to be defined before a session starts — config files, agent directories, etc. When the model hits a job none of the existing agents fit (e.g. "diff these two PDFs and report only semantic changes"), it either stretches a generic agent like general or has to stop and ask the user to write config and restart. That breaks the flow for one-off specialized work.
Proposal
Let the task tool accept an inline agent definition alongside the prompt, e.g.:
task(
description: "review pdfs",
prompt: "Compare a.pdf and b.pdf for meaningful changes",
runtime_agent: {
name: "pdf-reviewer",
description: "Specialized PDF review agent",
prompt: "You are a specialized PDF comparison agent...",
tools: { read: true, grep: true }
}
)
The agent would be registered in-memory in the agent service and spawned as a normal child session — no restart, no files written to disk. Rules I'd keep:
the tools map acts as a strict allowlist (everything denied, then the listed tools allowed)
permissions derived the same way as for static subagents
Benefits
One-off specialist agents on demand, mid-conversation. Complements file-based agents (which stay the right choice for recurring/team conventions) with no file-system side effects from the LLM.
I have a working implementation (~250 lines in agent.ts + task.ts) with a test suite and a live e2e run against a server built from source. Happy to open a PR if there's interest.
To restate it: you'd like the model to define a one-off subagent inline (name, description, system prompt and a strict tool allowlist) when it spawns a subagent. The agent would live only in memory and run as a normal child session, with no restart and no config files written.
One note for v2 (@opencode/cli, the dev branch): the tool is now called subagent, not task (packages/core/src/tool/plugin/subagent.ts), and its agent input must name an agent that is already registered. If your implementation targets agent.ts/task.ts, it is probably based on v1's code, so a PR would need to target v2's packages/core. You may want to wait for a maintainer to say whether they're interested before porting it.
Activity
opencodejr commentedon Oct 28, 2026
Thanks for the detailed proposal, @Vamshi9415!
To restate it: you'd like the model to define a one-off subagent inline (name, description, system prompt and a strict tool allowlist) when it spawns a subagent. The agent would live only in memory and run as a normal child session, with no restart and no config files written.
One note for v2 (
@opencode/cli, thedevbranch): the tool is now calledsubagent, nottask(packages/core/src/tool/plugin/subagent.ts), and itsagentinput must name an agent that is already registered. If your implementation targetsagent.ts/task.ts, it is probably based on v1's code, so a PR would need to target v2'spackages/core. You may want to wait for a maintainer to say whether they're interested before porting it.Maintainers will consider the request.