Automation works beautifully when reality behaves like the process.

But reality rarely does.

A customer asks for something unusual.

A payment doesn’t fit the normal pattern.

An AI agent encounters a situation it wasn’t designed for.

A production system receives an input nobody anticipated.

A policy conflicts with a real-world case.

The system reaches a point where the rules stop helping.

That’s the exception.

And as we automate more of the normal path, the exception becomes increasingly important.

The Automation Illusion

Imagine a support organization.

Before automation:

100 requests → 60 handled automatically → 40 handled by people

Now AI improves the system:

100 requests → 95 handled automatically → 5 handled by people

That sounds like a massive improvement.

And it can be.

But look at the remaining five.

They aren’t necessarily random requests.

They may be:

• unusually complex
• high-value
• ambiguous
• sensitive
• novel
• poorly understood
• outside the system’s assumptions

The human workload became smaller.

But potentially more difficult.

This creates an important systems principle:

As automation improves the normal path, the exception path becomes more valuable.

The Exception Layer

Every system has at least two paths:

The Normal Path

The situation fits the model.

Rules apply.

Automation works.

The system proceeds.

The Exception Path

Something doesn’t fit.

The system needs to:

Stop → Understand → Decide → Escalate → Adapt

Most organizations invest heavily in the first path.

Very few deliberately design the second.

That’s a mistake.

Because when automation reaches 90%, 95%, or 99%, the remaining 1% can determine whether the system is trustworthy.

AI Makes This More Important

Traditional automation usually follows explicit rules.

AI introduces something different.

The system can now encounter situations that were never explicitly programmed.

An agent might reason:

“This looks similar to what I’ve seen before.”

But similar isn’t identical.

The dangerous question isn’t:

“Can the model handle this?”

It’s:

“What should happen when the model encounters something it shouldn’t handle?”

That’s an architecture question.

Don’t Design Only for Success

A mature system doesn’t only define:

What should happen when everything works?

It defines:

What happens when the system is uncertain?

For an AI agent, that might mean:

High confidence

→ Execute

Medium confidence

→ Ask for clarification

Low confidence

→ Escalate

High-impact + uncertain

→ Require approval

This is more useful than simply asking whether the model is accurate.

Because accuracy isn’t the same as safe autonomy.

The Exception Architecture

A practical exception layer has five components.

1. Detection

The system needs to recognize that it has left the normal operating range.

Signals might include:

• low confidence
• conflicting information
• missing context
• unexpected inputs
• policy violations
• unusual transaction values
• repeated failures
• model disagreement

You can’t manage an exception you can’t detect.

2. Containment

Once an exception is detected, prevent it from spreading.

Don’t let one uncertain decision trigger ten more automated decisions.

For an AI agent:

Stop the chain.

Preserve the state.

Limit permissions.

Prevent irreversible actions.

This connects directly to the Reversibility Principle from the previous issue.

3. Escalation

Not every exception needs a senior executive.

Design an escalation path based on:

Impact × Uncertainty

Low impact + low uncertainty:

→ Automate

High uncertainty:

→ Review

High impact:

→ Escalate

High impact + high uncertainty:

→ Human decision

The important part is that escalation should be designed, not improvised.

4. Resolution

When a human receives an exception, don’t simply give them:

“Something went wrong.”

Give them:

• what the system was trying to do
• what it expected
• what actually happened
• relevant context
• available options
• recommended action
• potential consequences

The human should receive the decision surface, not just the error message.

This is where good interfaces matter.

5. Learning

An exception should produce more than a ticket.

Ask:

“Why did this happen?”

Then classify it.

Was the:

• rule wrong?
• model wrong?
• context missing?
• interface unclear?
• policy incomplete?
• workflow poorly designed?
• assumption outdated?

If the same exception appears repeatedly, it isn’t really an exception anymore.

It’s a missing capability.

The Exception Loop

This gives us a useful operating cycle:

Exception

↓

Detect

↓

Contain

↓

Escalate

↓

Resolve

↓

Learn

↓

Improve the normal path

↓

Fewer exceptions

This is how mature systems evolve.

The exception becomes feedback.

The Dangerous Alternative

Many organizations handle exceptions like this:

Something unusual happens

↓

Someone manually fixes it

↓

Everyone moves on

↓

It happens again

↓

Someone manually fixes it

↓

Repeat

This creates invisible operational debt.

The organization is effectively running a second system:

The documented system

and

the system people actually use to handle reality.

That gap grows quietly.

Until one day the exception path becomes the real process.

The Exception Tax

There’s another hidden cost.

When normal work becomes highly automated, organizations often underestimate the cost of exceptions.

Suppose automation handles 98% of transactions.

That sounds excellent.

But imagine those remaining 2% require:

• manual investigation
• multiple approvals
• cross-team coordination
• customer communication
• reconciliation
• special processing

The percentage looks small.

The effort may not be.

So don’t measure only:

Automation rate

Also measure:

Exception rate × Exception cost

And more importantly:

Exception recurrence

If the same exception keeps appearing, the system is telling you something.

Listen to it.

The Human Role Changes

This has a major implication for work.

As systems automate routine decisions, humans increasingly move toward the edges.

Not away from the system.

Toward its boundaries.

Humans handle:

• ambiguity
• novel situations
• conflicting objectives
• ethical constraints
• unusual customers
• strategic trade-offs
• system failures

So the future isn’t necessarily:

AI does the work. Humans supervise.

It may look more like:

AI handles the known space. Humans shape the unknown space.

That requires a different kind of human capability.

Not just execution.

Judgment.

What Leaders Should Design

If you’re deploying AI or automation, ask these five questions:

1. What does the normal path look like?

If you can’t define it, you can’t automate it reliably.

2. What qualifies as an exception?

Make the boundary explicit.

3. Who owns the exception?

Not “someone from operations.”

A real owner.

4. What happens when the exception occurs?

Detection, containment, escalation and resolution should already exist.

5. How does the exception improve the system?

Every recurring exception should become input to architecture, policy, training or process redesign.

The System Layer Test

Here’s the question I would ask before automating any workflow:

“When reality doesn’t fit our model, what happens next?”

If the answer is:

“The system stops.”

You have an exception problem.

If the answer is:

“Someone figures it out.”

You have an ownership problem.

If the answer is:

“The system handles it automatically.”

Ask:

“How do we know it handled it correctly?”

And if the answer is:

“We don’t.”

You have a governance problem.

The Bigger Principle

The goal of automation isn’t to eliminate humans from the system.

It’s to move human attention to where it creates the most value.

That means designing the boundary carefully.

Automate the predictable.

Surface the uncertain.

Contain the dangerous.

Escalate the consequential.

Learn from the exceptional.

That’s what a mature system does.

Closing Thought

The best automated systems aren’t the ones that never encounter exceptions.

They are the ones that know what to do when they do.

Because exceptions aren’t evidence that the system failed.

Sometimes they’re the system telling you:

“Your model of reality is incomplete.”

And that’s valuable information.

The question is whether your architecture is designed to hear it.

The System Layer Test

When reality doesn’t fit your model, what happens next?

If you don’t have a deliberate answer…

you don’t have an exception strategy.

You have an exception hope.

The System Layer — Majid Nisar

Thinking clearly about products, software, leadership, and AI by examining the systems beneath them.

Read the full issue on LinkedIn →

The System Layer publishes on LinkedIn. Subscribe here.