Skip to main content
The orchestrator’s freedom depends on what the builder has authored. More control primitives means more framework enforcement, less LLM discretion.

​
Boundary rules

  1. An ordered block enforces local order, not global lock-in. The user can trigger a different skill mid-block (interrupt). The block pauses and, if the user chooses to resume, continues at the same step when the interrupt completes.
  2. @skill.<name> guarantees parent resumes; user-initiated interrupt does not. An @skill.<name> reference is a structured invocation with guaranteed return. An interrupt is a user changing topic; the original skill stays on the stack but may not be revisited.
  3. Prose and ordered blocks coexist. Prose references a block via @block.<block_id>. The orchestrator enters the block, runs it, and returns to prose.
  4. if: markers are prompt-level, not execution-level. They change what the LLM sees, not what the orchestrator tracks. Each marker scopes the one paragraph beneath it, so every case reads as its own if:.
  5. tool_constraints are always enforced. Whether the LLM or an ordered-block execute_tool: step attempts the call, requires: and any confirmation gate are checked before the function runs.
  6. Every gate fails closed. When a requires: or if: condition does not hold, the tool stays hidden and the paragraph stays out of the prompt. Withholding is the safe direction, so it is also what happens when a condition cannot be evaluated.
  7. Values can satisfy upcoming collect: steps early. A user who volunteers several answers at once lets the block advance past each already-satisfied collect: step in one turn, unless the step sets ask_before_filling: true. Order is still preserved: the block never runs a later step before an unsatisfied earlier one.

​
Conditions

Every requires:, if:, complete_when:, utter: when:, and next: condition is a string expression in one grammar. See Conditions.