- In short
- An access failure means the tool could not reach its data source, so the empty response is uninformative and may warrant a retry. A valid empty result means the tool reached the source and genuinely found nothing, so the emptiness is the answer. Error propagation must distinguish the two, because retrying a valid empty result wastes resources and confuses downstream agents.
What access failure vs valid empty result means
Access failure vs valid empty result is the analytical distinction at the centre of reliable error propagation. An access failure is when a tool could not reach its data source at all, the database timed out, the API returned a 503, the credentials were rejected. The empty response it produces carries no information about the underlying data, because the tool never actually looked. A valid empty result is the opposite: the tool reached its source, ran the query successfully, and genuinely found nothing. Here the emptiness is the answer. Telling these two apart is the whole knowledge point, and at the analyse level the exam expects you to diagnose which one a scenario describes.
This is the context-domain application of a distinction you first meet in tool design, listed here as a correlated prerequisite, and it builds directly on structured error context. The reason it earns a place in Task Statement 5.3 is that the two states demand opposite recovery moves, and choosing the wrong one is a classic, expensive mistake.
- Access failure vs valid empty result
- Two distinct outcomes that look identical as a blank response. An access failure means the tool never reached its source and the empty is uninformative. A valid empty result means the tool reached the source and found nothing, so the empty is the answer. Each requires a different recovery decision.
Why the distinction changes the recovery decision
Recovery hinges entirely on which empty you are holding. Retry the access failure: the source was unreachable, conditions may improve, and a second attempt could return the data you need. Do not retry the valid empty result: the source was reached, the answer is genuinely "nothing matched", and re-running the same query will return the same nothing while burning time, tokens, and rate-limit budget. Worse, an agent that keeps retrying a valid empty result can loop, or can eventually decide the repeated emptiness means something is broken and escalate a non-problem.
The inverse mistake is just as damaging. Treat an access failure as a valid empty result and you accept "no data" as a real finding when in fact you never looked. In the Customer Support scenario that means telling a customer there is no policy covering their situation because the knowledge base happened to be unreachable. In the Multi-Agent Research scenario it means a coordinator concluding a topic has no relevant sources when really the source was down. Both produce confident, wrong answers, the exact downstream corruption that the silent suppression anti-pattern warns about, arriving here through a subtler door.
How the tool must signal which state it is
The critical design insight is that the model cannot reliably infer the difference from an empty payload alone, the tool has to tell it. Anthropic's documentation supports this directly: a tool execution error is returned as a tool_result with is_error set to true and a message describing what went wrong, whereas an ordinary call that found nothing is just a normal, successful tool_result whose content happens to be empty. Those are two structurally different responses, and that structural difference is exactly what lets the model branch correctly.
So the responsibility lands on the tool author, not the prompt. When a knowledge-base search cannot reach its index, it must raise an access failure with the failure type, not return an empty list. When the same search reaches the index and matches no rows, it must return a clean, successful empty with perhaps a short note like "0 matches for the query." Encode the distinction in the response shape and the model's recovery logic becomes trivial; collapse both into a bare empty array and you have made correct recovery impossible no matter how clever the downstream prompt is.
Analysing a scenario: which empty is it?
At the analyse level you will be handed a situation and asked to classify the empty and choose the response. The diagnostic question is always the same: did the tool actually reach its source? If a vector search returns no documents because the query matched nothing, that is a valid empty result and the agent should report it plainly. If the same search returns no documents because the index service was down, that is an access failure and the agent should retry or reroute. The surface, an empty list, is identical in both cases, which is precisely why the distinction has to be carried in metadata rather than read off the payload.
A useful habit is to ask what a second, identical attempt would do. If retrying could plausibly change the outcome, you are likely looking at an access failure. If retrying is guaranteed to return the same empty, you are looking at a valid empty result and retrying is pure waste. This is the analytical reflex the exam is checking, and it feeds straight into the capstone, error propagation strategy design, where you decide retry policy across an entire system.
Worked example
A support agent searches the policy knowledge base for a refund rule and receives no results; the architect must decide how the tool should behave.
A customer asks whether a damaged item bought 40 days ago can be refunded. The agent calls search_policy(query="damaged item refund 40 days"). The knowledge base returns nothing. The agent now has to act on an empty response, but the right action depends on a fact the empty response alone does not contain.
Case one: the knowledge base was healthy and simply has no policy matching that query. This is a valid empty result. The correct behaviour is to accept it as the answer, there is no specific 40-day damaged-goods rule, and proceed to the next step, perhaps escalating to a human for a judgement call. Retrying the search would be pointless; the index will keep returning the same nothing.
Case two: the knowledge-base service was unreachable when the agent called it. This is an access failure. The empty response says nothing about whether a refund policy exists; the agent never actually checked. Accepting it would mean telling the customer there is no applicable policy when there may well be one. The correct behaviour is to retry, or to reroute to a cached copy, and only if those fail to escalate with a clear note that the policy source could not be consulted.
The architect's fix is in the tool, not the agent. search_policy must return a normal empty success in case one and an is_error access failure in case two, so the agent can branch correctly. If the tool returns a bare empty list in both cases, no prompt can recover the distinction, and the agent will sometimes retry forever and sometimes accept a gap as fact.
A field guide to telling them apart
Because the two states look identical as a payload, it helps to have concrete signals that a tool author can use to classify what actually happened before returning a response. The clearest signals are at the transport layer. A timeout, a connection refused, a 500 or 503 from the upstream service, or an authentication rejection all mean the tool never got a real answer from its source; these are access failures, and the tool should mark them as errors. A clean success status from the source with an empty result set is the signal of a valid empty result; the source was consulted, ran the query, and returned nothing, which is a complete and trustworthy answer.
The middle ground is where care is needed. A 200 response that wraps an internal error message, or a partial page returned before a connection dropped, can masquerade as success while really being a failure. A tool author has to look past the surface status and ask whether the source genuinely completed the operation. Rate limiting is a particularly common trap, because a throttled request superficially resembles a normal call but returns nothing useful; it is an access failure, and treating its empty body as a valid empty result is how an agent ends up reporting that a well-populated source has no data.
When the transport signals are ambiguous, fall back to the behavioural heuristic introduced earlier: ask what an identical retry would do. If a second attempt under the same conditions could plausibly return data, the first empty was almost certainly an access failure and the tool should say so. If a second attempt is guaranteed to return the same nothing, the result is valid and empty, and the tool should report it cleanly so the agent accepts it once and moves on. Encoding these signals in the tool, rather than hoping the model infers them, is the design discipline this knowledge point is really about, and it is what makes every downstream recovery decision correct by construction. A useful test of any tool you design is to ask what it returns in each of the two cases and confirm the answers are visibly different; if a reviewer cannot tell from the response alone whether the source was reached, neither can the agent, and the distinction has been lost at the only place it could have been preserved.
Reading the HTTP status code, not the empty body
For tools that call the Claude API directly, the cleanest signal for the access-failure-versus-valid-empty question is the HTTP status of the response, not the contents of the body. Anthropic documents errors as non-2xx responses carrying a structured JSON error object with a type and a message plus a request_id; a successful 2xx response whose content or list simply happens to be empty is not an error at all. There is no "empty result" error type anywhere in the taxonomy, so a 200 with nothing in it is the valid-empty case and should be accepted as the answer, never retried as though the call had failed.
The status code also tells you which kind of failure you are holding, and therefore whether a retry is even sensible. A 404 not_found_error means the resource does not exist, so you verify the id or path rather than hammering it; a 403 permission_error and a 401 authentication_error are credential and scope problems to fix, not transient blips to retry. The genuine retry candidates are 429 rate_limit_error, 500 api_error, and 529 overloaded_error, where backing off and trying again can plausibly change the outcome. The whole rule collapses cleanly: a 2xx empty is accepted, a 4xx is a request or access problem to correct, and a 5xx or 429 is a retry candidate.
Common misconceptions
Misconception
An empty result always means there was no data, so the agent should just report that nothing was found.
What's actually true
Misconception
To be safe, an agent should retry any empty result until it gets data.
What's actually true
How it shows up on the exam
Because this is an analyse-level knowledge point, expect a diagnostic question rather than a definition. A scenario will describe an agent receiving an empty response and behaving badly, retrying a search that will never return anything, or telling a user no record exists when a service was actually down. You will be asked to identify the error and the fix. The strongest answers name the missing distinction and locate the fix in the tool's response shape: signal access failures with is_error and return valid empties as clean successes, so the agent retries the right one and accepts the other.
A research subagent's web-search tool returns an empty list both when a query genuinely matches nothing and when the search provider is rate-limiting it. The agent sometimes retries fruitlessly and sometimes reports a real topic as having no sources. What is the correct fix?
People also ask
How does an agent tell a failed lookup from a genuine empty result?
Should an agent retry when a search returns no results?
What is a valid empty result?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Anthropic's Secret: How we Build Multi-Agent AI
Why watch: Breaks down Anthropic's multi-agent research architecture including how subagent failures and tool results are handled and resumed, which grounds the distinction between an access failure that warrants a retry and a valid empty result that is the answer.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.