When Can an AI Agent Give a Partial Answer After a Tool Failure?
Start with the short answer ↓
Decide which verified facts an AI agent can share after a tool failure, which conclusions need more evidence, and who resolves the gap.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Decide which part of the request can stand on its own
An operations coordinator asks whether a technician arrived and whether the work is complete. The dispatch system confirms arrival. The service system times out while the agent retrieves the completion checklist. A useful response can report the recorded arrival and leave completion open for verification.
Start the design with the conclusions the reader wants to draw. Arrival needs a matching check-in record. Completion needs the evidence agreed for closing the job. Work out whether the first fact is independently useful and whether sharing it could imply the second. Make that distinction before choosing retries or writing response copy.
In the illustrative visit J-72, the dispatch record shows a check-in at 09:12. The completion checklist is temporarily unavailable. The permitted partial answer covers the recorded arrival and tells the coordinator what evidence is still needed for closeout.
Classify what each lookup actually returned
A field can be verified, empty after a complete lookup, unavailable, stale, or in conflict with another source. Give each state a meaning for the task. An empty checklist retrieved successfully and a checklist that could not be retrieved call for different next steps. A known empty result also depends on the scope and completeness of the lookup.
For each fact, check the record identifier, the viewer’s access, the time of the evidence, and the system responsible for that fact. The worksheet shows how the same request can lead to different responses as evidence changes.
| Evidence state | Permitted response | Next action |
|---|---|---|
| Current check-in | Report recorded arrival | Keep the source and time |
| Checklist timed out | Mark completion unverified | Assign a closeout check |
| Earlier saved checklist | Show dated history if permitted | Get the current checklist |
| Record or access mismatch | Hold the affected details | Verify scope and access |
| Complete lookup is empty | Say no checklist entries were found | Check why evidence is missing |
Carry the gap through to the answer
Google’s guidance for eligible partial-success list operations describes returning reachable results with an explicit indication of resources the API could not reach. The GraphQL specification likewise allows execution results with both data and errors. These conventions give the application information it can use to decide whether an answer is complete.
Preserve usable values and their evidence separately from missing fields as results pass from the connector to the response builder. An arrival field can carry its source and timestamp. Completion can carry an unavailable state and the name of the check still required. Give the response builder those distinctions even when the transport reports a successful response.
Make approval and closeout depend on application checks of the required evidence. In J-72, the partial summary can be shown to the coordinator. Closing the job stays pending until the designated checklist supports that transition. If the record identity itself is uncertain, verify identity before sharing either fact.
Write a response that tells the coordinator what to do
For J-72, the agent might say, “The dispatch record shows that the technician checked in at 09:12. The completion checklist is unavailable. The operations coordinator needs to verify it before closing the job.” That gives the reader an observed fact, a specific gap, and an owner for the next decision.
Keep the gap next to the affected conclusion, including in a summary copied to a work queue. If later evidence arrives, update the same request and preserve the time of the new check. If a fallback source is permitted, apply its freshness and access rules before using it. Label historical evidence with its date so the reader can tell which version they are seeing.
Use a separate recovery rule for a write with an uncertain outcome. If a tool may already have closed a job before its response was lost, reconcile the actual record before attempting the action again.
Test complete and partial results with the same request
Use a synthetic job with known records and keep production writes disabled. First return a matching check-in and valid checklist. Then keep the check-in fixed while you simulate a checklist timeout, a complete empty checklist, an outdated snapshot, and a response for the wrong job. Include a case where the transport reports success alongside an incomplete result.
For each case, compare the displayed facts with the known evidence. Check that missing completion evidence stays visible, the team can find the next action, and the closeout remains gated. Restore the checklist and confirm that the new result updates the original request. Measure complete answers, useful partial answers, and unresolved work separately when reviewing the pilot.
Put the evidence rules in the implementation scope
Choose one request and ask the implementation team to name the source of each conclusion, the minimum evidence to present it, and the person responsible for resolving a gap. Decide which actions must wait for complete evidence and what an authorized viewer can still learn from a partial result.
Review the proposed rules with the people who close the work. Their acceptance should include recognizing a missing field, finding the original request, and verifying the recovered evidence. The pilot can then show how the agent helps during a real dependency failure within the agreed workflow.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.