multi-agent-delegation

Multi-Agent Delegation

Use this skill when the work will be executed by one or more AI agents rather than by a single linear local edit loop. It does not replace product-rd-workflow; it is the execution model used after there is a clear plan, task list, or implementation direction.

Scope Boundary

This skill is about using AI agents / subagents to execute work — delegation, parallelism, and verifying what the agents produced. Two adjacent owners it must not duplicate:

• Building an agent feature that ships inside a product — the runtime agent loop as a backend contract (max-iteration / tool-call / wall-time / token bounds, tool input/output schemas, tool allowlist + authorization scope, idempotency keys for write tools), the vendor agent SDK, advanced tool use, context-editing / memory tools, agent-skill-system runtime (how a product loads, routes, and sandboxes skills at inference time — not a temporary dev/execution subagent that this skill dispatches selecting its own skills while doing delegated work), the agent eval harness, prompt-injection defense, and Computer Use — is owned by llm-inference-integration (see ../llm-inference-integration/references/retrieval-agent-safety.md).
  • Route product-embedded agent runtimes there.
  • This does NOT mean execution subagents go unbounded: for the temporary dev/execution subagents this skill launches, you still bound each worker's file scope, allowed tools/actions, side-effect permissions, retry/stop conditions, and expected evidence — but in the dispatch prompt (per the Core Rules and playbook below), not via a reusable runtime-loop contract.
  • Before a worker prompt includes a delivery spec/plan/requirement/status/retrospective/task card — or any text generated from one, including this gate's own block reasons / findings / review packets / records — run product-rd-workflow's artifact-egress confidentiality gate on the prompt payload — a worker prompt is a cross-boundary handoff (often to another model), and a controller can dispatch from here without reloading product-rd-workflow, so the full pass must fire at this dispatch site (see ../product-rd-workflow/references/artifact-egress-confidentiality.md). Apply both halves to the payload before dispatch: strip or route secrets/PII/raw-logs/customer-data to their existing owners, AND apply the semantic confidentiality axis (named-person+negative-judgment / customer+negative-event / unannounced-strategy / NDA / internal-codename). The capability-scoping rule below is only a post-dispatch tool/read boundary — it limits what the worker can read or do after dispatch and does NOT sanitize content already placed in the prompt, so it is not a substitute for sanitizing the prompt payload.
  • Route to llm-inference-integration only when the deliverable is a reusable product/runtime agent loop, not when bounding a one-off worker.
• The named workflow-pattern taxonomy (prompt chaining / routing / parallelization / orchestrator-workers / evaluator-optimizer), the sub-agent isolation failure checklist (context starvation / result inflation / hidden dependency / trust drift), and the failure-escalation thresholds (same-error-retry, budget warning, dependency hard-stop) are covered in depth in ../skill-extraction-workflow/references/harness-patterns-and-eval.md; read it when available for the expanded taxonomy and isolation checklist. This skill carries the load-bearing minimums inline (escalation message contract in the Core Rules below) so it stands alone, and applies the patterns to executing real work rather than redefining them.