AI Agent Task Verification: Proof, Not Identity

Much of the published guidance on verifying AI agents, from identity vendors to NIST and OWASP, is not about tasks at all. It is about identity: confirming that an agent acting on a customer's behalf is genuine, properly authorised and not an impostor. That is a real problem, and an important one, but it is a different problem from the one an engineering lead or a head of delivery faces on a Monday morning, which is whether the work an agent says it finished was actually done, and done to the standard the task asked for.

The stakes for getting the distinction right are commercial. Gartner predicted in June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls. A team that buys an identity control when its real exposure is unchecked output has bought the wrong risk control, and the business value stays unclear because nobody can say which completions were real. This guide is written for the delivery owner who has to answer that question. It separates the three things vendors mean by agent verification, sets out who should do the checking, and gives you questions to put to any vendor that says its agents are verified.

Scope, stated plainly: this post is about telling the meanings apart and deciding who verifies. It deliberately cedes the detailed contents of a proof package and the delivery metrics that replace velocity to our AI agent work management guide, and it cedes the engineering-specific question of agentic code review to our post on the coding agent review queue.

This guide is shipped by the team behind Cognibl, work management for teams where people and AI agents share one board, and a task reaches done only once proof is attached. Or see DATS, our five-stage AI consulting system.

What does AI agent task verification actually mean?

AI agent task verification means checking that a specific piece of work an agent produced meets the written standard set for that task, using evidence rather than the agent's own report. It is distinct from verifying who the agent is and from evaluating how well a model performs in general. The question it answers is narrow and practical: did this task, on this day, produce what its definition of done asked for?

Three different checks travel under the one word, and a buying conversation goes wrong when a vendor answers one while the buyer is asking about another. The first is identity: is this agent who it claims to be, and is it allowed to do what it is attempting? The second is evaluation: across a test set or a benchmark, how often does this model or agent get things right? The third is task output: for this particular piece of work, is the result correct, complete and evidenced? Each has its own owner, its own tooling and its own failure mode, which is why the AI operating model for an agent programme should name all three separately rather than assume one covers the others.

The fourth node in that flow, sign-off, is not a separate kind of verification so much as the point where task-output verification becomes a record. It matters because a check that leaves no trace cannot be audited later, and an audit is usually where an agent programme is asked to prove its numbers. Our enterprise AI consulting guide covers what a board should ask before it approves AI spend.

Why do so many agent verification guides talk about identity?

Agent verification guides talk about identity because agents increasingly act on behalf of people, booking travel, handling transactions and touching health data, and the first fear in those settings is impersonation. Identity vendors, NIST and OWASP have all published on that risk. Their work answers whether an agent may act, not whether the work it completed is right.

The identity meaning has serious institutional backing. Vouched, which offers identity verification services, published a guide on how to verify an AI agent in February 2026 that frames the job as a Know Your Agent framework, likened to the Know Your Customer rules used in finance, with the aim of establishing a verifiable identity for each agent acting on a user's behalf. In the same month, NIST's National Cybersecurity Center of Excellence released a concept paper on software and AI agent identity and authorization, published on 5 February 2026 and open for comment until 2 April 2026, asking how organisations handle identification, authorization, auditing and non-repudiation for AI agents.

Security practitioners reached the same place. The OWASP Top 10 for Agentic Applications for 2026, published on 9 December 2025 with input from more than 100 experts, lists Identity and Privilege Abuse as ASI03, alongside Tool Misuse and Exploitation as ASI02. This work is aimed at controlling what agents may access and do, which is a platform and security concern, and those teams will need it. The parallel in voice is instructive: a contact centre verifies a caller's identity before discussing an account, as our guide to caller identity verification explains, and nobody confuses that check with whether the call resolved the customer's problem.

The same OWASP list carries a quieter entry that points straight at task verification: ASI09, Human-Agent Trust Exploitation. Its description says the risk is amplified when humans over-rely on autonomous recommendations or unverifiable rationales, approving actions without independent validation. That is the territory of the rest of this guide, and it is where most delivery teams are exposed.

How is task verification different from agent evaluation and benchmarks?

Task verification differs from evaluation because evaluation measures an agent's average performance across many prepared cases, while task verification checks one real piece of work against its own written standard. A strong benchmark score says an agent is usually capable. It cannot say whether Tuesday's migration, invoice reconciliation or bug fix was done correctly, because that task was never in the test set.

Evaluation is valuable and belongs earlier in the lifecycle. It tells you which model to choose, whether a prompt change made things better or worse, and how often a class of task tends to fail. Our post on evaluation harness engineering covers how to build that discipline properly. The mistake is treating an evaluation result as a substitute for checking production work. An agent that scores well across a test set still produces individual results that are incomplete, subtly wrong or correct on the surface but built against a misunderstood brief.

There is a useful vendor signal on how large that gap can be. MindStudio, an AI agent platform vendor, wrote in a guide published on 5 August 2026 that when you ask an AI agent to complete a task you typically get something in the range of 60 to 70 percent done, then climb toward 90 or 95 percent through manual back and forth. Treat that as one vendor's working estimate rather than a measurement, but notice what it implies: the distance between done and claimed done is closed by somebody checking, and the question is whether that checking is structured or improvised.

Observability sits beside evaluation and can be mistaken for verification. Traces and logs tell you what an agent did, step by step. They are essential for diagnosis, as our post on LangGraph and a work management layer sets out. A trace still records activity rather than judging the result against a standard, so it supports task verification without being it.

What evidence should a verified agent task carry?

A verified agent task should carry a written definition of done, a reference to what the agent actually produced, and evidence a second party can open without rerunning the work, all attached to the task record rather than left in a chat thread. In Cognibl, from DILR.AI, that evidence is a proof version, and the database refuses a done status without one.

The detail of what goes inside that package is covered in our proof of done guide, so only the principle belongs here. On the live Cognibl product page, the proof is described as a CSV describing the run, with the artefact, screenshots and hashes referenced from inside it, and the same rule holds for a person and for an agent. The value of that last clause is easy to miss. If agents face a stricter evidence bar than people, it creates an incentive to route contested work to a person to avoid the gate, and the verification record can develop a blind spot exactly where the risk is highest.

Two properties make evidence usable for verification rather than decoration. It has to be something a reviewer can open and check, not only the agent's own summary, and it has to be stable once filed. In Cognibl, proof versions are immutable, the trace of each call is written by the gateway rather than reported by the agent, records are append-only and hash-chained, and every write is attributed by key name, which is why our guide to an AI agent audit trail in a bank treats that record as the start of a regulatory evidence file rather than the whole of it.

Who should verify an AI agent's work: the agent, another agent or a person?

An AI agent's work is best verified in layers: the agent checks its own output against the definition of done, an automated check confirms the evidence is complete and matches, and a named person accepts the result where the consequences matter. No single layer is sufficient alone. Each catches a different kind of miss, and a person carries the accountability.

Self-verification is worth building in. The MindStudio guide defines a verification loop as a step an agent runs after producing output to check it against a standard before considering the task done, and the habit is designed to catch misses before work reaches a reviewer. Its limit is structural rather than technical: an agent that misunderstood the brief will check its work against the same misunderstanding. A verification loop cannot correct an error in the standard it is checking against.

A second, automated layer is where evidence gets compared with the contract. In Cognibl, the AI tier adds a proof validation flow alongside a status summary flow, and the product page is explicit about the boundary: the AI flows flag problems; they do not decide, and people keep the decision. That division is a sensible default for any tool you evaluate, and a question worth settling early in any AI developer productivity programme that adds agents to an engineering function.

The person at the end of the chain is there because accountability cannot be delegated to software, and because human reviewers are vulnerable to a known bias. The EU AI Act names it directly. Article 14 requires a high-risk AI system to be provided in such a way that the people assigned to oversee it are enabled "to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)", as set out in Regulation (EU) 2024/1689. The requirement applies to high-risk systems, and whether a given work-management agent is one depends on its use, so check the classification rather than assume it. The lesson still travels: a reviewer shown a confident completion message and no evidence is being set up to rubber-stamp it.

The practical design follows from that. Put the evidence in front of the reviewer before the agent's summary, make the definition of done visible at the point of sign-off, and record who accepted the work. For teams that want help running that sign-off design day to day, see our AI execution office, and the law firm agent governance guide shows the same supervision logic in a regulated profession.

