The Node Workbench made agent debugging visible.

A graph editor is easy to draw and hard to operate. The first version can make a diagram look convincing, but the real question arrives later: which node touched run state, why did a condition branch fire, which trigger payload field was missing, and why did the model call a tool at that point?

The Workbench was built for those questions. It is not only a canvas. It is the operator view of how one run moved through agents, deterministic nodes, state projections, and tool calls.

The important shift is that the editor now speaks the same language as runtime: trigger contract, run state, node config, edge behaviour, graph version, and step result. That removes the translation layer where bugs hide.

A support graph, a booking pipeline, and a human-approval workflow can look different on the canvas while still sharing the same inspectable lifecycle.

Run State made long-running work coherent. It gives workflows a typed object they can read, patch, project, and carry across handoffs, waits, approvals, fanout branches, and resumptions. The debugger makes that object visible at each step.

That matters because agent debugging is rarely about one wrong sentence. It is usually about a missing field, a stale projection, a policy that allowed a node to write more than it should, or a resume path that skipped a guardrail.

{
  "customer": { "email": "maria@example.com" },
  "booking": { "date": "2026-05-18", "status": "pending" },
  "approval": { "required": true, "queue": "operations" }
}

Before this work, debugging a graph meant reading logs, replaying mentally, and hoping the reproduction hit the same path. After it, an admin can inspect the run as a sequence of node-level events and ask a much sharper question: did the orchestration do the wrong thing, or did the model make a poor choice inside a correct step?

That distinction is crucial. The first is a product bug. The second is a prompt/tool/guardrail problem. Mixing them creates slow teams.