Waa Agent Delegation

Agent Delegation

Govern an already-chosen delegation without taking direction, extra authority, named-agent activation rights, or final responsibility.

Run the delegation loop

1. Confirm real delegation is already chosen and useful for independent work, professional judgment, parallel benefit, or independent verification; otherwise do not dispatch.
2. Choose exactly one EXECUTION_SUBAGENT, TASK_SPECIALIST_SUBAGENT, or authorized NAMED_AGENT. Visibility, availability, recommendation, or fit never authorizes a named Agent.
3. Check capability fitness, platform compatibility, Rules, task authorization, platform permission, prohibitions, exceptions, and external effects.
4. Read references/protocol.md, which is authoritative for the packet, handshake, return forms, and failure labels. Build one risk-sized TASK-006 packet with task_packet_version, task_id, assembly_type, artifact_id, artifact_version, and one owner; render it from references/packet-template.md.
5. Load only the active map: Codex, Claude Code, Agy, or OpenCode. Read platform compatibility when certainty matters.
6. Apply the required handshake, dispatch through the current native interface, and preserve the packet boundary.
7. Reconcile identity and ownership, verify returned evidence, and integrate only what it supports. If independent evaluation is authorized, read references/evaluation.md.

Apply executor rules

• EXECUTION_SUBAGENT: use for bounded work following clear rules. Low-risk, reversible, unambiguous work with no external effect may skip the handshake; otherwise require ACCEPTED / BLOCKED.
• TASK_SPECIALIST_SUBAGENT: use for non-mechanical professional judgment. Embed the eight-part temporary specialist_contract, always require ACCEPTED / BLOCKED, and create no persistent personality or tracking/promotion signal.
• NAMED_AGENT: use only after the user selected it, or authorized the primary agent to choose and the choice was recorded. Always require ACCEPTED / BLOCKED and confirmation of that authorization basis, even for low-risk work, because the handshake binds the named identity to the current-task authorization.

ACCEPTED confirms understanding of the packet version, objective, evidence duty, standard, capability conditions, permissions, prohibitions, and return contract. It proves neither expertise, authority, execution, verification, nor success.

Preserve identity, ownership, and authority

Every packet has exactly one uppercase assembly_type and all six identity fields. The packet, required acceptance record, and result must preserve them; reject mismatches.

owner solely owns the current artifact version. The primary agent remains responsible for delegation, reception, verification, coordination, synthesis, user communication, and the integrated outcome without automatically owning each delegated version.

Every action must pass all three gates: Rules allow it, the packet authorizes it, and the platform permits it. Never switch capability or execution paths to bypass a gate.

Return and evaluate deliberately

After execution begins, start the completion message with ACCEPTED / <DONE | PARTIAL | FAILED> under the protocol's first-line rule, then return exactly one matching delivery state:

• DONE: the minimum deliverable is complete and evidenced.
• PARTIAL: disclose completed and unfinished work, impact, evidence, unknowns, next handoff, and the safest next action.
• FAILED: the minimum deliverable was not reached; preserve cause, attempted scope, evidence, residual-state uncertainty, and a safe recovery or diagnostic action when blind retry could cause harm.

Independent evaluation is optional and separate. Connect it only when authorized and useful; never auto-start evaluation or a Loop. Subagent output remains evidence until the primary agent verifies and integrates it.