Agent Delegation 101: How Nova OS Decides Which Agent Gets the Job
When a request arrives in Nova OS, "routing" is only the first decision. For complex tasks, routing selects a Director agent — and then the Director delegates to specialists. For requests that cross domain boundaries, delegation may pass through multiple agents before work actually begins. For requests where the primary agent is unavailable, fallback logic redirects the task without any visible interruption.
All of this is delegation. This article explains the mechanics: what triggers delegation, how the agent mesh graph structures it, how the system decides which agent gets the work at each handoff, and how delegation outcomes feed back into future routing decisions.
Two Levels of Delegation
Nova OS uses delegation at two distinct levels:
Level 1 — Cascade routing to a Director. When a request arrives, the 3-tier cascade router selects the appropriate domain pack. For a contract compliance request, that's the Legal pack. The Legal Director agent receives the request.
Level 2 — Director delegation to specialists. The Director doesn't execute the task itself. It determines which specialists are needed, in what order, and delegates accordingly. The Legal Director knows that "review this contract for compliance" requires the Clause Extractor, the Compliance Checker, and the Risk Scorer — and it coordinates them.
This two-level structure keeps the cascade router's job simple: select the right domain. The Director's job is richer: decompose the task and assign subtasks to specialists it knows.
The Agent Mesh Graph
Delegation paths in Nova OS are encoded in a directed weighted graph — the agent mesh. Agents are nodes. Connections between agents are edges. Every edge has a type:
| Edge type | What it means |
|---|---|
| Direct | This agent can handle the request directly |
| Delegation | This agent passes specific subtasks to the target |
| Fallback | If the primary fails, try this agent next |
| Pipeline | Output of this agent feeds as input to the next |
| Broadcast | Send to multiple agents simultaneously |
These edge types encode the logic of how work moves through the system. A Director-to-Specialist connection is a delegation edge. The Clause Extractor feeding into the Compliance Checker is a pipeline edge. An alternative Compliance Checker registered as a backup is a fallback edge.
The graph is what makes delegation structured rather than arbitrary. When the system needs to route a request to the next agent, it follows the edges — it doesn't make ad hoc decisions about which agent to try.
Agent Discovery: Finding the Execution Path
After the cascade router selects a primary agent, the discovery layer traverses the mesh graph to find the full execution path. Three traversal strategies handle different task shapes:
BFS (Breadth-First Search)
BFS explores the agent graph level by level — it evaluates the immediate neighbors of the selected agent before going deeper. Use this when the request might benefit from a wide evaluation of options before committing to a path. BFS is the right strategy when the branching factor of the relevant mesh subgraph is high — many agents at the same depth level with plausible relevance.
DFS (Depth-First Search)
DFS follows one path deep before backtracking to explore alternatives. Use this when the request clearly needs a chain of specific specialists — one after another, in a known sequence. A contract review task that requires Clause Extraction → Compliance Check → Risk Score → Report is a natural DFS traversal: each step follows from the last, and the path is known.
Hybrid (Adaptive)
The StrategySelector evaluates two properties of the incoming request:
- Branching factor — how many plausible next agents exist at each level
- Specialization depth — how deeply the task needs to follow a specific capability chain
If the branching factor exceeds the threshold, BFS is selected. If specialization depth is above 0.7, DFS is selected. Most production requests use hybrid selection — the StrategySelector makes the call per request based on what the request actually looks like.
What discovery excludes:
Discovery only considers agents in IDLE or available states. OFFLINE and ERROR agents are excluded from path-finding entirely. An agent that the cascade selected as primary but is currently OFFLINE triggers fallback immediately — discovery finds the next viable path through the graph without surfacing the failure to the requester.
How Directors Decide Who Gets the Work
Within a domain pack, the Director agent makes delegation decisions. It has full visibility into the pack's specialist agents — their capabilities, current availability, and recent performance.
When the Legal Director receives a task, it evaluates:
What does this task require? The NovaBrain planning step produces a BrainPlan with explicit required capabilities for each subtask. The Director reads these capability requirements and matches them against the specialists in its pack.
Who is available? Each agent has a status: IDLE, BUSY, OFFLINE, DEGRADED, or ERROR. The Director only delegates to agents in healthy states. A BUSY agent can still receive work if its queue has capacity; DEGRADED agents can receive lower-priority work; ERROR agents are bypassed.
Who has the best track record? Each agent carries a trust score — a composite of success rate (40%), latency (20%), error rate (25%), and data freshness (15%). When two specialists could both handle a subtask, the one with the higher trust score gets it. A Compliance Checker that has processed 500 tasks with a 98% success rate is preferred over one that has processed 10 tasks with unknown reliability.
The Director encodes domain knowledge that the cascade router doesn't have. The cascade router knows which pack owns this request. The Director knows which specialist within the pack is right for each piece of it.
The Fallback Chain
Every agent in the mesh can have a configured fallback chain — an ordered list of alternative agents to try if the primary is unavailable or fails.
When the primary agent for a task is BUSY, OFFLINE, or returns an error, the FallbackChain activates:
- Try fallback agent #1
- If unavailable, try fallback agent #2
- Continue in order until an available agent is found
Fallback chains are configured per agent at deployment time. A Legal Compliance Checker might have a fallback chain pointing to a secondary Compliance Checker instance, then to a more general-purpose Legal agent. The chain reflects operator judgment about acceptable substitutes.
Fallback is not retry. Retry handles transient failures — a timeout, a rate limit, a momentary connection issue. The retry policy uses exponential backoff with jitter (100–500ms base) and only applies to errors classified as transient. Fallback handles capacity and availability failures — the agent is genuinely not available for this request.
Pipeline Delegation: Passing Output Forward
Some delegation isn't about selecting which agent runs — it's about moving data between agents that each do one step of a larger task.
Pipeline edges encode this. When the Clause Extractor completes, its output — a structured list of extracted contract clauses — is passed directly to the Compliance Checker as input. The Compliance Checker doesn't re-read the original contract. It operates on the extracted clauses.
This matters for two reasons:
Context focus. Each agent in the pipeline receives exactly the data it needs, not the full upstream context. The Compliance Checker's context window contains clauses and regulatory criteria — not the entire original document.
Error propagation control. If the Clause Extractor produces low-quality output, the Compliance Checker can flag this rather than silently degrading. Errors surface at the boundary between agents rather than compounding through a single model's context.
When NovaBrain plans a complex task and builds a DAG, pipeline edges define the data flow between nodes. The DAGExecutor follows these edges to pass outputs from completed tasks to tasks that depend on them.
Delegation Tracking and the Feedback Loop
Every delegation in Nova OS is recorded. Each routing decision — which agent was selected, by which method, with what confidence, whether it succeeded — generates an entry in the call log.
These logs feed back into the trust score system. An agent that receives delegated work and completes it successfully accumulates a higher success rate. An agent that times out, errors, or produces low-quality output that requires fallback accumulates negative signals.
Over time, this means delegation improves. The Director's choices become more reliable because the trust scores reflect real performance history, not static configuration. The fallback chain gets exercised only when needed because primary agents earn high trust scores and get the work. Underperforming agents get deprioritized before operators need to manually investigate.
Delegation at Nova OS is not a static configuration. It is a self-optimizing system — every completed task makes the next delegation more accurate.
What Operators Configure
The delegation system has several operator-configurable properties:
Fallback chains — which agents serve as alternatives for each primary agent, in what order. Configured per agent in the agent registry.
Agent availability thresholds — when an agent transitions from BUSY to unavailable, based on queue depth or active task count.
Trust score weighting — the default weights (success rate 40%, latency 20%, error rate 25%, freshness 15%) can be adjusted per deployment. A latency-sensitive deployment might increase the latency weight; an accuracy-critical deployment might increase the success rate weight.
Publish state — unpublished agents are excluded from delegation entirely. This gives operators a clean way to stage new agents into the mesh without immediate production exposure.
What operators don't need to configure: the trust score itself, the delegation path optimization, or the fallback activation logic. These operate automatically. The operator defines the structure; the system optimizes within it.
Stay Connected
💻 Website: meganova.ai
📖 Docs: docs.meganova.ai
✍️ Blog: Read our Blog
🐦 Twitter: @meganovaai
🎮 Discord: Join our Discord