History and threads

Look up what each prompt carries from earlier steps, and how sessions continue from one step to the next.

syntax.toml

[steps.answer.plan]
prompt = "Plan an answer to {{ inputs.goal }}."
thread = "answer"
next = "steps.answer.give"

[steps.answer.give]
prompt = "Give the planned answer."
thread = "answer"

Before each prompt, Orbital adds a preamble with the goal, a heading for each finished step, steering and relevant context. Repeated visits fold into one step heading with a visit count. A step’s final message is not carried: a step hands the next one what it needs through its declared outputs, and a prompt that wants an earlier agent’s prose quotes {{ context.response.<id> }}.

Threads and restart

Turns normally start fresh sessions. thread = "implementation" shares a session across agent steps carrying that thread name. The steps of one thread must resolve to the same harness, and threads are not allowed inside parallel branches.

A route or next with loop_restart = true clears the values the loop wrote to context, the history of finished steps that later prompts show, and every thread’s session. It keeps the original inputs, the run’s identity, the visit counts and the budgets.

Parallel branches

A fan_out step runs each of its child steps as a branch, in file order, up to max_parallel at a time. Every branch must reach the fan-out’s join, a fan_in step. Branches cannot loop, hold a gate, set a thread or route out of their branch.

Each branch gets its own context and visit accounting, without the results an earlier round of the same fan-out left. Results arrive in the order of the child steps under parallel.results, with node, outcome, failure_reason and context. A branch agent’s answer appears in the preamble of the fan-in’s own turn only; any later step reads it by quoting {{ context.response.<id> }}, such as {{ context.response.reviews.clarity }}, so a loop through the fan-out does not grow every later prompt. Branches share working files, so use read-only reviews or disjoint writes. Successful collection enters the join; a partial failure takes a matching route from the fan-out’s routes. With no such route the run is Paused and shows “Waiting on you”.

A fan-in with a prompt runs one synthesis turn. Without a prompt it is only the meeting point. In templates use a quoted index, such as {{ context.parallel.results['0'].context.assessment }}. The parallel guide validates that spelling in a complete workflow.

Waits

A wait step requires a duration, for example 5m. Waiting keeps the interface responsive. You can choose Skip to end the wait early, and the transcript records that choice. A wait keeps its wake time across a restart, and poll loops spend no agent turns from max_visits.

Related

• Run steps in parallel: a complete fan-out and join that validates.
• Template variables: how a prompt quotes an earlier agent’s answer.
• Gates and waits: when to pause a run for a person or a time.
• Workflow file: a complete workflow that validates.