Waa agent delegation

Agent Delegation

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

<FAILURE-LABEL-CONTRACT>

Before execution, put one exact root-cause label on the first task-status line:

• BLOCKED: critical task input is missing or the contract conflicts.
• MISSING_CAPABILITY: a required capability is absent, incompatible, or unreliable.
• CAPABILITY_OUT_OF_SCOPE: the capability exists but Rules or current task authorization excludes it.
• PLATFORM_PERMISSION_BLOCKED: platform policy, sandboxing, or approval prevents the action.

Preserve these labels verbatim. If a required handshake stops, add Handshake: BLOCKED after the root-cause label. Delivery states apply only after execution starts.

</FAILURE-LABEL-CONTRACT>

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. Build one risk-sized TASK-006 packet with task_packet_version, task_id, assembly_type, artifact_id, artifact_version, and one owner; vary only the depth of its nine information classes. Read references/protocol.md.
5. Load only the active map: Codex, Claude Code, or Agy. 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.

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.

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, return exactly one delivery state:

• DONE: the minimum deliverable is complete and evidenced.
• PARTIAL: disclose completed and unfinished work, impact, evidence, unknowns, and next handoff.
• FAILED: the minimum deliverable was not reached; preserve cause, attempted scope, and evidence.

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.