If your agent cannot survive a mid-flight correction, it is not ready.

This is a loser-interesting question because it starts at the least flattering moment in the workflow. The user gave the agent enough rope to act, then noticed it was heading in the wrong direction. Now they want to interrupt without feeling stupid, without losing the useful parts, and without spending the next hour cleaning up side effects the tool created too eagerly. That moment decides more real adoption than the first dazzling demo ever will.

The thesis:

Serious agent systems optimize for correction, not just completion. That means state is carried by explicit handles instead of warm-session folklore, long-running work has a real poll, update, and cancel path, risky tools stay behind human-visible approvals, and local repair remains cheap enough that the user can change course before public proof is emitted.

The social cost is the hidden product metric

Most agent demos are graded on whether the model looked autonomous on the first pass. Operators grade the same system on a meaner criterion: what happens when reality changes halfway through? A teammate pastes a corrected URL. A missing file shows up. A deploy should hit staging, not production. The model picked the wrong target. The user simply changes their mind after seeing the first result.

If that moment forces the user to either let the wrong run continue or confess they no longer trust the system, adoption stalls. The embarrassing part of real AI work is not being wrong. It is being wrong in public while an overeager tool is still moving.

This is why the correction path matters more than the benchmark claim. A user will forgive a tool for needing redirection. They will not forgive a tool that makes redirection expensive.

The protocol stack is already converging on this rule

The official MCP tools spec says the quiet part out loud: there should always be a human in the loop with the ability to deny tool invocations, clear indicators when tools run, and confirmation prompts for operations (MCP tools spec). The draft MCP overview pushes the same trust model further: users must explicitly consent to data access and tool use, and hosts must keep users in control of what is shared and what actions are taken (MCP draft specification).

The state model is moving in the same direction. SEP-2567 removes protocol sessions as the place where continuity quietly lives and replaces that pattern with explicit, server-minted handles that the model threads through later calls. If the user says "not this browser" or "resume the other run," there is something concrete to point at.

Long-running work is getting the same treatment. SEP-2663 defines a task handle plus tasks/get, tasks/update, and tasks/cancel. That is not glamour. It is recoverability. A serious agent run now has a shape the operator can inspect, redirect, or stop without pretending the original blocking call is still the only reality.

Name the state.

If a workflow spans calls, the model should carry a real handle: task_id, browser_id, run_id, or another inspectable identifier.

Make interruption first-class.

A durable poll path and a real cancel or update path matter more than one more speech about autonomy.

Keep approval visible.

If a tool changes the world, the user should be able to deny, reroute, or narrow it without spelunking hidden state.

Separate correction from publication.

A draft run can stay private and local. Public proof should only happen after the corrected path is the one you actually endorse.

Risk vocabulary is useful, but it does not remove judgment

The newer tool-annotation discussion makes this even clearer. The official MCP blog frames readOnlyHint, destructiveHint, idempotentHint, and openWorldHint as a basic risk vocabulary for tool calls, while stressing that these fields are still hints rather than trusted contracts (Tool annotations as risk vocabulary). That is exactly the right posture. Better hints help the user understand what kind of interruption or confirmation a tool deserves. They do not remove the need for the host to keep a real approval boundary.

UI-rich agent experiences are landing in the same place. The official MCP Apps launch post highlights sandboxed iframes, auditable JSON-RPC messages, and optional explicit approval for UI-initiated tool calls (MCP Apps). In other words: richer interfaces are welcome, but they are not allowed to smuggle the human decision point out of the workflow.

Surface Autonomy theater Correction-friendly system

Continuity Warm session remembers everything Explicit handles survive retries and handoffs

Long work Blocking call plus hope Pollable task with update and cancel path

Tool authority Generic shell with vibes Named tools with visible approval seams

UX Success narration hides risk Indicators, approvals, and auditable messages stay visible

Shipping "Trust me, it finished" Diff, build, smoke, deploy, and live verification receipt

Local-first stacks are especially tempted to cheat

Local systems can fake maturity because process lifetime is so convenient. The same PTY remembers the current directory. The same browser keeps the login. The same worker hides the same fragile state. A correction looks easy only because the entire story is still warm.

That is why a stable serving boundary matters. The current vLLM docs emphasize an OpenAI-compatible HTTP server with supported APIs, including Chat Completions and Responses (vLLM OpenAI-compatible server). That interface is boring in exactly the right way. The model can change, the routing can change, the run can restart, and the contract can still stay legible to the rest of the stack.

When the model boundary is boring, you can be stricter about the action boundary too. The host-side layer does not need to pretend free-form shell state is a product. It can expose bounded verbs and let correction operate on named objects instead of ambient folklore.

The Chopshopr interpretation is narrower on purpose

Chopshopr's public package and site contracts make more sense through this lens than through demo theater. The local model path is intentionally dull: one default model endpoint per MCP registration, a stable OpenAI-compatible server boundary, and a normal prompt path on local_generate_default. The host path is equally explicit: nemoclaw_doctor, nemoclaw_run, and openshell_run expose bounded operations instead of pretending a warm shell is the product (Chopshopr README: NemoClaw MCP).

The ship path follows the same logic. Worktree-first build and autoship insist that a finished change can survive verification outside the original typing trance: bun run build, smoke, synth, push, deploy, and live verification (Chopshopr README: worktree-first build and autoship). That is just the same correction philosophy wearing release clothes. The system should make it cheap to catch the wrong route before it becomes public fact.

Expose the handle: if the run spans time, return a durable identifier the operator can inspect and pass forward.
Make stop and update real: cancellation should be a product surface, not a terminal superstition.
Keep risky verbs bounded: the user should know whether a tool is read-only, destructive, idempotent, or open-world before authorizing it.
Prefer local repair first: fix the draft, the browser state, or the task handle before emitting public proof.
Publish receipts after correction: route, search index, smoke, build, deploy, and live checks are where corrected trust becomes transferable.

The rude question worth keeping

Do not ask only whether the model can finish the task. Ask what happens when the user interrupts the run, supplies a new fact, or simply says "wait, not like that."

If the answer is "the user must become the continuity layer and the cleanup crew," the product is still borrowing trust from performance. If the answer is "the system exposes the handle, shows the risk, accepts the correction, and leaves a cleaner receipt," then you are getting closer to a dependable tool.