A visual workflow canvas gives your team a shared, inspectable representation of how agents, conditions, and approvals are wired together. Instead of reading code or configuration files to understand a multi-step process, you see the flow as a directed graph — nodes for the work units, edges for the transitions — and you can reason about it before triggering a single run.

Why a visual canvas matters for agent workflows

Agentic workflows are harder to reason about than traditional automation pipelines. A node does not just execute a fixed function; it invokes an agent that can call tools, loop, make decisions, and produce variable output. When several agents are chained together with conditional branches and approval gates, the control flow becomes non-obvious quickly. For a broader look at the patterns involved, see orchestration patterns for multi-agent systems.

A visual canvas externalises that complexity. You can trace the path from entry to terminal node with your eyes, spot missing branches, and catch ambiguous handoffs before they become runtime failures. The diagram is also a better communication surface than a JSON payload when you need to explain a workflow to a product manager or a compliance reviewer. For a practical look at how real-time collaboration works across workflow sessions, see Real-Time Collaborative Workflow Editing.

The building blocks: nodes and edges

The fundamental unit of a workflow is a node. Each node type corresponds to a distinct kind of work:

  • Agent nodes delegate a task to a named agent. You configure which agent handles the node and what context it receives.
  • Condition nodes evaluate a logical expression and route execution down different edges depending on the result.
  • Approval nodes pause execution until a designated human approves or rejects the step — essential for high-risk or irreversible actions.
  • Guardrail nodes apply content checks to inputs or outputs before the flow continues, acting as inline policy enforcement.
  • Sub-workflow nodes embed an existing workflow as a reusable step, so common sequences do not need to be duplicated across graphs.

Edges connect nodes and carry the transition logic. An edge from a condition node, for example, is labelled with the branch it represents. The graph as a whole is what gets persisted and versioned.

Configuring nodes without touching a config file

Each node has its own side panel. When you select a node on the canvas, the panel opens and lets you set agent assignment, input mappings, timeout behaviour, and any node-specific parameters. This keeps configuration co-located with structure: you see the node in context and configure it in the same view.

The panel-based approach also enforces a degree of schema validation at authoring time. Fields that an agent node requires — like which agent to invoke — are surfaced as explicit inputs rather than free-form text that might be mistyped later.

Versioning: every save is a snapshot

Every time you save a workflow, the platform records a version snapshot of the complete graph. Version history is accessible from the editor: you can browse prior states, inspect what changed between versions, and roll back to any previous snapshot if a change misbehaves in testing.

This is the same discipline applied to code — treat the workflow definition as an artefact under version control, not a mutable configuration. Rollback gives you a safety net when iterating quickly, and the version list gives auditors a record of how the workflow evolved over time. The versioning and rollback mechanics are covered fully in versioning and rollback for AI agents.

Praesidia's workflow editor is built on this version-first model. Every save records a new snapshot, and any previous version can be restored as the current live graph through the version history panel.

Collaborating on a workflow in real time

Multiple team members often need to work on the same workflow simultaneously: one person adjusting the agent assignments while another updates the approval routing. Without coordination, concurrent edits collide and changes are lost.

Praesidia's canvas synchronises edits across participants in real time. Each team member's cursor and changes are visible to everyone in the same session, and edits merge without locking the canvas or forcing anyone to wait. Presence indicators show who is working on which part of the graph. The result is closer to collaborative document editing than the traditional save-and-reload cycle.

Reasoning about the flow before it runs

A workflow on the canvas is a plan. Before you activate it and connect a trigger, you can walk through every path mentally — or with a colleague — and ask: what happens if the condition node evaluates false? What does the approval node do when the approver is unavailable? Is there a terminal node on every branch?

This pre-flight reasoning is much cheaper than discovering a gap after a workflow run fails in production. The visual representation makes edge cases visible that would be easy to miss in a flat list of steps.

Once the design is stable, you assign a trigger (a cron schedule, a signed webhook, or an internal platform event) and the workflow is ready for execution — the full trigger options are described in triggering workflows: scheduled, webhook, and event. The canvas design phase and the execution phase are deliberately separate so that changes to a live workflow require an intentional save-and-version step rather than an accidental in-place edit.

Sub-workflows and reuse

Complex organisations accumulate repeating patterns: a standard escalation sequence, a data-enrichment pass before every agent handoff, a compliance check that appears in multiple processes. Sub-workflow nodes let you extract those patterns into a standalone workflow definition and reference them from any other graph.

When the shared sequence changes, you update it once and all referencing workflows pick up the new version on their next run. This is the same modularity principle as functions in code, applied to visual workflow design.

A visual canvas is not just a diagramming tool — it is the source of truth for how your agents cooperate. When the diagram is authoritative, versioned, and collaborative, it becomes something you can show to a security reviewer, hand to an on-call engineer, or audit against a compliance requirement. See executing and monitoring workflow runs to understand what happens once you activate a canvas design, or explore reusable workflow templates for patterns you can adopt without starting from scratch. If you prefer to generate an initial workflow structure from a natural-language description rather than building from scratch, chat-to-build: generating workflows with AI covers that approach.

Common questions

Can I edit a workflow that is already live? Yes. You can modify a live workflow from the canvas at any time. The save operation creates a new version snapshot, so the previous graph is preserved and can be restored via rollback. Only the version explicitly set as current is executed by new runs; in-flight runs continue against the version they started with.

What node types are available for policy enforcement? Guardrail nodes let you apply content checks inline within the flow — for example, scanning agent output for sensitive data before it is passed to the next step. Approval nodes add a human gate for actions that require explicit sign-off. Both are first-class node types on the canvas, not add-ons configured elsewhere.

How does version rollback work if a change breaks a workflow? The version history panel lists every saved snapshot with a timestamp. Selecting a prior version shows its graph, and triggering a rollback makes that version the active definition. Subsequent runs use the rolled-back graph. The change is itself recorded as a new version entry, so the rollback action is traceable in the history.