DEV Community: PRATHAP K

The six states of "done": why AI agents say they finished when they didn't

PRATHAP K — Tue, 13 Oct 2026 11:33:00 +0000

WhatsApp solved a problem most AI agents still haven't.

One grey tick: sent. Two grey ticks: delivered. Two blue ticks: read.

Three states. Nobody has to explain them. My parents understand them. You know exactly where your message is without asking anyone.

Now look at most AI agents. You ask one to send an email, update a CRM record or book a slot, and it comes back with one green tick and one word: "Done."

That one word hides six very different things.

The ladder

When an agent says it did something, it could mean any of these:

Intended. The agent decided to do it. Nothing has happened in the world yet.
Attempted. It called the tool. The request left your system.
Accepted. The API returned 200. The other side received the request.
Applied. The real system shows the change. The email is in the Sent folder. The row exists in the database. The calendar has the event.
Correct. The change matches what the person actually asked for. Right contact, right amount, right thread.
Effective. The outcome happened. The customer got the email. The payment cleared. The person showed up.

Most agents report step 3 and call it step 6.

That gap is where every "it said it sent the email" story comes from.

Why step 3 feels like the end

When you build an agent, the tool call is the last thing your code sees. The function returns, the status is 200, there's an id in the response, and the trace shows a green step. From inside the agent, that is the end of the story.

But a 200 only means the other system accepted the request. It doesn't mean:

the mail 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,
the message went to the person you meant.

I wrote about the first half of this in a 200 OK is not proof your agent did the work. That post got a long discussion on Reddit, and a few people in that thread pushed the idea further than I had. This post is the version I use now.

What each step needs as proof

The useful part of the ladder is that each step has a different kind of evidence. If you can't name the evidence, you're not at that step.

Step	What proves it
Intended	The plan or the tool choice in the trace
Attempted	The outgoing request in your logs
Accepted	The response code and id from the API
Applied	A fresh read from the real system, not from the agent's memory
Correct	That read compared against the original request
Effective	A signal from the outside world: delivered, paid, replied

Steps 1 to 3 are cheap. You get them for free from your logs.

Step 4 is where most of the value is. It costs one extra read, and it catches most of the silent failures.

Step 4: read it back from the real place

The rule I follow: an agent is only allowed to say "done" after it has read the result back from the system it changed.

Sent an email? Check the Sent folder or the provider's message status, not the id the send call returned.
Updated a record? Fetch the record again after a short delay. Workflow rules love to run a second later.
Booked a meeting? Read the event and check the attendee list.

Today I had 18 WhatsApp follow-ups going out. Each one was checked in the chat for its tick, sent or delivered, before it was marked finished. It's boring. That's the point. Boring checks are what make an agent trustworthy enough to leave alone.

Step 5 is the sneaky one

This one came from a comment on Reddit, and it changed how I build these checks.

A read-back compares the system against what the agent planned to do. If the agent picked the wrong person from the CRM, the email goes to the wrong person, the read-back matches the plan, and the action gets marked as verified.

Everything passes. Everything is wrong.

So the second check compares the result against the original request, not the agent's plan:

Is this the contact the person named?
Is this the amount they asked for?
Is this the thread they were talking about?

For anything that sends, pays or deletes, I want both checks. The cost is a few lines of code. The cost of skipping it is an apology email to the wrong customer.

Step 6 is mostly out of your hands

You can't force someone to read a message or pay an invoice. An agent can't promise step 6.

But it can be honest about where it stopped. That is the real fix: stop collapsing six states into one word.

Instead of "Done", the agent says what it actually knows:

"Accepted by the mail API" (step 3)
"In your Sent folder" (step 4)
"Sent to Dana from Acme, the one you mentioned" (step 5)
"Delivered" or "Paid" when a webhook confirms it (step 6)

That's exactly what WhatsApp does with its ticks. It never claims more than it knows.

A small checklist

If you're building an agent that takes real actions, these are the questions I'd ask:

Which step does my agent actually stop at today?
For every write, is there a read-back from the real system?
For anything that sends, pays or deletes, is the result checked against the original request?
Does the status the user sees use an honest word, or just "done"?
When a read-back fails, does the agent stop and say so, or does it retry blindly and risk doing the thing twice?

None of this needs a new framework. It needs the agent to stop at the right word.

The short version

"Done" is six states: intended, attempted, accepted, applied, correct, effective.

