Agent Flows

​

Overview

Agent Flows let you compose typed nodes into a flow on a visual canvas. When you publish a flow, Experio compiles it to a LangGraph graph and runs it — orchestrating LLM calls, knowledge graph queries, MCP tools, document generation, and human approvals as a single pipeline. A flow can run on its own from the canvas, or be enabled as a sub-agent that the chat agent launches on a user’s behalf. Navigate to Admin > AI & Agents > Agent Flows.

​

The Flows List

The Agent Flows page lists every flow with its name, description, tags, and latest published version. A Sub-agent badge column shows whether a flow is exposed to the chat agent, and a filter above the list switches between All flows and Sub-agent enabled. From here you can:

• Create a new empty flow (give it a name — the system handles the internal id)
• Open a flow to edit it on the canvas
• Duplicate a template into a new draft (see Templates)
• Delete a flow

​

Building a Flow

Opening a flow shows the canvas editor. You build a flow by dragging nodes from the palette onto the canvas. Nodes are compact cards — they don’t show input/output ports on the canvas. To connect two nodes, drag from one node onto another; the canvas auto-wires their compatible ports. Edges float between nodes and re-route automatically as you move nodes around. The flow name is editable inline at the top of the editor. A collapsible right-hand pane holds the support panels; it re-opens automatically when you click a node:

• Inspect — configure the selected node (its config fields, input bindings, and budget), or the selected edge’s routing. Each node also takes an optional Display name — the human-readable step name end users see in the chat progress view while the flow runs (it falls back to the node’s label or id)
• Run — start and watch a run (see Running a Flow)
• Versions — review prior published versions and control which one is Live (see Publishing and Versioning)

​

Config fields

The Inspect panel renders each node’s config from its schema:

• Fields that hold prose — Query, Custom instructions, Prompt, System prompt, Output instructions and the like — render as multi-line text areas you can scroll and resize, rather than a single-line box you have to scrub through. Short identifiers (titles, artifact keys, numeric limits) stay single-line.
• Fields that point at another record render as a picker rather than asking you to paste an identifier:
  • Model (model_id, fallback_model_id, report_model_id) — the configured chat models, with Default model first. See Model Configurations.
  • Assistant — whose per-assistant model configuration the node borrows. Leave it on Default models to use the global ones.
  • MCP server — the server whose tools the step may call. See MCP Servers.
  • Document template — the branding template a generated file is rendered into. See Document Templates.
• Fields with a fixed set of values — the document Theme, output modes, error policies — render as dropdowns.
• Fields that hold a list — Tool groups, Allowed blocks, an MCP Tool whitelist — render as checklists of the real choices. Leaving one empty is meaningful and the panel says what it means (for a tool whitelist, “all discovered tools”).
• A nested configuration (such as the optional MCP enrichment on the research agent) renders as its own small group of controls, including the pickers above.

​

Bindings

Each node has typed input and output ports under the hood. Connecting two nodes auto-wires their compatible ports; to send one specific value, drag from a node’s output port to a target input in the Inspect panel. A binding path looks like $.nodes.<node_id>.outputs.<port>, and inputs can also bind to run parameters ($.params.*), the chat message ($.params.message), and uploaded files ($.files.*). Bindings are validated when you save — type mismatches and missing required inputs are surfaced inline on the canvas. Edges order execution; bindings move the data. Reads count too: reading another node’s output — through a binding, or through a {{ nodes.<node_id>.outputs.<port> }} template in one of the node’s config fields — counts as a dependency, not just the edges you drew. That is a safety net against a node running before the value it reads exists, not a guarantee of order. A node reading its own previous output (a loop body) is not treated as waiting on itself. If a node it reads from fails, the reading node fails too rather than running on an empty input — the branch stops there instead of producing a document out of nothing. An input that carries a default is the exception: it falls back to that default and the reading node still runs — but only because it reads the failed step, not because it follows it. A step you drew an edge from is on the failed branch, and that branch stops at the failure whatever its inputs default to. Drawing the edge is what actually orders the two steps. Validation does check for a node reading the output of a node that isn’t upstream of it, and reports it as a warning: run Validate — or apply an edited definition from Edit as JSON — and every such finding is listed in an amber strip above the canvas, naming the node to fix. Warnings never block publishing, by design, and there is no per-node marker on the canvas or in the Inspect panel, so that strip is the only place you can read the detail. Publish without validating first and nothing surfaces at publish time — the publish dialog lists blocking errors only; the new version’s entry in the Versions tab carries a warning count instead, as a prompt to go back and run Validate.

