Skip to main content
What it does: Lets agents define, run, save, and monitor multi-agent execution graphs (DAGs). Each node is a sub-agent task; independent nodes run in parallel, dependent nodes wait their turn. Who it’s for: Anyone who wants to coordinate more than one specialist agent on a single problem — research teams, code review rotations, debate / vote setups, multi-step content workflows, gated trade execution. For the conceptual background — node types, barrier modes, context modes, scheduling, and the architecture of the graph coordinator — see Execution Graphs. This page is the developer reference for the pipeline tool itself.

From natural language to graph

When a user describes a multi-agent workflow in chat, the agent translates it into a pipeline call. For example:
The agent calls pipeline action: execute with a 5-node graph. Four research nodes have no depends_on (they run in parallel); the final recommendation node depends on all four (barrier_mode: all):
The graph coordinator runs the four analysts concurrently, blocks the recommendation node until all four return, then injects each upstream result into the prompt via {{nodeId.result}}. You can monitor the run with pipeline action: status graph_id: <id> and grab final outputs with pipeline action: outputs graph_id: <id>.

Prerequisite

Agent-to-agent communication must be enabled in your configuration:
Without this setting, the pipeline tool will not be available.

Actions

The pipeline tool supports 10 actions. The default action is execute if no action is specified.

define

Validates a graph structure without executing it. Returns the topological execution order and any warnings. Use this to check a graph before running it.

execute

Starts a graph and returns a graphId for monitoring. Root nodes (no dependencies) begin immediately.

status

Check the status of a specific graph or list recent graph executions.

cancel

Stop a running graph. All running nodes are terminated and remaining nodes are skipped. Requires user confirmation (_confirmed: true) because it is a destructive action gated by the action classifier.

save

Persist a graph definition for reuse. Edges are automatically derived from depends_on if not explicitly provided.

load

Retrieve a previously saved graph definition by its ID.

list

Browse saved graph definitions with optional pagination.

delete

Remove a saved graph definition. Requires user confirmation because it is a destructive action.

outputs

Retrieve node output values from a completed or running graph. Uses memory-first retrieval with disk fallback for expired graphs. Each node output is truncated at 12,000 characters.
Response:
Nodes that have not completed yet return null. The source field indicates whether outputs were retrieved from the in-memory coordinator ("memory") or from persisted output files on disk ("disk").

from_intent

Synthesize a multi-agent graph from a one-line intent — a canonical pattern plus a few agent/task names — and run it, without hand-writing the node list. The synthesizer deterministically expands one of four canonical patterns and dispatches the result through the same execute path, so all graph validation and sub-agent governance apply automatically.
Patterns: An invalid intent (for example debate with fewer than two agents) is rejected before any graph runs. from_intent is gated by the orchestration.authoring.intentAction config flag (default true — on out of the box); set it false to make the daemon refuse the call. Each successful synthesis emits a graph:synthesized_from_intent audit event.
from_intent produces template-shaped graphs — plain agent nodes ({ nodeId, task, dependsOn }) wired in the named fan-out → fan-in shape. It does not emit the typed orchestration drivers: a synthesized debate is a one-shot pro/con fan-in into a moderator node, not the multi-round type_id: debate driver (with type_config.rounds / synthesizer). For the typed multi-round drivers, author the graph with define/execute and per-node type_id + type_config (see Node configuration below). from_intent accordingly takes no rounds parameter.

Node configuration

Each node in the nodes array accepts the following parameters:

Graph settings

Top-level parameters that apply to the entire graph:

Edges

Edges define structural connections between nodes. They are auto-derived from depends_on if not explicitly provided:
Each edge can have an id (auto-generated as source->target if omitted), and source/target (or from/to aliases).

Data flow

Nodes receive upstream results through {{nodeId.result}} template interpolation directly in the task text. The nodeId must appear in the node’s depends_on array.
In this example, search is the upstream node ID referenced in depends_on, and {{search.result}} is replaced with the search node’s output at runtime.
Use ${VARIABLE_NAME} for user-provided inputs that the web dashboard prompts for before execution. Use {{nodeId.result}} to inline upstream node outputs. These are two different interpolation syntaxes — ${VAR} is resolved at execute time from the variables parameter, while {{nodeId.result}} is resolved at runtime when the upstream node completes.
Important constraints:
  • Template references ({{X.result}}) must use a node ID that appears in the same node’s depends_on array
  • Outputs exceeding 12,000 characters are automatically truncated
  • If an upstream node did not complete (failed or skipped), the template is replaced with [unavailable: node "nodeId" did not complete]
  • Additionally, upstream outputs are automatically injected as context for downstream nodes. Set context_mode: "none" to disable automatic injection and rely solely on {{nodeId.result}} templates.

Shared data folder

Each graph execution creates a temporary directory at ~/.comis/graph-runs/{graphId}/. All nodes can read and write files here, making it ideal for exchanging large payloads between nodes.
The shared folder path is automatically provided to each sub-agent.

Error handling

Failure policies

Barrier evaluation

With fail-fast, any failed dependency cascades to skip all downstream nodes. With continue, the barrier mode determines whether a downstream node runs or is skipped:
  • all: skipped if any dependency failed
  • majority: skipped only if more than half the dependencies failed
  • best-effort: skipped only if every dependency failed

Node status lifecycle

A node starts as pending, becomes ready when its dependencies are satisfied (or immediately if it has none), transitions to running when spawned, and ends as completed, failed, or skipped.

Budget and timeout cancellation

If the graph exceeds its budget (max_tokens or max_cost) or timeout, all running nodes are killed and remaining nodes are skipped. The graph:completed event includes a cancelReason field (timeout, budget, or manual).

Examples

Research pipeline

A sequential chain where each step builds on the previous:

Code review pipeline

Parallel analysis steps that feed into a final decision:

Content pipeline with budget limits

A production pipeline with cost controls:

Debate pipeline

A pipeline with adversarial debate for balanced analysis:

Approval-gated pipeline

A pipeline that pauses for human approval before executing a high-stakes action:

Vote pipeline

A pipeline where multiple agents vote independently:

Agent (typed) pipeline

A pipeline that explicitly sets type_id: agent with driver-level configuration for model and step limits:
Setting type_id: agent explicitly is optional — a node without type_id runs as a single-agent task by default. Use the explicit form when you need to override the agent’s model or step limit via type_config while using the driver system.

Refine pipeline

A pipeline where multiple reviewers sequentially improve a draft, each building on the previous reviewer’s output:

Collaborate pipeline

A pipeline where agents contribute sequentially, each adding a different perspective to the accumulated work:

Map-reduce pipeline

A pipeline that fans out work to parallel mappers and then reduces their outputs into a single result:

Execution Graphs

Conceptual guide to execution graph architecture

Visual Builder

Design and run graphs from the web dashboard

Tool Policy

Configure pipeline tool access via tool policy

Sessions Guide

Sub-agent sessions for simpler delegation