Why agent workflows need a graph, not a queue

The first agent we put into production ran for eleven days before it charged a customer twice. Nothing in the logs looked wrong. The model had done exactly what it was asked, twice, because the process that asked it had restarted halfway through a step.

What a queue cannot tell you

A queue knows that a message was delivered. It does not know that the message was step four of nine, that step three produced a document the model now depends on, or that step four had already called a payment API before the worker died.

We tried to make it know. Every message grew a header with the run id, the step number, the hash of the previous output. Within a month the headers were the system, and the queue was a slow, expensive way to move them around.

What a graph gives you

A graph of typed steps makes three things explicit that a queue leaves implicit.

Order and dependency. Step four cannot start until step three has a recorded result. That sounds obvious; it is not what most agent loops actually enforce.

Idempotency. Each step has a key derived from its inputs. A retry with the same key gets the same result without calling the model or the API again.

An audit trail you can read. When a customer asks why something happened, you walk the graph. Every node has the prompt, the response, the tool call and the timestamp.

const run = graph()
  .step('fetch-invoice', fetchInvoice)
  .step('match-po', matchPO, { after: ['fetch-invoice'] })
  .step('charge', charge, { after: ['match-po'], idempotent: true });

What it cost us

Building this took longer than bolting headers onto a queue. It also ended the duplicate charges, and it turned “what did the agent do” from an afternoon of log archaeology into a page.

That is the trade we would make again, and it is the reason GraphSmith exists.