Human-on-the-Loop: Durable Autonomy Through Exception-Driven Escalation

Abstract

As AI systems evolve from conversational assistants into autonomous workflow executors, the operational cost of human supervision becomes a fundamental constraint on their usefulness. A system that requires a human to monitor every intermediate decision, approve routine actions, resolve every minor uncertainty, or remain available throughout execution has not achieved meaningful autonomy. It has merely transferred the execution burden to a machine while retaining the human as its continuous operational dependency.

Escepine adopts a different architectural objective: the workflow should execute autonomously within its authorized boundaries, while the human remains responsible for exceptional decisions that the system cannot safely resolve on its own.

This model places the human on the loop, rather than requiring the human to remain continuously inside the execution loop. The system proceeds independently through routine, authorized, and recoverable operations. When it encounters a condition that requires human judgment, explicit authorization, external intervention, or a decision beyond its permitted recovery capabilities, it escalates the condition, durably suspends the affected workflow, and releases its execution resources.

The resulting workflow enters a parked state in which no agent loop, polling process, repeated model invocation, active worker, or periodic execution cycle is required to keep it waiting. Its state is persisted, its outstanding decision is recorded, and the workflow may remain suspended indefinitely. It resumes only when an authorized external event, typically a human response, satisfies the conditions for continuation.

This architecture distinguishes autonomous execution from unattended execution. Escepine is not expected to solve every possible problem autonomously. It is expected to recognize when autonomous execution is no longer appropriate, stop safely, preserve enough state to continue correctly, and transfer the decision to the appropriate human without requiring that human to supervise everything that came before.

The central architectural principle is straightforward:

The system should spend computation on progressing the workflow, not on waiting for a human.

1. The Problem With Continuous Human Supervision

The conventional approach to human oversight often introduces a human checkpoint into the execution path whenever an agent reaches a decision. The system proposes an action, the human reviews it, and execution continues only after approval. This pattern is appropriate for specific high-impact operations, but applying it indiscriminately creates a system whose throughput and availability remain constrained by human attention.

Three problems emerge.

1.1. Human Availability Becomes an Execution Dependency

If a workflow requires a person to remain present, monitor progress, or respond to routine decisions, the workflow inherits the person's availability constraints. Execution may stop unnecessarily during meetings, sleep, travel, or periods when the human is simply unavailable.

The result is a system that can perform work autonomously but cannot manage its own operational continuity.

1.2. Waiting Becomes an Execution Cost

A naive implementation may keep a process alive while waiting for approval, repeatedly poll for a response, retry a blocked operation, or invoke an agent to determine whether anything has changed.

None of these activities advances the workflow.

A workflow waiting for a human decision does not need a continuously running reasoning process. It needs durable state and a reliable mechanism for detecting the event that permits it to continue.

1.3. Uncertainty Can Cause Unsafe Continuation

The opposite failure is equally dangerous. An agent may encounter an unexpected API response, contradictory evidence, an ambiguous instruction, an authorization failure, or a condition it cannot reliably recover from. If the system is optimized to continue at all costs, it may invent a recovery strategy, make unsupported assumptions, or repeat an operation whose outcome is unknown.

Autonomy without a reliable stopping condition becomes uncontrolled continuation.

The architectural requirement is therefore not to maximize the number of situations in which an agent can continue. It is to maximize autonomous progress while preserving the ability to stop safely when its authority, evidence, or recovery capabilities are insufficient.

2. The Human-on-the-Loop Model

Escepine separates the responsibility to execute a workflow from the authority to resolve exceptional conditions.

The system is responsible for carrying out authorized operations, tracking execution state, validating outcomes, applying permitted recovery strategies, and determining when an exception requires escalation.

The human is responsible for decisions that exceed the system's delegated authority, require contextual judgment, introduce unacceptable uncertainty, or demand explicit approval.

This relationship establishes three distinct operational responsibilities:

1. Autonomous execution: Escepine progresses through the workflow without requiring routine human intervention.
2. Exception detection and containment: Escepine identifies conditions that cannot safely be resolved within its authorized recovery policy and suspends the affected execution.
3. Human-directed resolution: The human reviews the evidence, provides a decision or corrective input, and authorizes the workflow to resume where appropriate.

The human does not need to supervise every operation. The human needs a reliable way to intervene when intervention matters.

This is not a claim that humans are infallible or that automation should always be preferred. It is a division of responsibilities in which routine execution is delegated, while exceptional authority remains explicitly governed.

3. The Core Architectural Invariant

The fundamental invariant is:

A workflow may execute autonomously only while its next operation remains within its authorized execution boundary and its continuation conditions are satisfied. When that boundary is exceeded, execution must stop, state must be preserved, and the workflow must remain dormant until a valid resolution event permits continuation.

This invariant has several consequences:

