In my personal experience using Gemini in tool-enabled workflows, I have encountered responses that present a task as completed when I cannot verify the intended outcome. I want to discuss that gap constructively with other developers.
A confident completion message affects what a user does next: trust the result, retry an operation, or investigate a failure. If the message is not grounded in the actual tool result, the user ends up doing the verification work anyway.
Scope of this feedback
This is qualitative feedback from my own experience, not a benchmark or a claim about every Gemini model or integration. I am not attaching a minimal reproducible example, exact model/version details, or request/response traces here. I therefore cannot isolate the cause to the model rather than the application, orchestration layer, or tool integration.
The distinction I want applications to make
- Proposed: the assistant describes an action.
- Attempted: a tool call was issued.
- Tool-reported success: the tool returned a success response.
- Verified outcome: the resulting state was checked and matches the requested outcome.
Those states should not all be described as "done." If a tool fails, access is unavailable, or the final state cannot be checked, the response should say so clearly.
For workflows that change something, I would like applications to check the resulting state where practical before reporting completion. When only part of a task succeeds, the response should identify that part and what remains unresolved.
Questions for developers
How do you keep completion claims grounded in tool results in Gemini function-calling workflows? What patterns have worked for ambiguous tool responses, partial success, and verification after an action?
I would also welcome suggestions for the most useful details to include in a reproducible follow-up report.
I shared the same concern on the Google AI Developers Forum.
I am interested in practical ways to make these workflows more reliable and their status messages more accurate.
Top comments (2)
In the cases you hit, did the tool result itself come back as success, or was it empty/ambiguous and the model filled the gap with "done"? We see the second far more often on our side (Auten team, we build a computer-use MCP server). The pattern that helped most: after any action that changes state, the agent re-reads the real state and only reports done if the expected change is actually there, otherwise it reports what it saw instead.
Before the action runs, save the current value of whatever it should change, then read that value back from what's running and check that it moved. In one of my agent's deploys, Argo CD showed Synced and Healthy and the pod had restarted, but its image digest was identical to the six-day-old one the agent had saved first. The pipeline pins the new digest in a second commit, and Argo synced the merge commit before the pin landed, so the old binary came back up. The routes the change removed still answered until the next sync fixed it.