Couldn't find an image for Human-on-the-Loop—looks like the market is still stuck in the loop, paying humans to babysit workflows and wondering why the unit economics don't make sense.
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.
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.
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.
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.
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.
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:
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.
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:
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.
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.
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.
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.
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.
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.
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:
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.
Escepine's behavior can be expressed as a small set of architectural commitments:
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.
The proposed architecture separates workflow orchestration, execution, escalation, durable state, and human interaction.
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.
The exception layer evaluates whether the workflow can continue safely.
It detects conditions such as:
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.
When escalation is required, Escepine creates a durable exception record containing the information needed for resolution.
The record should identify:
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.
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.
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.
The parked state is the defining mechanism of this architecture.
A conventional d 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.
When a workflow is parked:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The workflow lifecycle should be represented explicitly rather than inferred from logs, agent messages, or the presence of a running process.
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 s inside a worker.
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 |
+----------------------+
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.
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:
The persisted record should not depend exclusively on a model's conversational memory or on an in-memory execution stack.
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.
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.
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.
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.
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:
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.
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:
The system should therefore preserve several independent controls:
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.
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.
Exception-driven autonomy must preserve a complete record of how the workflow reached its current state.
An audit record should capture:
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:
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.
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:
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.
The architecture should be implemented around the following principles.
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.
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.
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.
The response must be associated with a specific pending decision, validated against the current workflow state, and authorized for the requested action.
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.
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.
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.
Permissions, resource state, and other relevant conditions must be checked again before consequential operations execute after a potentially long wait.
The persisted workflow and its pending decisions must remain recoverable even when the process that encountered the exception has been terminated.
Timeouts, missing notifications, unavailable reviewers, and indefinite waiting must not silently transform an unresolved decision into permission to continue.
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:
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.
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.