Agent Orchestration

Choose boundaries from context dependencies and task outcomes. A separate team, domain name, or reasoning phase is a candidate module, not sufficient reason for another agent.

Inspect the actual boundary

Establish the requested outcome and scope: architecture advice, an audit, or an implemented change. Inspect available prompts, tools, traces, and evaluations. For each candidate boundary, identify:

• Information needed on both sides, including user constraints, mutable state, exact identifiers, and earlier decisions.
• Work that can proceed independently, and whether its bulky intermediate material can be discarded.
• Evidence of repeated handbacks, missing information, duplicated investigation, tool-selection errors, or context-related failures.
• Effective tool access and enforcement, rather than permissions asserted only in a prompt.

Missing traces mean an architectural hypothesis, not a measured bottleneck. Do not invent usage frequencies or performance gains.

Choose the least costly adequate arrangement

For new systems, one loop is a useful initial hypothesis when dependencies dominate. Parallel tool calls can handle independent operations without separate reasoning agents. For existing systems, retain the working baseline until a candidate is evaluated. Neither default establishes universal superiority.

Make a retained worker's boundary usable

When delegation is within the user's scope and the host permits it, give the worker the task, necessary inputs, constraints, allowed effects, completion condition, and expected result. Choose effort and concurrency from the task and available budget; this skill supplies no fixed agent count.

Require a usable result: status, findings or artifact location, supporting source/data identifiers, unresolved issues, and what was actually checked. Preserve exact values needed downstream. Inspect consequential evidence or artifacts before relying on a worker's conclusion; a summary can omit the decisive detail. Treat timeout or partial work as partial. If repeated clarification exposes hidden coupling, bring the dependent reasoning together or revise the boundary.

Separate contexts alone do not prove security isolation. Preserve actual restrictions when merging or folding; verify the host's effective permissions and tool behavior. An architecture review does not authorize spawning workers, changing live systems, or expanding access.

Change and verify

For migrations or comparisons of measured variants, read migration-and-evaluation.md. It covers obligation preservation, matched evaluations, regression handling, and rollback.

Deliver the proposed or implemented boundaries, their task-specific rationale, what the evidence establishes, and remaining uncertainty. Distinguish a plausible design, an executed test, and a demonstrated improvement.

Read evidence.md when the recommendation needs source appraisal, conflicting findings, or a refresh. For evaluating this skill, use requests.md; keep rubric.md out of a test worker's context.