Automations Overview

Automations let you build and run graph-based workflows that connect MarkDocket's IP intelligence tools into repeatable, multi-step pipelines. Each automation is a directed graph of nodes; when you trigger a run, MarkDocket executes that graph as a durable background function — resuming after failures, checkpointing after every node, and surfacing results back in the dashboard.

What is an Automation?

An automation is a saved workflow graph made up of nodes connected by edges. Nodes represent individual actions — running an agent, calling a catalog tool, sending a notification, and so on. Edges define the order in which nodes execute.

You build automations visually in the Automation Builder, a canvas-based editor. When you add a new action node from the palette it is automatically wired to the open tail of the graph, and relevant variables are pre-populated with {{vars.key}} template bindings so you can pass data between nodes without manual configuration.

Node Types

Agent Nodes

Agent nodes run an AI turn against MarkDocket's agent service. Each execution mints a fresh delegated token scoped to that run, so agent nodes can access MarkDocket tools (trademark search, prior-art lookup, clearance checks, and others from the tool catalog) on your behalf. BYOK (Bring Your Own Key) users can route agent nodes through their own AI provider keys — this capability is limited to agent nodes inside Automation Runs only.

Catalog Action Nodes

Catalog action nodes call a specific tool from the MarkDocket tool catalog — the same catalog used by the CLI, the MCP server, and the /v1/tools API. These nodes are synchronous where the underlying tool returns quickly, or asynchronous where the tool enqueues a background job (for example, a USPTO filing status check or a brand-intel clearance scan).

For async catalog actions, the run pauses and waits up to two hours for the background job to reach a terminal state before proceeding to the next node. If the job does not complete within that window, the node times out and the run fails at that step.

Other Node Types

The builder supports additional node categories for control flow and notifications. Refer to the individual node reference pages for configuration details specific to each type.

How Runs Execute

Every automation run is executed as a durable function backed by Inngest. This has several practical consequences:

• Per-node checkpointing. Each node runs inside its own isolated step. If a node succeeds, its result is memoized. If the run process restarts for any reason, execution resumes from the first node that has not yet completed — already-completed nodes are not re-run.
• Automatic retry. Failed nodes are retried according to the run's retry policy without restarting the entire graph.
• Long-running support. Because runs are durable, an automation can span hours of wall-clock time — waiting for async jobs, agent completions, or external events — without holding a long-lived HTTP connection.

Run Execution Trace

Once a run completes (or while it is in progress), you can select it in the Automation Builder to see a live trace overlay. Each node in the graph is colorized by its execution outcome — succeeded, failed, skipped, or still running — without discarding any unsaved edits to the graph itself.

Billing During Runs

Automations interact with MarkDocket's billing system at two points:

1. Per-node metering. Each node that consumes a billable action (agent AI turns, tool calls, research jobs) is metered individually as the run progresses.
2. Billing blocks. If a node encounters a billing limit — for example, your plan's usage cap is reached mid-run — the run is suspended cleanly rather than marked as failed. The run stays in a suspended state, and you can resolve the billing requirement from the dashboard and resume. Suspended runs are distinct from failed runs and do not consume a retry.

Concurrency

MarkDocket enforces a fair-share concurrency limit of 2 simultaneous runs per user. If you trigger a third run while two are already executing, it will be queued until one of the active runs completes.

Optimistic Concurrency on Updates

When you update an automation — whether from the builder UI or via the CLI — MarkDocket performs an optimistic concurrency check using the automation's last-updated timestamp. If another change was saved between the time you loaded the automation and the time you submitted your update, the save is rejected and you are prompted to reload. This prevents silent overwrites when multiple sessions or automation scripts modify the same workflow concurrently.

Running Automations from the CLI

You can manage and trigger automations using the @markdocket/cli package. The markdocket automations update command always fetches the current automation state before applying changes, and passes the live updatedAt value as a concurrency guard — so CLI-based updates get the same protection as UI-based saves.

See the CLI reference and Automations CLI commands for full usage details.

Next Steps

• Building your first automation
• Node reference
• Automation runs and history
• BYOK for Automation Agent Nodes