1. The agent cannot authorize itself to bypass a required human decision merely because it believes continuing would be useful.
2. An exception is not simply a notification attached to a still-running workflow. It changes the workflow's execution state.
3. The suspension must survive process termination, worker restarts, deployment changes, and infrastructure failures. The workflow cannot depend on the continued existence of the process that originally encountered the exception.
4. A human response must not automatically authorize arbitrary continuation. The response must be associated with the correct workflow, the outstanding decision, and the specific operation or recovery path being approved.
5. The system must not interpret the absence of a human response as approval. Silence is a waiting condition, not an authorization signal.

4. Escepine: Autonomous Execution Without Continuous Human Supervision

Escepine is designed around a fundamental distinction: a human should govern exceptional decisions without becoming a permanent dependency of workflow execution.

Escepine is not intended to be an agent that requires a human to watch every action, validate every intermediate result, or remain available to prevent it from making an unsafe decision. Nor is it intended to be an unrestricted autonomous system that continues operating when its assumptions, permissions, or recovery capabilities are no longer sufficient.

Instead, Escepine treats autonomous execution, safety enforcement, and human escalation as separate responsibilities within a durable workflow architecture.

4.1. The Role of Escepine

Escepine is responsible for progressing a workflow from its initial objective toward completion while remaining within its authorized execution boundaries.

During normal execution, Escepine performs the required operations, evaluates their outcomes, maintains workflow state, and applies permitted recovery strategies. It does not require continuous human attention simply because it is performing consequential work.

When an exception exceeds its ability or authority to resolve it safely, Escepine transitions the workflow into a durable parked state and escalates the issue to a human.

This is a deliberate architectural behavior, not an unexpected interruption.

Escepine must be capable of recognizing that the correct next action is no action at all.

4.2. Escepine Does Not Require a Babysitter

A system that requires a human to remain present throughout execution has not eliminated the operational dependency on human attention. It has merely automated individual actions while leaving the overall process dependent on continuous supervision.

Escepine is designed to eliminate this dependency wherever policy and risk permit.

A human can initiate a workflow and leave while Escepine continues executing. The workflow may finish independently, recover from a known failure, or reach a condition that requires intervention.

If intervention becomes necessary, Escepine preserves the workflow's state, records the outstanding decision, notifies the appropriate human, and parks the workflow.

The human can respond when available. Until then, the workflow remains suspended.

There is no requirement for the human to keep a session open, maintain an active conversation, monitor a dashboard continuously, or repeatedly check whether the system has made progress.

The human's responsibility is to resolve the exception, not to keep the workflow alive.

4.3. Escepine Treats Parking as a First-Class Execution State

In Escepine, a workflow awaiting human intervention is not an active agent process waiting for permission to continue.

It is a persisted workflow whose execution has been suspended.

The workflow's continuation state, outstanding decision, relevant evidence, and execution checkpoint are retained durably. Active workers are released, agent execution stops, and no repeated reasoning or polling is required merely to maintain the suspended workflow.

The workflow may remain parked indefinitely.

When a valid human response arrives, Escepine verifies the response against the pending decision and the workflow's current state. If the response satisfies the applicable requirements, the workflow becomes eligible for resumption.

Execution is then scheduled from the appropriate checkpoint, subject to renewed authorization and safety checks.

This separation between persisted state and active execution is essential. Escepine must not need to keep an agent running simply to remember that it is waiting.

4.4. Escepine Escalates Uncertainty Rather Than Inventing Authority

Escepine's autonomy is bounded by explicit execution and recovery policies.

When a failure is known and a safe recovery procedure exists, Escepine may attempt recovery without involving a human. When the failure cannot be resolved within those boundaries, it must stop and escalate.

This includes unresolved contradictions, unexpected state changes, ambiguous outcomes, exhausted recovery budgets, missing authorization, and conditions that could cause severe or irreversible consequences.

Escepine must not treat its own confidence as a substitute for evidence, policy compliance, or required human approval.

Nor should it continue merely because stopping would delay completion.

Its responsibility is to make progress when progress is authorized and safe, and to preserve a safe stopping point when it is not.

4.5. Escepine Preserves the Distinction Between Notification and Permission

Notifying a human does not grant permission to continue. Acknowledging an escalation does not necessarily authorize the blocked operation. A model-generated recommendation does not constitute human approval.

Escepine must preserve these distinctions throughout the workflow lifecycle.

The system records what decision is required, who is authorized to make it, what operation the decision covers, and what conditions must hold before execution can resume.

A human response is accepted only after the applicable identity, authorization, workflow-state, and decision-binding checks have succeeded.

If the approved operation changes materially before execution, Escepine must determine whether the original approval remains valid or whether another decision is required.

The human governs the exceptional decision; the system enforces the conditions under which that decision can be acted upon.

4.6. Escepine Separates Workflow Continuity From Human Availability

A workflow should not become unsafe simply because a human is unavailable, and it should not consume active execution resources simply because the system cannot predict when the human will return.

Escepine therefore separates three concerns:

• Workflow continuity: The durable state required to preserve the task and resume it correctly.
• Human availability: The time at which an authorized person can review and resolve an outstanding decision.
• Execution availability: The compute resources required when the workflow is eligible to perform work.