​

Edit as JSON

The canvas toolbar includes an Edit as JSON action. It opens the flow’s full definition as JSON, where you can export it (copy or download) or paste an edited definition back. Applying a pasted definition runs the same server-side validation as the Validate button — unparseable or structurally-invalid JSON (missing nodes/edges arrays) is rejected before it touches the canvas.

​

Node palette

​

Budgets

Agent nodes (orchestrator, knowledge research, web research, MCP action) run a model-driven loop and must be bounded. Each exposes a budget so a single node can never run unchecked: Each box shows that node’s own default — leave it empty to use it. Reaching the call or token limits ends the agent’s loop and returns what it has so far; it does not fail the run, so a budget set too low shows up as truncated work rather than an error. Max wall seconds is a hard deadline rather than a soft one. The knowledge research, web research and Orchestrator agent steps stop at it and hand on the work they already have; the MCP action step reports a timeout through its own error policy. Every other step that has a time limit is failed when it overruns: the step is cut off, whatever it had produced by then is discarded, and the failure is reported like any other step error, so an unresponsive step can no longer hold a run open indefinitely. Steps that carry a built-in time limit — the knowledge graph steps, for example — are now actually held to it; a step with no time limit of its own and no built-in default still runs unbounded. Those built-in limits also apply to flow versions you published before the limit existed — a knowledge-graph step that used to take as long as it needed is now failed at its cap. Raise a step’s Max wall seconds if it legitimately needs longer — from the Budget editor on an agent node, or through Edit as JSON (budget.max_wall_seconds on the node) for a knowledge-graph step, whose Budget editor the canvas doesn’t render.

​

Publishing and Versioning

A flow you are editing is a draft. Publishing snapshots the current draft into an immutable version:

1. Click Publish. The draft is validated first — publishing is blocked if validation reports errors. Validation also checks MCP action nodes: an unknown or disabled MCP server, or Allow writes enabled on a server that doesn’t support writes, blocks publishing; whitelisted write tools that would be stripped because Allow writes is off are surfaced as a warning.
2. A new AgentFlowVersion is created with an incrementing version number. Published versions are immutable.
3. The flow’s latest published version pointer advances to the new version.

​

The live version

Every run of a flow uses its live version — the version the chat agent launches, and the default for a canvas or API run. The Versions panel marks the current one with a Live badge. By default a flow follows the latest published version: each time you publish, the newest version automatically becomes live. To roll back or hold on an older version, click Set as live on any validated version in the panel — this pins the live version there, and publishing no longer changes what’s live. Click Follow latest to clear the pin and return to auto-advancing on publish. Either action also loads the now-live version onto the canvas, so the editor shows what actually runs — it arrives as an unsaved change, and your saved draft is untouched until you save. If your canvas already holds unsaved changes, you are asked first: loading replaces them and there is no undo, so you can keep editing instead. The pin is applied either way — declining only leaves the canvas alone. While live is pinned to something other than the latest published version, the editor header carries a Live badge naming the pinned version, as a reminder that the newest published version is not the one running. Only a version that passes validation can be set as live. Existing runs always stay on the version they started with; changing the live version only affects new runs. You can review prior versions from the Versions panel. Use Validate at any time to run save-time validation on the draft without publishing.

​

Letting the chat agent run a flow

You don’t wire a flow to a dedicated assistant. Instead, you let the normal chat agent discover and launch it as a background sub-agent:

