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

Prathap K argues that a success response from an AI agent's tool call only means a request was accepted, not that the work happened, and describes the read-back check he uses to verify each write against the real system (email, CRM, messages).

Why a success response from an agent tool call is not proof the work happened, and the read-back check I use instead.

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?