Why “I’ll do it next” is not task completion

Here is the short version: “I’ll do it next” is not task completion. It is only a promise about future work. If an assistant has not actually performed the next step, verified the result, and explained the real current state, it should not present the task as “handled” or “done.” For execution-oriented systems, completion never means “I know what I plan to do next.” It means the required work has actually been completed, or the task has stopped at a real and explainable boundary. That is why GoWork keeps assistant_done separate from continuation.

When users hand a task to an assistant, they usually do not want a polished construction forecast. They want a trustworthy outcome: what is finished, where execution currently stands, what is blocked, and why the next step has not happened yet. One reason OmniGoAI built GoWork around “push to a natural completion point before reporting back” is to avoid a very common fake-completion pattern: a reply that sounds final even though it only wraps future actions in the language of present results.

If you have already read Why multi-step tasks need plans that persist across runs, Why long-running tasks need progress heartbeats in chat, and Resume AI tasks after failure instead of restarting, this article answers a related but slightly lower-level question: why should “I will do X next” never be mistaken for “X is done”?

What counts as an unfulfilled next-step promise?

An unfulfilled next-step promise is any reply where the assistant says something like “next I’ll deploy it,” “I’ll continue publishing in the next round,” or “I’ll update the logs afterward,” even though those actions have not happened in the current run.

The wording itself is not always wrong. The problem is that it is often delivered in a conclusion-like tone that makes the user think the task is essentially over. Typical examples include:

the assistant has only finished writing, but says “the article is handled; next I’ll publish it”;
it has only fixed a build error and not rerun validation, but says “I’ll continue deployment and distribution”;
it stops at a mid-task milestone but ends with something like “all good, I’ll finish the rest next.”

None of those are completion. They are pending work presented in language that feels too much like a result.

Why does this confuse users so easily?

Because users do not see your internal plan. They see your outward status report. If the sentence sounds like a conclusion, they will naturally read it as “this round reached a stable stopping point, and the remaining work is already effectively taken care of.”

But future intent and current state are not the same thing. They differ on at least three layers of fact:

whether the action has actually happened;
whether the result has been verified;
whether there are still failure points between now and that future step.

Once “will do” is presented as “handled,” the user is misled at exactly the point where trust matters most.

What is the real boundary of assistant_done?

For an execution-oriented assistant, assistant_done does not mean “I am pausing here” and it does not mean “I know the next step.” It means the current run has reached a natural completion point and can truthfully report a real state to the user.

That natural completion point usually satisfies at least one of these conditions:

the goal is completed and the result is verified;
the task is genuinely blocked and only the user can unblock it;
the assistant must stop before a high-risk external action;
a long task has reached a clear milestone and hands off the rest through continuation.

The last point matters a lot: real continuation is not “I’ll do the rest later.” It is “here is what was completed and verified in this run, and here is what the next run must do next.” It is a structured handoff, not a vague promise.

Why continuation is not just “we’ll get to it later”

People sometimes hear continuation and think it means “let’s stop now and maybe continue later.” That is too loose.

In GoWork, continuation means:

this run has already produced concrete progress;
the remaining work is substantial enough that it should not be forced into the same run;
the assistant has explicitly recorded what is done, what is verified, and what the next run must do.

So continuation is not procrastination. It is stateful handoff for unfinished work without pretending that unfinished work is already complete.

Without that structure, “I’ll continue next” is only a verbal promise. It does not prove what has already happened, and it does not guarantee that future execution will truly resume on the same path.

Why knowing the next step is not the same as completing it

This confusion shows up most often in long tasks because planning and execution happen close together.

Take a content pipeline. The assistant may already know the path:

write the article;
run check and build;
deploy the website;
submit URLs for indexing;
publish to platforms and update logs.

But knowing that path does not mean each step has happened. The difference is the same as the difference between having a map and reaching the destination. Being able to describe the route is not the same as having walked it.

That is also why long tasks should not rely on one temporary plan inside a single turn. Plans answer “what should happen next.” Completion answers “what has actually happened already.” Both are necessary, but they must never impersonate each other. For more on that distinction, see https://omnigoai.com/en/blog/gowork-update-plan-cross-run-persistence/ .

Which phrases create fake completion most easily?