These concerns must not be coupled unnecessarily.

A workflow can remain durably available for resumption while its execution resources are released. Human unavailability may delay completion, but it does not require continuous agent execution.

If the human never responds, the workflow can remain parked indefinitely, subject to explicitly defined retention and governance policies. It must not silently proceed or manufacture a decision to avoid remaining suspended.

4.7. The Escepine Execution Contract

Escepine's behavior can be expressed as a small set of architectural commitments:

1. Execute autonomously when the next operation is authorized and its continuation conditions are satisfied.
2. Recover autonomously when a permitted recovery procedure is available and remains within its defined limits.
3. Escalate when human judgment, explicit approval, or intervention beyond the system's authorized capabilities is required.
4. Park the workflow durably before relying on successful notification delivery.
5. Release active execution resources while the workflow waits for a human decision.
6. Preserve workflow state and the outstanding decision independently of the worker that encountered the exception.
7. Resume only after a valid resolution has been recorded and the applicable continuation checks have succeeded.
8. Revalidate permissions, resource state, and safety conditions before consequential actions resume.
9. Never interpret silence, timeout, notification failure, or the absence of a response as authorization.
10. Maintain an auditable record of the exception, the human decision, and the subsequent execution.

These commitments define the intended behavior of Escepine's human-on-the-loop architecture. They are architectural requirements to be enforced and verified by the implementation, not guarantees established merely by adopting the terminology.

Escepine is designed so that humans can leave, workflows can wait, and execution can resume without sacrificing control. Human attention is required when a decision genuinely needs it—not as the continuous operating condition of an otherwise autonomous system.

5. Architecture: Execute, Escalate, Park, Resume

The proposed architecture separates workflow orchestration, execution, escalation, durable state, and human interaction.

5.1. Autonomous Execution Layer

The execution layer carries out the workflow's authorized steps. It may invoke models, tools, APIs, internal services, and deterministic business logic as required by the task.

Each step is executed under the permissions and constraints applicable to that operation. Successful completion advances the workflow to its next step.

When a recoverable failure occurs, the system may apply a predefined recovery strategy, such as bounded retries, refreshing an expired connection, correcting a validated input, or rerunning an idempotent operation.

Recovery is permitted only when it is defined by policy and the system has sufficient evidence that the recovery is safe.

5.2. Exception Detection Layer

The exception layer evaluates whether the workflow can continue safely.

It detects conditions such as:

• A required human approval or review.
• A decision that exceeds the agent's delegated authority.
• Contradictory evidence that cannot be reconciled under established rules.
• Missing information that cannot be obtained through authorized means.
• Repeated failures that exhaust the permitted recovery budget.
• An external operation whose outcome cannot be established.
• An unexpected state transition or violation of a workflow invariant.
• A potentially catastrophic consequence that requires an explicit safety decision.
• A security, authorization, or policy failure that must not be bypassed.
• Any other condition classified as requiring human intervention by the workflow's governing policy.

The exception layer does not need to prove that an outcome will be catastrophic before escalating. A sufficiently credible risk, unresolved uncertainty, or inability to establish that an operation is safe may be enough to require suspension.

5.3. Escalation and Notification Layer

When escalation is required, Escepine creates a durable exception record containing the information needed for resolution.

The record should identify:

• The workflow.
• The failed or blocked step.
• The exception category.
• The relevant evidence.
• The actions already taken.
• The remaining options.
• The decision required from the human.

The notification system then delivers the escalation through an appropriate channel.

Notification delivery and workflow suspension are separate responsibilities. A notification failure must not cause the workflow to resume, and a workflow must not remain dependent on an active notification process to preserve its parked state.

5.4. Durable Suspension Layer

The workflow orchestrator transitions the execution into a persisted parked state. The active worker is released, pending execution is prevented from advancing, and the outstanding decision is recorded.

The workflow's logical identity and continuation state remain durable even though its execution process no longer exists.

The orchestrator retains responsibility for remembering that the workflow is waiting, but it does not need to continuously execute the workflow to maintain that fact.

5.5. Human Resolution Layer

The human receives the escalation and reviews the relevant evidence.

Depending on the exception, the human may approve the proposed operation, reject it, provide missing information, select an alternative, request a bounded recovery attempt, correct an assumption, or terminate the workflow.

The resolution is recorded as a structured decision associated with the original exception.

Once the orchestrator validates the response and confirms that continuation remains permissible, it schedules the workflow to resume from the appropriate checkpoint.

The workflow continues from its persisted state rather than restarting the entire task or reconstructing its history from a conversation.

6. The Parked State: Zero Active Execution, Indefinite Waiting

The parked state is the defining mechanism of this architecture.

A conventional paused process may still consume resources through polling, heartbeat loops, open worker allocations, repeated agent invocations, or scheduled retries. Escepine's parked state should not require any of these mechanisms merely to wait for human input.

