Status questions and stop commands are not the same

Here is the short answer: “Where is the task now?” and “Stop doing that” should not be handled as the same kind of message. The first is a status query. Its job is to read existing progress and report the current state. The second is a control command. Its job is to change the system by actually stopping a running task. When an execution-focused assistant mixes the two up, the common failure mode is not a slightly awkward conversation. It is real damage: either the assistant retriggers work while answering a progress question, or it kills a task when the user only wanted an update.

That is why OmniGoAI’s GoWork separates status reporting, continuation, and stopping. In a system that can read files, run commands, operate the desktop, and keep multiple runs alive at once, short user messages are not harmless chat. They can map to real side effects. A reliable assistant does not treat every follow-up as the same generic “next step.” It first decides: is the user asking for an observation, or issuing a control instruction?

If you have already read Why a status question should not retrigger the task and Why assistants should explain intent before tool actions, this article takes the next step: why asking for progress and asking to stop are not just different tones, but different orchestration inputs altogether.

The short answer: status queries report facts, stop commands change facts

A practical rule helps here:

Messages like “where is it now?”, “how much longer?”, and “did that task finish?” are usually asking for the current fact state.
Messages like “stop,” “never mind,” “don’t do that,” and “cancel that task” are usually asking the system to change the execution state right now.
The safest default for the first group is to read the active run summary, recent events, and waiting reason.
The safest default for the second group is to identify the target run and actually cancel it—not merely say “okay, I’ll stop.”

That boundary may sound simple, but it determines whether an assistant behaves like a collaborator or a hazard. Status queries solve an understanding problem. Stop commands solve a control problem. They need to hit different layers of the system.

Why “where is the task now?” should not be handled like “stop doing that”

Because the user wants observation, not intervention

When users ask where a task stands, they are usually asking things like:

which steps are already done;
what the task is currently waiting on;
whether it is running, queued, blocked, or finished;
roughly how much work is left;
whether there is an error or an outside blocker.

What those questions have in common is simple: the user wants execution facts the system should already know. The correct first move is to inspect that state, not to interfere with it.

If the assistant misreads a status question as a stop signal, the experience breaks immediately. The user only wanted context, but the assistant made a decision on the user’s behalf and killed the task.

Because status questions should be read-only by default

A healthy execution system should already expose signals such as:

the active run state;
the latest user-visible progress update;
the current step title, waiting reason, or failure summary;
the resource holder or queue state.

So when the user asks for progress, the most sensible default is: read those signals first, then answer. If the assistant jumps straight to a stop path instead, it skips the exact evidence layer that exists for this kind of question.

Why “stop doing that” should not be handled like “where is the task now?”

The reverse mistake is just as bad. A stop command cannot be satisfied by a status summary.

Because the user is not asking what the system sees

If the user says:

“stop”;
“never mind”;
“don’t do that anymore”;
“cancel that task”;

then the real request is not “tell me the current state.” It is “apply control to the current state.” If the assistant merely replies with a progress update such as:

“it is publishing to the third platform now”; or
“deployment is done, indexing is next”;

that may be factually correct, but it does not satisfy the user’s request. A read-only answer does not stop a running task.

Because saying “stopped” is not the same as actually stopping

One of the most dangerous fake completions in execution systems is saying “I cancelled it” while the underlying run is still active. A desktop workflow may still be clicking, a background command may still be building, and a publishing pipeline may still be moving through targets. If the assistant does not actually invoke cancellation, then “okay, I’ll stop” is only language, not control.

That is why a proper stop flow in a system like GoWork usually has to:

identify which active run the user means;
issue the real cancel action;
then report what had already finished and what the true final state is.

That order matters. Skipping the second step creates a false sense of control.

Why these two message types hit different system layers

Status queries hit the execution metadata layer

Status questions usually depend on read-only signals such as:

recent events;
the latest summary;
the waiting reason;
current plan-step states;
resource occupancy and queue information.

Those signals matter because they are:

read-only, so they do not disturb the scene;
close to now, so they answer present-tense questions well;
cheap, so they avoid retriggering desktop or shell work;
explainable, so the assistant can turn them into a clear human answer.

Stop commands hit the task-control layer

Stop commands depend on something else:

which run is still active;
what “that one” refers to in the current context;
whether cancellation actually succeeded;
what state remains after the cancel request.

So this is not a “read and summarize” flow. It is a “control first, then report” flow. If the assistant never touches the task-control layer, the task will not stop.

