A customer calls about order #12345. The database times out. The tool returns isError: false, "No results found". The agent says: “I don’t see order #12345 in our system. Are you sure that’s correct?” The customer has a confirmation email. The order exists — the database was just temporarily down.
The two outcomes that look identical
Access failure (timeout, connection error, service down):
- The query didn’t execute successfully
- The data might exist — we just couldn’t check
- Agent should: retry or say “I’m having trouble looking that up right now”
Valid empty result (query succeeded, no matching records):
- The query executed successfully and found nothing
- The data genuinely doesn’t exist
- Agent should: accept as definitive and inform the user
How to distinguish them
| Outcome | isError | Content | Agent behavior |
|---|---|---|---|
| Database timeout | true | ”Database temporarily unavailable” | Retry or inform “having trouble” |
| No matching record | false | ”No customer found for ID X” | Accept as definitive |
The rule: if the query executed successfully → isError: false (even if zero results). If the query failed to execute → isError: true with error details.
The real-world damage
An academic research agent searches a database. The database is unreachable. The tool returns empty content + isError: false. The agent tells the researcher: “No papers found on this topic.” The topic has thousands of papers. The researcher changes their research direction based on false information.
A customer support agent looks up an order during database outage. Returns “No results found” + isError: false. Agent tells customer the order doesn’t exist. Customer has confirmation email and escalates — creating an unnecessary complaint.
The silent swallow
Returning isError: false with empty content when the database is unreachable is the “silent swallow” — the error is swallowed, converted to a false negative, and the agent (and user) never know a failure occurred.
Including the attempted query
For timeout errors, include what was attempted: “Database timeout while looking up order_id=‘ORD-12345’”. This enables the agent to retry with the exact same parameters, or inform the user specifically what couldn’t be checked.
One-liner: Database outages returning isError: false + “no results” cause agents to tell customers their data doesn’t exist when the service is just down — access failures must return isError: true, valid empty results return isError: false, and the distinction prevents false negatives.