A parked workflow is durable state without an active execution loop.

6.1. What Parking Means

When a workflow is parked:

• Its execution position and required continuation data are durably persisted.
• Its outstanding exception, approval request, or unresolved decision is recorded.
• Its active worker and model execution are terminated or released.
• It performs no agent reasoning, repeated tool calls, or workflow polling merely to check whether the human has responded.
• It does not retry the blocked operation unless an explicitly authorized, separately scheduled mechanism requires it.
• It does not advance past the unresolved decision.
• It remains eligible for resumption when a valid continuation event arrives.

The workflow may remain parked for minutes, days, months, or indefinitely, subject to the application's explicit data-retention and governance policies.

No timeout should silently convert a pending human decision into approval.

If a business process requires a deadline, the deadline should trigger an explicit policy-defined event, such as a reminder, reassignment, cancellation, or further escalation. It should not implicitly authorize the workflow to continue.

6.2. Zero Compute Does Not Mean Zero Infrastructure

The distinction between active execution and durable persistence is important.

A parked workflow still requires its persisted state to be stored and protected. The system may also need durable notification records, an event-ingestion endpoint, and infrastructure capable of accepting a future response.

The zero-compute objective means that the parked workflow itself requires no continuously executing worker or reasoning process. It does not imply that durable storage, event delivery, security controls, or the shared orchestration infrastructure are free.

The system should avoid per-workflow active compute while allowing shared infrastructure to serve many parked workflows efficiently.

6.3. Event-Driven Wake-Up

A parked workflow should not repeatedly ask whether it can resume. It should be resumed by an external event.

A human submits an approval, provides the missing information, rejects an action, or supplies a recovery decision. The response is validated and durably recorded. The orchestrator then transitions the workflow from its parked state into a resumable state and schedules execution.

If the response arrives while the workflow is already being processed, or if the same response is delivered more than once, the system must handle that condition without duplicating the decision or the resulting side effect.

The architecture therefore depends on durable event handling, idempotent transitions, and a clear relationship between a response and the exact pending decision it resolves.

6.4. Indefinite Suspension Is a First-Class Capability

Indefinite waiting is not an error condition. It is a valid operational state.

A workflow can be waiting for an executive approval, a security review, an external investigation, a customer response, a legal determination, or a manual resolution that may not arrive on a predictable schedule.

The system should not consume compute simply because it cannot predict when the human will respond.

The parked workflow remains a durable obligation of the orchestration system, not an active process that must be kept alive.

7. Escalation Policy: When Should Escepine Stop?

The most important decision in a human-on-the-loop architecture is determining when autonomous execution must yield to human authority.

A system that escalates everything creates an unnecessary human bottleneck. A system that escalates too little can continue through conditions it cannot safely interpret.

Escepine should distinguish between ordinary failures, policy-defined recoverable failures, decisions requiring human judgment, and conditions that require immediate containment.

7.1. Routine Conditions

Routine conditions include expected API responses, valid state transitions, ordinary tool outputs, and other operations that satisfy the workflow's execution contract.

These conditions should be handled autonomously.

7.2. Bounded, Recoverable Failures

Some failures can be resolved using predefined, safe recovery strategies.

Examples include retrying a transient request within a bounded retry budget, refreshing credentials through an authorized mechanism, or repeating an idempotent operation after a confirmed transient failure.

The system may attempt these recoveries without human intervention, provided that each attempt remains within its defined limits.

If the recovery budget is exhausted, the result remains ambiguous, or the recovery would require an unauthorized assumption, the workflow escalates and parks.

7.3. Human Judgment or Authorization Required

Certain actions require explicit human input regardless of the agent's confidence.

Examples include approving a consequential financial transaction, authorizing a destructive production change, resolving a material policy conflict, or deciding between alternatives that require business judgment.

The workflow parks at the relevant checkpoint and waits for an authorized decision.

7.4. Contradictions and Unresolved Ambiguity

When evidence sources disagree, the system should first apply any deterministic reconciliation rules explicitly permitted by the workflow.

If the contradiction remains material, the workflow must not silently select whichever result best supports its existing plan.

It should preserve the conflicting evidence, explain the unresolved issue, and escalate the decision.

The same principle applies when a user instruction conflicts with a governing policy, a tool response contradicts an expected state, or a proposed recovery depends on facts that have not been established.

7.5. Potentially Catastrophic Outcomes

When a condition creates a credible risk of severe or irreversible harm, the system must prioritize containment over continued execution.

The appropriate response depends on the operation, but may include blocking the next action, revoking a pending execution capability, isolating an affected task, preventing additional side effects, and notifying an authorized human.

A catastrophic-risk condition must not be treated as an ordinary retryable error.

Where an operation has already been initiated, the system must distinguish between stopping future actions and reversing an action that has already occurred. Suspending the workflow cannot undo an external side effect that has already taken place.

7.6. Authorization and Security Failures

An authorization denial, invalid approval, expired permission, or unresolved security requirement must not be converted into permission merely to keep the workflow moving.

