Turns, agents, steering, and continuation

The runtime treats a logical agent, an execution attempt, a provider session, and a workspace as separate identities. This permits recovery and redirection without treating a process as the agent itself.

Runtime identities

Identity	Purpose
Logical agent	Stable parent/child identity, assigned role, skill, depth, and collaboration address.
Agent attempt	One claimable execution of the logical agent, with lease, heartbeat, terminal state, and recovery lineage.
Backend session	Provider-specific conversation or process state used by one attempt.
Workspace	The bounded filesystem target assigned to execution; coding work can use an isolated Git worktree.
Turn	One controlled model/tool interaction boundary with persisted counters and events.

Controlled turn lifecycle

01
Preflight
Resolve the Project, owner, launch request, model, selected skill, modules, tool policy, provider state, and bounded input identity.
02
Reserve
Create or reuse the durable root agent and reserve an attempt under an idempotency key and ownership fence.
03
Compose context
Build the model-visible history, selected skill instructions, Mission state, collaboration messages, tool schemas, and current policy snapshot.
04
Model and tools
Run the provider turn. Tool calls pass through namespace, profile, path, risk, and approval checks before execution.
05
Persist
Append redacted events, messages, tool outcomes, state transitions, usage, and artifact references as execution progresses.
06
Decide boundary
Finish, ask for input, continue an active Mission, recover a failed unit, or stop because a guard or user control fired.

Agent spawning

Delegation is hierarchical. A child receives a server-owned parent identity, depth, assigned role, skill, model configuration, bounded context, item identifier, and expected artifact when the workflow defines one.

Spawning is non-blocking. The parent can continue useful work and receives child completion at safe boundaries. Completion text is not sufficient evidence: the parent is expected to read the persisted artifact or state transition before synthesis.

root agent
├── child A · one bounded work item
│   └── child A.1 · narrower verification
└── child B · independent work item

parent responsibilities:
  observe → message → redirect → interrupt
  verify artifact → recover smallest failed unit → synthesize

Steering and interruption

Control traffic is distinct from ordinary peer collaboration. The root can address a child, send follow-up context, redirect the active task, interrupt an attempt, close completed work, or recover it under a successor attempt. A Team peer message cannot grant these controls.

Control	Effect
Message / follow-up	Add context or a bounded request without replacing the child identity.
Redirect	Replace the current focus at a controlled boundary while retaining the relationship and history.
Interrupt	Request termination of active execution. Persisted state determines whether recovery is needed.
Close / reopen	Manage the logical collaboration lifecycle independently from one provider process.
Retry / recover	Reserve a fenced successor attempt for a failed, expired, or incomplete unit.

Mission loop

A Mission is optional. Normal Chat can complete bounded work without creating one. When a Mission is active, the root can continue across turn boundaries until completion evidence passes or a guard stops the loop.

01
Run a normal turn
The controlled loop records the turn and durable progress signals.
02
Quality gate
File-changing work can require a retained quality review before completion.
03
Completion gate
A completion review must report the required terminal status before the Mission is marked complete.
04
Continuation decision
If the Mission remains active and guards pass, the runtime creates the next continuation boundary.
05
Guard or control
Pause, interruption, token budget, stall detection, continuation limit, or missing progress stops automatic continuation.

Mission states include active, paused, blocked, budget_limited, interrupted, failed, and complete. State changes and continuation decisions are written to the event stream.

Recovery model

Attempts are reserved and claimed with fencing rather than inferred from process existence.
Claimed or running attempts use heartbeat and expiry data.
An abandoned attempt can receive one bounded successor linked to its predecessor.
Immutable input drift, exhausted attempts, or uncertain side effects become manual_required instead of being replayed speculatively.
Queued completions are deduplicated so a recovered child does not produce multiple parent-visible completions for one attempt.