Most AI tooling talks about "agents" as if they are magic. In practice, the interesting part is not the agent. It is the orchestration layer: who gets to do what, when work is delegated, how permissions are enforced, and how results come back.
That is where OpenCode gets interesting.
OpenCode does not treat agents as loose prompts glued onto a model. It treats them as a runtime system. Native agents are defined in code. File-based agents are loaded from Markdown. Both are merged into the same registry, then executed through the same prompt, permission, and session pipeline.
At the center of that system is the task tool.
When one agent delegates work, it does not simply "call another prompt." It creates or resumes a child session, selects a subagent, passes a scoped instruction, and receives a result back in a structured form. That makes delegation session-based, resumable, and inspectable.
That matters because orchestration is more than routing. It is control.
Here is the OpenCode model:
- Agents live in a shared runtime registry.
- Permissions decide which tools and delegation targets are actually available.
- Prompts shape behavior, but permissions enforce capability.
- Delegation happens through child sessions, not inline prompt chaining.
- The parent agent stays in control while subagents do isolated work.
One of the clearest examples is our Agent Orchestrator, which is intentionally restricted: it is a primary agent denied direct execution tools like edit, bash, read, glob, and grep. It is allowed to use task, skills, and todo management—in other words, it is designed to think in terms of routing and coordination, not direct execution.
That design forces the right behavior.
The orchestrator does not research on its own. It does not implement on its own. It does not document on its own. It classifies the request, decides whether work should be split, chooses the right specialist, and delegates.
So who are "we" when we use it?
We are not a single monolithic agent. We are a coordinated system of specialists.
The orchestrator hands work to the right subagent for the job:
- exploration agents for codebase discovery and tracing
- librarian agents for reference gathering and documentation lookup
- oracle-style agents for higher-order reasoning and tradeoff analysis
- writer agents for final drafting, rewriting, and polish
- general agents for broader multi-step execution
That is the real value of orchestration. It turns "an AI assistant" into an operating model.
OpenCode also gets an important architectural detail right: permissions are the control plane. The runtime filters tools before the model even sees them, then checks permissions again at execution time. That means orchestration is not based on trust alone. It is bounded by policy.
The result is a cleaner division of labor:
-
orchestratorroutes -
exploreandlibrarianresearch -
build,general,dev, andfixerimplement -
writerwrites
And because delegated work runs in child sessions, context does not sprawl uncontrollably across every step. The parent can coordinate the workflow without inheriting all the noise of every subtask.
That is why agent orchestration in OpenCode feels less like prompt engineering and more like systems design.
It is not about creating one super-agent. It is about building a disciplined network of agents with clear roles, bounded permissions, and explicit delegation paths.
That is how we use the Agent Orchestrator: as the control layer that decides which specialist should do the work, how tasks should be split, when subtasks should run in parallel, and how results should be recombined into something useful for the user.
That model is more durable than the "one agent does everything" pattern. It is easier to reason about, easier to extend, and safer to operate.
And as agentic systems mature, I think that distinction will matter more and more.
If the first wave of AI products was about generating outputs, the next wave will be about coordinating capabilities.
OpenCode shows what that can look like in practice.
References:
Top comments (0)