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/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. A chain also stops when one of its steps fails, so a later stage only ever sees a successful previous.
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. A Node stage that throws, returns a
Promise, or runs past the stage timeout (the optional third pipeline
argument, 30,000 ms by default) is treated as null. A Python stage that
raises is treated as None. A Go stage returns (*AgentStepSpec, error); an
error stops that item's chain, and Pipeline returns it after every item
finishes.
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 ledger
reaches the cap, every child's next model call or tool call is denied, so those
steps end with success: false. It is a soft cap: usage is recorded after each
model call, so concurrent turns can overshoot it, and a call already in flight
is never 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).
A Node pipeline stage that throws is treated as null, and a Python stage
that raises is treated as None. A Go stage error stops that item's chain
and is returned by Pipeline.
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.