An agent stopped mid-task is not the same as an agent that finished. If the agent has already taken some actions and not others, the world is in an inconsistent state. A flight booked, a hotel not yet booked. A label added, a related label not yet removed. A draft created, the parent thread not yet archived. The three patterns below let you stop an agent without leaving these gaps.

The patterns come from distributed-systems engineering, where this problem is older than agents (Garcia-Molina & Salem, "Sagas", 1987). Agents add the wrinkle that the agent's own decisions can change between runs, which means a half-finished run cannot necessarily be resumed by re-running.

Why mid-task stops are tricky

Most agent tasks are not single atomic actions. The agent reads, decides, calls a tool, reads the result, decides again, calls another tool. The intermediate state between tool calls is the agent's reasoning context, which lives in the model's context window and is lost when the run stops.

If the agent has only made read-only calls, killing is safe. The agent's decisions are gone but no external state changed. If the agent has made write calls that need to be paired with other writes, killing leaves the writes-so-far in place without the writes-still-to-come. The blast radius depends on which writes happened. The reversibility classifier in how to limit AI agent actions tells you which writes are reversible, compensable, or irreversible.

Pattern 1: Checkpoint between actions

Checkpointing is the right pattern when the agent's task is naturally segmented into independent units. A daily inbox triage agent processes 50 messages independently; each message is its own unit. After processing message N, the agent records a checkpoint: messages 1 through N are done, message N+1 is next.

If the agent stops mid-task, the next run reads the checkpoint and resumes from N+1. The work already done is preserved; the work not yet done is picked up. The pattern requires that each unit is independent (no cross-unit state) and that the checkpoint is durable (written to a destination the agent does not lose on restart).

Most personal agents fit this pattern. Inbox triage, document classification, watch-list scanning: each unit is independent. Checkpoint between units; resume on restart.

Pattern 2: Compensating actions (saga pattern)

The saga pattern is the right design when the task is a single transaction split across multiple tools. The classic example: book a flight, book a hotel, charge a card. Each step is a write to a different system. If step 2 fails (or the agent stops between step 1 and step 2), the flight is booked but the hotel is not.

The saga pattern records a compensating action for each write. The compensation for "book flight" is "cancel flight." For "book hotel" is "cancel hotel." For "charge card" is "refund card." If the run is interrupted partway through, the recorded compensations are applied in reverse order. The flight gets cancelled; the partial state is undone.

Saga: forward writes (top) paired with compensations (bottom) 1. Book flight 2. Book hotel 3. Charge card Done Stop signal at step 2 → run compensations in reverse order: 3. Refund card 2. Cancel hotel 1. Cancel flight Each forward write has a recorded compensation. State returns to pre-task baseline. Source: Garcia-Molina & Salem, "Sagas", 1987; Aryan Agarwal, May 2026.
The saga pattern is older than agents and works for any multi-step transaction across systems.

The compensations have to be designed before the run. They are part of the agent's task definition: "for each write, here is the compensation." Some writes have no compensation (sent emails cannot be unsent), in which case those steps cannot be part of a saga and should be the final step of the task or be kept separate.

Pattern 3: Soft-stop with completion-or-rollback

The soft-stop pattern is the production default. Instead of killing the agent's process, the operator sets a flag the agent checks between actions. When the flag is set, the agent finishes the current logical unit of work and exits cleanly. If the agent is in the middle of a saga that cannot finish cleanly, it triggers the compensations.

Soft-stops have several origin points. The operator's kill switch (manual). The cost cap (the agent's per-task budget is exhausted). The schedule (the agent's allowed run window has expired). The platform's safety controls (an anomaly was detected). All of these resolve to the same flag the agent checks between actions.

The soft-stop pattern requires the agent to actually check the flag. This is a runtime concern, handled by the agent platform, not by the prompt. Verify with the platform's documentation that soft-stops are honoured between every tool call. If they are honoured only at the end of the run, the soft-stop is no better than waiting for the run to finish.

The kill switch checklist

A working kill switch has the following properties:

The kill switch is a feature, not an emergency tool. Use it routinely: after a deployment, when changing prompts, when reconfiguring tools. Routine use surfaces issues with the stop logic before an actual emergency.

Frequently asked questions

Can I just kill an AI agent mid-task?

You can, but the cost depends on what the agent has already done. If the agent has only made read-only calls, killing is safe. If the agent has made write calls that need to be paired with other writes (a transaction split across tools), killing leaves inconsistent state. The three patterns below avoid the inconsistency.

What are the three safe-stop patterns for an AI agent?

Checkpoint between actions (the agent records progress between each tool call so a stop can resume cleanly), compensating actions (the saga pattern: every write has a recorded inverse that can be applied if the run is interrupted), and soft-stop with completion-or-rollback (the agent receives a stop signal and either finishes the current logical unit or rolls back what it has done).

What is the saga pattern for AI agents?

The saga pattern, borrowed from distributed systems, treats a multi-step task as a sequence of writes each paired with a compensating action. If the run is interrupted partway through, the recorded compensations are applied in reverse order to undo the partial work. The pattern is the right design when each step is independently committable and the steps can be undone individually.

When should I use checkpointing vs sagas?

Checkpointing is right when the agent's task is naturally segmented into independent units (process 100 inbox messages, one at a time). Sagas are right when the task is a single transaction split across tools (book a flight, book a hotel, charge a card). Use whichever matches the task structure; combining them is rarely needed.

What is a soft-stop signal for an AI agent?

A soft-stop signal is a flag the agent checks between actions. When set, the agent finishes the current logical unit of work and exits cleanly, instead of being killed in the middle of a tool call. The signal is set by the operator (kill switch) or by the platform (cost cap reached, schedule expired). Soft-stops are the right default for production agents.

Three takeaways before you close this tab

Sources