The system should stop the protected operation and escalate when appropriate. It must not ask the same agent that proposed the action to override the enforcement boundary.

The authorization decision remains the responsibility of trusted enforcement logic, not the model's interpretation of what should be allowed.

8. Human Intervention Is an Exception, Not a Continuous Dependency

The operational objective is not to eliminate human participation. It is to make human participation selective, explicit, and meaningful.

A human should not need to watch a workflow perform routine operations simply because the system is capable of making mistakes. Instead, the system should be designed to detect when a mistake, uncertainty, or exceptional condition has crossed a defined boundary.

This changes the relationship between the human and the workflow.

The human can start a task, leave, and return later without losing control of the process. If the workflow completes, the human receives the appropriate completion record. If it encounters a condition requiring judgment, the human receives an actionable escalation. If the human is unavailable, the workflow remains safely parked.

The ability to leave is not a user-interface convenience. It is a consequence of separating workflow durability from active execution.

A system that requires the user to remain present to prevent the agent from making an unsafe decision has not fully implemented this architecture. The stopping conditions, authorization rules, and suspension mechanisms must operate independently of continuous human attention.

9. Workflow State Machine

The workflow lifecycle should be represented explicitly rather than inferred from logs, agent messages, or the presence of a running process.

9.1. Proposed Workflow States

• READY — The workflow is eligible to execute.
• RUNNING — An execution attempt is actively progressing.
• RECOVERING — A permitted, bounded recovery procedure is in progress.
• PARKED_REVIEW — Human review is required before continuation.
• PARKED_APPROVAL — Explicit authorization is required before a protected action can proceed.
• PARKED_EXCEPTION — An unresolved failure, contradiction, ambiguity, or unexpected condition requires human resolution.
• PARKED_SAFETY — Execution is blocked because of a potentially catastrophic or otherwise prohibited condition.
• RESUME_READY — A valid resolution has been recorded and the workflow is eligible to resume.
• COMPLETED — The workflow has reached its defined successful terminal state.
• REJECTED — A required action or continuation has been explicitly rejected.
• CANCELLED — The workflow has been terminated under an authorized cancellation policy.
• FAILED_FINAL — The workflow cannot continue and has been explicitly classified as terminally failed.

The parked states are persistent states, not transient pauses inside a worker.

9.2. Workflow Lifecycle Diagram

The following Mermaid diagram can be rendered by Markdown editors that support Mermaid:

                  +----------------------+
                  |   WORKFLOW CREATED   |
                  +----------+-----------+
                             |
                             v
                  +----------------------+
                  | AUTONOMOUS EXECUTION |
                  |                      |
                  | Execute authorized   |
                  | workflow steps       |
                  +----------+-----------+
                             |
                             v
                  +----------------------+
                  |  EVALUATE NEXT STEP  |
                  |                      |
                  | Authorized, safe,    |
                  | and recoverable?     |
                  +----------+-----------+
                             |
             +---------------+----------------+
             |               |                |
             v               v                v
      +-------------+ +-------------+ +------------------+
      | SAFE TO      | | RECOVERABLE | | HUMAN DECISION   |
      | CONTINUE     | | FAILURE     | | OR SAFETY RISK   |
      +------+------+ +------+------+ +--------+---------+
             |               |                  |
             v               v                  v
      +-------------+ +-------------+  +------------------+
      | Execute     | | Attempt     |  | Persist Workflow |
      | Next Step   | | Bounded     |  | State            |
      +------+------+ | Recovery    |  +--------+---------+
             |        +------+------+           |
             |               |                  v
             |        +------+-------+  +------------------+
             |        |              |  | Create Durable   |
             |        v              v  | Escalation       |
             |  +-----------+ +-----------+--------+---------+
             |  | Recovery  | | Recovery  |        |
             |  | Succeeds  | | Exhausted |        v
             |  +-----+-----+ +-----+-----+ +------------------+
             |        |             |       | Notify Human     |
             |        |             +------>|                  |
             |        |                     +--------+---------+
             |        |                              |
             |        |                              v
             |        |                     +------------------+
             |        |                     |  PARK WORKFLOW   |
             |        |                     +--------+---------+
             |        |                              |
             |        |                              v
             |        |                     +------------------+
             |        |                     | Release Worker   |
             |        |                     | Stop Execution   |
             |        |                     | Persist State    |
             |        |                     +--------+---------+
             |        |                              |
             |        |                              v
             |        |                     +------------------+
             |        |                     | WAIT INDEFINITELY|
             |        |                     |                  |
             |        |                     | No polling       |
             |        |                     | No agent loop    |
             |        |                     | No active worker |
             |        |                     +--------+---------+
             |        |                              |
             |        |                              v
             |        |                     +------------------+
             |        |                     | HUMAN RESPONSE   |
             |        |                     | OR VALID EVENT   |
             |        |                     +--------+---------+
             |        |                              |
             |        |                              v
             |        |                     +------------------+
             |        |                     | Validate         |
             |        |                     | Identity         |
             |        |                     | Authorization    |
             |        |                     | Pending Decision |
             |        |                     +--------+---------+
             |        |                              |
             |        |                              v
             |        |                     +------------------+
             |        |                     | Can Resume       |
             |        |                     | Safely?          |
             |        |                     +--------+---------+
             |        |                              |
             |        |                    +---------+---------+
             |        |                    |                   |
             |        |                    v                   v
             |        |             +-------------+    +-------------+
             |        |             |     YES     |    |     NO      |
             |        |             +------+------+    +------+------+
             |        |                    |                  |
             |        |                    v                  v
             |        |             +-------------+    +-------------+
             |        |             | RESUME_READY|    | Remain      |
             |        |             +------+------+    | Parked or   |
             |        |                    |           | Terminate   |
             |        |                    v           +-------------+
             |        |             +-------------+
             |        +------------>| Resume from |
             |                      | Checkpoint   |
             |                      +------+------+
             |                             |
             +-----------------------------+
                                           |
                                           v
                                +----------------------+
                                | Continue Workflow   |
                                | or Complete Task    |
                                +----------+-----------+
                                           |
                                           v
                                +----------------------+
                                |      COMPLETED       |
                                +----------------------+
 

