Linear & Adaptive Orchestrators

The Linear and Adaptive Orchestrators coordinate a pool of Agent nodes through a manager LLM: the Linear Orchestrator plans a full task list up front and executes it in order, while the Adaptive Orchestrator re-decides what to do after every step. Both are legacy nodes — this page documents how they behave so you can maintain existing workflows, and shows how to rebuild each pattern on the Graph Orchestrator.

Shared anatomy

Both orchestrators have the same external contract and internal structure:

• Input — a single required input string: the objective to accomplish.
• Output — a single content string: the synthesized final answer.
• Agents — a list of Agent nodes the orchestrator can delegate to. Each agent keeps its own LLM, role, and tools; the manager identifies agents by their name, so give every agent a distinct, descriptive name and role.
• Agent Manager — a managing agent with its own LLM. The Linear Orchestrator pairs with a Linear Agent Manager, the Adaptive Orchestrator with an Adaptive Agent Manager.

Before planning anything, the manager first analyzes the user input and decides whether to respond directly (for greetings, off-topic questions, or anything the agent pool isn't needed for) or to plan and run the delegation flow. The manager's reply must parse as structured JSON; if parsing fails, the orchestrator retries the analysis.

Linear Orchestrator

The Linear Orchestrator runs a plan-then-execute loop:

1. Plan. The manager LLM receives the objective and the list of agent names, and produces a JSON task list. Each task has an id, name, description, dependencies (ids of earlier tasks whose results it needs), and an expected output. If the plan fails to parse, the manager retries with feedback — up to 5 attempts.
2. Assign and execute. Tasks run strictly in order. For each task, the manager picks the best-suited agent by index; the task description — plus the formatted results of its dependency tasks — becomes that agent's input.
3. Summarize. By default a final summarization step produces the content answer from the task results.

Because the plan is fixed before execution starts, the Linear Orchestrator is predictable and traceable, but it cannot react to surprises mid-run — a failed assumption in task 2 will not reshape tasks 3 through 5.

Configuration

Select the Linear Orchestrator node to open its panel:

• Agents — each row is an agent; the gear icon opens the agent's own configuration, the trash icon removes it. The empty selector at the bottom adds another agent.
• Agent Manager — the Linear Agent Manager and its LLM; the gear icon configures the manager.
• Max user analyze retries — how many times the manager may retry the initial input analysis when its reply fails to parse (default 3).
• Streaming — orchestrators default to streaming the final answer on the data event; switch the mode to stream intermediate manager steps too.

Adaptive Orchestrator

The Adaptive Orchestrator skips the upfront plan. On every loop iteration the manager LLM looks at the conversation so far and chooses one action:

• delegate — send a described task to one of the agents; the result is appended to the shared history.
• final_answer — stop and produce the final content.
• respond — answer directly without delegating.

The loop runs until the manager produces a final answer or the maximum of 15 loops is reached. This makes the Adaptive Orchestrator flexible on open-ended objectives, and also the least predictable pattern — cost and latency scale with however many steps the manager decides to take.

Configuration

• Agents and Agent Manager — same as the Linear panel, but the manager is an Adaptive Agent Manager.
• Reflection — when checked, enables reflection mode, which has the manager review and revise its own proposed action against the conversation so far before executing it (default off).
• Streaming — same defaults as Linear.

Migrating to the Graph Orchestrator

Both patterns map cleanly onto graph states:

• A linear pipeline becomes a chain of states: create one state per stage, put the relevant Agent (or Python function) in its Tasks, and connect the states START → stage-1 → stage-2 → … → END. Dependencies between stages are implicit — every state sees the shared chat history and context, so downstream states read upstream results without a manager call.
• Adaptive delegation becomes a hub state with conditional routing: keep a router state that decides where to go next (a Python conditional edge for objective criteria, or manager routing for judgment calls), and one state per specialist agent, each routing back to the router or to END.

The graph version replaces most manager LLM calls with explicit edges, which typically cuts cost and removes the largest source of nondeterminism. The Graph Orchestrator tutorial builds a complete loop of this shape step by step.