Runtime Behavior of Orchestration Skills
This chapter explains how the orchestration subsystem turns a parsed oskill.md descriptor into a bounded execution environment and how that environment differs between the SOP and loop paths.
Execution Path
When an orchestration skill is executed, the subsystem first reads the prepared descriptor configuration and resolves the downstream skills admitted by the allowlist. These skill records are then wrapped as tools through the shared MainAgent, so delegated calls still travel through the same routing surface used elsewhere in the library. The orchestrator therefore coordinates execution; it does not replace the downstream skills it invokes.
The session choice is then resolved from the prepared configuration. If the descriptor yields the session value loop, the subsystem starts a loop-based agentic session. In every other case, it starts a SOP session. This means that the session model is not inferred heuristically from the request. It is selected through a narrow rule in the subsystem.
Preparation and Capability Boundaries
If a preparation section exists, the subsystem turns it into a bounded preparation stage before the main session proceeds. In loop mode, that preparation block is passed as session preparation together with preparation tools. In SOP mode, it is passed together with a preparation commands registry and preparation skill descriptions. The same conceptual stage therefore exists on both paths, but it is attached to different session mechanisms.
The allowed skill surface also has two levels. The main allowlist governs which skills the orchestrator may call during normal execution. The preparation allowlist governs which skills may be used before the main session begins. If Allowed-Prep-Skills is absent, the preparation stage reuses the main allowlist. If it is present but empty, preparation has no delegated tools at all. This distinction is part of the runtime contract rather than a matter of documentation style.
MainAgent treats explicitly allowlisted skills as owned by the orchestrator. Owned skills are still available to the orchestrator through delegated execution, but they are omitted from the top-level tool surface built for ordinary prompt sessions.
If Allowed Skills is not declared, the subsystem exposes all discovered skills except the orchestrator itself. An explicit allowlist is therefore the main mechanism by which orchestration remains bounded.
Loop and SOP Session Behavior
When an orchestration skill is invoked from a parent loop session, MainAgent passes a snapshot of that parent conversation into the orchestrator context. The subsystem prepends that snapshot to the current orchestrator prompt so follow-up requests can resolve prior user messages, assistant replies, tool calls, and resolved tool results even though the orchestrator starts its own sub-session for execution.
In loop mode, the subsystem builds a system prompt from the descriptor description and instructions and starts a loop agent session with a fixed maximum step budget per turn. If the loop session later pauses in an awaiting-input state, the subsystem stores that session in sessionMemory under an orchestration-specific key and resumes it on the next prompt. If the session completes, the stored state is removed.
In SOP mode, the subsystem builds a commands registry whose commands correspond to the allowed downstream skills. It then starts a SOP Lang agent session with the normalized instructions, the commands registry, and the optional preparation block. After execution, it returns both the session result and the variables collected inside the SOP session.
The practical distinction is therefore straightforward. Loop mode supports turn-by-turn continuation with persisted awaiting-input state. SOP mode supports an explicit command-oriented planning and execution path. Both are bounded by the orchestration descriptor, but they differ in how the session is represented and resumed.