1. Open the flow and turn on the Sub-agent toggle in the editor header. The flow becomes available to the chat agent.
2. Write a clear flow description in the editor next to the toggle. The chat agent reads this description to decide when to run the flow, so describe what the flow does and the kind of request it handles. A sub-agent flow with no description shows an amber nudge — the agent can’t route to a flow it can’t recognize.

Once enabled, the chat agent can launch the flow during a normal conversation. When a user asks for something a flow covers — for example, “prepare a response for this RFP” — the agent confirms once (“I can run RFP Response Pipeline — proceed?”), then launches the flow in the background. The conversation stays fully usable while the flow runs. Users can also launch a sub-agent flow directly from the chat composer’s Launch a flow menu, which skips the matching step and starts the chosen flow immediately. The agent maps the user’s request onto the flow’s parameters automatically (flows read them as $.params.<name> / {{ params.<name> }}, and $.params.message is typically the user’s core request forwarded at launch) and binds the conversation’s uploaded files to the flow’s file slots. If the flow needs a file the user hasn’t provided, the agent asks for it instead of launching. While a sub-agent flow runs, a live flow-run view opens in the chat’s right-hand panel showing a progress bar with a step counter (“Step X of N”), the currently-running step by its Display name, a checklist of steps in the order they execute, produced files, and a Stop control; the conversation pulses in the sidebar until the run finishes. Closing the panel leaves a View progress control (above the message box) to reopen it, and a finished run leads with the result and files, followed by a “What happened” timeline of the executed steps (each expandable into that step’s outputs, with human-review steps marked), with the technical run detail under a Show details toggle. Past runs stay reachable afterwards via the Runs dropdown in the conversation header, which lists the conversation’s runs newest-first and reopens any of them in the panel. When the flow finishes, it posts a message into the conversation with the full result and any files it produced — this arrives on its own (no manual refresh). Users can also just ask the agent for the status or results of a flow it launched.

​

Running a Flow

​

From the canvas

Use the run panel in the editor to start a run with parameters and uploaded files. The run executes in the background — progress, per-node status, and produced artifacts stream back to the panel. The usage panel shows per-node model/tool call counts and token usage — including, for MCP action nodes, the names of the tools the run actually called, so you can confirm it used the tool you intended.

​

From chat

When a flow is Sub-agent enabled, the chat agent can launch it during a normal conversation — see Letting the chat agent run a flow. The agent confirms, runs the flow in the background, maps the user’s request onto the flow’s parameters, binds uploaded files to the flow’s input slots, and posts the result and any produced files back into the conversation when the run finishes.

​

Human-in-the-Loop (HITL)

Flows pause whenever they reach a Human review node (or a Knowledge Graph node configured to interrupt on clarification). A paused run waits for a reviewer to approve or reject (with a comment) before it resumes. Paused runs surface in the Agent Inbox at Admin > AI & Agents > Agent Inbox, which lists every run awaiting human input — newest pause first — with the paused node and a click-through to act on it. Runs you start from the canvas also surface their pause in the editor’s Run panel. Resuming a run is atomic: two reviewers cannot both resume the same pause.

​

Several questions at once

A run can pause on more than one question at the same time — for example two Human review nodes that sit on parallel branches, or a review plus a Knowledge Graph clarification. When that happens:

• Every pending question is listed together, and you answer them one at a time.
• Answering one leaves the others on screen. A question you have answered does not come back, and the conversation’s amber review marker stays lit until the last pending question has been answered.
• While a run is processing an answer, the remaining questions are shown but disabled — only one resume can run at a time, so they become answerable again a moment later.

Because each answer is applied to a specific question, an API caller resuming a run with several pending questions must say which one it is answering (see API surface); a bare value is rejected.

​

Templates

Experio seeds two starter templates you can duplicate into your own draft:

• RFP Response Pipeline — extracts requirements from an uploaded RFP, drafts sections, and produces a formatted response document.
• Grunley Scope Merge — merges uploaded scope-of-work documents into a single document.

Duplicate a template from the flows list, then edit and publish your copy.

​

REST API

Agent Flows are also available over REST under /api/agent-flows/ for programmatic use: