Why Long-Horizon Agents Never Grade Their Own Work
Why agents falsely report tasks as done and how deterministic, evidence-based verification stops false completion in long-horizon agent systems.
The Risk of False Completion in Long-Horizon Agents
An agent reporting a task is finished when it is not represents one of the most damaging failure modes in enterprise automation. For long-horizon agents that manage complex jobs over weeks or months, this problem is especially severe. A single task marked complete at an early stage can silently poison all downstream dependencies, causing a process to fail in ways that are only discovered much later in the real world. This is how a customer onboarding process breaks on day ten because of a false completion on day two.
The root cause lies in the nature of the LLM itself. It is trained to produce plausible, helpful output, which creates a natural bias toward reporting success. An LLM has no internal ground truth about the state of the world. It can hallucinate that it sent an email, that a document was received or that a goal was met. The agent often conflates its own action with the desired outcome. "I sent the welcome email" is not the same as "the customer is successfully onboarded". "I asked the supplier for the certificate" is not the same as "a valid certificate is on file". To build reliable systems, we must design for this weakness and prevent false completion.
Why Common Verification Solutions Fail
The first instinct for solving false completion is often to apply another layer of intelligence, but these approaches fail because they do not address the core problem of ground truth. Effective agent task verification requires connecting to real-world state, not just adding more narrative layers.
The most direct approach, asking the agent if it is done, is also the least reliable. This is circular logic where the component most likely to be wrong is asked to verify itself. A second common fix is to add a supervisor or judge agent to review the primary agent's work. This does not solve the problem. A second LLM is still a probabilistic model with no access to ground truth and can be convinced by the same plausible but false narrative. Finally, many teams try to solve this with better prompting. Instructions like "make sure the task is truly complete" only shift the probabilistic burden. Better instructions do not grant the agent the ability to check external state. Robust evaluation requires checking against ground-truth outcomes, a step that simple prompting or supervisor agents cannot perform reliably.
Comparison of Flawed Verification Methods
| Approach | Core Flaw | Why It Fails for Long-Horizon Tasks |
|---|---|---|
| Agent Self-Report | Circular reasoning | The component most likely to be wrong is asked to verify itself. |
| Supervisor Agent | Probabilistic, no ground truth | A second LLM can be convinced by the same plausible but false narrative. |
| Enhanced Prompting | Does not grant access to state | Better instructions do not connect the agent to real-world evidence. |
Separating Task Achievement from Verification
The solution is to architecturally separate the act of achieving a goal from the act of verifying its completion. These are two distinct concerns that require two different types of components. The agent's job is to perform the non-deterministic work required to achieve the goal. The system's job is to perform the deterministic evaluation to confirm it.
This separation creates a clear and reliable operational flow. The agent works until it believes the task is complete. It then signals this to the system. The system runs a deterministic check against explicit success criteria using real-world data. Based on the result, the system either accepts the completion or rejects it, reopening the task and sending the agent back to work. This loop continues until verifiable evidence is present.
Crucially, the agent is never allowed to close its own task. Completion is a status granted by the system, not a state declared by the agent. This is the foundation of building deterministic agent systems that can be trusted to execute complex, multi-step processes without direct supervision.
Building on Evidence Instead of Narratives
In this model, "done" is not a narrative from the agent. It is an observable change in an external system of record. This evidence must be concrete and verifiable. For a customer onboarding task, completion is not when a nudge email is sent but when a product activation event fires in a database. For a compliance task, it is not when a supplier says they sent a document but when a valid, unexpired certificate is present and validated in a file store. These are verifiable agent outcomes.
This leads to a core principle: observe, do not ask. The verification system must read the source of truth directly rather than asking the agent for a status update. This approach aligns with a zero-token architecture, where critical verification data and identifiers are kept out of the agent's context. The agent decides the intent, for example "verify the compliance certificate", but deterministic infrastructure holds the artifact, runs the checks and returns a simple pass or fail. The agent never handles the certificate itself, preventing it from hallucinating identifiers or fabricating a successful outcome. The system observes the file arriving, validates its contents and only then marks the task complete.
Design Principles for Verifiable Outcomes
Building reliable verification requires a disciplined approach. The following design principles provide a framework for creating systems where completion is based on evidence, not belief. Adhering to these principles is essential for achieving high agent reliability in production environments.
- Define completion as code, not prose. Success criteria should be explicit, checkable predicates that function like unit tests, not ambiguous natural language goals. The system should evaluate a function that returns true or false.
- Verify against external state and real evidence. The verifier must read from the source of truth, like a database, an API or a product event stream, not the agent's own transcript or memory.
- Keep the verifier deterministic and outside the agent. Do not use another LLM as the source of truth. The verifier should be simple, reliable code that produces the same result every time for a given state.
- Make "done" rejectable. The system must have the authority to reject a claimed completion and reopen the task. This forces the agent to retry, take a different approach or escalate if it is truly stuck.
- Observe, do not ask. Build infrastructure that watches for evidence of completion directly instead of querying the agent for its belief state. This is the most reliable way to connect the agent's work to real-world impact.
- Log the evidence that closed each task. For auditability and debugging, every completed task should have a clear record of the specific evidence that triggered its closure. This makes the entire process transparent and trustworthy.
Trust Through Verifiable Autonomy
Trustworthy autonomy for long-horizon agents is achieved by never letting the model grade its own work. The agent brings powerful, open-ended reasoning to complex problems. The deterministic system brings verifiable completion and ensures the work is actually done. This strict separation of concerns is what allows an agent to run unsupervised for weeks or months and still be trusted to deliver the correct outcome. It transforms the agent from a plausible narrator into a reliable operator. This is the approach we take at lemongraph.dev to build agents that own complex operations from end to end.