The dangerous cases are often not obvious lies. They are smooth, plausible lines like these:

“It’s handled. Next I’ll publish it.”
“I’ll stop here and continue automatically afterward.”
“Everything looks fine now. I’ll finish the rest next.”
“I’ve arranged for the next round to deploy it.”

The problem is not that future work will never happen. The problem is that these sentences blur future actions and current results into a single conclusion-like statement, making it hard for the user to tell what is real now and what is only planned.

A safer report separates them clearly:

what is already true now;
what has been completed;
what has not happened yet;
why it has not happened yet;
how the next run will continue.

Only then can the user tell whether this is a final result, a milestone update, or a handoff to continuation.

Why does this boundary matter so much to users?

Because it directly shapes trust.

Users are usually not upset that a task needs another run. They are upset when unfinished work is presented as if it were already done. Once that happens, the fallout is practical:

the user thinks publishing is finished, but nothing was posted;
the user thinks files were committed, but the repository still has uncommitted changes;
the user thinks the assistant is waiting only on them, while in reality many safe steps could still have been completed autonomously.

The value of an execution assistant is not just that it can speak smoothly. It is that its state reports can be trusted. And trustworthy state reporting requires one discipline above all: do not package the future tense as a completion state.

A simple test: is this sentence reporting a result or a plan?

If you are unsure whether a reply creates fake completion, ask one question:

is this sentence describing a result that was actually observed or verified, or only a plan for future execution?

If it is the first kind, it belongs in the conclusion. If it is the second, it should not be used as evidence that the task is done.

A practical self-check is even simpler:

has the action I am describing actually happened in this run?
if yes, has the result been verified?
if not, could the user misread this sentence as completion?

If the answer to the third question is yes, the sentence should be rewritten.

What does a clear boundary report look like?

A reliable milestone update usually follows this pattern:

say what is already completed;
say the current real state;
say what remains and whether continuation will handle it.

For example:

“The bilingual drafts are finished and local check passed. Build has not run yet; the next run will build before deciding on deployment.”
“Website deployment succeeded and indexing was submitted. Platform publishing has not started yet because Juejin tags and category still need to be finalized.”
“This run finished through log updates. Git commit has not happened yet because one broken link in the build output still needs to be fixed.”

That kind of wording does not smuggle future work into present completion, and it gives the user a much more accurate view of where the task stands.

Why progress heartbeats are safer than end-of-run promises

A lot of unfulfilled next-step promises appear because the assistant tries to compensate for a long silence with one last sentence like “I’ll keep going from here.”

A better pattern is not to patch the silence with a promise. It is to emit honest progress heartbeats during the task: what has been done, what is in progress, and what will happen immediately next. That way the user does not lose trust during a long run, and the assistant does not need to use conclusion-like promises as emotional filler. For more on that, see https://omnigoai.com/en/blog/gowork-task-progress-heartbeats-in-chat/ .

FAQ

FAQ 1: If the assistant really will continue in the next run, is the phrase still a problem?

Yes. The issue is not whether the future action is sincere. The issue is whether the current reply accurately represents the current state. Even if the next run really continues, this run must not describe unexecuted work as if it were already complete.

FAQ 2: Does that mean assistants should never say what comes next?

No. They can and should say it when useful. But it must be labeled as next-step planning or remaining work, not merged into a completion statement. Plans are fine. Fake completion is not.

FAQ 3: When should continuation be used instead of just ending the task?

When the task has already reached a verifiable milestone and substantial work still remains. Continuation is for structured handoff in long tasks, not for hiding the fact that the current run simply stopped too early.

FAQ 4: Why is this boundary more important for execution assistants than for ordinary chatbots?

Because execution assistants do not merely suggest. They write files, deploy systems, publish posts, submit content, and verify results. If they present unfinished work as finished, the cost is not only conversational confusion. It becomes a real-world operational error.

If you agree that a reliable assistant should never make “I’ll do it later” sound like “I already did it,” then what you care about is honest execution boundaries. GoWork is built around that idea: plans, task state, continuation, and completion are kept separate so users can see exactly what is done, what is next, and what is only planned. To try that approach yourself, start with the GoWork download page, why AI assistants should answer task status in chat, and how continuation works after failure.