Nobody Wrote Down the Order
Backfill before cutover. Check before you drop. The sequence that keeps you out of an incident lives in one engineer's memory and in no document.
Read your own runbooks and you will notice they are lists of things to do. They are rarely lists of things to do in an order, because by the time somebody sits down to write a runbook the order has stopped feeling like information. It is just how you do it. So the steps get written down and the sequence does not, and the sequence is the part that decides whether Thursday is uneventful.
Backfill before the cutover. Verify what depends on the table before dropping it. Take the lock before the read, not between the read and the write. Confirm the payment settled before you tell the customer it did. None of these are clever. Every one of them is the residue of somebody getting it the wrong way round once, and the reason you know it is that you were there, or you inherited it from someone who was.
Order is learned, not documented
Documentation is written by people who already know the answer, which is exactly the wrong vantage point for capturing sequence. The steps are legible to a newcomer. The order is invisible to the author, because to them it is not a decision, it is just what the work is.
That leaves order in an awkward category. It is real, it is consequential, and it exists almost nowhere in writing. It lives in the engineer who ran the last migration, and it survives in your organization for exactly as long as that person does.
An agent walking into this has the steps and not the sequence, so it orders the work by what looks reasonable, which is usually the order the task was described in. That is fine right up until it is not. In a study of 20,574 real coding-agent sessions, acting before establishing what the action depended on was one of the named recurring causes of failure, sitting alongside the agent simply not following an instruction it had been given.
The cost is lopsided
Getting the order wrong on reversible work costs you minutes and some irritation. You notice, you redo it, nobody writes it up.
The trouble is that sequence matters most precisely where reversibility runs out. Dropping the table, running the cutover, sending the notification, releasing the funds. Those are the steps where order stops being about efficiency and starts being the only thing standing between a routine change and an incident review, and they are increasingly the steps teams are handing to agents, on the reasonable grounds that they are repetitive and well understood.
They are well understood by the people who learned them the hard way. That is the part that does not transfer with the task description.
What changes when the order carries
The order is learnable. It just cannot be learned from documents, because it was never in them. It can be learned from what actually happened: which sequence produced a clean run, which one produced the rollback, which precondition turned out to matter on the third attempt rather than the first.
Agents on Hyperstruck accumulate that. The precondition that mattered once holds the next time the same shape of work comes around, without anyone remembering to mention it, and the sequence stops being a property of who happens to be running the task.
What you notice first is not that the agent got more careful. It is that the order stopped being your job to supervise, and the knowledge that used to live with whoever ran the last migration now outlives them being on the team.