Delegation Protocol

Overview

Defines how the orchestrator delegates work to specialist agents. Every subagent spawn MUST use the 8-field prompt format — an explicit target agent plus the 7 sections — and MUST NOT omit the target agent. This ensures tasks are atomic, outcomes are verifiable, agents stay within scope, and spawns never fail outright from a missing subagent_type.

Usage

Use this skill when:

• Spawning any subagent for a delegated task
• Deciding which agent handles a piece of work
• Coordinating parallel or sequential agent execution
• Handing off artifacts between agents

Delegation Prompt Format

Every delegation MUST include all 8 fields — the 7 sections below, plus an explicit TARGET AGENT preamble line:

TARGET AGENT: <Exact subagent_type value — see "Never Omit the Target Agent" below. Never leave blank.>

TASK: <Atomic, specific goal — one verb, one outcome>

EXPECTED OUTCOME: <Concrete deliverables with success criteria>

REQUIRED SKILLS: <Relevant expertise the subagent needs>

REQUIRED TOOLS: <Explicit tool allowlist — only these tools may be used>

MUST DO:
- <Exhaustive requirements list>
- Preserve existing comments and JSDoc blocks
- Preserve existing logging statements
- Add inline comments for complex logic

MUST NOT DO:
- <Forbidden actions list>
- Do NOT remove comments or documentation
- Do NOT strip logging statements
- Do NOT silently reduce scope

CONTEXT: <File paths, patterns, constraints, handoff file references>

If a section is not applicable, write N/A — never omit the section. TARGET AGENT is the one exception: it is never N/A — every delegation targets exactly one agent.

Never Omit the Target Agent

