A contract can follow its code exactly and still act against what the parties need. When I spoke with Amy Wan in 2018, she explained why the appeal of self-executing transactions has to be matched by a way to respond when facts, intent, or conditions change.
A smart contract cannot decide by itself when the agreed path no longer fits the real transaction. That is where recourse, governance, and human judgment have to enter the design.
Certainty matters more than novelty
Amy Wan described the early blockchain market as a place where users were expected to accept losses, coding mistakes, and unintended outcomes as if that were simply the price of entry. She did not see that as sustainable. Mainstream users and small businesses do not want a transaction tool that becomes untouchable the moment something goes wrong.
That point translates beyond blockchain. If a project system can trigger payment, release a document, transfer a right, or lock in a commitment, the people using it need to know what happens when the source data is wrong or the situation changes. A fast process does not create confidence by itself. Confidence comes from knowing how the process behaves when something unexpected shows up.
Rigid logic breaks first when conditions move
Amy Wan gave a practical explanation for the problem. Contracts are written in the middle of an unpredictable world. A legal team can spend hours trying to account for every possibility and yet miss the condition that changes the deal. If the code is rigid and the context shifts, the system can execute the wrong action or get stuck waiting for a condition that no longer fits the transaction.
That is why Amy's framing matters. She described Sagewise as a safety net, not as a replacement for the original contract logic. The purpose was to let parties pause, amend, self-resolve, terminate, or bring in a third party when the contract no longer matched reality.
For project teams, that is a useful test. Before automating a workflow, ask what the team will do when the approved path stops matching the facts on the ground. If the only answer is that the system already ran, the design is incomplete.
A backdoor is not the same thing as governance
Amy Wan also warned about centralized override power. It can be tempting to solve flexibility by giving one administrator the power to reverse or change anything. She argued that this creates a different kind of risk. The system may look decentralized until one person, or one compromised credential, controls the outcome.
That is not a small detail. It changes the whole trust model.
The better question is not whether the contract can be changed. It is who can initiate that change, under what conditions, with what record, and with what escalation path if the parties disagree. In other words, the flexibility has to be governed, not hidden in a privileged shortcut.
Amy Wan made the limit explicit: “Blockchain and smart contracts are not the panacea to all of society's ills.” She said many proposed blockchain uses should probably stay conventional databases. She wanted teams to start with user behavior and transaction fit, not with the assumption that every system becomes better once blockchain is added.
The goal is not to make people learn more technical machinery than they need. It is to make the transaction more dependable. If a system adds complexity while leaving the user with the same uncertainty, it is not really solving the problem.
One useful way to test that idea is to review a current automated approval, payment, or document workflow and map the exception path before the next change request forces it. Who can pause it? Who can review it? What record shows why the change happened? Those answers reveal whether the workflow was designed for real work or only for the happy path.
Before a team automates a commitment, it should decide how people can pause, review, and change it when the facts move. The exception path is part of the contract, not an afterthought to the code.
