Flows
Visual workflows composed of typed, extensible steps.
A flow is a visual workflow that can express supervisor patterns (a coordinator agent directing specialist agents), conditional branching, manual iteration, and tool calls, and supports human-in-the-loop pause/resume.
[Input]
│
▼
[Coordinator Agent] ──────────────┐
│ │
▼ ▼
[Knowledge Agent] [Specialist Agent] [Tool Agent]
│ │ │
└────────────────────┴──────────────────┘
│
▼
[Output]An extensible step catalog
Every step type in the flow builder follows the same contract — a display name, a typed configuration schema, and an execution behavior. New step types can be added to the catalog without changing any existing step or how the workflow runs, so the catalog grows without risk of regressions elsewhere.
Built-in step catalog
| Step | Category | Description |
|---|---|---|
| Agent | AI | Runs a configured agent (system prompt + model). Optional toggles let it reuse the agent's own Knowledge Base(s) ("Use Agent Knowledge") or connected MCP server(s) ("Use Agent MCP Servers") directly — the same retrieval/tool-calling behavior as standalone agent execution, without wiring a separate Knowledge retrieval/Tool call step |
| LLM | AI | A single raw model call, without agent wrapping |
| Tool | AI | Exposes a tool definition to the preceding model call and runs it |
| Catch Up | AI | Terminal step that rejoins a tool result back into the model call that requested it |
| RAG Retrieval | Data | Retrieves from a knowledge base |
| Text Output | Data | Emits a fixed or templated piece of text into the run's output |
| MCP Tool | Integration | Calls a tool exposed by a connected MCP server |
| HTTP Request | Integration | Calls an external HTTP endpoint |
| Code | Logic | Runs a sandboxed UO Script snippet against the run's data |
| Condition | Control | If/else branching (true/false handles), evaluated in a restricted, sandboxed manner. The only step type allowed to sit on a cycle — build iteration by routing a false branch back to an earlier step |
| Once | Control | Splits on whether this is the session's first run (first_run/already_ran handles) |
| Sleep | Control | Pauses the run for a configured duration |
| Trigger Flow | Control | Runs another flow as a sub-flow and returns its result |
| Input | Control | Flow entry point |
| Output | Control | Flow exit point and result formatting |
Passing data between steps
Every run carries one shared data envelope. input holds the values produced by
the step that just ran; session_storage holds values that persist across steps
and across turns of the same session. Steps read from it and write back into it,
and the Code/Condition steps address its fields directly:
UO_Data.session_storage.employee_id = UO_Data.input.text;Address the fields beneath the envelope — the envelope itself is not something
you construct. Its live contents after each step are visible in the Data tab
of the flow test panel, streamed on every flow_step event.
Error fallback routing
Any non-structural step can declare an On error, go to target. If that step
raises, the run routes to the target instead of failing; steps without a target
keep the default behavior of aborting the whole run. The fallback is drawn as a
dashed red on error edge. It doesn't count as a normal outgoing connection
during validation, so a step reachable only through an error branch is still
reported as a dead end.
Versioning & execution
Updating a flow increments its version. Executing a flow runs the full workflow with the same streaming and checkpointing infrastructure used for single-agent execution.