The Exception Problem: Building Flexibility Into Structure

Pawel Zimoch · ~13 min read · Essay 06

Rigid rules create bad outcomes at the edges.

"No refunds after 30 days" makes sense as policy. It prevents abuse, creates predictability, bounds liability. But on day 31, with a loyal customer and a legitimate complaint, enforcing it rigidly is worse for the business than making an exception.

Humans understand this intuitively. The rep thinks: "The rule exists to prevent abuse. This isn't abuse. The spirit doesn't apply here. I'll make an exception."

This is judgment - the ability to recognize when a rule's letter conflicts with its spirit, and act on the spirit instead.

When you automate with AI agents, you face a dilemma. Rigid rules create bad customer experiences. But flexible "use your judgment" creates ungovernable systems - gaming, inconsistency, audit failures, eroded rules.

How do you get flexibility without losing control? And how do you reconcile flexibility with the discreteness and redundancy that error correction requires?

Rules Are Proxies for Intent

First, understand why the problem exists.

Humans think in fuzzy concepts. We want "fairness to customers while preventing abuse and maintaining predictable operations." That's the actual intent.

"No refunds after 30 days" is a proxy for that intent. It approximates the fuzzy concept with a precise rule. Most of the time, the proxy works - it advances the underlying intent in a way that's clear and enforceable.

But proxies diverge from intent at the edges. The 30-day cutoff doesn't distinguish between a scammer trying to game the system and a loyal customer who received a defective product. The intent would treat these differently. The proxy treats them the same.

When humans operate systems, they recognize this divergence. They see that the letter of the rule conflicts with its spirit, and they apply the spirit. That's what making an exception is - recognizing that the proxy has diverged from the intent, and acting on the intent instead.

Automated systems enforce the proxy. They don't have access to the underlying intent. They can't recognize when the proxy has diverged from what we actually care about.

This is why automated systems feel inhuman at the edges. Not because automation is rigid by nature, but because rules are proxies for intent, and proxies are always incomplete.

Why Unstructured Exceptions Are Dangerous

The naive solution: let the agent make exceptions. "Use your judgment. If the rule doesn't fit, do what makes sense."

This is dangerous.

Gaming. Once people learn exceptions exist, they optimize for triggering them. "Just tell them you're a long-time customer and they'll waive the fee." The exception path becomes a well-worn shortcut that undermines the rule entirely.

Inconsistency. Which cases get exceptions depends on how the request is phrased, what mood the agent (human or AI) is in, what context it has. Two identical situations get different outcomes. This is both unfair and legally risky.

Audit failure. When asked "why did you break the rule?" the answer is "the agent thought it made sense." That's not an answer that satisfies auditors, regulators, or lawyers. You've lost the ability to explain your system's behavior.

Liability. "The AI decided to make an exception" is not a defensible position. Someone needs to be accountable. Unstructured exception-making diffuses accountability to the point where no one is responsible.

Erosion. Exceptions become the norm. If agents can always make exceptions, and the path of least resistance is to make them, then the rules stop meaning anything. You've lost the predictability that made the rules valuable.

Unstructured flexibility isn't flexibility - it's chaos with a friendly interface.

How Human Systems Handle This

Human organizations don't actually give everyone unlimited exception authority. They structure it.

Hierarchy and authority levels. The front-line rep follows the script. Small exceptions go to supervisors. Larger exceptions go to managers. Major policy overrides require directors or above.

Customer recourse is escalation. "Can I speak to your manager?" isn't just a meme - it's accessing a higher authority level with greater exception-making power.

This works because:

But it's also frustrating. The front-line person can't help even if they want to. Escalation is slow. Customers feel like they're fighting the system. And it doesn't scale - every exception requires human attention, senior people become bottlenecks, consistency depends on which human you get.

Agent systems need a better approach. One that preserves the governance of structured authority while removing the bottlenecks.

Structured Flexibility

The middle ground between unstructured exceptions and rigid rules is structured flexibility—exception-making that's governed, bounded, observable, and improvable. Effective systems share several characteristics:

Rule Encoding

