The tool call returned 200. The agent moved on. The configuration was unchanged. Thirty minutes later, the downstream system failed because the setting the agent "applied" was never actually applied.
This is the Silent Tool Failure pattern. HTTP 200 means the server received and processed the request without error. It does not mean the operation had the effect the caller intended.
Why This Happens
APIs return 200 for several conditions that are not successful writes:
- The request was valid but idempotent — the resource was already in the target state, so nothing changed
- The write was accepted but queued — the 200 acknowledges receipt, not completion
- A validation layer accepted the payload but a downstream constraint rejected it silently
- The API is eventually consistent and the read-back window hasn't closed yet
An agent treating 200 as confirmation will chain subsequent operations on a foundation that does not exist.
The Fix: Mandatory Read-Back
After every write operation, read the resource back and verify the specific field that was supposed to change.
// Write
PATCH /config/settings { "timeout": 30 }
// → 200 OK
// Read-back (required)
GET /config/settings
// → verify response.timeout === 30
If the read-back does not match the written value, the operation failed. The 200 was not a lie — it was just telling you something narrower than you assumed.
What to Build Into Agent Pipelines
Any tool that performs a write operation should have a corresponding verification step built into the skill or tool definition. Not optional, not a separate step the agent can skip — baked into the tool's execution contract.
The agent should not be able to report success on a write without having confirmed the write. The 200 is evidence. The read-back is confirmation. Do not accept the evidence as the confirmation.
Comments 0