This morning I ran the same API call twice, one character apart.<\/p>\n
The first came back with 40 records<\/strong>. The second came back with 0<\/strong>. Same table, same key, same second. The only difference: one asked for Both returned HTTP 200<\/strong>. Both looked like an answer. One was a fact and one was a typo, and nothing in either response told me which was which.<\/p>\n That is an AI agent silent failure, and it is the nastiest failure mode you will hit \u2014 because it doesn’t look like a failure. It looks like good news<\/em>. Empty queue. Nothing to process. All clear. Your agent reads the zero, logs “nothing to do,” exits clean, and your dashboard goes green over a question you never actually asked.<\/p>\n Three shortcuts to catch it. All three came out of my own logs this week.<\/p>\n Before your agent is allowed to believe an empty result, make it ask a question it already knows the answer to.<\/p>\n Same endpoint, same credentials, a filter that must<\/em> return rows. If the control comes back full and your real query comes back empty, the zero is real \u2014 act on it. If both come back empty, your query is broken, and you just avoided reporting “all clear” on a table with forty live rows sitting in it.<\/p>\n That’s two calls instead of one. It is the cheapest insurance in your entire stack, and it’s the same instinct behind the ten-second health check I run before any agent spends money<\/a>.<\/p>\n Here’s the one that nearly cost me a duplicate post.<\/p>\n I’m on Bali time. My WordPress install stores everything in UTC \u2014 I checked five posts in a row this morning and every one had an identical local and GMT timestamp, so there is no offset being applied at all.<\/p>\n Yesterday’s article published at 07:10 my time. WordPress stamped it Nothing is wrong. The post is live, indexed, and sitting on the homepage. But a monitoring agent reading that zero concludes the publish failed and helpfully runs it again \u2014 and now you have two of yesterday’s article. Every date filter your agent writes should be converted to the server’s timezone before it’s sent<\/strong>, not after you’ve believed the answer.<\/p>\n You don’t need this paranoia everywhere. You need it in specific places, and you can find them in about ten minutes.<\/p>\n Take each API your agent touches and send it something deliberately wrong. Then watch what it hands back:<\/p>\n Write the list down. Wherever a wrong question and a true “nothing” produce the same bytes, that’s where the control query from shortcut one earns its keep \u2014 and nowhere else.<\/p>\n An error is a gift. It stops the line and points at the problem. An empty result is the opposite: it is the machine declining to answer while looking exactly like it answered.<\/p>\n This is the same disease as an agent that counts page one and calls it the total<\/a>, and the same reason I check that things actually arrived rather than trusting that they were sent<\/a>. Different endpoints, one root cause: we keep treating a response as a result.<\/strong><\/p>\n Teach your agent one sentence: zero is a claim, not a fact.<\/em><\/p>\n Before it acts on nothing, make it prove the pipe is open with a query it can’t get wrong. Ten extra lines. It’s the difference between an agent that tells you the queue is empty and an agent that knows<\/em> it is \u2014 and this week those were forty records apart.<\/p>\n'Ready'<\/code> and the other asked for 'ready'<\/code>.<\/p>\n1. Never trust a zero without a control query<\/h2>\n
2. Check which clock the machine is on, not the one on your wall<\/h2>\n
2026-09-17T23:10<\/code>. So when I ask the perfectly reasonable question “did anything publish since the 18th?” using my own calendar, the API answers: zero posts<\/strong>.<\/p>\n3. Sort your APIs into loud and silent \u2014 then only guard the silent ones<\/h2>\n
\n
HTTP 422 \u2014 Unknown field names<\/code>. I sent a badly formatted date to my social scheduler and got HTTP 400<\/code> with the correct format spelled out in the error. These APIs defend you. Let them.<\/li>\n200<\/code> and an empty list. A wrong-but-valid ID returns 200<\/code> and an empty list. A search with no hits returns 200<\/code> and an empty list. Three completely different situations, one identical response.<\/li>\n<\/ol>\nThe pattern underneath all three<\/h2>\n
\u4eca\u65e5\u8981\u9ede<\/h2>\n