Richer rules encode more of the underlying intent into the rule itself. Instead of "No refunds after 30 days," a rule might specify "Refunds after 30 days require one of: product defect documented, first-time request with account in good standing for 2+ years, or customer lifetime value exceeding $5,000." Many cases that would be "exceptions" to the simpler rule become rule applications under the richer one. This reduces exceptions while handling more of the intent's surface area.

Categorized Exceptions

Rather than ad-hoc exceptions at agent discretion, exceptions are enumerated types with defined criteria. Goodwill exceptions, defect exceptions, escalation exceptions—each category has explicit criteria. The agent classifies cases into these categories rather than making unstructured judgment calls. This tractable classification problem has measurable accuracy.

GoodwillException:
  - Customer LTV > $1,000
  - No prior exceptions in 12 months
  - Amount < $200

DefectException:
  - Product failure documented
  - Any timeline
  - Any amount

Exceptions are part of the structure, tracked, audited, analyzed. You know exactly which type was applied and whether criteria were met.

Documented Reasoning

Exceptions require explanations. Not just "approved" but "approved as defect exception because customer provided photo showing manufacturing failure." This record serves multiple purposes: accountability (why was it made), pattern detection (what's actually driving exceptions), training signal (what good exception-making looks like), and gaming resistance (audit trails reveal exploited loopholes).

Rate Monitoring

Exception rates are tracked. If more than some threshold—say 5% for low-stakes retail—of decisions are exceptions, something has shifted. Either the base rules no longer fit reality, or the agent is being too lenient, or gaming is occurring. Rate limits are an early warning system, not prevention.

Expense Budgets

Agents operate within bounded exception capacity. Maybe $10,000 per month in refund exceptions, or 50 exception approvals per week. The budget forces prioritization—exceptions reserved for cases that genuinely warrant them rather than applied liberally. Budgets can be hierarchical, mirroring human authority structures: small budgets route to higher authorities when exhausted.

Systematic Review

Exceptions are sampled and reviewed by humans. Was the exception appropriate? Did the reasoning make sense? This feedback loop catches inappropriate exceptions and reinforces good judgment. Because exceptions are categorized and explained, review is systematic—evaluating specific decisions against specific criteria rather than open-ended behavior.

Learning Through Patterns

Rules are treated as hypotheses. Exception patterns reveal where rules don't match reality. When the same exception occurs repeatedly for the same reason, it signals whether the base rule needs change or a new exception category exists. The exception mechanism becomes a learning system: exceptions reveal gaps, gaps inform rule refinement, rules improve, exception rates decline.

Escalation as a Designed Path

Some cases exceed what exceptions can handle. They require human judgment beyond structured categories.

When escalation is explicit—with clear criteria for what triggers it and transparent communication to customers—it becomes part of the system rather than a failure mode. The agent can state: "I handle these cases automatically. For those, I'll connect you with a person." Customers understand the tradeoff.

This can even be framed as a choice: "I can process your return immediately under standard policy. For an exception, I can connect you to a team member with a typical 10-minute wait." Customers can choose: fast with rules, or slower with human judgment. Many choose fast simply because they want the problem solved. Those with genuinely exception-worthy situations wait for human review.

This approach sets expectations clearly for both customers and operators. Early in deployment, escalation volumes may be high as the system learns what it can handle versus what needs humans. Effective escalation UX prevents operator discouragement. As the system refines, automation expands and escalation declines. This is the pattern of staged releases: alpha and beta deployments building toward production capability.

The Speed/Flexibility Frontier

There's a fundamental tradeoff here, and it's worth acknowledging.

Rigid rules are fast. No judgment required, no escalation, immediate resolution. But they create bad outcomes at edges.

Full human judgment is flexible. Every case evaluated on its merits, context considered, intent applied. But it's slow and doesn't scale.

Structured flexibility is in between. The agent handles most cases automatically, applies structured exception logic where appropriate, escalates what needs human judgment. Faster than pure human handling, more flexible than rigid rules.

Where you land on this frontier depends on your domain. High-volume, low-stakes decisions can lean toward automation. Lower-volume, higher-stakes decisions might lean toward human judgment. Many domains will want a hybrid - automated handling for 95% of cases, human handling for the 5% that need it.

The point isn't to eliminate the tradeoff. It's to navigate it intentionally, with structure that makes the tradeoffs visible and manageable.

What This Looks Like in Practice

Let's make it concrete. A refund request comes in, day 45, for a $300 item.

Rigid system: Denied. Policy is 30 days.

Unstructured flexibility: Agent vibes it out. Maybe approved, maybe denied, depends on how the request was phrased.

Structured flexibility:

  1. Agent checks base rules. Outside 30 days - not automatically approved.

  2. Agent checks exception categories:

    • Goodwill exception? Customer LTV is $800 (below $1,000 threshold). Doesn't qualify.
    • Defect exception? Customer says item "didn't work right." Agent asks for details or photo.
    • Customer provides photo showing obvious manufacturing defect.
    • Defect exception criteria met.

  3. Agent approves with explanation: "Approved under defect exception. Customer provided photo showing [specific defect]. Manufacturing issue evident. 45 days since purchase, $300 refund."

  4. Exception logged, categorized, explanation stored.

  5. End of week: This exception is part of the sample reviewed by the team. Reviewer confirms: appropriate application of defect exception.

  6. End of month: Analysis shows defect exceptions are up 20% for this product line. Investigation reveals supplier quality issue. Supplier notified, rules unchanged.

The customer got a good outcome. The decision is explainable. The data feeds improvement. No one had to "use their judgment" in an unstructured way.

The Pattern Generalizes

This isn't just about refunds. The same structure applies wherever you need flexibility within governance.

Content moderation:

Base rules define what's clearly prohibited (spam, illegal content, harassment). But edge cases abound: satire vs. hate speech, newsworthy violence vs. gratuitous violence, artistic nudity vs. inappropriate content.

Structured flexibility:

Loan approvals:

Base rules define credit score thresholds, debt-to-income ratios, employment requirements. But good borrowers sometimes have unusual profiles: self-employed with variable income, recovering from medical bankruptcy, strong assets but thin credit history.

Structured flexibility:

Scheduling and allocation:

Base rules handle standard shifts, vacation requests, resource allocation. But reality intrudes: emergencies, special events, unusual circumstances.

Structured flexibility:

In each domain, the pattern is the same: identify the exception types that legitimately exist, define criteria for each, require explanations, monitor rates, sample and review. The structure doesn't eliminate judgment—it channels judgment into observable, improvable form.

Structure Across Time

One more dimension: structure doesn't require immediate human review. Agents can orchestrate workflows that span time—scheduling, delays, triggers.

Instead of "this requires immediate human judgment," structure can say: "flag for manager review if unresolved in 2 days," "remind customer to respond by Friday," "escalate to senior if no progress after 3 hours."

The human doesn't have to be monitoring. The agent handles the temporal orchestration. The structure specifies when decisions need to happen and what triggers review. The rules are still explicit, the judgment is still bounded, the escalation paths are still defined. Time just becomes another design variable.

This matters because it means human expertise can be used efficiently. An agent does the work, documents its reasoning, and humans review on a schedule that makes sense for the business—not constantly, but systematically.

Conclusion

The exception problem isn't a choice between rigidity and chaos. It's a design problem.

Rules are proxies for intent. Proxies diverge at edges. You need a way to handle that divergence that doesn't sacrifice governance for flexibility or flexibility for governance.

Structured flexibility gives you both:

The agent exercises judgment, but within a structure that makes that judgment visible, bounded, and improvable.

This is more work than "just use your judgment." It requires thinking carefully about what exceptions should exist, what criteria should apply, how to monitor and improve over time.

But it's the only way to get flexibility at scale. The alternative - unstructured exception-making - isn't actually flexible. It's ungovernable. And ungovernable systems don't last.

Structure doesn't prevent flexibility. It makes flexibility sustainable.

This essay is part of a series on building reliable AI agent systems.

Overview: The Structure Problem

Previous: The Boundary Model

Next: The Missing Scaffolding — Organizational and economic barriers