The Ten Node Types Every AI Workflow Is Built From

Two node types exist purely to define where a workflow begins and where it can finish. They contain no logic of their own, but every valid workflow graph depends on them.

Start

The Start node is the single entry point of a workflow. Every workflow must have exactly one Start node. Execution begins here and nowhere else. The node does not create tasks, invoke agents, or call external services: it simply marks the origin of the graph. If a workflow has no Start node, it cannot execute. If it has more than one, the execution path is undefined.

In the Workflow Editor's Node Palette, the Start node is shown with a green icon. Drag it onto the canvas first, before any other node, and treat its position as the top of the graph. Every other node connects downstream from it, directly or indirectly.

End

The End node is a terminal node that marks workflow completion. A workflow can have multiple End nodes, one for each distinct outcome. This is not just a technical allowance: it is a design tool. A graph with End nodes labeled Approved, Rejected, and Escalated communicates the workflow's possible outcomes at a glance, without reading a single routing rule.

Every execution path through the graph must terminate at an End node. A path that reaches a non-terminal node with no outgoing edge has nowhere to go and will cause the workflow instance to hang at runtime. The Workflow Editor does not prevent you from saving a graph with dangling paths, so checking that every path ends at an End node is your responsibility before publishing a version.

The End node does not create tasks or invoke agents. It is a terminal marker only.

Two node types pause workflow execution and hand control to a person. They are the mechanism by which DAVE keeps humans in the loop at defined points in a pipeline.

User Interaction

The User Interaction node pauses the workflow and creates a task for a specific user or role. The workflow resumes only after the user submits input through that task. This is the correct node type when the workflow needs information from a person before it can continue: a content brief, a topic selection, a set of parameters, or any other input that cannot be determined automatically.

User Interaction nodes generate tasks that appear in the Tasks list for the assigned user. Notifications for the task follow the workspace rule for task.assigned by default, but each node can override this: you can suppress notifications for a high-frequency step, or configure a custom audience that differs from the workspace default. The setting is stored on the node and travels with the workflow version.

When the user submits their input, the values are mapped into the workflow's field context and execution continues to the next node.

Human Review

The Human Review node creates a review task for a human reviewer. The reviewer can take one of three actions: approve, reject, or request changes. Each action produces a different outcome, and the workflow branches based on the reviewer's decision. This makes the Human Review node the natural anchor for any quality gate, editorial approval, or compliance sign-off in a pipeline.

Like User Interaction, the Human Review node generates a task visible in the Tasks list, supports the same notification override options, and pauses execution until the reviewer acts. Unlike User Interaction, its three fixed outcomes (approve, reject, request changes) are designed to drive branching: connect the node to three downstream paths and add routing rules on each outgoing edge to match the corresponding decision value.

Human Review nodes are typically paired with a Routing node immediately downstream to keep the branching logic separate from the review step itself.

Two node types invoke AI agents during workflow execution. Both require an agent to be configured and assigned in the node's properties, and both call the agent's current version when the instance reaches that node. Neither creates a human task: the AI handles the step automatically.

Agent Interaction

The Agent Interaction node invokes an AI agent to process the current workflow context and return a result, without any human involvement. This is the workhorse of an AI workflow: content drafting, summarisation, translation, classification, data extraction, and any other task you want an AI model to perform automatically all belong in an Agent Interaction node.

The node references an agent configured in your workspace. The agent uses the AI provider and model specified in its current version's Config JSON. When the node executes, DAVE calls your AI provider directly using your stored credentials. The result is mapped back into the workflow context and execution continues.

Agent Interaction nodes do not create tasks and do not pause for human input. If you want a human to review the agent's output before the workflow continues, place a Human Review node immediately downstream.

Agent Review

The Agent Review node is an AI-powered automated quality check. An agent evaluates content against defined criteria and returns a pass or fail result. It is the automated counterpart to the Human Review node: where Human Review pauses for a person's judgment, Agent Review runs instantly and returns a structured verdict.

Use Agent Review nodes as automated gates in high-volume workflows where most content is expected to pass and human review is reserved for genuine exceptions. Pair the Agent Review node with a Routing node downstream: route pass results forward automatically and route fail results to a Human Review node or a revision branch.

Agent Review nodes require an agent assignment in the same way Agent Interaction nodes do. The agent's prompt should be written to return a structured, machine-readable verdict so the downstream Routing node can act on it reliably.

Two node types handle the structural and integration work of a workflow: conditional branching and external system calls. Neither invokes an AI agent and neither creates a human task.

