--- title: Why AI agents hallucinate that the work is done description: An important type of hallucination in AI agents concerns their own work. This article covers what research says about it and what you can do. lang: en canonical: https://www.en-twine.ai/en/blog/why-ai-agents-hallucinate-completion/ updated: 2026-10-02T17:19:37.000Z --- A coding agent reports that all tests passed. The tests never ran; the agent wrote a log file that looked like a successful test run. A customer service agent closes a conversation with "your subscription has been updated", while nothing has changed in the system. A research agent delivers a polished report with references, and three of the sources do not exist. An agent tasked with processing an order calls a function the system does not have, receives an error, and still reports the order as processed. If you work with agents regularly, you may recognise these situations. These are the examples that keep appearing in the literature over the past year, and they share something that is often overlooked. They are not invented facts about the world. They are invented outcomes of the agent's own work. ## What the research says For a chatbot, hallucination means a factual error: an incorrect year or a quotation that does not exist. An agent adds a second kind: an invented outcome of its own work. A 2025 survey of agent hallucinations ([Lin et al.](https://arxiv.org/abs/2509.18970)) distinguishes errors in planning, errors in calling tools, and errors in reading what a tool returns. The causes the authors identify are strikingly ordinary: unclear or incomplete tool descriptions, a model superficially mimicking the pattern of a typical tool response, and invented parameters when the task does not contain enough information. In June 2026, [Advani](https://arxiv.org/abs/2606.09863) studied "false success": cases where an agent declares completion but the environment shows otherwise. Across almost twelve thousand customer service runs, agents confidently closed nearly half of the failed runs as though they had succeeded. Two findings matter more for your work than the percentage. The runtime recorded "successful" after every run, whatever had happened. And a second language model acting as a judge barely distinguished false success from real success. Like the agent, it trusted confident closing statements instead of checking the system's actual state. That confirms what we see in our own work. The problem is rarely in the model. It is in the layer around it, [the harness](/en/what-is/harness/): the tools, their descriptions, and above all what does and does not come back after an action. ## A model cannot see its own work A language model predicts text and has no senses. It does not know whether the email went out, whether the CRM update landed, or whether the function it called even exists. It only knows what the software around it returns. If that software returns nothing, or only a superficial "ok", a gap remains, and a model fills a gap with the most likely continuation. After "send this email", that is "the email has been sent". So the question is not why the model lied. The question is why the model had no useful information on which to base a correct answer. ## The difficult variant: the response is correct, the effect is missing The clearest cases (a tool that does not exist, or an ignored error message) can still be caught. Cases where the tool responds properly but the response does not mean what the model thinks are harder to catch. Three patterns keep recurring in practice. - **The request was received, but the change was not applied.** An agent sets a customer's CRM status to "active". The CRM confirms that the request was technically received, but states in the response body that the change was rejected because a required field is empty. The tool looks only at the technical acknowledgement and passes on "success". The CRM still says "inactive". - **The result is empty and looks like an answer.** An agent searches for outstanding invoices older than thirty days, but the date filter is constructed incorrectly. The search succeeds and returns zero results. Without an independent check, the model cannot know that the filter is wrong or that zero results are unlikely. It reports that nothing is outstanding, while twelve invoices remain unpaid. - **The page loads, but the data does not.** An agent retrieves a delivery status from a carrier's portal. The session has expired, the portal shows a login screen, and the tool returns the page content as if it were the status page. The model reads a page without a status and fills in what it expected. In all three cases, transport technically succeeded, but the intended business effect is missing. Without an additional check, the model cannot establish that the change was rejected, the filter is wrong, or the wrong page loaded. Whether that distinction appears in the return value is a tool design choice. Someone therefore needs to define what "success" means for each tool and what evidence supports it. ![Noor looks at a screen with a tick, while a form with an empty field and a cross lies on her desk; Twijn points at the screen](/images/blog/agent-verstuurde-mail-scherm.png) ## Why this is worse than an agent that does nothing Our agents do things in the real world. They open websites, write to systems, send messages. An agent that says it did something when it did not is more harmful than an agent that does nothing. You notice an agent that gets stuck; someone takes over. An agent that falsely reports success disappears from view: the task is marked complete, nobody looks at it again, and it surfaces when the customer asks why they never heard anything. The same applies in the other direction. If an action may have gone through and the agent simply tries again, the order appears twice. When outcomes are unknown, retrying is just as risky as doing nothing. ## Four things you can do None of the four is spectacular, but together they significantly reduce the chance of falsely reported success. ### 1. Make every consequential action return evidence Not "success", but what changed, in which version, and at what time. In the CRM example: the tool reads the record back after the change and returns the new value, not the request's status code. That takes more work when building the tool, but saves you the later debate about whether something actually happened. ### 2. Make "outcome unknown" a valid status Alongside success and failure. After a timeout, nobody knows what happened, and that should remain visible rather than being rounded off to either outcome. What happens next is a choice: check whether the effect occurred, or refer it to a person. Both are better than guessing. ### 3. Make retrying safe Give every task a unique identifier and record whether it has already been executed. A repeated attempt after a timeout then does not lead to a second email, payment, or order. The agent can first check what happened to the original task instead of blindly repeating the same action. ### 4. Put risky actions before a person Human approval is appropriate for actions with a major impact, substantial uncertainty, limited reversibility, or sensitive consequences for customers and employees. Think of sending, paying, deleting, or publishing something on behalf of your organisation. That last point may feel like a temporary restriction. We see it as a feature: [a human in the loop](/en/what-is/human-in-the-loop/) is the point where someone in your organisation can still change or reject the proposed action. ## The question to ask a supplier When asking a supplier about an agent, do not just ask what it can do. Also ask them to demonstrate what happens when an action fails or its outcome remains unknown, and what evidence the system records. That says more about production reliability than a flawless demo. If you are building it yourself, start with how results are returned, rather than the prompt. You can find the background in [what state means for an AI agent](/en/what-is/agent-state/), and how it fits into the rest of the build in the guide to [building your own AI agent](/en/guides/build-ai-agent/). And the question we ask ourselves with every new tool: which action would you never let an agent take without someone reviewing it?