Sigil: Subagent Strategy

• three or more sources, lenses, or returns must be synthesized,
• raw exploration would overwhelm the parent context,
• exploration should be isolated, discardable, or independently checked,
• two or more independent work lanes can run concurrently,
• the user asks for a governed subagent strategy, proposal, or dispatch,
• repository rules require tension checks, registration, and closeout evidence.

• direct inline work is smaller than the coordination cost,
• one helper can complete a bounded task inside its parent's scope,
• the task is only to validate a dispatch document; use the local dispatch validator,
• the dispatch type has no live owner,
• required tension, registration, or agent-lifecycle mechanisms are unavailable,
• the human has not explicitly confirmed the complete strategy sheet.

• goal and evidence boundary,
• expected outputs and artifact destination,
• proposed dispatch type,
• candidate groups, roles, and angles,
• runtime profile following templates/runtime-profile.md,
• type-owner contracts, preflight requirements, and stage-handoff readiness criteria,
• strategy-sheet schema and validator,
• non-mutating confirmation-readiness validation mode,
• deterministic agent-eligibility and final-approver admission rules,
• digest-owned tension-evidence representation,
• temporary-sheet storage and deterministic append-only registration,
• callable subagent mechanism,
• tension-check, registration, ledger, inventory, and observability bindings.

• dispatch-sheet field definitions,
• type-specific research, review, experiment, code, or planning judgment,
• local agent eligibility,
• a consuming repository's constitution or ledger schema,
• another capability's output semantics,
• project-specific artifact placement or publication policy.

Resolve those concerns through the repository-local runtime profile and the named owner capability. Never copy private owner prose or paths into this public contract.

1. Synthesis: three or more sources, lenses, or returns must be combined.
2. Context protection: raw work would be much larger than the parent should carry.
3. Isolation: exploration should be independently checked or safely discarded.
4. Parallelism: independent work can proceed concurrently.

A single helper spawned inside one agent's bounded scope is not a dispatch. Report it post-hoc in the parent's helper closeout. It becomes a dispatch when it fans out to two or more agents or outgrows the parent's scope.

The sheet is a UTF-8 temporary JSON record under the runtime profile's governed temporary root. It is not durable evidence. The deterministic registrar appends the confirmed dispatch row to the configured YAML ledger and consumes the temporary JSON before any working agent is launched. The YAML row is the durable confirmed strategy; no separate material-strategy artifact exists.

Dependency completion and stage readiness are separate checks. The source group finishing satisfies the edge only provisionally; the target still waits for the dispatch type owner's declared handoff criteria. This sigil routes that verdict but never invents type-specific evidence rules.

Keep scopes distinct: layers belong to groups, edge loop caps belong to zig-zag or feedback edges, and the global maximum loop count belongs to the whole dispatch.

Emit or preserve:

• profile identifier and dispatch type,
• trigger decision and matching triggers,
• group, agent, role, angle, and dependency counts,
• preflight status and its concrete design consequence,
• confirmation-readiness status and obligations closed, expected and observed form versions, exact sheet digest, and pre-confirmation revision count,
• tension-check results and revision count,
• confirmation request count, avoidable confirmation request count, preventable post-confirmation revision count, sheet-byte revision count, and exact-sheet confirmation state,
• registration and close row identifiers, YAML ledger path, and temporary-record consumption status,
• stage-handoff readiness verdicts, typed gaps, feedback or revision routes used, and remaining loop capacity,
• agent lifecycle counts and partial failures,
• final approver and approval status,
• result artifacts and validation,
• Quality Bar status, Anti-Pattern hits, workflow gaps, output-contract drift, and reflection trigger.

Use templates/usage-telemetry.md. Reflect after five meaningful executions, ten generated artifacts, three related workflow gaps, or one severe gap. Missing confirmation, unregistered execution, unpaired ledger rows, orphaned successful temporary records, unsafe scope expansion, private evidence leakage, unclosed agents, companion-only gate evidence, or a repeated confirmation caused by a deterministically discoverable pre-confirmation defect are severe gaps.

