Stop, Resume and Restart

Stop interrupts execution, Resume tries to continue from saved state, and Restart begins again.

What you will learn

  • Explain: context is the workbench
  • Apply the idea in an example: Stop, Resume and Restart
  • Recognize limitations and verify the exercise outcome

Stop interrupts execution, Resume tries to continue from saved state, and Restart begins again. This matters when actions have effects.

These steps refer to features identified in the application code. This material has not been validated on a live instance; check the documentation and the options in your version.

How it works, step by step

Context is the workbench

Context includes instructions, the current request, relevant history, retrieved documents and tool results. The context window has limited capacity; reserve room for the response too. More text does not automatically improve accuracy. Irrelevant information and contradictions can hide important evidence. Summarize history carefully and preserve the origin of facts. State describes the current run, a checkpoint saves a resumable point, and persistent memory retains information across runs. These are different mechanisms managed by the application.

Errors need explicit paths

A timeout differs from a permission error. Retry only transient errors, with bounded attempts and increasing delays. An operation with side effects may execute before its response is lost; retrying without an idempotency key can duplicate the effect. Streaming shows progress but does not guarantee completion. Checkpoints may allow failed stages to resume within runtime limits. Store the run identifier, stage, duration and error while removing secrets from logs. Measure slow paths as well as averages.

The model proposes, the tool executes

Tool calling produces a call request with a name and arguments. The application validates the schema, permissions and limits before execution. The result returns to context for the next step. For example, get_product_stock takes a SKU and returns a quantity; its description should explain that it does not reserve products. Distinguish empty results, validation errors, missing access and timeouts. Valid JSON does not prove the arguments are correct or the action is authorized. For external effects, also consider duplicate execution.

The visual map

Stop, Resume and Restart Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. Resume uses the saved execution; Restart begins a new one. A checkpoint is not persistent memory. Connections: User request → Agent / LLM; Agent / LLM → Result to verify; Result to verify → Human verification; Agent / LLM → Stop current execution; Stop current execution → Execution checkpoint; Execution checkpoint → Resume saved execution; Resume saved execution → Result to verify; Restart a new execution → Agent / LLM; Shared execution state → Execution checkpoint. U03 · Relationship map Stop, Resume and Restart Input User request AI model / agent Agent / LLM Store / index Shared execution state Decision / control Stop current execution Store / index Execution checkpoint Processing Resume saved execution Processing Restart a new execution Output Result to verify Decision / control Human verification Main flow Data and context Feedback and return

Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. Resume uses the saved execution; Restart begins a new one. A checkpoint is not persistent memory. On smaller screens, scroll horizontally to follow the entire diagram.

A complete example

A workflow retrieves policy and then hits an unavailable tool. Resume can retain completed work when a checkpoint exists. Restart may repeat retrieval and other operations.

Try it yourself

  1. Test interruption on a read-only workflow and compare Resume with Restart.
  2. Record the input, source and expected outcome before running the experiment. Use only the fictional data in the example.
  3. Follow the diagram stages. At every step record what information is received and produced; do not confuse intermediate output with the final outcome.
  4. Repeat after removing necessary information or making the input ambiguous. Check whether the system clarifies, stops or invents an answer.
  5. Compare with the explained solution. Keep the configuration, date, result and an explanation for differences. Change one thing and retest.

An explained solution

Choose recovery after checking completed stages and their effects. A successful exercise lets you show the connection between input, stages and outcome. When information is missing, a cautious answer is more useful than invented details. Compare more than style: check conditions, sources and operations too.

When it helps and what can go wrong

Stop does not undo completed operations. Choose this approach when it improves a measured need. Keep a simple baseline and compare outcomes using identical inputs. One successful example does not establish reliability in every situation.

Check your understanding

Is a checkpoint permanent user memory?

No. Saving a run does not imply retaining preferences across conversations.

Does a timeout prove the operation did not execute?

No. Check state before retrying an action with side effects.

What outcome should this exercise produce?

Choose recovery after checking completed stages and their effects.

Words to remember

  • Checkpoint: Saved state used to resume an execution.
  • Idempotency: Controlled repetition without duplicating an effect.
  • Tool calling: A structured request to use an external capability.

Sources and your next step

To prepare: U02 — Playground as a laboratory