9.3. Enforcing Valid State Transitions

The state machine must enforce valid transitions.

For example, a workflow in PARKED_APPROVAL cannot transition directly to RUNNING because a notification was delivered or an agent generated a new plan. It must first receive and validate the required approval.

Similarly, a workflow in PARKED_SAFETY cannot resume merely because a human has acknowledged the alert. Acknowledgment and authorization to continue are distinct decisions.

The exact state names are implementation choices. The invariant they represent is not: parked workflows cannot execute until the required continuation conditions have been satisfied.

10. Durable Suspension and Correct Resumption

Persisting a workflow's status is necessary but insufficient. The system must also preserve the information required to resume correctly.

At minimum, the durable workflow record should contain:

• A unique workflow identifier and current state.
• The current execution checkpoint and workflow version.
• The relevant task inputs and validated outputs.
• The outstanding exception or approval request.
• The evidence and context required for human review.
• The operations already completed and their known outcomes.
• The permitted recovery actions and remaining retry budget.
• The identity and authorization requirements of the required reviewer.
• The identifiers of pending external operations and outstanding decisions.
• The history of prior decisions, transitions, and execution attempts.
• The conditions that must be revalidated before continuation.

The persisted record should not depend exclusively on a model's conversational memory or on an in-memory execution stack.

10.1. Resume From a Checkpoint, Not From an Assumption

When a human responds, the workflow must resume from a defined checkpoint using validated state.

It should not rerun the entire workflow from the beginning unless the workflow explicitly requires that behavior.

Restarting from the beginning can repeat external actions, invalidate prior decisions, or create duplicate side effects. Conversely, blindly continuing from a saved instruction without checking whether its assumptions remain valid can execute an operation that is no longer safe.

The continuation process should therefore reconstruct the workflow from durable state and revalidate the conditions relevant to the next consequential operation.

10.2. Human Responses Must Be Bound to the Pending Decision

A response is not valid simply because it contains the word "approve."

The system must verify that the response belongs to the correct workflow, the correct pending request, and an authorized reviewer. It must also verify that the approved operation remains the operation that will actually execute.

If the target resource, amount, scope, beneficiary, or other material argument changes after approval, the system must determine whether the original approval remains valid. If the change invalidates the approval, the workflow must return to the appropriate review or authorization state.

10.3. Handle Duplicate and Concurrent Responses

Human responses and external events may be delivered more than once, arrive out of order, or race with cancellation and other workflow transitions.

The orchestrator should use durable event identifiers, idempotency controls, version checks, or equivalent concurrency mechanisms to ensure that duplicate responses do not trigger duplicate continuation or execution.

Only a valid transition from the current persisted state should be allowed to schedule the next execution attempt.

10.4. Revalidate Before Consequential Actions

A workflow can remain parked for an extended period. During that time, permissions may change, resources may be modified, credentials may expire, and the original assumptions may become stale.

The system should revalidate the relevant permissions, resource state, policy conditions, and approval binding before performing consequential actions.

A human response permits the workflow to enter its authorized continuation path. It does not grant unlimited authority to every subsequent action.

11. Notifications Are Not the Source of Truth

The notification system communicates exceptions to humans, but it should not determine whether a workflow is allowed to execute.

A notification may be delayed, duplicated, lost, or delivered through a channel that the recipient no longer uses. The workflow's durable state must remain correct regardless of these outcomes.

The proper sequence is:

1. Persist the exception and transition the workflow into the appropriate parked state.
2. Record the outstanding human decision and its authorization requirements.
3. Create a durable notification event.
4. Deliver the notification through the configured channel.
5. Record delivery attempts and expose unresolved delivery failures to operational monitoring.
6. Accept the human's response through an authenticated interface.
7. Validate and durably record the response.
8. Transition the workflow to RESUME_READY only when the applicable conditions are satisfied.
9. Schedule a new execution attempt.