• decide and explain whether a dispatch trigger holds before fan-out,
• keep a bounded one-helper case outside the dispatch lifecycle,
• resolve a live type owner and valid runtime profile before registration,
• create the exact sheet only under the governed temporary root and pass it through the live form owner's non-mutating confirmation-readiness validator before tension or confirmation,
• close every configured deterministic admission obligation at one composite readiness point,
• treat stale runtime or schema projections as visible pre-confirmation warnings that still fail closed until rematerialized,
• expose the full strategy and artifact destination to the human,
• define real anti-bias tension for every multi-agent group,
• keep all load-bearing tension evidence inside the admitted sheet bytes,
• receive two independent PASS results before confirmation,
• require at most one explicit confirmation request while the exact sheet bytes remain unchanged,
• rerun readiness and tension checks and require reconfirmation after every byte change,
• register before spawning working groups,
• consume the dispatch temporary JSON only after registration succeeds,
• keep the canonical execution dispatch immutable and carry post-confirmation approval only through a verified run-local execution entry,
• honor blocking and non-blocking dependency semantics,
• require the type owner's stage-handoff readiness verdict before launching a consuming group,
• route correctable handoff gaps only through declared edges and remaining loop capacity,
• propagate partial failures and confidence limits,
• use an independent final approver,
• join and close every agent,
• append one dispatch row and one paired close row to the configured YAML ledger,
• consume the temporary close JSON after the close row is admitted,
• keep project-specific and private authority in the consuming profile,
• update configured result and observability hooks,
• return evidence, residue, and the next human action.

• dispatching because subagents are available rather than because a trigger holds,
• treating a single bounded helper as a registered fan-out,
• inventing sheet fields or type-specific judgment inside this router,
• using duplicated roles as fake tension,
• presenting a sheet before its tension checks pass,
• asking for confirmation before the exact temporary sheet passes the live form owner,
• treating syntactic form validation as complete when agent eligibility, approver admission, tension-evidence coverage, type-owner prerequisites, or publication checks are still unresolved,
• satisfying a tension gate with companion prose, parent summaries, or evidence not included in the admitted sheet digest,
• treating a form-version warning as permission to admit a stale sheet,
• treating silence, continued discussion, or draft-revision authorization as dispatch confirmation,
• making a reviewer react to checker findings before preserving the reviewer's independent verdict,
• editing sheet bytes without rerunning readiness and both tension checks,
• carrying confirmation across any sheet-byte change,
• spawning working agents before deterministic registration,
• persisting dispatch sheets, material-strategy projections, runtime profiles, or per-topic ledgers beside result artifacts,
• deleting an invalid temporary record before its validation failure can be diagnosed,
• leaving a successfully registered or closed temporary JSON behind,
• treating an upstream file or return as stage-ready merely because it exists,
• spending a downstream approval or revision loop on an upstream evidence gap when the declared feedback route can still repair it,
• inventing a feedback edge or exceeding a loop ceiling to repair a handoff,
• treating read-model or Inventory evidence as authority,
• hiding agent failures from downstream groups,
• letting working agents approve their own collective result,
• leaving agents open or ledger rows unpaired,
• copying a consuming repository's private names, paths, or evidence into Arcanum,
• claiming promotion readiness from contract prose without experiment evidence.

## Subagent Strategy Result

- Mode: inline | propose | run | close
- Runtime profile: <profile-id and path | unavailable>
- Dispatch type / owner: <type / owner | not applicable>
- Trigger decision: inline | dispatch | blocked
- Trigger evidence: <matching triggers or reason none apply>
- Preflight: <status, selected evidence, exclusions, gaps, design consequence | not configured>
- Confirmation readiness: <pass with schema and digest | warning and rematerialization required | blocked | not configured>
- Confirmation requests: <total, avoidable, and preventable post-confirmation revisions>
- Groups / lanes: <purpose, role, anti-bias axis, parallel or dependent>
- Subagents: <names or handles, roles, angles, expected outputs>
- Dependency flow: <sequential, zig-zag, feedback, final approval>
- Tension gate: <PASS/PASS | revision required | unavailable | not applicable>
- Human gate: <awaiting confirmation | confirmed/exact-sheet-bound | invalidated-by-byte-change | not applicable>
- Registration: <unregistered | registered in YAML with sheet digest | blocked | not applicable>
- Execution: <not started | completed | partial | failed | not applicable>
- Stage handoffs: <ready | needs_feedback with typed gaps, repair owner, edge, and loops remaining | blocked | not applicable>
- Agent closeout: <open/joined/failed/closed counts and residue>
- Ledger closeout: <paired in YAML | pending | blocked | not applicable>
- Temporary records: <dispatch consumed; close consumed | preserved after failure | not applicable>
- Result artifacts: <paths or inline>
- Validation: <checks and status>
- Reflection trigger: none | manual | usage-threshold | output-threshold | gap-threshold | severe-gap
- Next human action: <confirm, revise, decline, inspect, or none>