"200 OK" Doesn't Mean Your AI Agent Actually Did the Job

Your AI agent says it sent the proposal. The tool call returned an ID. The trace shows a green "success" for that step.

But the client never got the email.

This happens often enough that I've stopped trusting a successful response as proof that anything actually got done. Here's why — and what I check instead.

A Success Response Means "Accepted," Not "Completed"

Most APIs tell you they received your request. They don't tell you the final outcome.

• Email APIs return an ID when a message is accepted. That's not the same as "delivered" — or even "sent to the right person."
• CRMs return 200 when the request is processed. But a workflow rule might overwrite the value you just wrote a moment later.
• Calendar APIs create the event, then silently drop an attendee they couldn't resolve.

Every one of those looks like a success in the logs. None of them prove that the work actually happened. This is one of the most overlooked blind spots when building AI agent systems — we conflate "the API acknowledged the request" with "the thing happened in the real world."

This problem has a name in distributed systems: Eventual Consistency. Many modern APIs — especially cloud services and SaaS platforms — use asynchronous processing architectures. Your write request enters a message queue, the service returns 200 to confirm it's been queued, and the actual persistent write happens asynchronously in the background. This means the data change may not have landed at the moment the request is acknowledged. Email services like SendGrid and Mailgun work exactly this way — the returned message ID only means the email entered the send queue. It can still be bounced or silently dropped due to domain reputation issues, recipient rate limits, or content filtering. CRM "triggers" and "workflow rules" similarly run in an async layer after the write, and can modify or overwrite what you just wrote within milliseconds of your request completing. For AI agents, this is particularly acute: agents typically complete tool calls and move on to the next step within milliseconds — long before any async operation has resolved.

The Three Types of Evidence We Usually Have

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

1. The trace: what decision the model made, which tool it called.
2. The tool response: what the API returned. A status code, an ID, an ok: true.
3. The model's summary: "I sent the email and updated the deal."

The problem is that all three describe the request itself. None of them check the actual state of the system after the action. In other words, we're verifying what we said, not what reality became. For an agent that autonomously executes multiple steps in sequence, this gap compounds with every step.

The Real Proof: Read It Back

The fix is straightforward in principle: after the agent writes something, read it back and compare it to what you intended.

• Sent an email? Fetch that message. Is it in the Sent folder? Is the right person in the recipient field? Is the subject what you wanted?
• Updated a deal? Fetch that deal and check every field you set.
• Created a record? Fetch it by ID and verify the values.

I've found it useful to label each action by how confident we actually are:

• Verified: Read back and it matched.
• Acknowledged: The API said yes, but no read-back was performed. That's all a "200 OK" can prove.
• Contradicted: The read-back ran and the result doesn't match what the agent claimed.

Two rules keep this system honest. First, if the check didn't run at all — network error, missing ID — that's not "Contradicted," it's "Unchecked." Second, if the record exists but there's nothing to compare against, it's still only "Acknowledged," not "Verified."

The Case That Matters Most to Catch

"Contradicted" is the state most worth catching. The API said yes, and the real system said no: the email is sitting in drafts, the deal stage got rolled back by a rule, the message went to the wrong channel.

Without a read-back, you find out from a frustrated customer. With it, you find out within seconds — along with the specific field that didn't match. That difference is often the gap between a contained internal alert and a customer-facing incident.

There are a few root causes worth cataloging for the "Contradicted" state in practice. Silent failures are the most insidious: the system returns no error but doesn't perform the operation you expected — for instance, when Slack sends a message to a private channel the bot can't access, the API may return success but the message never arrives. Idempotency conflicts mean that on duplicate writes, only the first one actually takes effect; subsequent calls return success but nothing changes. Field type coercion can silently alter the values you wrote — a CRM rounding a float you passed in, or quietly discarding timezone information. What these scenarios share is that the API designer considers the behavior "spec-compliant," so no error is thrown — but from the caller's business perspective, the thing didn't get done. That's exactly why a read-back can't just check whether the record exists; it has to compare the actual values field by field.

Where This Check Belongs

Frameworks are starting to add approval and human-review steps, but very few add read-back verification. The reason is that it requires knowing — for each system — which read proves which write. That knowledge is the same regardless of which framework you use. So it fits best as a thin, standalone layer sitting in front of any operation that touches a real system.

If you're about to put an agent in front of email, a CRM, or customer messages, start here: for every write, think through which read would prove it actually took effect.

A Final Thought

As more AI agents are granted write access to real-world systems, the center of gravity for verification needs to shift — from "was the request accepted" to "did the outcome actually happen." Read-back verification isn't a fancy new architecture. It's a pragmatic engineering discipline: pair every write with a read that can prove it. How are you currently confirming that your agent did what it claims to have done?