This ordering prevents a notification failure from leaving a workflow executing when it should be suspended.

It also prevents a notification from becoming an implicit approval mechanism.

The system may issue reminders, reassign an escalation, or raise its priority according to policy. These operations must not require the parked workflow itself to resume computation.

12. Security and Authorization Boundaries

Human-on-the-loop execution does not replace the need for strict authorization.

The model should be able to propose operations, but the application must independently enforce the permissions governing those operations.

A human approval should be treated as a specific, scoped decision rather than an unrestricted authorization token.

For example:

• Approving a particular production change does not authorize the agent to make additional unrelated changes.
• Approving a payment does not authorize changing the beneficiary or amount after the review.
• Approving a recovery attempt does not authorize unlimited retries.

The system should therefore preserve several independent controls:

• Execution authorization: Whether the proposed operation is permitted for the current principal, resource, and context.
• Human approval: Whether a required reviewer has approved the specific operation or decision.
• Continuation authorization: Whether the workflow is permitted to resume from its current state.
• Runtime safety enforcement: Whether the actual operation remains safe and permitted at the point of execution.
• Auditability: Whether the system can establish which operation was proposed, which controls were applied, who made the decision, and what actually executed.

The absence of a human decision must never be interpreted as permission. Neither should the agent's assertion that approval has been obtained.

If the authorization service is unavailable, the approval cannot be verified, or the workflow state is inconsistent, the system should fail closed for the protected action and escalate where appropriate.

13. Operational Reliability and Failure Recovery

A durable parked workflow must remain parked through infrastructure failures.

A worker crash must not erase the workflow. A deployment must not cause pending approvals to disappear. A temporary notification outage must not allow execution to continue. A scheduler restart must not require the workflow to reconstruct its history from the model.

This requires the parked state and pending decision to be persisted independently of the worker's lifecycle.

The orchestration system should also distinguish between a workflow's logical state and its current execution attempt. A workflow may have multiple execution attempts over its lifetime, but only a valid attempt should be permitted to advance its state.

Where a worker crashes after initiating an external operation, the system must not assume that the operation failed simply because the worker did not record success. It should reconcile the operation's outcome before deciding whether to retry, continue, or escalate.

For operations with irreversible consequences, exactly-once execution cannot generally be guaranteed by workflow persistence alone. The system must use appropriate downstream idempotency keys, transactional mechanisms, operation-status reconciliation, or compensating procedures where available.

The same care is necessary when resuming a workflow after a long suspension. Before replaying an operation, the system must establish whether that operation has already taken effect.

The architectural objective is not merely to make the workflow survive a crash. It is to make the workflow's next action correct despite a crash.

14. Auditability and Human Accountability

Exception-driven autonomy must preserve a complete record of how the workflow reached its current state.

An audit record should capture:

• The original task.
• The relevant execution checkpoints.
• The triggering condition.
• The evidence presented to the reviewer.
• The decision requested.
• The identity and authority of the reviewer.
• The recorded response.
• The subsequent execution outcome.
• Automated recovery attempts.
• Policy evaluations.
• Notification failures.
• Cancellations and changes to the workflow's continuation conditions.

Human decisions should be distinguishable from model-generated recommendations. A model may explain why it recommends a particular action, but that explanation must not be mistaken for an actual human authorization.

Likewise, a human's acknowledgment of an exception should be distinguishable from approval to proceed.

The resulting record should allow an operator to answer three questions:

1. Why did the workflow stop?
2. What decision authorized it to resume?
3. What did the workflow execute after resumption?

This is especially important when the workflow has been parked for a long period and the original execution context is no longer available in an active process.

15. Measuring Whether the Architecture Works

The effectiveness of human-on-the-loop execution should be evaluated through operational behavior rather than the mere presence of an approval interface or a workflow status field.

Useful measurements include:

• Autonomous completion rate: The proportion of workflows completed without requiring human intervention.
• Escalation precision: The proportion of escalations that correspond to genuine policy-defined intervention requirements.
• Unsafe continuation rate: The frequency with which a workflow advances beyond a condition that should have required suspension.
• Parked compute consumption: The active execution resources consumed by workflows while waiting for human input.
• State durability: The ability to recover parked workflows and their pending decisions after worker crashes, restarts, and deployments.
• Resume correctness: The proportion of resumed workflows that continue from the correct checkpoint without duplicating completed side effects.
• Approval integrity: The ability to establish that the actual operation executed matches the operation authorized.
• Notification reliability: The proportion of required escalations successfully delivered or surfaced through an operational fallback.
• Human response latency: The time between escalation and a valid resolution, measured separately from active execution time.
• Recovery effectiveness: The proportion of failures resolved within the permitted automated recovery budget.
• Safety containment: The ability to prevent prohibited or potentially catastrophic operations from proceeding after a relevant condition is detected.

