Workflows

Workflows let you orchestrate multi-agent pipelines visually. Where a behavior tree defines what happens inside a single agent, a workflow defines what happens between agents, triggers, and side effects — a graph that fires on a schedule, a webhook, a task moving across a board, or a button press, then routes envelopes through agents and actions to a terminal result.

Opening the editor

Open the Workflow Editor from the desktop app’s sidebar. The editor is built on a pannable, zoomable canvas with three tabs across the top:

Workflows are saved as versioned JSON artifacts under .agentloop/workflows/<slug>.json. They are git-friendly and shareable, so a workflow you build can be reviewed and committed like any other source file.

Anatomy of a workflow

Every workflow is a directed graph of nodes connected by edges. Nodes fall into five color-coded categories, and each workflow begins with exactly one trigger.

Edges come in two classes:

• Data-control edges (solid, left-to-right) carry envelopes from one node’s output to the next node’s input.
• Binding edges (dashed, top-to-bottom) attach a capability — Model, Tools, or Memory — to an Agent node.

Triggers

Triggers are the entry point. Each workflow has one trigger node, and its kind determines how the workflow fires.

Agent nodes

An Agent node runs a single agent. Configure it by agent type — engineer, qa-tester, chat, or any custom agent — and optionally pin a specific instance such as engineer-2. Agent nodes expose three binding ports for Model, Tools, and Memory, which you attach with dashed binding edges.

When a workflow runs, an Agent node synthesizes a transient task and maps envelope keys into the agent’s behavior-tree blackboard, so upstream data is available to the agent’s logic.

Routing nodes

Routing nodes are deliberately minimal — they shape control flow without doing work.

Action nodes

Action nodes produce side effects that are not agent runs.

Sink nodes

Sinks terminate a branch.

Building a workflow

Drilling into an agent’s behavior tree

To see exactly what an Agent node does, double-click it (or right-click and choose Open BT). A read-only panel slides out over the inspector and renders the agent’s full behavior-tree graph, with a header showing the agent type and any pinned instance. There are no step controls — this is a static view of the agent’s structure. Close it with the X button or Escape.

This is the bridge between the two layers of AgentLoop: the workflow graph shows how agents are wired together, and the drill-down shows the behavior tree that governs each agent’s internal decisions.

Running and testing

Each node shows a status badge in its upper-right corner while a workflow runs:

Iterating without re-firing live triggers

Two mechanics make iterating fast without re-triggering a live webhook or cron:

• Pin output freezes a node’s last successful output (shown as a gold badge). Downstream test runs reuse it instead of re-fetching upstream.
• Test step (Cmd-Enter) re-runs only the selected node using upstream pinned outputs, short-circuiting live execution.

Together these give you an iterative-debugger feel — tweak one node, re-run just that node, and inspect its output in the inspector.

Executions and Tests

The Executions tab lists historical runs. Click one to load a frozen snapshot of that run’s node outputs and edge counts, replay-style.

The Tests tab holds saved synthetic trigger payloads, each paired with an expected terminal state. Run the whole suite with Cmd-T to confirm a workflow still behaves as intended after edits.

Sink nodes such as Notify post to the panel covered in Alerts, and the orchestrator governs how the agents a workflow launches are scheduled and assigned.