The easiest mistake: treating every short follow-up as the same kind of message

Real users rarely speak in perfect full sentences. The frequent inputs look more like this:

“what about that one?”
“and now?”
“stop.”
“leave it.”
“continue.”
“change the one above.”

The problem is that they are all short, but they do not mean the same thing.

Read-only status questions usually sound like this

For example:

“Where is it now?”
“How much longer?”
“Did that task finish?”
“What step is it on?”

The core meaning is: tell me the current state.

Explicit stop commands usually sound like this

For example:

“Stop.”
“Never mind, don’t do it.”
“Cancel this task.”
“Don’t continue that one.”

The core meaning is: make it stop.

The hardest cases are corrections, not pure status or pure stop

Messages like “pick the 64-bit one,” “log in with another account,” or “skip CNBlogs” are often neither read-only status requests nor full stop commands. They are course corrections. In those cases, the safest response is usually not to cancel immediately, but to determine whether the user wants to modify the current task or start a new one.

That boundary matters too: being able to redirect a task does not mean the assistant should kill it first.

What goes wrong when both message types are treated as one

1. It creates unnecessary interruption

If the user only wants a progress update and the assistant stops the task, completed work may be wasted:

a build finished but deployment had not started;
a login session is ready but submission has not happened;
a queued desktop run loses its place;
half the publishing targets are done but logging has not finished.

That is not just a conversational mistake. It is a workflow-control mistake.

2. It creates the illusion of control

The opposite mistake is worse: the user clearly says stop, but the assistant only provides a status summary and never issues cancellation. In that case, external actions may continue:

background builds keep running;
desktop automation keeps occupying the resource;
publishing continues to the next target.

The user believes the system obeyed, but it did not.

3. It breaks concurrent orchestration

In a resident assistant like GoWork, multiple runs may coexist. Status questions should usually be answered through read-only state and should avoid touching the desktop. Stop commands should precisely target the intended run. If the system confuses the two, it either grabs exclusive resources for no reason or stops the wrong task.

In concurrent execution, that is not a minor flaw. It is a correctness problem.

A safer decision order

When a short follow-up arrives, this order is usually the safest:

decide whether the user wants an observation or a control action;
if it is an observation, read the active run, recent events, and waiting reason;
if it is an explicit stop command, identify the target run and cancel it;
if it looks like a correction, do not cancel by reflex—decide whether the user means to redirect the current task instead;
only then explain the true resulting state in natural language.

The advantage of this order is simple: it separates reading state from changing state. Once those are no longer mixed, the assistant is much less likely to make basic but costly orchestration mistakes.

Why this boundary directly affects user trust

Users notice two failures immediately:

“I only asked for progress. Why did you stop my task?”
“I clearly told you to stop. Why are you still running it?”

Once either happens, trust breaks at two levels:

trust in understanding: did the assistant even distinguish what I asked for?
trust in execution boundaries: will a short message get misread as a different kind of action?

For a long-term collaborative assistant like GoWork, trust does not come from always sounding proactive. It comes from being precise about boundaries: read state when the user wants state, and really stop the task when the user wants it stopped. The more reliably a system holds that line, the more safely users can hand ongoing work to it.

You can try that execution model on the GoWork download page. If you want the status side of this boundary in more detail, also read Why a status question should not retrigger the task and Why AI assistants should answer task status in chat.

FAQ

FAQ 1: If the user only says “that one,” is it a status query or a stop command?

By itself, it is not enough to know. The following verb matters. “Where is that one now?” sounds like a status query. “Don’t do that one” is clearly a stop command. Only when the meaning is still ambiguous should the assistant ask a clarification question instead of making an irreversible guess.

FAQ 2: If the user says “stop,” should the assistant report progress before cancelling?

No. The primary request is to stop execution, not to hear a summary first. The assistant should cancel first, then briefly report what had already completed and what the real final state is after cancellation.

FAQ 3: What if multiple tasks are running at the same time?

Then the assistant should not stop the “most likely” one by instinct. It should use active runs, recent events, and the user’s reference to identify the target. If ambiguity remains, it should confirm which run the user means. Stop commands require precise control, not fuzzy matching.

FAQ 4: Why can’t “continue” and “stop” be handled symmetrically?

Because they push the system in opposite directions. “Continue” means the task should proceed along its current plan. “Stop” means later actions should be terminated. Both are control instructions, but the execution path is not the same, so they should not share one generic handler.