Most agents report the third and call it the sixth. Read back from the real system, compare against what was asked, and let the agent say exactly where it stopped.

Your chat app already does this. Your agent can too.

If you've built agents that take actions, I'd like to hear which step yours stops at, and what broke when it didn't. I'm on X as @devprathapk.

Originally published on devprathap.online.

"200 OK" doesn't mean your AI agent did the job

PRATHAP K — Mon, 12 Oct 2026 07:53:16 +0000

Your agent says it sent the proposal. The tool call came back with an id. The trace shows a green step.

The customer never got the email.

I've seen versions of this enough times that I no longer trust a success response on its own. Here's why, and what I check instead.

Success responses mean "accepted", not "done"

Most APIs tell you they received your request. They don't tell you the end result.

A mail API returns an id when the message is accepted. That's not the same as delivered, or even sent to the right person.
A CRM update returns 200 when the request is processed. A workflow rule can overwrite your value a moment later.
A calendar API creates the event and quietly drops an attendee it couldn't match.

Every one of these looks like success in the logs. None of them proves the work happened.

What we usually look at

When an agent takes an action, we normally have three kinds of evidence:

The trace: what the model decided and which tool it called.
The tool response: what the API said back. A status code, an id, ok: true.
The model's summary: "I sent the email and updated the deal."

All three describe the request. None of them looks at the system after the action.

What proof looks like: read it back

The fix is simple to describe. After the agent writes something, read it back and compare it with what you meant to do.

Sent an email? Fetch the message. Is it in Sent? Is the right person in the To field? Is the subject what you intended?
Updated a deal? Fetch the deal and check every field you set.
Created a record? Get it by id and check the values.

I find it useful to label every action with how sure we actually are:

Verified: read back and it matched.
Acknowledged: the API said yes, but nothing was read back. This is all a "200 OK" is worth.
Contradicted: a read-back ran and disagreed with what the agent claimed.

Two rules keep this honest. If the check couldn't run (network error, missing id), that's not a contradiction, it's just unchecked. And if the record exists but there's nothing to compare, it's still only acknowledged.

The case that matters most

The contradicted case is the one worth catching. The API said yes and the real system said no: the email sitting in Drafts, the deal stage a rule reverted, the message posted to the wrong channel.

Without a read-back, you find out from an unhappy customer. With one, you find out seconds later, along with the exact field that didn't match.

Where this check should live

Frameworks are adding approvals and human review. Fewer are adding read-back, because it needs to know which read proves which write for each system. That knowledge is the same no matter which framework you use, so it fits best as its own small layer in front of anything that touches a real system.

If you're putting agents in front of email, a CRM or customer messages, start here: for every write, decide what read would prove it worked.

How are you checking that your agents actually did what they said?

A 200 OK is not proof your agent did the work

PRATHAP K — Sat, 03 Oct 2026 15:00:09 +0000

Your agent just told you it sent the proposal. The tool call came back with an id, the trace shows a clean green step, and the customer never got the email. That gap is small and quiet, and it is the thing underneath a loud week.

People spent the last few days watching agents take real actions and finding out afterward what they had done. One widely shared Hacker News post describes an OpenAI Codex account that, from a single request, launched 826 parallel agents and ran up roughly 78,000 dollars in tokens with the records of what it touched deleted. Another describes Claude Code pulling a contract out of a Gmail thread, finding a saved signature image, placing it on the document, and preparing to send it before the owner intervened. Different tools, same hole: everyone could see what the agent said it did, and almost no one could check what it actually did.

I work on the layer where agents touch real systems, and I have lived with this failure on real accounts, not in a chat demo. So I want to be precise about what we usually mean by "it worked," and why none of it is proof.

Three kinds of evidence, all model-side

An agent stack hands you three things after an action. The trace: what the model said and which tool it called. The tool response: what the vendor claimed, a status code or an id or ok: true. And the model's own summary: "I sent the email and updated the deal." All three are generated or reported by the side that wanted the action to succeed. None of them looks at the world after the call.

That matters because success codes lie by omission. A mail API returns an id when a message is accepted, not when it is delivered. A CRM PATCH returns a 200 when the request was processed, including when a workflow rule overwrote your value a millisecond later. A calendar API creates the event and silently drops the attendee it could not resolve. Every one of these is a success. Not one is proof.

Proof is a read-back

The only evidence that counts comes from the system of record itself. Send the email, then fetch it and check that it is actually in SENT, that the recipient you meant is in the To header, that the subject is the one you set. Create the lead, then GET /leads/{id} and compare the fields you wrote. Proof is boring work: you read back what you just wrote and see whether the world agrees.

This is the whole idea behind Attest, the open-source library I wrote to prove what an agent did. It never executes your action; your tool does. It decides whether the action may run, gates it behind a human when it matters, then reads back from the system of record and records the result either way. Because it never executes anything, it owes no connectors and works with any app and any framework on day one.

The result is never a boolean. It is a level: verified when a read-back matched, verified-custom when your own check passed, acknowledged when the action was accepted but nothing was read back, attested-only when there was nothing checkable, and unverified when a check ran and contradicted the claim. That acknowledged rung is exactly what a bare 200 is worth.

Here is what that looks like in the ledger. Two identical CRM writes, both reported successful by the tool, both approved by a human:

sources/ATTEST/README.md

$ attest ledger
#2  2026-09-19 10:16:46  someweirdcrm.create → leads   ask  approved  unverified   a09e7641db12
#1  2026-09-19 10:16:46  someweirdcrm.create → leads   ask  approved  verified     77a6d99a60f6

The second read back clean. The first did not, and the row names the field that disagreed:

sources/ATTEST/README.md

{ "level": "unverified", "matched": false,
  "evidence": { "compared": 4, "exists": true, "failed": ["stage"],
    "fields": { "stage": { "want": "qualified", "got": "new", "ok": false } } } }

A trace would have shown two green steps. That gap is the entire point.

"Could not check" is not "did not happen"

The rule that keeps this honest is the one people get wrong. A check that could not run, a network error, a missing id, a read-only token, is not a contradiction. It degrades to acknowledged with the error written into the evidence. Only a read-back that finds the record and sees a field disagree earns unverified. "We could not check" and "it did not happen" are different facts, and a tool that blurs them is worse than useless, because it trains you to ignore red.

You do not have to teach it every API to get there. Point it at an unknown REST service and it climbs the ladder with whatever you give it:

sources/ATTEST/examples/unknown_app.py

@at.action(method="POST", url="https://api.someweirdcrm.io/v2/leads")
def create_lead(name: str, email: str, source: str = "web") -> dict:
    return http_post("https://api.someweirdcrm.io/v2/leads", {"name": name, "email": email, "source": source})


# the same tool with a one-line custom check ⇒ L2 `verified-custom`
@at.action(method="POST", url="https://api.someweirdcrm.io/v2/leads",
           verify=lambda r, d: (http_get(f"https://api.someweirdcrm.io/v2/leads/{r['id']}") or {}).get("email") == d.params["email"])
def create_lead_checked(name: str, email: str) -> dict:
    return http_post("https://api.someweirdcrm.io/v2/leads", {"name": name, "email": email})


# the same tool with an HTTP getter ⇒ convention read-back GET /v2/leads/{id}, field compare ⇒ L3 `verified`
@at_l3.action(method="POST", url="https://api.someweirdcrm.io/v2/leads")
def create_lead_l3(name: str, email: str) -> dict:
    return http_post("https://api.someweirdcrm.io/v2/leads", {"name": name, "email": email})

The first wrap gives you acknowledged. Add a one-line verify= and you get verified-custom. Give it your own HTTP getter and the convention driver does the GET, compares the fields, and you get verified, with your credentials, in your process. A wrong guess can only make a real write read as unverified; it can never invent a pass.

What to do this week

You do not need to verify everything. You need to verify the actions that would cost you if they silently failed: the outbound email, the deal update, the money movement. Wrap those, read them back, and put the level where a human will see it. The overhead is small, roughly a sixth of a millisecond per action on the repo's benchmarks, and the payoff is that a reverted deal stage or an email stuck in Drafts shows up as a red row thirty seconds later instead of a customer complaint next week.

The incidents this week were not caused by agents being too capable. They were caused by nobody holding a receipt. Build the receipt into the layer in front of every agent that touches a real system, and "did it actually work" stops being a guess.

Attest is MIT-licensed, pip install attestlayer or npm install attestlayer, with 355 offline tests in the SDK and 37 in the cloud. The code and the read-back recipes are at dev-prathap.github.io/ATTEST if you want to see exactly which read proves which write.