Every subagent spawn — every Agent() call (Claude Code), every subagent tool invocation (Kiro CLI), and every agent() call inside a Workflow tool script (.claude/workflows/*.js) — MUST include an explicit target agent drawn from the Agent Registry below. Never omit it. For Agent() and subagent, the tool's own default when the target is omitted is general-purpose — this fleet registers no agent by that name, and the spawn fails outright ("Agent type 'general-purpose' not found"). For agent() inside a Workflow script, the equivalent field is the agentType option in the call's options object (the second argument) — set it explicitly on every call; never leave it to default.

Resolve the exact identifier from the runtime's own available-agents list for the current session — do not guess or hardcode a single form, since the correct literal string is install-dependent:

• Claude Code: use the agent name exactly as it appears in your own tool definitions / available-agent list for this session (e.g. konductor:k-architect for a Claude Code plugin install, k-architect for a konductor install into .claude/agents/).
• Kiro CLI: use the bare name from toolsSettings.subagent.availableAgents (e.g. k-architect).
• Workflow agent() calls: set the agentType option using the same Claude Code naming form as above (e.g. agentType: "konductor:k-researcher"). The Workflow tool is Claude Code only, so there is no Kiro CLI equivalent to resolve.

This is distinct from spawning the wrong agent for the task (an IMPORTANT-tier Quality Gate issue below) — this rule guards against spawning no agent at all.

Deliberate exception for Workflow agent() calls: a call may omit agentType only when the step is pure reasoning over data already inlined into the prompt (decomposition, classification, or synthesis with no need to read files, run commands, or use any other tool) — in that case the session's default reasoning agent is a legitimate choice, not an oversight. Every such omission MUST carry an inline comment immediately above the call explaining why no specialist is needed, so the omission is never mistaken for the bug this rule exists to prevent. A call that needs file/tool access (reading a file, listing a directory, running a command, web search, etc.) always needs an explicit agentType — omitting it there is the CRITICAL defect below, not a deliberate exception.

Format ownership rule: MUST DO / MUST NOT DO sections should not contradict the receiving agent's skills or system prompt. If a specialist agent has a skill that defines how output is produced (e.g., cloudscape-mock-ui uses a CDN bundle), do not add constraints that override that skill's behavior. Format guidance from the user's request (e.g., "output as a single file") is acceptable to pass through.

Agent Registry

SDLC Specialists

Meta-Agents (Quality & Planning)

When uncertain which agent to use, check the agent's skill list in the README or invoke sdlc-navigator.

Tool-to-Agent Routing

Authoritative source: This table is the detailed routing reference. context/k-orchestrator-routing-rules.md is a quick-reference summary loaded at startup — when the two conflict, this file wins. Update both when adding new tool domains.

For web content, prefer k-researcher for information retrieval. Delegate to k-browser for interactive automation or scraping, and to k-media-analyzer when the page content requires visual or structural interpretation.

Per-Agent SOP Registrations

Which SOPs each agent declares in its own dependencies.agentSops.agentSopNames, read directly from agents/*.agent-spec.json. This is the authoritative source for which agent a SOP dispatches to when it names another SOP by identifier — a referencing SOP should look up the owning agent here rather than stating or assuming one independently.

konductor additionally registers k-delegate; konductor-mux-orchestrator and konductor-cmux-orchestrator do not.

When a SOP is registered on more than one agent, the caller MUST pick the target based on what else the delegating step needs rather than treat the lookup as single-valued.

A SOP registered directly on an orchestrator's own agentSopNames, such as kiro-spec-workflow on konductor above, MUST be invoked directly rather than routed through a specialist-agent lookup, since it delegates to its own agents internally.

Parallel Execution

• Independent tasks ALWAYS run in parallel (max 4 concurrent subagents)
• Typical pattern: research + explore → synthesize → plan → implement
• Never block on one subagent when another independent task can start
• Dependent tasks run sequentially — wait for the upstream handoff file before spawning

Both runtimes support spawning the same agent multiple times in parallel with different tasks (e.g., two k-developer instances — one for backend, one for frontend, each in its own worktree), via their native delegation tool: the subagent tool (Kiro CLI) or Agent() (Claude Code). Each instance runs independently with its own context; the orchestrator waits for all spawned instances to complete before proceeding.

Before spawning any write agent, explicitly name its exact target in the dispatch prompt — a new dedicated worktree, an existing worktree to reuse, or (solo sequential dispatch only) the shared working tree. Never let an agent infer or default to a location: a silent default is what causes two agents, from the same task or different tasks, to collide in the same tree. The write agent itself provisions or reuses the named target using its own shell/file tools — not the orchestrator — on either runtime.

Parallel write agents MUST own disjoint files. Before spawning two or more write agents at once, list the files each one will edit. If a file appears in more than one list (a shared router, an index.ts, a registry), give that file to one agent, or run the parts that touch it in sequence. Separate worktrees do not prevent this: both edits conflict at merge, or one is lost.

For dispatch into a separate, visible pane or surface rather than an in-session subagent call, see claude-teams-behavior (Claude Code Agent Teams), mux-dispatch (tmux/zellij), or cmux-dispatch (cmux) for the dispatch-method-specific steps. mux-dispatch and cmux-dispatch each detect and drive Kiro CLI the same as Claude Code, so Kiro CLI is already covered there; for a plain in-session subagent/Agent() call with no multiplexer, the three paragraphs above are the complete procedure on either runtime and no separate skill is needed.

Examples of parallelizable work:

• Two k-developer instances: one for backend handler, one for frontend component
• Running code review + test coverage analysis on separate modules
• Generating threat model + cost estimation from the same design doc

Handoff Pattern

Large outputs between agents go through handoff files:

1. Subagent writes output to .konductor/handoff/<agent>-<task>.md
2. Subagent returns only the file path to the orchestrator
3. Next subagent reads the handoff file directly as CONTEXT
4. Max ~300 lines per handoff file — split into multiple files if larger

File naming: <source-agent>-<descriptive-task>.md Example: architect-system-design.md, developer-task-breakdown.md

Post-Implementation Review

After code changes, run the maker-checker cycle:

1. Get the git diff of all changes
2. Spawn the appropriate reviewer agent (e.g., k-developer with backend-review or frontend-review)
3. Address all CRITICAL findings
4. Re-review. If the fix fails, follow rule 5 under Orchestration Rules in your orchestrator prompt.

Failure Recovery

This section covers failed spawns: the spawn errors, times out, or the subagent returns nothing. For output that fails verification, follow rule 5 under Orchestration Rules instead.

• If a spawn fails, retry once with additional CONTEXT explaining the failure. If it failed because a permission was denied (a declined prompt, a permission rule or hook, or a sandbox or OS refusal such as EPERM, EACCES or a read-only filesystem), do not retry or re-route it; ask the user.
• If the retry fails, escalate to the user with: what was attempted, what failed, and the root cause
• If a subagent times out, check .konductor/handoff/ for partial output. Verify any partial output under rule 5; retry the spawn only if there is none.

Quality Gate

CRITICAL (block delegation):

• Subagent spawned with no explicit target agent (subagent_type omitted) — the tool defaults to general-purpose, which is not registered in this fleet, and the spawn fails outright
• Workflow agent() call with agentType omitted and no inline comment justifying the omission (see "Deliberate exception" above) — treat as an unreviewed omission, not a deliberate one
• Delegation prompt missing any of the 7 required sections (or the TARGET AGENT preamble line)
• Subagent spawned without explicit MUST NOT DO constraints
• Dependent task spawned before upstream handoff file exists
• More than 4 concurrent subagents
• Any write agent spawned without an explicitly named target (new worktree / existing worktree to reuse / shared tree) in its dispatch prompt

IMPORTANT (fix before proceeding):

• Wrong agent selected for the task domain
• Handoff file exceeds 300 lines without splitting
• Post-implementation review skipped after code changes

SUGGESTION:

• Could parallelize independent tasks that are running sequentially
• Could add more specific success criteria to EXPECTED OUTCOME