How Sub-Agents Work

14 January 2026•4 min read

When orchestration breaks a complex task into pieces, those pieces need workers to execute them. That's where sub-agents come in—specialized, ephemeral workers that your main agent spawns to handle specific subtasks. Each sub-agent focuses on one piece of the puzzle, works independently in its own session, and reports results back to the coordinator.

Sub-agents are intentionally lightweight. They're created for a specific purpose, given only the context they need, and cleaned up after they complete their work. This focused design makes them efficient and prevents the confusion that might arise if they tried to maintain broader context.

Sub-Agent Characteristics

Sub-agents have distinct characteristics that differentiate them from your main agent. Understanding these helps explain why orchestration works the way it does.

Key characteristics of sub-agents:

Focused - Each sub-agent handles exactly one subtask. It doesn't try to do more than assigned.
Ephemeral - Sub-agents are created on demand and disposed after completion. They don't persist between orchestration runs.
Isolated - Each sub-agent runs in its own session (browser or computer), separate from other sub-agents.
Lean - Sub-agents receive minimal context—just what they need for their specific task, not the full history of your conversation.

This design enables true parallel execution. Because sub-agents are isolated, multiple can run simultaneously without interfering with each other.

How Sub-Agents Are Created

When your main agent's orchestration plan includes subtasks, sub-agents are spawned to handle them. The creation process ensures each sub-agent has what it needs without excess baggage.

The spawning process:

The orchestration plan identifies a subtask that's ready for execution (no dependencies pending)
A sub-agent is created with focused instructions for that specific subtask
The sub-agent inherits minimal identity from your main agent—enough to maintain consistency
A session (browser or computer) is created for the sub-agent to work in
The sub-agent executes its assigned work
Results are reported back to the main agent for aggregation

From your perspective, this happens automatically. You see subtasks appear in the plan and progress through completion, but you don't need to manage the sub-agents directly.

Execution Types

Different subtasks require different execution environments. Sub-agents can work in three types of sessions, each suited to different kinds of work.

The execution types are:

Browser - For web navigation, scraping, form filling, and any task that requires interacting with live websites
Computer - For code execution, file generation, data analysis, and any task that requires running Python or creating files
Internal - For database searches, internal tool calls, and tasks that use native O-mega capabilities without external sessions

The main agent determines the appropriate execution type when planning the task. A subtask involving web research gets a browser sub-agent; a subtask involving data processing gets a computer sub-agent.

Parallel Execution

The real power of sub-agents is their ability to work simultaneously. While one sub-agent researches pricing information, another can research feature comparisons, and a third can process data you've already collected.

Parallel execution in action:

Main Agent
├── Sub-Agent A → Browser Session 1 (researching competitors)
├── Sub-Agent B → Browser Session 2 (gathering pricing)
└── Sub-Agent C → Computer Session (analyzing collected data)

This parallelism dramatically speeds up complex tasks. What might take 30 minutes if done sequentially can often complete in 10 minutes when work is distributed across parallel workers.

The main agent coordinates this parallel execution, tracking which subtasks are complete and ensuring dependent work doesn't start until its prerequisites finish.

Timeouts and Limits

To prevent runaway execution and ensure reliable operation, sub-agents operate within defined boundaries.

Built-in safeguards include:

Maximum duration - Each subtask has a default timeout of 30 minutes
Maximum steps - Browser sub-agents are limited to 100 steps per task
Forced timeout - Sessions that hang or become unresponsive are terminated

If a sub-agent fails—whether from timeout, error, or inability to complete the task—the main agent can respond appropriately. It might dispatch a replacement sub-agent with a modified approach, mark the subtask as failed and proceed with available results, or adjust the plan to work around the obstacle.

These safeguards ensure that orchestration remains predictable and doesn't consume resources indefinitely on problematic subtasks.