Start with the outcome
An orchestrator turns an intention into bounded work. Define the observable outcome, the source inputs, allowed paths, acceptance commands and stop conditions before selecting a worker. A useful task says what changes for a user and how a verifier can inspect that change. A long prompt without an acceptance test remains an intention.
Choose the smallest sufficient executor
Use a deterministic script when parsing, counting or validation settles the question. Use an AI worker for a bounded transformation with a clear contract. Reserve architectural arbitration for a real unresolved decision. L0–L3 describes responsibility and escalation; it is not a universal ranking of model intelligence. Independent tasks may run together only when their allowed files and dependencies do not overlap.
Make the handoff inspectable
A handoff carries the task identifier, source version, changes, check results, unresolved limitations and the next receiver. A session label is useful routing metadata, not proof of identity. Keep the work artefact and its evidence together. If a stop condition occurs, return the reason and preserve partial work rather than inventing a success state.
Begin with one real workflow
Our practical offer is a scoped workflow pilot: one input, a finite execution path, explicit acceptance and a human-readable handoff. The engineering library already contains board, checkpoint and verification components; that does not mean every external worker has been migrated. Start with an agreed integration boundary and measure accepted results, not messages sent.
Sources and boundaries
Adapted from the project operator wiki and recorded engineering evidence, observed 15 October 2026. Practical recommendations are distinguished from scoped implementation results.
Read the related evidence wiki →