Exception Design Sets the Unattended Limit for Autonomous Operations

Introduction

On September 17, 2026, UiPath added a preview Case Manager Agent to Maestro Case that can start and cancel tasks, enter and complete stages, and escalate work. Its configuration includes the model and tools the agent can use, but also something less conspicuous: escalation paths. UiPath documents the capability in its September 2026 Maestro release notes.

That less glamorous design choice matters because production autonomy is constrained not only by what an agent can do, but by what happens when the agent no longer has a satisfactory next action.

An autonomous process can perform well while cases remain ordinary. Its operating limits become visible when evidence conflicts, an external system stops responding, a deadline expires, a human decision is required or the agent reaches a situation for which no satisfactory action is available.

For autonomous operations exception design, those conditions cannot be treated as implementation debris discovered after deployment. They are part of the process model. The system needs to know which failures can be retried, which conditions should change the route, when work should wait, where escalation goes and what state survives while the problem is being resolved.

UiPath’s current product direction makes this unusually visible. Maestro Case was introduced for goal-driven work in which the next step depends on what has already happened, with deterministic rules and agentic decisions operating inside the same case structure. Microsoft Agent Framework, meanwhile, can persist workflow checkpoints and pending human requests so interrupted work can resume rather than restart. UiPath’s June 2026 Maestro Case release and Microsoft’s workflow checkpoint documentation show two different implementations of the same operational requirement: autonomous work has to survive conditions that interrupt ordinary progression.

The objective is not to eliminate exceptions before allowing autonomy. It is to decide what the operation will do when the happy path stops describing the case.

At a glance

• Autonomous operations need explicit outcomes for unresolved work, not only successful task completion.
• Temporary system failures, contradictory business evidence and overdue human responses require different operational reactions.
• Retries are useful for transient failures but become dangerous when they merely repeat an invalid assumption.
• Durable waits, escalation paths and recoverable process state allow autonomy to stop cleanly without collapsing the wider operation.
• Exception tests should be designed before autonomy is expanded, not after unusual cases begin accumulating in production.

The unresolved case is where autonomy becomes an operating-model problem

A demonstration usually begins with cases that contain enough information, available systems and a plausible next action. Production introduces cases in which one or more of those conditions disappear.

A supplier-onboarding agent, for example, might collect company information, request missing documents, query internal systems and prepare a supplier record. Most cases may progress without intervention. A harder case arrives when the registration record uses one legal name, the submitted document uses another and an external verification service is temporarily unavailable.

The unavailable service may justify another attempt later, while conflicting identity data may require clarification or a human decision. A document that never arrives introduces a third condition because the case may eventually become ineligible to proceed at all.

If the process exposes only `completed` and `failed`, those materially different outcomes are forced into states that say little about what the operation should do next.

Current orchestration products increasingly give process designers mechanisms for representing those differences. UiPath Maestro supports process-level errors and conditional node-level error mappings, allowing matching runtime errors to follow defined handlers instead of leaving every failure to generic recovery logic.

Autonomy therefore depends not on avoiding unresolved cases, but on giving materially different unresolved conditions legitimate places in the process.

Supplier onboarding shows why “try again” is not a universal answer

Suppose the external company registry fails while the onboarding agent is checking a supplier.

A retry can be appropriate because the business facts have not necessarily changed; the dependency may simply be unavailable. UiPath’s current Maestro runtime supports element-level retries for executable tasks including Agent, Service, API Workflow and Queue Item tasks. The retry policy can define maximum attempts, delay, backoff behavior and which errors qualify.

Now change the condition. The registry responds successfully, but its legal-entity name conflicts with the document submitted by the supplier.

Repeating the same request five times will not resolve the discrepancy.

Camunda’s error-event guidance draws a useful distinction based on the reaction the process requires rather than whether the problem looks technical or business-related. Temporary technical failures can often remain generic retry or incident behavior; conditions requiring a business reaction belong in the modeled process.

For autonomous operations, that distinction prevents retry logic from becoming a substitute for judgment.

A retry policy can absorb temporary instability. It should not convert contradictory evidence into repeated execution.

Some cases need a durable pause rather than a forced answer

The pressure to keep autonomous work moving can make waiting look like failure, even when waiting is the correct operational state.

The supplier may need to provide another document. A risk team may need to review the discrepancy. An external authority may not respond until the next business day. None of those conditions requires the case to disappear, restart from the beginning or remain trapped inside an agent’s conversational memory.

Microsoft Agent Framework checkpoints are designed for workflows that need to survive failures, pause and resume later, preserve progress for audit purposes or move between environments. A checkpoint captures executor state, pending messages, shared state and pending requests or responses.

Its human-in-the-loop workflow mechanism preserves pending requests in those checkpoints as well. After restoration, the request can be emitted again and answered without reconstructing the entire run.

The process can remain unresolved without becoming lost.

Escalation needs a destination, not merely a threshold

“Escalate if uncertain” sounds reasonable in an agent instruction. It is not yet an operating design.

Someone or something has to receive the case. The process needs to know what information travels with it, which activity stops, whether parallel work can continue and what event allows normal processing to resume.

UiPath’s September 2026 Maestro release makes escalation an explicit part of the preview Case Manager Agent configuration. The agent can make orchestration decisions such as starting or cancelling tasks, entering or completing stages and escalating, while designers configure the escalation paths available to it.

