A success message.A folder still there.
The process had finished normally. There was no error output. Yet the folder that should have been deleted was still there.
A testing record JC shared internally on October 5 captures the difficulty of entrusting work to AI. A command’s exit code and the completion of the requested job are not the same thing. The warning was clear: “Do not judge the effect from the exit code alone.” The record also notes that the deletion was actually verified after a retry.
An exit code tells us how a process ended. The user wants to know whether the desired state has been reached. If AI says “done” without bridging that gap, the burden of checking quietly returns to the person.
Can this problem be solved simply by making model answers more accurate? Another design proposal in which JC organized internal requirements shifts the focus beyond the model. The idea is to design an execution and interaction system that handles not only reasoning, but the entire course of work: starting, stopping, handing over and finishing.
Give work a life beyond the conversation
An AI conversation contains requests and replies in sequence. But a piece of work does not necessarily end within one conversation. A connection may drop while an external process is running. Responsibility may change hands, requiring someone to revisit what happened before.
At the heart of the proposal is the idea that work state should not depend solely on conversational memory. Define a unit of work and bring its objective, owner, progress and verification conditions together. Keep a record of events that can be traced afterward. In technical terms, this means a task envelope and a durable event log.
For example, “requested an operation,” “received a result” and “verified the target state” can be treated as separate events. If they are not collapsed into one “executed” status, resuming after an interruption makes it easier to distinguish what is finished from what remains unchecked.
Having a record does not, however, mean it is safe to execute again. If an external action has already taken effect, repeating it can create duplicates. Recording work and preventing the same work from being performed twice must be designed together.
Completion needs evidence
Extend this idea to completion, and a sentence saying “it worked” is no longer enough. What was checked, and where is the result recorded? Completion needs supporting evidence.
In the folder example, one check is whether the target exists after the operation. For a document update, read the destination to see whether it contains the intended changes. Distinguish successfully invoking a process from verifying the change the user wanted. Build that distinction into the workflow rather than leaving it to the model’s attentiveness.
Clear ownership matters too. When several agents share a task, collecting all their replies does not necessarily mean the overall request can be closed. Who picks up unresolved issues and takes responsibility for the final check? Assigning an owner means leaving no ambiguity about that role.
Evidence here is not a guarantee of absolute correctness. External conditions can change after a check, and the check itself may be inadequate. That is why records should distinguish observed facts from conclusions inferred from them.
Decide where to hand back to a person
If every operation requires human confirmation in the name of reliability, an agent cannot make progress. If it ignores ambiguity instead, later actions may accumulate on top of a mistaken assumption.
The design goal is not to eliminate uncertainty, but to make it manageable. A result has arrived, but its effect cannot be verified. Required permission is missing. The next action is difficult to undo. Preserve those distinctions, then decide which conditions call for human judgment.
The interface for human intervention should reflect the same distinctions. Showing what was tried, what is known and what remains unknown offers a better basis for judgment than simply asking “Continue?” Records help not only a machine resume, but also a person take over.
Detailed records and verification have costs, of course. More information must be stored, and verification adds processing and waiting time. Decisions are also needed about how much confidential information to retain. Should a small, reversible action carry the same procedural burden as one with major consequences? Designing for reliability includes deciding how to distribute those costs.
What surrounds the model shapes the experience
This is a design proposal responding to problems observed in testing. The shared materials alone do not establish the implementation status or effectiveness of the system as a whole.
The framing still matters. To be trusted with work, AI needs more than the ability to choose its next move. It needs a way to verify what the previous move actually changed.
Future evaluation of the proposal should go beyond cases in which everything works normally. Can interrupted work resume? Can duplicate requests be recognized? Can the system stop rather than report completion when evidence is insufficient? Such situations reveal the value of the design.
Users want more than a fluent completion report. They want to be able to verify what is finished and what remains. Trust in an agent begins with drawing that boundary carefully.
SOURCES & EDITORIAL NOTE
October 5 testing record ／ Shared proposal for execution and interaction
These references require access to the company’s internal Slack.
This article begins with facts and proposals documented in shared materials, then adds editorial reflection on their design implications and challenges. The diagrams are explanatory concepts, not evidence of implemented features or verified performance. The article contains no interview quotations.