We spend a surprising amount of time trying to make systems certain.

Predict the demand.

Choose the right architecture.

Pick the right model.

Approve the right strategy.

Make the right decision.

But uncertainty doesn’t disappear because we built a better plan.

And AI is making one thing particularly dangerous:

It is becoming much cheaper to act on a decision before we’re completely sure about it.

That changes how systems should be designed.

The goal isn’t to predict the future perfectly.

The goal is to make being wrong survivable.

Speed Changes the Cost of a Decision

Imagine a product team considering a new feature.

Before AI:

Research → Design → Build → Test → Launch

The process takes weeks.

That creates friction.

But that friction also creates something valuable:

time to discover that the idea might be wrong.

Now AI can generate the prototype in an afternoon.

The team can build five versions before the old process would have finished one.

That’s powerful.

But there’s a new question:

How easily can we undo the decision if version three turns out to be wrong?

Because faster execution doesn’t just accelerate success.

It accelerates commitment.

And commitment is where systems become dangerous.

Reversible vs. Irreversible

Not every decision deserves the same amount of process.

Consider two decisions:

Changing the UI color

and

Migrating customer data to a new architecture.

Both are decisions.

But the cost of reversing them is radically different.

One can be changed in minutes.

The other might take months, disrupt customers, create compliance issues, and leave permanent consequences.

Yet organizations often process both through roughly the same machinery:

Meeting.

Approval.

Implementation.

Done.

A better system distinguishes between them.

Reversible decisions

Make them:

• fast
• delegated
• cheap to test
• easy to rollback

Hard-to-reverse decisions

Make them:

• explicit
• observable
• constrained
• reviewed more carefully
• staged before full commitment

The principle is simple:

The harder a decision is to reverse, the more deliberately the system should make it.

AI Makes This More Important

AI changes the economics of experimentation.

A developer can now generate a prototype in hours.

An analyst can explore dozens of scenarios.

A product manager can produce multiple specifications.

An agent can execute workflows continuously.

This creates enormous optionality.

But optionality only has value if you preserve it.

If your AI system immediately commits to production, sends the customer communication, modifies the database, or spends money, you’ve converted a reversible experiment into an irreversible action.

That’s the real architectural challenge.

Don’t just make AI capable of acting.

Design how easily its actions can be undone.

The Reversibility Stack

A practical AI system can be designed around several layers.

1. Sandbox

Let the system experiment without affecting production.

Think before act.

2. Checkpoint

Capture the state before a meaningful action.

If something goes wrong, you have somewhere to return to.

3. Approval

Introduce human approval when the consequence crosses a defined threshold.

Not every action needs approval.

Irreversible actions often do.

4. Limits

Give the system explicit boundaries.

For example:

• spending limits
• data access limits
• API permissions
• rate limits
• environment restrictions

Autonomy without boundaries is simply uncontrolled reach.

5. Rollback

Make reversal technically possible.

Feature flags.

Versioning.

Database recovery.

Deployment rollback.

Transaction reversal.

The specific mechanism changes by system.

The principle doesn’t.

If you can’t undo it, you need to think harder before doing it.

6. Auditability

When something goes wrong, you need to know:

What happened?

Why did it happen?

What information was available?

What decision was made?

Who or what authorized it?

Without that trail, reversibility becomes much harder because you can’t reliably reconstruct the system’s state.

The Autonomy Question

This also changes how we think about AI agents.

The question shouldn’t simply be:

“Can the agent do this?”

That’s a capability question.

The better question is:

“What happens if the agent is wrong?”

Then classify the action.

ActionReversibilitySystem responseDraft an emailHighAutomateCreate a test environmentHighAutomateOpen a development ticketHighAutomateDeploy to stagingMediumAutomated with checksDeploy to productionMedium/LowGuardrails + approvalDelete customer dataLowStrong controls + approvalTransfer significant fundsVery lowExplicit authorization

The point isn’t that one universal approval policy exists.

The point is:

Autonomy should correspond to consequence and reversibility.

The Organizational Version

This principle isn’t only about software.

It applies to leadership too.

Suppose a manager can make a decision affecting one person.

Should they need three levels of approval?

Probably not.

Now consider a decision affecting an entire organization.

Should one person be able to make it in five minutes?

Probably not.

The system should create a relationship between:

Decision scope → Reversibility → Authority

Small and reversible decisions can move quickly.

Large and irreversible decisions need stronger decision architecture.

This is how organizations avoid two opposite failures:

Too much bureaucracy

and

too much uncontrolled autonomy.

The Hidden Cost of AI Speed

There’s another reason this matters.

When execution becomes cheap, organizations can accumulate commitments faster than they can evaluate them.

More:

• features
• services
• agents
• automations
• workflows
• integrations
• policies
• dependencies

The system becomes increasingly difficult to change.

This is where the ideas from earlier issues connect.

The Coordination Tax grows.

The Interface Economy becomes more important.

The Comprehension Bottleneck becomes harder.

And eventually you get a system where everything works…

but nothing is easy to change.

That’s a different kind of technical debt.

Commitment debt.

Design for Optionality

A resilient system doesn’t ask:

“How do we make the perfect decision?”

It asks:

“How do we keep our options open while we learn?”

That leads to very different architecture.

Instead of:

Decide → Commit → Hope

Design for:

Experiment → Observe → Learn → Decide → Commit

And wherever possible:

Commit in stages.

Canary releases.

Feature flags.

Progressive rollouts.

A/B tests.

Versioned APIs.

Sandbox environments.

Approval gates.

Kill switches.

These aren’t merely technical practices.

They are mechanisms for preserving the ability to change your mind.

The Reversibility Audit

Here’s a simple exercise you can run with your team.

Take the ten most important automated decisions in your system.

For each one, ask:

1. What happens if we’re wrong?

2. How quickly would we discover it?

3. How difficult is it to reverse?

4. Who has authority to reverse it?

5. Can we test it before committing?

6. What is the smallest safe version of this decision?

You will probably discover something interesting.

Some decisions have enormous consequences but almost no rollback mechanism.

Those are your architectural pressure points.

The System Layer Test

Before allowing an AI system to act autonomously, ask:

“If this decision turns out to be wrong tomorrow, how hard is it to undo?”

If the answer is:

“Easy.”

You probably have room for more automation.

If the answer is:

“Expensive.”

Add safeguards.

If the answer is:

“We don’t know.”

You have an architecture problem.

The Deeper Principle

We often think good systems are systems that make good predictions.

But prediction is fragile.

The future changes.

Customers change.

Markets change.

Requirements change.

Models change.

Our assumptions change.

A better system doesn’t eliminate uncertainty.

It contains uncertainty.

It creates room to experiment.

It makes mistakes visible.

It limits their blast radius.

And most importantly…

it preserves the ability to change direction.

The Reversibility Principle

The strongest systems aren’t necessarily the ones that make the best decision the first time.

They’re the ones that make wrong decisions cheap to discover and cheap to undo.

That is increasingly important in an AI world.

Because AI is making execution cheaper.

Which means decisions will happen faster.

And when decisions happen faster, the ability to reverse them becomes a competitive capability.

So don’t ask only:

“Can we automate this?”

Ask:

“Can we safely undo it?”

That question belongs in architecture.

In product.

In governance.

And increasingly…

in every AI system we build.

The System Layer Test

If this decision is wrong tomorrow, how hard is it to undo?

If the answer isn’t clear, don’t add more autonomy.

Design for reversibility first.

The System Layer — one layer deeper, every week.

Majid Nisar

Read the full issue on LinkedIn →

The System Layer publishes on LinkedIn. Subscribe here.