The 'Done' Trap of AI Agents: Six Completion States and the Trust Crisis

One Word Hides Six Truths

WhatsApp solved the communication problem of "where did my message go" with three types of checkmarks: one gray check means sent, two gray checks mean delivered, and two blue checks mean read. No one needs to explain, no one needs to ask — the status speaks for itself.

Now look at most AI Agents. You ask it to send an email, update a CRM record, book a time slot, and it just replies with one word: "Done." That single word actually conceals six completely different states. Developer devprathap systematically breaks down the root of this problem in their blog, sparking in-depth discussion on Reddit.

The Six-Level Ladder of Completion States

When an Agent says it "did something," it could be at any one of the following six levels:

1. Intended: The Agent decided to do this thing, but nothing has happened in the real world yet.
2. Attempted: It called the tool, and the request left your system.
3. Accepted: The API returned 200, and the other system received the request.
4. Applied: The change is visible in the real system — the email is in the Sent folder, the record is in the database, the event appears on the calendar.
5. Correct: The change matches what the user actually asked for — the right person, the right amount, the right conversation thread.
6. Effective: The outcome actually happened — the customer received the email, the payment cleared successfully, the person actually showed up.

The core of the problem is this: most Agents report step 3 while claiming to be at step 6. All the stories of "it said it sent the email" stem from this gap.

These six levels borrow classic concepts from distributed systems and transaction processing. In database transactions, the Durability property of ACID emphasizes that a write must be persisted to disk to truly count as complete; in message queues (like Kafka, RabbitMQ), delivery semantics such as "at-least-once" and "exactly-once" similarly distinguish between "sent" and "consumed and processed." At the network protocol level, TCP's three-way handshake confirms that "the other party received my packet," not that "the other party's application processed my request." The dilemma Agents face is essentially the same: the 200 returned by a tool call is equivalent to TCP's ACK — it only proves success at the communication link level, not success at the business semantics level. Understanding this distinction is the key cognitive prerequisite for pushing Agents from "seems to work" to "can be trusted."

Why Step 3 Looks Like the Finish Line

When building an Agent, the tool call is the last step your code can see. The function returned, the status code is 200, there's an id in the response, and the trace shows a green node. From inside the Agent, the story ends here.

But 200 only means the other system accepted the request. It doesn't guarantee: the email actually left the outbox, a workflow rule didn't overwrite your CRM value a second later, the calendar didn't silently drop an attendee it couldn't match, or the message went to the person you actually intended.

The author previously argued in a first article that "200 OK is not proof the Agent completed the work," and the Reddit discussion further expanded this idea — ultimately forming the six-layer framework presented here.

Here, 200 refers to the HTTP status code 200 OK, the most common success response in REST APIs. But the success defined by the HTTP specification only means the server understood and accepted the request; it does not promise that the business logic was correctly executed. In practice, many systems may return 200 while carrying business error codes in the response body (such as the errcode fields commonly seen in WeChat and Alipay open platforms). Even more insidious is asynchronous processing: after a request is accepted, it enters a queue, and subsequent processing may fail or be overridden by rules, while the initial 200 was returned long ago. Additionally, "eventual consistency" in distributed systems means that reading immediately after a write may return a stale value — which is also why the author recommends "a brief delay before reading back." Therefore, treating 200 as a completion signal is a common optimistic assumption in engineering, and one of the important sources of Agent hallucination.

What Evidence Each Level Requires

The most useful aspect of this ladder is that each level requires a different type of evidence. If you can't say what the evidence is, you're not at that level.

Level	How to Prove It
Intended	The plan or tool selection in the trace
Attempted	The outbound request in the logs
Accepted	The status code and id returned by the API
Applied	Results re-read from the real system, not the Agent's memory
Correct	Comparing the read-back result with the original request
Effective	Signals from the external world: delivered, paid, replied

Steps 1 through 3 are very low-cost, available for free from logs. Step 4 is where the greatest value lies — it only requires one extra read operation, yet can catch most silent failures.

Read-Back Verification: Confirming Results from the Real System

The core rule the author follows is: an Agent is only allowed to say "done" after reading the result back from the system that was modified.

Specific practices include: sent an email? Check the Sent folder or the provider's message status, not the id returned by the send call. Updated a record? Re-fetch that record after a brief delay — workflow rules love to run a second later. Booked a meeting? Read the event and check the attendee list.

The author shares an everyday scenario: 18 WhatsApp follow-up messages to send in a day, each one marked complete only after confirming the checkmark status (sent or delivered) in the chat interface. It's boring, but that's exactly the point — boring checks are what make an Agent trustworthy enough to leave alone.

Read-after-write verification corresponds in engineering to "read-after-write consistency" checks, a common technique in distributed system debugging and idempotency design. Its core idea is: don't trust the return value of a write call; instead re-query the authoritative data source. In actual implementation, several details need attention: first, eventually consistent systems may require read retries or a brief delay; second, the read-back should hit the "real system" rather than the Agent's short-term memory or cache, otherwise it's self-confirmation; third, for operations with side effects (sending email, charging), the read-back itself may trigger rate limits or additional costs, so frequency must be weighed. The ideal approach is to encapsulate the read-back as a standard post-step of tool calls, so the Agent automatically performs a confirmation query before declaring completion — turning "blind confidence" into "verifiable assertion."

Step 5 Is the Most Insidious: Correctness Is Not Plan Consistency

This insight came from a Reddit comment, and it changed the author's approach to building.

Read-back verification compares the system state with what the Agent planned to do. If the Agent picked the wrong person from the CRM and the email went to the wrong recipient, the read-back matches the plan, and the operation gets marked as verified.

Everything passes, everything is wrong.

So a second layer of checking is needed: compare the result with the original request, not the Agent's plan: is this the person the user specified? Is this the amount the user requested? Is this the conversation thread they were discussing?

For any operation involving sending, paying, or deleting, the author recommends having both layers of checking. The cost is a few lines of code; the cost of skipping it is an apology email to the wrong customer.

Step 6 Is Fundamentally Outside Your Control

You can't force someone to read a message or pay a bill. The Agent can't promise that step 6 will certainly happen.

But it can honestly express where it stopped. That's the real fix: stop compressing six states into one word.

The Agent should say what it actually knows: "email API accepted" (step 3), "now in your Sent folder" (step 4), "sent to Dana at Acme, the person you mentioned" (step 5), "delivered" or "paid" (when the webhook confirms, step 6).

This is exactly what WhatsApp does with its checkmarks — it never claims to know more than it actually knows.

A webhook is a mechanism where an external system proactively pushes event notifications to your service — for example, an email provider calling back when an email is actually delivered or bounced, or a payment gateway calling back when a payment has cleared. It complements active polling: polling is limited by frequency and cost, while webhooks notify in real time when events occur. For Agents, webhooks are the key channel for obtaining step 6 evidence — only when the external world proactively reports back can the Agent upgrade from "accepted" to "delivered" or "paid." In engineering, you need to handle webhook signature verification, replay attack protection, delivery failure retries, and design idempotent event processing logic to avoid the same notification being consumed repeatedly and causing state corruption.

A Checklist When Building Agents

If you're building an Agent that performs real actions, here are a few questions worth asking:

• What step does my Agent actually stop at today?
• For every write operation, is there read-back verification from the real system?
• For operations involving sending, paying, or deleting, is the result compared with the original request?
• Does the status users see use honest words, or just one "done"?
• When read-back verification fails, does the Agent stop and report honestly, or blindly retry at the risk of duplicate execution?

None of this requires a new framework — it only requires the Agent to stop at the right word. Trust doesn't come from claiming completion; it comes from accurately expressing how far it got.