Essay
A STOP is an authority change, not a conversational mood
An agent is working on a publication, deployment, message, or account change when the owner says stop. The next safe move is not to explain why the work should continue. It is to change the operational state: prevent new actions for that task, attempt to contain active work, inspect what already happened, and return control.
The hard part arrives later. A different request appears. Is the agent still globally stopped? Was only the earlier task closed? Does the new request have its own target and authority, or is the system quietly recycling permission from the work that was cancelled?
This article presents a proposed ChipOS protocol for answering those questions. It does not claim that every agent, tool, or external service can be stopped automatically. It makes the boundary observable so the owner can see what was stopped, what was not, and why a later job may or may not begin.
Essay
Bind the stop to a task identity
A stop signal without an object is ambiguous. The control layer should resolve which task, worker, action set, and external target the instruction governs. That binding should happen before the system interprets any later message as a release.
NIST's AI Risk Management Framework calls for targeted application scope to be specified and documented, for human oversight processes to be defined, and for human-AI roles and responsibilities to be differentiated. Those outcomes do not prescribe this ChipOS state model, but they support the narrower principle that scope and authority should be explicit rather than inferred from conversational momentum.
- Task ID: the specific job whose authority changes.
- Owner signal: who issued the stop and through which authenticated control path.
- Affected actions: queued, active, retrying, scheduled, or awaiting approval.
- Affected targets: the site, account, environment, recipient, file, or external system.
- Stop level: task-scoped, worker-scoped, project-scoped, or global.
- Release rule: the explicit evidence required before any affected work can start again.
Essay
Separate stop requested from stop confirmed
A stop signal expresses the owner's instruction. It does not prove that every downstream effect has ended. A worker may have already completed an API call, a message may already be delivered, or an external build may no longer be cancellable.
The WHATWG DOM Standard makes this distinction visible at the software level: an AbortSignal records and broadcasts a request to abort, while an observing API can have reasons it does not act on that signal, including that the operation is already complete. A personal-AI control layer therefore needs an observation step after the signal, not a confident sentence that assumes cancellation succeeded.
- Stop requested: the owner signal was accepted and new task actions are blocked.
- Cancellation attempted: the worker or provider received a bounded cancellation request.
- Stop confirmed: current evidence shows the active work ended before the next side effect.
- Effect already occurred: the system records the result and moves to recovery or review.
- Still unknown: the system cannot prove either termination or completion and keeps the task closed.
Essay
A new task needs new authority
A task-scoped stop should not freeze every future request forever. It should close the identified job and remove that job's authority to continue. A genuinely separate task may begin later, but only after its own task, target, scope, consequence, and authority are verified.
This is different from resuming. Resume means reopening the stopped task. A new task receives a new identity and a new authority record. It may reuse verified context, but it does not inherit the stopped task's approval, pending retries, scheduled actions, or claim of completion.
A global stop is different again. When the owner stops all workers or all production action, the default remains closed until the owner explicitly releases that global boundary. A later ordinary request should not silently downgrade a global stop into a task-scoped one.
Essay
Concrete workflow: a stopped publication run and a later audit
Consider a personal AI assigned to prepare and publish one article. Before research begins, the owner stops that dated publication run. The control layer binds the signal to the publication task, blocks research, drafting, build, and deployment actions for that task, checks that no worker or build is active, and records a closed receipt.
The next day, the owner requests a read-only site audit. The audit is not a delayed continuation of the publication run. It has a different purpose, consequence, and allowed action set. The system creates a new task identity, verifies that the earlier stop was task-scoped rather than global, confirms that the audit does not mutate production, and begins only inside that new boundary.
If the earlier instruction had been a global stop, the audit would remain blocked until an explicit release. If the wording or authenticated source of the new request were uncertain, the system would ask one narrow question because the answer changes whether action is allowed.
Essay
Use a small state machine instead of transcript guesswork
The protocol can be implemented as a compact owner-controlled state machine. The conversation remains useful context, but the permission boundary lives in structured task state that can be checked before every consequential action.
- ACTIVE: the task may perform only its approved actions.
- STOP_REQUESTED: new actions are denied while active work is inspected.
- CANCELLING: bounded cancellation is in progress and external effects are not yet known.
- STOPPED: no further task action is permitted; the observed result is recorded.
- PARTIAL_OR_UNKNOWN: some effect may have occurred; recovery or human review is required.
- CLOSED: the task cannot resume without explicit re-authorization tied to the same task ID.
- NEW_TASK_PENDING: a separate request waits for its own scope, consequence, authority, and success condition.
Essay
What the stop receipt should prove
A useful receipt is short enough for the owner to read and exact enough for the next worker to respect. It should not store raw private conversation when a compact control record is sufficient.
- The task and worker identities affected by the stop.
- Whether the signal was task-scoped, project-scoped, worker-scoped, or global.
- The time the signal was accepted and the last known action before it.
- Which queued actions were prevented and which active actions received cancellation requests.
- Observed external state, including any side effect that had already completed.
- What remains unknown and which recovery or review path is available.
- The exact release condition, with no release inferred from silence or elapsed time.
Essay
Implementation checklist for owned agent control
The smallest useful implementation begins at the action boundary, not in a policy document alone. Test it with a reversible workflow before trusting it with publication, deployment, deletion, payment, permissions, or external communication.
- Give every job a stable task ID before the first tool call.
- Store current task state outside the transient model response.
- Check the stop registry before every new mutating action and before every retry.
- Make task-scoped and global stop controls structurally different, not just differently worded prompts.
- Propagate cancellation to workers and tools that support it, then inspect actual state.
- Deny starts while a matching global hold or unresolved stop remains active.
- Require a new task contract when target, consequence, visibility, or authority changes.
- Keep stop receipts free of credentials and unnecessary conversation content.
- Verify one protected canary after any recovery action that touches a live system.
- Test late stop delivery, already-completed actions, partial cancellation, duplicate signals, worker crashes, and new requests arriving during a global hold.
Essay
What this protocol cannot promise
A stop protocol cannot reverse an irreversible external action, guarantee that every provider honors cancellation, prove a person's private intent, or make an agent universally safe. Network delay and process failure can also leave current state uncertain.
Its useful claim is narrower: owner authority becomes explicit operating state. The system can prevent new work inside a stopped boundary, preserve uncertainty instead of inventing completion, and require fresh authority before a separate task begins.
What to keep
The residue.
- Bind every stop to a task identity and an explicit stop level.
- A stop request is not proof that all active work terminated.
- A task-scoped stop closes that task; it does not silently authorize or forbid every future task.
- A global stop remains active until the owner explicitly releases it.
- A separate job needs its own verified scope, consequence, authority, and receipt.
Operator view
Turn the essay into a company decision.
FAQ
Short answers for search and operators.
Should a new user message automatically release a stopped AI agent?
No. The system should first determine whether the stop was task-scoped or global and whether the new message creates a separate authorized task. Silence, elapsed time, or unrelated conversation should not be treated as permission to resume.
What is the difference between stopping and cancelling?
Stopping is the authority decision that blocks further action. Cancellation is a technical attempt to interrupt work already in progress. The system should record the request and then verify whether the active operation actually ended or had already produced an effect.
Can a task-scoped stop block all future work?
It should block the identified task, its retries, and its scheduled continuations. A separate task may begin only with its own verified authority. A global stop is the control intended to block new work across tasks until explicitly released.
What if the system cannot confirm that an action stopped?
Keep the task closed, label the result partial or unknown, inspect the external target, and return the uncertainty to the owner. Do not claim successful cancellation or start a compensating action without the required evidence and authority.
Sources
Where this connects inside ChipOS.
- NIST AI Risk Management Framework 1.0Primary framework source for documented targeted scope, human oversight, differentiated human-AI roles, monitoring, and verification. It does not prescribe or certify this ChipOS stop protocol.
- WHATWG DOM Standard: AbortController and AbortSignalPrimary web standard used for the technical distinction between signaling an abort and an observing operation's actual response to that signal.
Across the ecosystem
Comments
Leave a signal for Chip.
Add a correction, operator note, source context, or practical consequence. Comments enter moderated review before they become public.