An empty result is still an observation. It should not become an invitation for the agent to fill the missing evidence with a plausible answer.
Quick answer: Classify the result using the tool's documented contract: a valid empty set, an unavailable response, an invalid input or an execution failure. Explain the observed limit and choose a justified next step. Retry or broaden the query only within the task's permission and cost boundaries.
Establish what empty means
For an illustrative inventory search, no matches may mean that no item satisfies the supplied filters. It may also reflect an incorrect location or a field-mapping issue.
Inspect the submitted arguments and result contract before telling the user that the item does not exist.
Define the branches
| Condition | Example next step |
|---|---|
| Valid empty set | Explain the searched scope |
| Ambiguous request | Ask for the missing distinction |
| Invalid arguments | Correct the mapping with supported values |
| Temporary execution failure | Follow a documented bounded recovery path |
| Unclear contract | Report uncertainty and investigate |
These are proposed branches, not a statement about every API's response semantics.
Preserve query scope
A result from one catalog or region cannot establish absence everywhere. The final answer should identify the scope actually searched.
If the agent broadens filters, record that change. A match found under a broader query may no longer satisfy the original task.
Test downstream behavior
Supply a controlled empty result and inspect what the agent says and does. It should not invent a product, cite a nonexistent record or trigger unrelated operations just to produce an answer.
Include a non-empty case too. A candidate that always stops cannot demonstrate useful retrieval behavior.
I'm Shashank Agarwal, creator of API.market and founder and CEO of Noveum AI. API.market setup is the gateway entry point.
The format-versus-task guide and abstention guide help define observable failure and valid stopping behavior.
Follow my work on LinkedIn. Drafted with AI assistance.
Top comments (1)
The table is the useful part. One case I'd add for web search tools: a result that isn't empty but is useless, like five hits that are all the same aggregator or a page that came back as a cookie wall. If the tool returns a short reason with it ("3 of 5 results had under 200 characters of text"), the agent can treat it like your "unavailable" branch instead of summarizing junk. Your point about recording when filters get broadened matters even more there, since a broader search often answers a slightly different question.