Most teams evaluate agents by how much they can do without help. A more useful test is whether the agent can stop mid-task, hold its state, wait for a human, and pick up exactly where it left off.
Interruptibility is what makes broader delegation possible. An agent that must run to completion can only be trusted with work whose whole action space was approved in advance. A pausable agent can take on a wider range of work because it can ask for judgment at the moment judgment is needed.
This is where non-deterministic agents get hard. A script follows a known path. An agent may discover new files, reinterpret the goal, choose a tool, revise its plan, or propose an action that was not visible when the task began. Pre-approving the entire run either grants too much authority or forces the agent into a narrow sandbox. Neither pattern scales well to serious work.
The run-to-completion trap
Many agent workflows still behave like one-shot command invocations. You launch the agent, it acts, and then it finishes, fails, or times out. This model typically breaks in two ways:
- The agent reaches a risky action and proceeds because stopping would kill the run.
- The agent reaches a risky action and stops by failing, losing context, plan state, and partial progress.
Neither outcome builds trust. The first teaches users to fear automation. The second teaches them that agent work is fragile.
Claude Code's defer permission hook offers a third path. A headless CLI session can pause at a specific tool call, wait for asynchronous human approval through Slack, Discord, or an approval queue, and resume once approval arrives. The session does not die. The context does not disappear. The work becomes pending instead of failed.
Trust is also an execution problem
Reasoning still matters, but even strong models hit authority boundaries. In higher-risk environments, the execution system has to manage authority, state, and time.
Pause-resume changes what permission means. Instead of broad pre-authorization at the start of a run, the agent can ask for narrow approval at the exact action it wants to take.
A pause also changes the meaning of failure. A synchronous interruption looks like a crash. A stateful pause means the agent is waiting for a decision.
It changes the human workload too. Synchronous approval requires someone to watch the run. Asynchronous approval lets a reviewer handle a queue later, without discarding the agent's accumulated work.
The change goes deeper than interface polish. If an agent can stop before crossing a boundary, the boundary can be meaningful. If it cannot stop, the only safe boundary is the one drawn before the run starts.
What makes approval meaningful
Human approval is only useful if the pause-resume system preserves enough information for a reviewer to make a real decision.
For a conventional deployment script, the question might be simple: approve this known migration or not. For an agent, the approval request needs more context because the action may be the result of a chain of observations and choices. A useful approval packet should include:
- The exact tool call the agent wants to make.
- The reason the agent believes the action is necessary.
- The state changes that may occur if the action succeeds.
- The files, commands, services, or accounts affected.
- The alternatives the agent considered, if relevant.
- The point in the plan where execution will resume.
Without that context, human approval becomes theater. The reviewer ends up approving their own ignorance.
There is another subtle risk: time changes the world. If an agent pauses for minutes or days, its saved state may become stale. Files may change, tickets may close, deployments may move on, credentials may rotate. A good resume system cannot simply thaw the process and continue blindly. It needs resumability plus revalidation.
Before acting after a long pause, the agent should confirm that the assumptions behind the pending tool call still hold. In practice, that means re-reading touched files, re-running the check that justified the action, and confirming the target version, ticket, or environment still matches the approval packet. A resume check should compare concrete state: file hashes, package version, test status, environment name, and the exact command waiting for approval. For a release agent, approval to publish should not survive a new commit, a changed package version, a failed test rerun, or a different registry target. Those changes turn the old approval into stale evidence.
A release example
A release pipeline agent updates changelog text, runs tests, drafts release notes, checks package metadata, and reaches the point where it wants to publish the package.
Under a run-to-completion model, the team has two uncomfortable choices. It can pre-authorize publishing, which may be too much authority for an agent that can make non-deterministic decisions. Or it can require a human to sit beside the run, which turns automation into supervised waiting.
Under the defer model, the agent pauses at the publish step and sends an approval request with the package name, version, diff, test result summary, generated release notes, and exact publish command. A maintainer reviews it later, approves or rejects it, and the agent resumes from the saved state. The routine work gets machine speed. The irreversible step gets human judgment.
The platform test
This depends on state serialization. An agent platform that cannot snapshot a session, persist it across an arbitrary gap, and resume it faithfully cannot provide real just-in-time approval. It can simulate the experience with long polling, timeouts, or fragile process suspension, but those patterns collapse under production conditions.
The platform test is blunt: can the agent pause for human judgment and resume asynchronously without losing the plan, context, pending action, and authorization boundary?
If not, the safe answer is to keep that action outside the agent's control.
Low-risk, bounded workflows do not need this. But the moment an agent is expected to cross trust boundaries, mutate valuable systems, spend money, publish artifacts, alter customer-visible state, or handle secrets, stopping is not a nice-to-have. It is the control surface.