Every agent failure that makes the news tends to look like a single bad decision: one model, one tool, one moment of poor judgment. The Friday Order-of-Operations Incident shows why that framing is usually wrong. The damage here came not from any action being individually unreasonable, but from the sequence in which individually authorized actions were executed, turning a routine workflow into a production incident. When you grant an agent permission to act, you are also granting it permission to act in an order.
The shift was supposed to be boring. A routine database migration, the kind the team had run a dozen times before, scheduled for Friday afternoon because traffic dips over the weekend. The agent had been given its usual authorization set: access to the staging environment, permission to run the migration script, and the ability to promote the change to production once its own tests passed. Every one of those permissions was individually defensible.
The sequence was the failure
The incident began the way most do, with an order-of-operations problem rather than a logic problem. The agent ran its test suite against staging, got a green result, and moved to promote. But the test suite it ran was the stale one, cached from an earlier session, because the agent had checked out the old branch before pulling the latest migration definition. Nothing in its authorization required it to pull first. It was allowed to run tests, so it ran them, on the wrong version, and the tests passed.
What followed was a chain of individually reasonable steps. The migration ran against production. It succeeded, because the schema change was backward compatible on its own. Then the agent, following its instructions to verify the deployment, checked the application logs, found warnings that had been there for weeks, and escalated them to the on-call channel. That escalation triggered an automated rollback playbook, which reverted the migration, which orphaned the new data, which took the team the rest of Friday evening to untangle.
The deployment was not the mistake. The stale test was not the mistake. The escalation was not the mistake. The mistake was that nothing in the authorization model cared about the order in which those steps happened.
Approvals are not the same as sequencing
This is the hard lesson, and it applies well beyond this one incident. Most agent governance today treats authorization as a set of independent booleans. The agent may call this tool. The agent may access that resource. The agent may execute this action. What that model cannot express is that the agent must pull before it tests, must test against the deployed version before it promotes, or must verify a rollback path before it mutates production data.
The industry is starting to build tools for this gap. AWS recently released Dogwood, an Apache-2.0 governance language explicitly designed to enforce sequence-aware rules over AI-agent tool calls, including approvals, ordering, and rate limits. The ability to express "you may do B only after A has completed successfully" as a machine-checkable constraint, rather than a hope in a prompt, is the difference between an agent that is allowed to do the right thing and one that is caused to do it.
None of this is new in principle. The engineering discipline of identifying dependencies and enforcing them in build pipelines is as old as the Makefile. The shift is that the actor being sequenced is now an agent that will happily execute steps in any order its permissions permit, and that its permissions rarely encode the dependency graph.
The scaffolding collapse
There is a documented story that captures this mechanism precisely, the collapse of a scaffolding structure, where no single component failed. In the analysis published afterward, investigators found that every beam and connection met its individual specification. The structure failed because of the sequence in which components were loaded during construction, an order that put stress on connections before the bracing that would have supported them was in place. Each piece was sound. The arrangement was not.
An agent executing a workflow under independent permissions is the same structure. Each authorization is a beam that meets spec. The question is whether anything is checking the order in which the load is applied.
What to check before Monday
The concrete fix for most teams is not to buy a governance platform. It is to audit the workflows you already trust to agents and ask one question of each: if this agent does every step it is allowed to do, in the worst possible order, what breaks? Then act on the answer.
Start with the workflows that touch production data or external systems. Encode the dependency order explicitly at the orchestration layer, not in the prompt. If your agent framework supports preconditions and postconditions on tool calls, use them. If it does not, treat that missing capability as a gap worth filling before you expand what the agent is allowed to do. A rate limit is not a substitute for an ordering constraint, and an approval gate is not a substitute for a dependency.
The Friday incident ended with a rollback and a long evening, not a headline. That is the best case for a sequence failure. The team got its data back, the migration ran correctly the next week, and the only lingering cost was trust in the agent, which is precisely the wrong thing to lose. The tool did what it was allowed to do. The team that authorized it is the one that has to live with the order.
Comments
No comments yet.