Routing

The Routing node is a logic-only node for conditional branching and data manipulation. It evaluates output port criteria to determine which execution path to follow, with no user or AI involvement. It is the most versatile structural tool in the Workflow Editor.

Each outgoing edge from a Routing node carries a routing rule: a condition specifying a field in the workflow context, an operator, a value to compare against, and a priority. DAVE evaluates rules in priority order and follows the first edge whose condition is satisfied. An edge with no rule acts as a default path.

The Routing node's value is in separation of concerns. Branching logic belongs in a Routing node, not embedded in a Human Review, Agent Review, or Safety node. Keeping routing logic separate means you can change a branch condition without touching the functional node that produced the result, and you can read the graph's structure without parsing node configurations.

Common Routing patterns: a decision dispatcher placed after a Human Review node to branch on approve, reject, or request changes; a content type dispatcher placed after a User Interaction node to route different content types to different agents; and a loop controller that routes back to an earlier node when a revision is requested and forward when the result is approved.

API Call

The API Call node calls an external REST API during workflow execution. It sends an HTTP request, captures the response, and maps response values back into the workflow's field context. Use it to push data to an external system (a CMS, a CRM, a webhook endpoint), pull reference data into the workflow, or trigger an action in a third-party service at a defined point in the pipeline.

The node's configuration, set in the Properties Panel, specifies the HTTP method, URL, headers, body template, and response mapping. The body template can reference workflow field values, so the request is dynamically constructed from the current workflow context at runtime.

API Call nodes do not create tasks and do not invoke AI agents. They are integration connectors: the bridge between a DAVE workflow and any external system that exposes a REST endpoint.

Two node types serve specialised purposes: one enforces content policy at runtime, and one documents the graph without affecting execution at all.

Safety

The Safety node runs content safety and compliance checks. It flags or blocks content that violates configured policies. Use it as an explicit safety gate at any point in a workflow where content could be harmful, non-compliant, or policy-violating before it reaches a human reviewer or a downstream system.

The Safety node may generate tasks depending on configuration: in some modes, a flagged result creates a task for a human to assess rather than blocking execution automatically. This makes it flexible enough to serve both as a hard block (stop the workflow on a violation) and as a soft flag (route flagged content to a human reviewer for a final decision).

The Safety node does not require an agent assignment. It runs DAVE's configured safety and compliance checks, which are set at the tenant level. For custom safety logic that uses a specific AI model and prompt, use an Agent Review node with a safety-focused system prompt instead, or combine both: a Safety node for platform-level policy enforcement and an Agent Review node for domain-specific compliance checks.

Placing a Safety node early in a workflow, before content reaches Agent Interaction or Human Review nodes, is the most effective pattern. Catching a policy violation at the input boundary is cheaper and faster than catching it after an agent has processed the content.

Information

The Information node is a documentation and annotation node. It has no effect on execution: it does not create tasks, invoke agents, call APIs, or affect routing. It exists entirely for the benefit of the people who design, review, and maintain the workflow graph.

Drop an Information node next to any part of the graph that needs explanation: a complex routing condition, a loop entry point, a non-obvious agent configuration, or a step whose purpose is not obvious from its label alone. The node's label and config text appear on the canvas and in the Properties Panel, making the graph self-documenting without requiring a separate specification document.

Information nodes are particularly valuable in loops, where backward edges can make the graph harder to read. Annotating the loop entry and exit points with Information nodes makes the intended flow clear to anyone editing the workflow later.

All ten node types in one table, with the properties that matter most for workflow design.

Three design principles that apply to every node type

• One job per node. Each node type is designed for a specific purpose. Do not embed routing logic in a Human Review node or use an Agent Interaction node as a safety gate. Use the node type that matches the job, and use a Routing node to connect the results to the next step. Workflows built on this principle are easier to read, easier to test, and easier to change.
• Every path needs an End node. Trace every possible execution path through your graph before saving a version. Each path must terminate at an End node. A dangling path causes the workflow instance to hang at runtime with no error visible to the user. The node and edge counter in the top-right corner of the Workflow Editor canvas helps you spot unconnected nodes.
• Labels are documentation. The default label for every node is its type name: "Human Review", "Agent Interaction", "Routing". Change every label to something specific before saving. "Senior Editor Approval", "Draft Blog Post", and "Route on Review Decision" communicate intent; the defaults do not. The Properties Panel's Label field is editable for every node type.