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.0/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.
Node.js
Python
TypeScript
import{Agent}from'@a3s-lab/code';
constagent=awaitAgent.create('agent.acl');
constsession=agent.session('.', {});
// Independent steps; outcomes come back in input order, not completion order.
constoutcomes=awaitsession.parallel([
{
taskId: 'langs',
agent: 'general',
description: 'list',
prompt: 'Name three systems languages.',
maxSteps:2,
},
{
taskId: 'safe',
agent: 'general',
description: 'classify',
prompt: 'Is Rust memory-safe without a GC? yes/no.',
Outcomes are dicts in Python (o['task_id'], o['success'], o.get('structured')) and objects in Node (o.taskId, o.success, o.structured). The maxParallelTasks / max_parallel_tasks 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.
Node.js
Python
TypeScript
import{Agent}from'@a3s-lab/code';
constagent=awaitAgent.create('agent.acl');
constsession=agent.session('.', {});
// Stage 2 builds on stage 1's output. A stage callback MUST NOT throw —
// return null to stop this item's chain.
constresults=awaitsession.pipeline(
['the Rust programming language'],
[
(ctx)=>({
taskId: 'sum',
agent: 'general',
description: 'summarize',
prompt: `In one sentence, what is${ctx.item}?`,
maxSteps:2,
}),
(ctx)=>({
taskId: 'cls',
agent: 'general',
description: 'classify',
prompt: `Reply YES or NO: does this describe a programming language?\n\n${ctx.previous.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 (a raised stage is caught and treated as None).
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 when opening the session, or the call throws.
Pass a token budget as the second argument 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.
Node.js
Python
TypeScript
import{Agent}from'@a3s-lab/code';
constagent=awaitAgent.create('agent.acl');
constsession=agent.session('.', {});
constspecs=[
{
taskId: 'a',
agent: 'general',
description: 'q1',
prompt: 'Reply with one word: ready.',
maxSteps:2,
},
{
taskId: 'b',
agent: 'general',
description: 'q2',
prompt: 'Reply with one word: go.',
maxSteps:2,
},
];
// With a budget, parallel() resolves to { outcomes, budget } — all children
// share one ledger. (Without it, parallel(specs) returns the plain array.)
All three primitives return outcomes aligned to input order: { taskId, success, output, error?, structured? } (Node objects) / { "task_id", "success", "output", "error"?, "structured"? } (Python dicts).
Set outputSchema / output_schema on a spec to get a parsed result back in structured.
maxSteps / max_steps caps the steps per subagent; maxParallelTasks / max_parallel_tasks (session option) caps fan-out concurrency.
Pass a token budget to parallel (2nd arg budgetTokens / budget_tokens=) to cap a whole fan-out against one shared ledger; the return shape then becomes { outcomes, 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 (a raised stage is caught and treated as None).
A runnable version ships at crates/code/sdk/node/examples/orchestration/parallel-pipeline.mjs and crates/code/sdk/python/examples/orchestration_workflow.py.