Building Automation Workflows

Automations in MarkDocket are visual graphs you build on a ReactFlow-powered canvas. Each node represents a discrete step — a catalog action, an AI agent invocation, or a conditional branch — and edges define the order of execution. When a run is triggered, each node executes as its own durable, checkpointed step, so a failure or restart resumes from the last completed node rather than replaying the entire workflow.

Opening the Automation Builder

From your dashboard, navigate to Automations and either create a new automation or open an existing one. The builder canvas occupies the main panel; a node palette sits on the left, and a properties panel appears on the right whenever a node or edge is selected.

Adding Nodes

To add a node, drag an action type from the palette onto the canvas, or click Add Step at the bottom of an existing node.

The builder supports several node types:

• Catalog action nodes — call a specific MarkDocket tool (trademark search, watch setup, filing submission, and so on).
• Agent nodes — run an AI agent turn with a prompt you define. Agent nodes mint fresh delegated credentials for each execution and can use BYOK (Bring Your Own Key) AI provider settings if you have configured them. Note that BYOK applies only to agent nodes inside automation runs.
• Async action nodes — enqueue a long-running job (such as a prior-art scan) and wait up to two hours for a terminal result before continuing.
• Conditional nodes — branch the graph based on the output of a previous step.

Wiring Edges

Edges define execution order. To connect two nodes, hover over the source node until its output handle appears, then drag to the input handle of the target node.

When you add a new action node from the palette, the builder auto-wires it to the single open tail of the current graph — the last node that has no outgoing edge. If your graph has multiple open tails (for example, after a branch), you must manually choose which tail to connect. The auto-wire behavior keeps linear workflows fast to build without requiring you to drag handles for every step.

Graph constraints

• Each node may have at most one primary input edge from the linear execution path (branches are handled by conditional nodes).
• Cycles are not permitted; the canvas prevents you from drawing an edge that would create a loop.
• Disconnected nodes are saved but will not execute — a validation warning appears before you can activate a workflow with unreachable nodes.

Template Variable Bindings

Nodes pass data to one another through template variables. When you add a new action node, the builder automatically creates variable placeholders for its required inputs using the syntax {{vars.key}}. You can also type this syntax directly into any input field in the properties panel.

How bindings work

• {{vars.key}} references a named variable in the run's variable scope.
• Variable values can be set in the Run Variables panel (the gear icon on the canvas toolbar) as static defaults, or written dynamically by earlier nodes whose output maps to a variable name.
• When you reference a variable that does not yet exist, the builder prompts you to create it with an initial value.
• Variables are plain strings at rest; the execution engine resolves them before each node runs.

Binding outputs to variables

Select a node and open its Output Mapping tab in the properties panel. Use the path selector to pick a field from the node's expected output shape, then assign it a variable name. Downstream nodes that reference {{vars.thatName}} will receive the resolved value.

Billing Blocks During Runs

If a node encounters a billing limit mid-run, the run is suspended rather than failed. You will see the affected node highlighted in the trace overlay (described below) with a billing_blocked status. Resolve the billing requirement from the notification or billing dialog that appears, then resume the run from the Runs panel. Suspended runs do not count against your active concurrency limit.

Viewing the Run Trace Overlay

Every completed or in-progress run records a per-node outcome. To inspect a past run without leaving the builder:

1. Open the Runs tab in the right panel.
2. Click any run in the list.
3. The canvas overlays each node with a status badge:

The overlay is applied non-destructively — your graph definition and any unsaved edits are preserved. Clicking another run swaps the overlay to that run's outcomes. Clicking Clear Trace removes the overlay and returns the canvas to its editable state.

Inspecting a node's step output

Click any overlaid node to open its Step Detail drawer, which shows:

• The resolved input values (with variable bindings expanded to their actual values for that run).
• The raw output returned by the action.
• Any error message and the retry count if the step was retried before failing.
• The wall-clock duration of the step.

Activating and Triggering Workflows

Once your graph passes validation (all nodes connected, all required variables defined), click Activate in the toolbar. Activated automations can be:

• Triggered manually from the Runs panel.
• Scheduled using the trigger settings in the automation's settings panel.
• Called from the API or CLI — see Managing Automations from the CLI for details.

Deactivating an automation does not cancel in-progress runs; it only prevents new runs from starting.

Saving and Versioning

The builder saves your graph on every Activate action and whenever you click Save Draft. Drafts are not executed. The run trace overlay always reflects the graph definition that was active at the time each run was triggered — viewing an old run on a graph you have since edited is safe and will not apply old definitions to future runs.