subagent-orchestration

name	subagent-orchestration
version	1.0.0
description	Use when delegating work to subagents or choosing a model for a task — routing by task class, selecting provider-specific models and effort, and verifying subagent claims. Covers OpenAI/Codex, Anthropic/Claude, and Cursor.
compatibility	Self-contained; no OAT installation required.
user-invocable	true
metadata	{"internal":true}

Subagent Orchestration

Route work to subagents and models by task class and capability requirements, not by model name. This skill carries the durable selection contract; its provider references carry dated model examples that are subordinate to live catalogs and current user or repository instructions.

When to Use

• Deciding whether and what to delegate to a subagent.
• Choosing a model, effort, and service tier for a bounded task in any harness: Codex, Claude Code, Cursor, or a direct provider API.
• Reviewing whether a dispatch was routed at the right capability class.

This skill is guidance, not dispatch machinery. oat-dispatch-subagents (same pack) owns launch mechanics, catalog intersection, dispatch records, and recovery; it loads this skill's references as its source of model-selection policy.

Ownership: Root Keeps Judgment

• Keep cross-scope synthesis, consequential judgment, authorization, destructive or irreversible execution, credentials, and user dialogue in the root agent.
• Delegate bounded volume: reconnaissance, enumeration, self-contained generation, and independently verifiable work.
• A bounded dossier lead may synthesize within one declared scope; judging its output stays in the root.
• Verify load-bearing subagent claims before building on them. Require tool evidence, citations, logs, query results, or file references — or an independent reviewer — for any claim you will act on.
• Every nontrivial dispatch states: exact objective, bounded scope and authority, expected output, verification evidence, and escalation conditions. Model routing never repairs poor decomposition — narrow an over-broad task before escalating its model.

Five Task Classes

Classify in order: deterministic verifiability, silent-miss risk, dispersed-context reconciliation, ambiguity or novelty, then consequence. File count and duration alone never justify escalation.

Task class	Contract
mechanical-recon	Deterministic inventories, parity checks, enumeration, lint/test/build runs. Misses are visible. Optimize for cost and throughput.
intelligent-recon	Interpreting unfamiliar code, semantics, or policy; auditing API usage. A miss could be silent. Needs reliable judgment and tool use.
default-implementation	Normal multi-file coding, debugging, and reconciliation of dispersed context in one bounded scope.
hard-reasoning	Ambiguous debugging, architecture analysis, novel problems, competing interpretations.
consequential	Security, release safety, incidents, irreversible operations, adversarial analysis, foundational decisions, final load-bearing review.

Escalation boundaries:

• Mechanical → intelligent recon when a miss would be silent or judgment is needed to recognize a finding.
• Recon → default implementation when success depends on retaining and reconciling dispersed context, not merely searching many files.
• Default → hard reasoning when ambiguity, novelty, or reasoning difficulty dominates. Large context alone is not a reason.
• Any class → consequential when security, production impact, irreversibility, adversarial behavior, or expensive failure dominates.

Never route below a class floor. When uncertain between two classes, use the stronger one.

Selection Axes

Keep these independent; a model family name alone is not a route:

• task class; agent role; exact model selector; provider-native effort or reasoning mode; service or fast tier; authority; route or harness.

Do not normalize effort labels across providers — Sol high, Claude extended thinking, and Grok high are provider-native configurations with different behavior. Treat -fast variants as latency purchases, never capability upgrades, unless provider documentation explicitly says otherwise.

Provider References

Resolve the active harness and read exactly one:

• Codex or direct OpenAI API: references/provider-codex.md
• Claude Code or direct Anthropic API: references/provider-claude.md
• Cursor (IDE, CLI, or SDK): references/provider-cursor.md

Do not merge provider references into one policy, and do not infer direct-provider behavior from Cursor behavior or vice versa. Named models in these references are dated examples with verification frontmatter; the live catalog and current instructions always win.

Read references/model-selection-principles.md for the full durable contract, and references/evidence-and-refresh.md when guidance is past its review date, a newer model appears, or a consequential decision depends on evidence that is not current. A newer model is a candidate requiring qualification, never an automatic replacement.

Maintenance

This skill is the canonical source of model-selection policy. Downstream distributions (for example a private team plugin) sync it verbatim. Refresh the provider references per references/evidence-and-refresh.md and update each file's guidance_version frontmatter when incumbents change.