In the supplier case, escalation might suspend creation of the supplier master while preserving document collection that has already completed. A reviewer receives the conflicting legal identities, the evidence supporting each and the unresolved condition. Their outcome can return the case to autonomous processing, send it back for clarification or terminate onboarding.

The agent is not being asked to become less capable. The operation is defining what happens when its capability is no longer enough.

Recovery logic does not have to clutter the happy path

One reason exception design is postponed is the fear that an understandable process will turn into a diagram dominated by failure branches.

Modern workflow runtimes provide ways to separate recovery behavior from the main sequence.

UiPath’s event subprocess can react to process- or subprocess-level errors outside the normal flow. Common recovery, logging or notification logic can be centralized instead of attaching duplicate handlers to every task, and an interrupting event subprocess can take over when an error invalidates the current execution.

Camunda provides a comparable separation through boundary error events and error event subprocesses. An error can be routed through a modeled reaction, while an unhandled condition can instead create an incident requiring intervention.

The design question is therefore not whether every possible anomaly needs its own visible branch. It is whether materially different outcomes have defined semantics somewhere in the process.

This allows a workflow to remain readable without creating the opposite problem: a simple-looking process whose real recovery behavior lives in prompts, worker code and operator habit.

Time belongs in exception design

Not every exception begins with an explicit error; some begin because nothing happens within the period the process can tolerate.

A requested document is not returned. A third-party check remains pending. A person does not respond. An agent waits on an activity that has stopped making progress. In each case, elapsed time changes what the process should do even though no component necessarily reports failure.

Camunda 8.9 timer events can pause execution until a deadline or interrupt an activity when a configured duration expires. Its documentation specifically describes attaching a boundary timer to an ad-hoc subprocess hosting an AI agent so long-running agentic activity can be interrupted or redirected.

For the supplier process, the first reminder after a missing document might leave the case open. A later deadline might transfer it to assisted handling. Another condition might close the onboarding request.

The agent may participate in each response, but the elapsed-time policy should not rely on the model noticing how long the case has been waiting.

Exception design should preserve the work already completed

A poorly designed exception often sends work backwards unnecessarily.

If the supplier’s bank verification fails after corporate details, tax information and contact validation have already been completed, restarting the case creates more activity without improving the decision.

Durable workflow state allows recovery to resume from a meaningful point. Microsoft’s checkpoint model exists so long-running workflows can resume from saved execution state after interruption rather than replaying every prior step. UiPath Case similarly exposes live-instance operations including pause, resume, cancel, migrate and retry, as documented in the June 2026 Maestro Case release.

The practical requirement is not that every failure be recoverable automatically. Recovery should begin from an intentional state rather than from whatever information the agent happens to retain.

Testing begins where the agent stops following the expected route

A conventional happy-path test proves that the agent can complete ordinary work, but it says little about whether the surrounding operation remains coherent when the expected route disappears.

Useful tests deliberately create conditions in which the next action is less obvious: a dependency fails after several successful calls, a required fact conflicts with another source, a human request stays unanswered, a retry limit is exhausted or the agent chooses a different permitted route from the one observed during development.

Camunda’s current AI-agent testing guidance treats agentic paths as nondeterministic. Its Camunda Process Test approach can react to whichever tools the agent activates instead of assuming one fixed invocation order, while assertions can evaluate whether results meet the required meaning.

UiPath similarly recommends testing RPA, agents and human tasks individually before end-to-end Maestro testing verifies that steps connect, data moves correctly and the business outcome remains valid.

For autonomous operations, the more specific test begins once the expected path stops working: does the process still know what state it is in and what may happen next?

FAQs: autonomous operations exception design

What is autonomous operations exception design?

It is the design of process behavior for conditions that prevent autonomous work from continuing normally.

That includes how a process treats unresolved business conditions, dependency failures, timeouts, retry exhaustion, human intervention and recovery after interruption.

Should every exception be sent to a human?

No.

Transient failures may be handled automatically through bounded retries. Some conditions can follow another deterministic route. Others may require the agent to gather more information before continuing.

Human intervention is one available outcome, not the definition of exception handling.

How many retries should an autonomous process use?

There is no universal number.

The retry policy should reflect the failure mode, the dependency involved, the delay the process can tolerate and the consequences of repeating the action. The important design point is that retries are bounded and do not repeatedly execute a condition that requires a different business response.

What should happen when an AI agent cannot resolve a case?

The workflow should have a defined unresolved state or recovery path.

Depending on the process, that can mean waiting for more information, handing the case to a person, activating another workflow path, retrying a dependency later or terminating the case with an explicit outcome.

Is exception handling the same as AI governance?

No.

Governance may determine which actions an agent is permitted to take and under whose authority. Exception design determines what the operational process does when ordinary autonomous execution can no longer continue as expected.

The unattended limit is decided before the exception occurs

Autonomous operations will rarely fail because every agent suddenly stops working. More often, production exposes cases that are incomplete, contradictory, delayed or dependent on systems and people that behave differently from the demonstration path.

The operation becomes genuinely autonomous only to the extent that those conditions already have somewhere to go.

Retries absorb temporary instability. Durable waits preserve unresolved work. Escalation transfers responsibility without losing the case. Recovery paths retain useful progress. Explicit terminal states let the system admit that a case cannot continue rather than forcing the agent to manufacture another answer.

That is why exception design sets the unattended limit. Agent capability determines how much ordinary work can be handled dynamically; the exception model determines how much of the operation can continue safely when ordinary work stops being ordinary.