An agent is updating a production-facing system when the operator notices that its assumptions are stale.
One API call may still be in flight. A database mutation has completed. A customer notification is queued. The credential lease that authorized the run is still valid.
The operator presses Pause.
What, exactly, just stopped?
If the answer is “the agent,” the control plane has not answered the operational question. Did it stop scheduling new work? Did it revoke future authority? Can the in-flight call still commit? Are child runs paused too? Did timers keep moving? Can another operator take ownership? Which checkpoint will the operator inspect before the run resumes?
A control plane is the operational layer that governs a run’s state, authority, scheduling, and interventions. That layer needs to answer the questions above.
Run control is the contract for safely interrupting, inspecting, terminating, continuing, and recovering an active run. It is not one stop button. It is a set of distinct interventions, each with consequences for state, authority, side effects, ownership, and audit history.
Pause, Resume, Cancel, Retry, and Recovery Are Different Contracts
A planned approval boundary and an unplanned operational intervention solve different problems.
A human approval interruption can suspend work at a planned boundary. An emergency pause can stop new progress after an unexpected condition. A cancellation can ask the run to terminate. A retry can create another attempt. Compensation can repair an effect that already escaped. Ownership transfer can change who is accountable for the next decision. Recovery can reconstruct state after a worker or process disappears.
Calling all of these actions “stop” hides the most important behavior.
In short: pause preserves a run, resume revalidates it, cancel stops future work, retry creates another attempt, compensation repairs committed effects, ownership transfer changes accountability, and recovery reconciles state with the world.
This is my operator model. The point is to make each product's semantics inspectable before the product touches consequential work.
Pause should stop progress, not pretend to freeze the world
Temporal's Workflow Pause documentation offers a useful precedent. A pause stops a workflow execution from making new progress without terminating it or discarding its state. But timers continue, signals can still be recorded, and activities already in flight may complete. The pause also applies to a specific workflow execution rather than automatically cascading across every related object. Temporal currently labels the feature pre-release, which makes it evidence of a concrete design contract—not a universal standard.[^1]
That is the level of specificity an agent control plane needs.
A pause contract should answer at least five questions:
- What new work will no longer be scheduled or authorized?
- What already-dispatched work can still finish?
- Do timers, deadlines, signals, and inbound operator messages continue?
- Does the pause cascade to child runs or delegated agents?
- Who can issue the pause, and where is the reason recorded?
There is a second boundary: pausing execution is not the same as revoking authority. If a credential, tool grant, or delegated capability remains valid, the control plane must say whether it can still be used by in-flight work. Revoking future authority also cannot recall a request that an external system has already accepted.
The honest contract separates those facts instead of painting the run amber and hoping the world stopped with it.
Resume is a new decision against a changed world
Resume sounds simple because the run already has state. But durable state records what the system knew; it does not guarantee that the world still matches it.
LangGraph interrupts, for example, require checkpointing and a thread identifier. When execution resumes, the interrupted node starts again from the beginning, which means code before the interrupt can run again.[^2] OpenAI's Agents SDK similarly exposes pending tool approvals and a serializable RunState that can be resumed after an approve-or-reject decision, while persistence across processes remains an application responsibility.[^3]
Those mechanics are useful because they make the recovery boundary visible. They also show why “resume” cannot mean “continue as if nothing happened.”
Before resuming, the control plane should revalidate:
- the checkpoint or event-history boundary;
- the code, model, tool, and configuration versions;
- assumptions that may have gone stale during the pause;
- the status of external calls with ambiguous outcomes;
- the authority available to the run now;
- idempotency protections for any code that may execute again.
A safe resume is a deliberate state transition, not the removal of a UI flag.
Cancel, retry, and compensation solve different failures
Cancellation governs future execution. Compensation governs effects already committed.
Suppose a purchasing agent reserved inventory, generated a shipping label, and was about to charge a card. Canceling before the charge can prevent that next action. It does not automatically release the reservation or void the label. Those outcomes need domain-specific compensating actions.
The Saga pattern formalizes that separation: a long-running operation is composed of local transactions paired with compensating actions that can be invoked after a later failure. Temporal's description emphasizes registering compensation deliberately, considering order, and making compensations idempotent.[^4] Compensation is semantic repair. It is not physical rollback, and it can fail too.
Retry introduces a different risk. Imagine a tool call times out after the remote API may have accepted it. A blind retry can duplicate the action. The correct retry contract therefore needs a unit of work, an attempt identity, eligible failure classes, backoff, an idempotency key, and an exhaustion path.
AWS Step Functions makes one recovery boundary concrete. Redrive can continue an eligible failed, aborted, or timed-out Standard Workflow execution from its unsuccessful step while preserving successful states. The failed step is rescheduled; the runtime does not restore a frozen process at its instruction pointer.[^5] That is closer to “another controlled attempt from known history” than a magical resume.
The practical rule is simple:
Never retry until the system can account for what the previous attempt may already have done.
Ownership transfer needs its own event
During a serious intervention, execution ownership and decision authority often change.
An autonomous lane may hand the run to an on-call operator. That operator may transfer command to a domain specialist. A security responder may revoke the original tool authority but allow a different actor to inspect state. None of those changes should be inferred from whoever clicked the latest button.
Camunda's task APIs provide a useful adjacent precedent by separating assignment from completion. Assignment conflicts can be rejected unless an authorized override is used, and completion can be restricted to the current assignee.[^6] Agent runs need the same clarity even if their ownership model differs.
A transfer record should name:
- the prior owner and new owner;
- whether the change transfers assignment, execution lease, decision authority, or all three;
- the reason and the actor who authorized the override;
- the unresolved side effects and pending decisions;
- the authority the new owner receives;
- who may resume, cancel, compensate, or close the run.
This metadata is operational: it is how the system prevents two operators—or an operator and an agent—from mutating the same run under conflicting assumptions.
Google's incident-management guidance is blunt about the analogous operational risk: establish an incident commander, keep command clear, and avoid uncoordinated freelancing. Its operations role is the controlled lane for modifying the system during an incident.[^7] Small teams can combine roles. They should not make command authority implicit.
Recovery begins with reconciliation
A worker crashes. The control plane still has a checkpoint and an event history. Is the run safe to continue?
Not yet.
Recovery should reconstruct durable state, verify history integrity, confirm code and configuration compatibility, and reconcile external effects. Only then should the system choose among replay, redrive, retry, compensation, or escalation.
The recovery gate is easier to inspect as an operator decision path:
This is not a universal state machine. Real systems will add states and enforce different boundaries. My requirement is that every transition preserve who acted, why, what was known, what authority changed, and which effects remain unresolved.
Kubernetes auditing describes the underlying standard well: a chronological record should make it possible to answer what happened, when it happened, who initiated it, what object it affected, where it was observed, and where it originated.[^8] An agent control plane should add the run-specific questions: which checkpoint, which attempt, which authority envelope, which external effects, and which operator decision.
The operator's run-control test
Before trusting an agent system with multi-step production work, I would ask it to demonstrate these controls against one realistic run:
1. Pause during an in-flight side effect
Can the system show what stopped, what may still complete, whether children are in scope, and which credentials remain active?
2. Resume after the world changes
The system should identify the exact durable boundary, revalidate stale assumptions and authority, and show which code may run again.
3. Cancel after one effect commits
Can it terminate future work without pretending the committed effect disappeared?
4. Retry an ambiguous timeout
Can it prove the attempt identity and idempotency key, then reconcile whether the first call succeeded before issuing another?
5. Compensate a partially completed run
It should produce a ledger of completed effects, available compensations, execution order, failures, and irreversible actions.
6. Transfer ownership under pressure
Can it distinguish assignment, execution lease, and completion authority while preserving the handoff reason and unresolved decisions?
7. Recover after a worker disappears
Can it rebuild state from durable history, reconcile external systems, verify runtime compatibility, and explain why the selected next action is safe?
If the answer is a final status badge, a generic activity log, or one overloaded stop button, the control plane is not finished.
Better models can make an agent more capable inside a run. They do not define what happens when an operator must intervene in that run.
I treat that as a systems problem: explicit states, bounded authority, accounted-for effects, named ownership, and evidence for every transition.
The next credible agent platforms will not merely show that a run stopped. They will show exactly what the stop meant.
Sources
[^1]: Temporal, Workflow Pause. [^2]: LangChain, LangGraph interrupts. [^3]: OpenAI, Agents SDK: Human-in-the-loop. [^4]: Temporal, Saga Pattern. [^5]: AWS, Restarting state machine executions with redrive. [^6]: Camunda, Assign a user task and Complete a user task. [^7]: Google SRE, Managing Incidents. [^8]: Kubernetes, Auditing.