What should you ask a vendor that says its agents are verified?

Ask a vendor which of the three meanings it means, then ask to see one completed task and its evidence. A vendor whose agents are genuinely verified at the task level can show the written standard, the artefact, the evidence a reviewer opened and the record of who accepted it. A vendor selling identity or evaluation will describe credentials or benchmark scores instead.

Gartner's warning about agent washing is relevant here. The same June 2025 release estimated that only about 130 of the thousands of agentic AI vendors are real, with many rebranding existing assistants, robotic process automation and chatbots without substantial agentic capability. Verification claims deserve the same scepticism. If you would rather pressure-test a vendor's answers with someone who has no stake in the sale, talk to our team. A short set of questions sorts the substance from the label quickly, and it works whether you are evaluating a tracker, an agent framework or a full service partner such as a placement diagnostic team.

None of those answers requires a particular product. They describe a discipline, and a team can run it on paper before buying anything. A verification standard that cannot be written down will not be enforced by a tool either, and our DATS methodology page describes how we approach that first step.

What is the best way to verify AI agent work in 2026?

The best way to verify AI agent work in 2026 depends on which risk dominates. Where impersonation or unauthorised transactions are the main exposure, a dedicated identity and authorisation layer comes first. Where model quality is unknown, an evaluation harness comes first. Where the risk is accepting incomplete or wrong work as finished, a proof-based done gate on the work record matters most.

Judge the options on four criteria: whether verification happens per task rather than on average, whether there is evidence beyond the agent's own report, whether the same bar applies to people and agents, and whether a person keeps the decision. Against those criteria, classic trackers such as Jira, Linear and Asana were designed around human workflow; workflow rules can be configured in some of them, but an evidence requirement at done is something a team has to design and maintain itself. Agent frameworks such as LangGraph and CrewAI focus on how agents run and coordinate, and LangGraph supports human-in-the-loop interrupts, but a team still has to decide where the written definition of done and the record of who accepted the result are held.

Cognibl is built for the third case. As the Cognibl overview explains, it puts people and agents on one board under their own names and refuses a done status without an attached proof version. It is not an identity-verification product, and the concession is real: if your exposure is an agent acting on a customer's behalf with their money or data, an identity and authorisation layer, the territory of vendors such as Vouched, comes first. It also does not replace an evaluation harness for choosing models. Many teams will need all three layers, owned by different people, which is why the MCP skills library governance post treats tool access as its own control.

The broader market context argues for doing this early. McKinsey's State of AI found in November 2025 that 88% of organisations use AI in at least one function, yet only about 6% qualify as high performers capturing material EBIT impact. Gartner, in the June 2025 release, predicts that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024. Our view is that as agent output grows, unverified completions risk widening the gap between reported progress and real value, and that gap is cheaper to close with a standard in place than after an audit finds it.

Frequently asked questions

Does agent identity verification replace task output verification?

Agent identity verification does not replace task output verification. Identity checks confirm that an agent is genuine and authorised to act, which protects systems and customers from impersonation and misuse. They say nothing about whether the work that authorised agent produced is correct or complete. A fully authenticated agent can still deliver a wrong result, so the two checks run side by side.

Read the NIST concept paper and OWASP entries ASI02 and ASI03 as reference points for the identity side, and the proof of done guide for the output side.

Can an AI agent verify its own work?

An AI agent can usefully check its own work, and a self-verification loop is designed to catch misses before a reviewer sees them. It cannot be the final word, because an agent that misread the task will check its output against the same misreading. Self-checks belong at the start of a verification chain, followed by an independent evidence check and a person who accepts the result.

Cognibl applies that principle in its own flows, which flag problems for a person rather than deciding, as the Cognibl product page sets out.

Does the EU AI Act require a person to check every agent output?

The EU AI Act does not require a person to check every agent output. Article 14 sets human oversight requirements for high-risk AI systems, including awareness of automation bias, and whether an agent falls into that category depends on its use. Whatever the classification, the Act's reasoning about over-reliance is a sound design guide for any team accepting agent work.

UK teams processing personal data should also read the ICO's guidance on AI and data protection, and our strategy articles cover the governance side in more depth.

Want to see this in production? Try Cognibl live, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI inside enterprise systems.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.