Skip to main content

Orchestration Lifecycle

This page defines the canonical orchestration flow.

Lifecycle Stages​

  1. Intent User goals enter the system as a request.

  2. Framing The runtime clarifies objective, constraints, and expected outcome.

  3. Planning The runtime builds a bounded plan with explicit steps.

  4. Capability Selection The runtime selects capabilities that match scope and policy.

  5. Guarded Execution Execution runs under policy, scope, and safety controls.

  6. Verification Evidence The runtime records outcomes, checks completion, and stores evidence.

Lifecycle Map​

Retained Context​

  • The runtime can persist goal-scoped retained session artifacts such as summary, decision, assumption, open-question, failure, validation-evidence, and next-action.
  • Retained artifacts are compact host-owned working context. They are separate from the full durable turn transcript.
  • Model context may be synthesized from retained artifacts plus bounded recent transcript when full replay is unnecessary.
  • Retained artifacts are context inputs, not proof of fresh execution. Verification still comes from durable turns, run state, and evidence.

Canonical Invariants​

  • The system must not execute before framing and planning are established.
  • Capability selection must remain policy-aware and context-bound.
  • Guardrails must stay active through execution.
  • Evidence must be sufficient for review and audit.
  • Full turns remain transcript history. Retained artifacts do not replace transcript storage.
  • Retained working context must remain host-owned, goal-scoped, and inspectable.
  • Local guarded execution admits only one active run per persisted plan at a time; this is plan-scoped because current run records persist plan_id, not plan_step_id.
  • Runtime run-discipline status is observational: queued, active, pending, backpressure, lag markers, degraded status, and messages come from persisted runtime state and do not imply workers, scheduling, streaming, or in-flight cancellation.
  • Current desktop subagent orchestration is sequential and bounded: one parent turn may launch at most one read-only child lane with maxDepth = 1, explicit tool scope, explicit output contract, durable lineage, and fail-closed blocked behavior.

Current Desktop Child-Lane Floor​

  • Desktop main-chat may request one bounded summary-scout child lane during send-message execution.
  • The child lane uses role-aware model routing, but parent currentModelSelection remains authoritative for the parent main-chat route rather than the child route.
  • Child lanes can use only built-in read-only model-callable runtime tools projected as function-calling tools; if the desktop host cannot derive a non-empty safe allowlist, child execution is blocked instead of widening scope.
  • Successful child output is persisted as a retained summary artifact and surfaced as durable orchestration truth through session orchestrationSummary.
  • This implemented floor does not imply parallel subagents, cancellation, MCP delegation, browser or desktop automation, or unconstrained provider-native agent execution.

Success Criteria​

  • The result aligns with the original intent or an explicit revision.
  • The execution path is explainable.
  • The evidence is clear enough to support trust and follow-up actions.