Are you an LLM? View https://a3s-lab.github.io/Code/llms.txt for optimized Markdown documentation, or https://a3s-lab.github.io/Code/llms-full.txt for full documentation bundle. This page is also available as Markdown at https://a3s-lab.github.io/Code/v6.5.2/en/guide/examples/orchestration.md
This page shows the programmable orchestration primitives in A3S Code: session.parallel for fan-out, session.pipeline for per-item multi-stage chains, and session.parallelResumable for journaled runs that survive a crash. parallel also takes an optional token budget so a whole fan-out shares one ledger. Use orchestration when you have several independent subagent tasks (parallel), or one transformation that flows through ordered stages per input (pipeline).
For the conceptual model behind these primitives, see Orchestration.
parallel takes an array of AgentStepSpec and runs them concurrently, returning one StepOutcome per spec in input order (not completion order). Each spec routes to a named subagent (explore, plan, review, verification, general, ...). Set outputSchema / output_schema on a spec to get a schema-validated structured result back.
Prompt: "Name three systems programming languages, comma-separated.",
MaxSteps:&maxSteps,
},
{
TaskID: "verdict",
Description: "classify",
Agent: "general",
Prompt: "Is Rust memory-safe without a GC? Answer yes or no.",
MaxSteps:&maxSteps,
OutputSchema:json.RawMessage(`{
"type":"object",
"properties":{"memory_safe":{"type":"boolean"}},
"required":["memory_safe"]
}`),
},
},nil)
iferr!=nil{
log.Fatal(err)
}
for_,outcome:=rangeresult.Outcomes{
fmt.Printf(
"[parallel]%s: success=%tstructured=%s\n",
outcome.TaskID,
outcome.Success,
outcome.Structured,
)
}
}
Outcomes are dictionaries in Python, objects in Node, and StepOutcome values
in Go. The maxParallelTasks / max_parallel_tasks / MaxParallelTasks
session option caps concurrency; extra specs queue, and the outcome array is
still returned in full, in order.
pipeline takes a list of input items and an ordered list of stages. Each item flows through the stages independently — there is no barrier between stages, so a fast item can reach stage 2 while a slow item is still in stage 1. A stage callback receives a ctx: the first stage sees ctx.item, later stages see ctx.previous (the prior StepOutcome, whose .output you build on). Return the next spec to continue, or null / None to stop that item's chain early.
Prompt: "Reply YES or NO: does this describe a programming language?\n\n"+
stage.Previous.Output,
MaxSteps:&maxSteps,
},nil
},
},
)
iferr!=nil{
log.Fatal(err)
}
for_,outcome:=rangeresults{
ifoutcome!=nil{
fmt.Println(outcome.Output)
}
}
}
Key difference from parallel: stages are ordered and dependent, but items do
not wait for each other between stages. Node stage callbacks must never
throw — return null on error; Python stages may raise (caught as None); Go
stages return (*AgentStepSpec, error).
parallelResumable is parallel with a journal. It takes the specs first and
a stable workflowId second; each step's outcome is journaled to the session's
store, so if the process crashes mid-run you can call it again with the same
workflowId and completed steps are replayed from the journal instead of
re-executed. It requires a session store — pass sessionStore,
session_store, or Go's FileSessionStoreDir when opening the session.
Rust
Node.js
Python
Go
Rust exposes the same checkpoint behavior through a named workflow.phase.
When a session store is configured, every phase is a resumable barrier.
Pass a token budget and every child agent feeds one shared ledger. With a
budget, parallel resolves to { outcomes, budget }
(the ledger snapshot) instead of the plain outcomes array; once the cap is hit, a
step that starts afterwards is denied (success: false). It is a soft cap — a
wide fan-out can race a few in-flight turns past it; the in-flight work is never
force-killed.
All three primitives return outcomes aligned to input order. Go uses
StepOutcome; Node uses objects; Python uses dictionaries.
Set outputSchema / output_schema / OutputSchema on a spec to get a
parsed result back in structured / Structured.
maxSteps / max_steps / MaxSteps caps the steps per subagent;
maxParallelTasks / max_parallel_tasks / MaxParallelTasks caps fan-out
concurrency.
Pass a token budget to parallel to cap a whole fan-out against one shared
ledger. In Go, pass *uint64 as the third Parallel argument and read
ParallelResult.Budget. It is a soft cap (usage is recorded after each call).
Node pipeline stage callbacks must never throw — return null on error.
Python stages may raise (caught as None); Go stages return an error.
Runnable Node.js and Python versions ship at
sdk/node/examples/orchestration/parallel-pipeline.mjs and
sdk/python/examples/orchestration_workflow.py; the Rust and Go tabs above are
self-contained.