Parked compute consumption deserves particular attention. A system that claims to support indefinite waiting but maintains a continuously active worker or agent loop has not achieved the intended execution model.

Likewise, a system that reports low human-intervention rates while silently continuing through unresolved contradictions has not achieved safe autonomy.

The goal is not to minimize escalations at any cost. It is to reduce unnecessary human supervision while ensuring that conditions requiring human authority are consistently detected, contained, and resolved through an auditable process.

16. Implementation Principles

The architecture should be implemented around the following principles.

Principle 1: Execution and Waiting Are Different States

A workflow that is waiting for a human should not be represented as an active execution that happens to be blocked. It should be represented as a durable parked state with no active workflow computation.

Principle 2: Suspension Is Enforced by the Orchestrator

The agent should not be responsible for remembering to stop itself. The orchestration layer must prevent execution from advancing when a required gate is unresolved.

Principle 3: Escalation Must Be Durable Before Notification

The workflow must enter its persisted parked state before notification delivery becomes a dependency. The system must remain safe even if the notification channel fails.

Principle 4: Human Input Is Structured and Authenticated

The response must be associated with a specific pending decision, validated against the current workflow state, and authorized for the requested action.

Principle 5: Resumption Is a Controlled State Transition

A human response does not directly restart an arbitrary execution process. It resolves a pending decision, after which the orchestrator validates the transition and schedules the next eligible execution attempt.

Principle 6: Recovery Is Bounded by Policy

The agent may recover from expected failures only through authorized strategies with explicit limits. Unbounded retries, speculative corrections, and unsupported assumptions must not become substitutes for escalation.

Principle 7: Dangerous Uncertainty Stops Execution

When the system cannot establish that a consequential action is authorized and safe, it must not proceed merely because the workflow has already invested time or resources in reaching that point.

Principle 8: Long Suspensions Require Revalidation

Permissions, resource state, and other relevant conditions must be checked again before consequential operations execute after a potentially long wait.

Principle 9: The Workflow Survives Independently of the Worker

The persisted workflow and its pending decisions must remain recoverable even when the process that encountered the exception has been terminated.

Principle 10: No Response Is Not Consent

Timeouts, missing notifications, unavailable reviewers, and indefinite waiting must not silently transform an unresolved decision into permission to continue.

17. Relationship to Existing Workflow and Human-Oversight Models

Human-on-the-loop execution builds on established ideas from human-in-the-loop systems, durable workflow orchestration, event-driven execution, and policy-enforced authorization.

Human-in-the-loop mechanisms provide a way to request approval, preserve context, and resume after a decision. Durable workflow engines demonstrate how a workflow can persist its state while waiting for external input. Event-driven architectures provide a mechanism for resuming work when an external event arrives.

Escepine's proposed distinction is the combination of these mechanisms into a specific operational contract: the human is an exception resolver, not a continuously required execution dependency, and waiting must not require an active agent process.

The design is consistent with established durable-execution patterns in which a human task suspends workflow progress while preserving state for later continuation. See Conductor's documentation on human-in-the-loop workflows.

It also complements authorization architectures that separate model-generated action proposals from deterministic enforcement. See The Hard Authorization Boundary: Preventing Unauthorized Actions in Agentic AI.

These are complementary controls:

• Durable suspension determines whether and when a workflow may continue.
• Authorization determines whether the operation it intends to perform is permitted.

Neither control can safely replace the other.

The proposed architecture should be treated as a design specification until its guarantees have been demonstrated through implementation-level testing, failure injection, and operational evaluation. In particular, indefinite suspension, zero active workflow compute, crash-safe resumption, and protection against duplicate side effects must be verified rather than inferred from the presence of workflow state or approval functionality.

18. Conclusion

The next stage of workflow autonomy is not achieved by asking humans to trust an agent to handle every possible exception. It is achieved by designing a system that knows when it may proceed, when it must stop, and how to remain safely suspended until the appropriate decision becomes available.

Escepine should execute routine work independently, apply bounded recovery strategies to known failures, and escalate situations that exceed its authority or recovery capabilities. When escalation occurs, the workflow must be durably parked, its active computation released, its state preserved, and its pending decision made available to an authorized human.

The workflow should not poll, repeatedly reason about its inability to continue, or consume active execution resources while waiting. It should remain dormant for as long as necessary and resume only when a valid external event satisfies the conditions for continuation.

This model allows the human to initiate work and leave without surrendering control. The system remains responsible for routine progress and safe suspension. The human remains responsible for decisions that genuinely require human authority.

The defining property is not that the system never encounters a situation it cannot resolve. It is that an unresolved situation cannot force the system into either continuous human supervision or unsafe autonomous continuation.

Escepine's objective is deterministic autonomous execution with durable human escalation: run when authorized, recover when safe, park when uncertain, and resume only when permitted.

The human should not have to babysit the workflow. The workflow should know when it needs the human, preserve its state, stop consuming active execution resources, and wait until the human is ready to decide.