Park
Pattern: A named solution to a recurring problem.
Stop an agent run in a recorded, preserved, and resumable state when it reaches a boundary it shouldn’t cross.
Also known as: Orderly Stop, Safe Stop
Where the Name Comes From
A parked car and an abandoned car have both stopped moving. Only one is off the road, secured, findable, and ready for its owner to return with the key. Agent runs need the same distinction.
The name also has software roots. Message-processing systems use dead-letter and parking-lot queues to hold work that can’t proceed without discarding or repeatedly disturbing it. Teams also “park” a discussion when it needs a later decision. This pattern applies that familiar move to an agent run and gives it a stricter contract.
Understand This First
• Bounded Autonomy — the limits whose breach triggers a park.
• Externalized State — the durable state a later run needs to resume.
• Checkpoint — the state-saving mechanism a park may use.
Context
This is an agentic execution pattern. An agent is working without turn-by-turn supervision: clearing a queue, implementing a phase, researching a defect, or coordinating other agents. Its task is bounded, but its circumstances aren’t. A required permission may be missing. A tool may fail in a way the run can’t repair. The evidence may contradict the requested plan. The next action may exceed the agent’s authority.
Stopping is then the right decision. The quality of that stop determines whether the next person can trust what remains.
Problem
An agent that can’t finish often does one of two harmful things. It pushes past the boundary by guessing, retrying, or widening its authority. Or it goes quiet and leaves a mystery: partial files, live child processes, an ambiguous workspace, and a final message that says little more than “blocked.”
How can an autonomous run stop without turning its unfinished work into a recovery project?
Forces
• Continuing may be unsafe, unauthorized, or wasteful, even when the original goal remains valid.
• Cleanup can destroy the evidence needed to diagnose the block or resume from it.
• Leaving processes and resources alive makes the scene unstable after the agent reports that it stopped.
• A later run doesn’t share the first run’s context, so an unexplained stop becomes archaeology.
• A truthful failure is more useful than a vague claim of partial success.
Solution
Park the run: record why it stopped, preserve its work and evidence, leave a proven clean scene, and name the exact condition for restart. A park makes four promises.
1. Written account. Record what finished, what didn’t, the event that forced the stop, and why the run couldn’t resolve it within its authority. Separate observed facts from conclusions. Include the last successful gate and the failing command or acceptance condition, but don’t bury the account in raw output.
2. Nothing disturbed. Preserve relevant artifacts, logs, diffs, and intermediate state. Don’t retry after deciding to park. Don’t perform cosmetic cleanup that could erase the failure’s cause. If a destructive rollback is necessary for safety, record the before-state first and say exactly what was removed.
3. Clean scene. Stop child processes, release locks and temporary resources, and prove the workspace is stable. Check for descendants that outlived their parent. When an orphaned writer could still change files, watch for a quiet window before calling the scene clean.
4. Restart contract. State the decision, permission, repair, or external event that would make continuation legitimate. Name where to resume and which checks must run first. “Try again later” isn’t a restart contract.
Finish by writing a truthful terminal outcome for the run. A failed run can still be finalized cleanly. The goal remains unfinished, but this execution now has a closed, inspectable record.
Warning: Don’t call a run parked while any producer can still mutate its workspace. A live child process plus a reassuring final message is an unobserved continuation, not a clean stop.
A Practical Park Record
A useful record answers these questions without requiring the reader to reconstruct the session:
• What outcome was the run pursuing?
• What completed, and what evidence proves it?
• What exact condition caused the stop?
• What files, processes, locks, and external resources remain?
• What was deliberately left untouched?
• What authority or state change permits a restart?
• Where should the next run resume, and what must it verify first?
Store the record beside the workflow’s durable state, not only in chat history. Link to the relevant agent trace, progress log, and artifact digests so the next operator can inspect rather than trust a summary.
What a Park Isn’t
Established stopping modes cover parts of the job. None carries the whole contract.
| Mode | What it provides | Why it isn’t a park |
|---|---|---|
| Interrupt or pause-resume | A designed suspension until input arrives | It may persist execution state, but it doesn’t require a causal account, a proven clean scene, or explicit restart checks. |
| Checkpoint, replay, or recovery | Saved state and machinery for continuing after interruption | These make resumption cheap. They don’t decide when stopping is responsible or what the stop must record. |
| Halt or terminate | An end to execution | The process may stop with no preservation or restart contract. |
| Graceful shutdown | Resource release and orderly process exit | It cleans up the runtime but may say nothing about unfinished work, evidence, or authority. |
| Crash-only operation | Recovery paths handle every stop, so special shutdown paths aren’t needed | This fits stateless, replicated services better than evidentiary work whose intermediate state and causal record matter. |
| Premature termination or early exit | A failure label for stopping before the task is done | It names the unwanted outcome. A park is the deliberate discipline that prevents an incomplete run from becoming an opaque one. |
| Dead-letter or parking-lot queue | Failed work is held aside for inspection and deliberate replay | It applies the preservation idea to messages or jobs, not to the full state and obligations of an agent run. |
A Circuit Breaker is a close sibling. It stops calls through one failing path while the surrounding system keeps running. A park stops the run itself because continuing the broader execution is no longer justified.
Four Words for Run Lifecycle
Park becomes clearer alongside three other lifecycle terms. Each closes a different kind of uncertainty.
Finalized means the run has a truthful terminal record. Success, failure, timeout, and cancellation all qualify when recorded accurately. Finalization closes the lifecycle; it doesn’t claim that the goal was achieved.
Sealed means an artifact passed a named acceptance gate and is closed as evidence. A seal binds the artifact’s bytes to a verdict: what was checked, which authority accepted it, and which run produced the result. Downstream stages cite that sealed artifact rather than quietly regenerating it.
A Git commit is a familiar seal. Its hash covers a tree and chains it to prior history, but proves only what existed at that digest. It doesn’t prove why a later stage may rely on the content. An agentic seal adds that predicate: “this tree passed review X under authority Y in run Z.” Supply-chain attestation systems such as in-toto and SLSA formalize the same subject-plus-predicate structure.
This sense of sealed has nothing to do with Java sealed classes, which restrict type inheritance, or legally sealed records, which are hidden from view. An agentic seal exists to be read and relied on. Apple’s Signed System Volume offers a closer precedent: a Merkle root called the seal detects any change to the protected tree.
Refuse to seal when the gate failed, the artifact can still change, its digest is missing, its provenance is unknown, or the signer lacks authority. During a long phase, a workflow can seal an uncommitted working tree by digest, then bind that seal to the phase-closing commit. The evidence forms a chain: a coder implements against a sealed plan, a reviewer checks a sealed candidate with a frozen tool, and the final record cites each verdict.
Frozen means the measurement or execution tool is byte-identical and read-only under a recorded manifest. Freezing controls the instrument, not the evidence. If a renderer, test harness, or evaluator drifts between measurements, the comparison can’t support a verdict.
Parked means the run stopped under the four promises in this article. A park preserves finalized records, sealed evidence, and frozen instruments without confusing their roles.
How It Plays Out
A coding agent is implementing a database migration when it discovers that the production schema differs from the checked-in migration history. It has permission to edit the repository but not to inspect or change production. Instead of guessing from stale files, it parks. The record names the schema mismatch, preserves the generated migration and command output, confirms that no migration process remains live, and states the restart condition: a database owner must supply a read-only schema snapshot. The next run resumes at schema comparison rather than rebuilding the whole investigation.
An overnight dependency loop launches a worker for each service. One worker’s test command hangs and leaves a server process holding a port. The supervisor reaches its retry budget, terminates the worker’s descendants, verifies the port is free, and watches the worktree until its file times stop changing. It records the last passing commit, the timed-out test, and the command that reproduces the hang. The run is failed but finalized, and the candidate tree remains available for diagnosis.
A multi-agent construction workflow finishes its plan review. Before coding begins, the orchestrator seals the plan by hashing the tree and attaching the review verdict. The coder later finds that an acceptance criterion requires product authority the run doesn’t have. It parks without editing the sealed plan. The restart contract asks the owner to resolve one named decision; after that decision lands, a new plan seal is required before implementation can continue.
Consequences
Benefits. Parks make incomplete runs easier to inspect and resume. They keep agents from turning a legitimate boundary into an unauthorized guess. They also separate two truths that weak status reports blur together: the goal is unfinished, and the run stopped correctly.
Liabilities. A park takes time. Capturing evidence, finding descendants, proving stability, and writing restart conditions can cost more than another blind retry. Workflows also need durable places for records and artifacts. If every minor uncertainty triggers a park, throughput collapses into human triage.
The trigger should follow Bounded Autonomy: park when the next useful action needs authority the run lacks, when further attempts would disturb evidence, or when the workflow can’t prove that continuing is safe. Ordinary recoverable failures still belong inside retry budgets and verification loops.
Related Articles
Complements: Circuit Breaker — A circuit breaker stops calls through a failing path; a park stops the agent run itself.
Contrasts with: Human in the Loop — Human-in-the-loop checkpoints are designed suspensions; a park handles an unplanned boundary without losing the scene.
Depends on: Bounded Autonomy — Autonomy limits define the conditions that should trigger a park.
Produces: Handoff — The park record is a handoff to the person or later run that decides what happens next.
Used by: Background Agent — Background agents need a safe way to stop when unattended work reaches a human boundary.
Used by: Loop Engineering — Unattended loops need a defined park path when their stop conditions fire before the work is complete.
Uses: Agent Trace — A park preserves the trace that shows what the run did before it stopped.
Uses: Checkpoint — Checkpoints save recoverable state; a park adds the obligations for ending and later resuming the run.
Uses: Externalized State — A parked run needs inspectable state that survives after the agent goes quiet.
Uses: Progress Log — The progress log carries the causal account and restart conditions that make a park useful.
Sources
• LangGraph’s interrupt documentation defines designed pause-and-resume points that persist graph state while waiting for external input.
• George Candea and Armando Fox’s “Crash-Only Software” argues that reliable services can use one recovery path for both planned and unplanned stops, the philosophy contrasted here with evidence-heavy agent work.
• Santiago Torres-Arias and colleagues’ in-toto paper defines supply-chain attestations that bind artifacts and step metadata into a verifiable chain; the SLSA provenance specification gives a widely used subject-and-predicate form.
• The Git object model explains how commits identify complete trees and chain history by hash, providing the familiar substrate for artifact seals.
• Apple’s Signed System Volume security guide describes the Merkle-tree seal that detects modification anywhere in the protected system volume.
• AWS’s dead-letter queue pattern documents the message-processing ancestor: failed items are isolated for inspection and controlled redrive instead of being discarded or retried forever.