A task marked "done" is a label, not evidence — the receiver has to trust the producer's word, and that word carries nothing inspectable once the result is forwarded to someone who never saw the work.
← Back to patterns
Google
Intelligent AI Delegation Agent2Agent (A2A) Protocol
Trust & Verification
EmergingVerifiable Task Completion
Proof of Done You Can Open
Most products mark a task "done" with a checkbox, so whoever receives the result has only the producer's word for it. Verifiable Task Completion declares up front what "done" must prove, then attaches an inspectable bundle to the result — tests passed, sources checked, sign-offs collected. You open the proof instead of trusting the label, and the evidence rides along when the result gets forwarded.
Metaphor
Notarised Certificate
Interaction
Pre-flight Evidence Standard, Post-flight Proof
Use case
Delegated agent work, Code-review gates, Forwarded results
Failure mode
Done as a Label
Control mechanisms
Verification Policy Contract · Cryptographic Proof Bundle · Attestation Chain · Escrow Trigger
Reference examples
C2PA Content Credentials · Optimism Fault proofs · GitHub Required status checks · A2A Protocol Signed Agent Cards · Google Antigravity /goal
Concept Frame
"Done" is not a label. It is evidence you can open.
Marking a task done is a checkbox in most products — an assertion with nothing behind it. In delegation chains and high-stakes work, that checkbox cannot carry the weight that follows it: money, downstream commitments, regulatory consequences. So make "done" something you can open: the result arrives with a proof bundle — passed tests, checked sources, sign-offs — that the receiver inspects, that survives forwarding, and that a contract can release payment against. You pick the strictness per task; the cryptographic end (zk-SNARK traces, TEE attestations) is for private or high-stakes work, and the pattern as a whole is still emerging.
Interactive Example
The live side-by-side is the comparison.
This prototype already contains the contrast between the status-quo approach and the pattern response. The left column names the failure mode of the naive baseline (fixed dispatch, label-as-done, hidden hierarchy, uniform friction); the right column is the move.
"Done" is a label. A proof is evidence.
Most products mark a task complete with a checkbox, which asserts an outcome without demonstrating one. In delegation chains and high-stakes work that is not enough: the delegator needs something that survives forwarding, that a third party can audit, and that a contract can release payment against. A chat output is unsigned, unattestable, and re-tellable — there is no native way to ask "is this really done, by these criteria, signed by whom?"
Verifiable Task Completion declares what "done" must prove up front, then attaches a proof bundle to the result the receiver can open — passed tests, checked sources, sign-offs — and a third party can re-check. Done then means exactly the declared criteria, no more and no less. You pick the strictness per task; the heavy-duty end — zk-SNARK traces, TEE attestations — buys auditability at real cost, so it is reserved for private or high-stakes work.
If completion cannot be proven to someone who was not in the room, it has not been verified — only claimed.
DOPE Lens
How this pattern improves AI interaction quality.
Observability
The proof bundle is inspectable — every attestation, signer, and verification artefact is visible alongside the result
Directability
Delegators choose verification strictness (none / unit-test / zk-proof / panel) per task and renegotiate if a delegatee cannot meet the standard
Predictability
The verification policy is declared up front; done means exactly the criteria the policy specified, no more, no less
Explainability
Each proof carries its method (test suite, ZKP circuit hash, TEE enclave id) and the verifier identity that signed it
Fit
Where it earns its place.
Use it
when
when
When a result carries its own evidence, the receiver verifies it in seconds instead of trusting a checkbox that proves nothing once it is forwarded.
Avoid
when
when
The task is low-stakes and the receiver can just look at the result themselves — attaching proof costs more than reading the output.
In the wild
Where this pattern already ships.
The pattern is shipping but still maturing across products. Entries below show how different teams have approached it; expect variation as the space settles.
C2PA · Content Credentials
C2PA · Adobe / OpenAI / Leica
A Content Credential is signed provenance data embedded in, or linked from, an image, video, audio file or document. A C2PA-enabled camera, AI generator or editing app adds it when it captures, generates or edits the file, recording when and with which device or tool the file was made, any edits since, and who signed the record. It travels with the file unless a platform strips it, and anyone can drop the file into the public Verify tool to see the signer and whether anything changed after signing. It proves where the file came from and that its record is intact, not that the signer's claims are true or that the work met criteria declared in advance.
Visit C2PA · Adobe / OpenAI / Leica ↗
Optimism · Fault proofs
OP Labs
Optimistic verification: a claim about the chain's state is posted with a bond and stands unless someone challenges it within a ~1 week challenge period, and anyone can challenge it with the op-challenger tool. The two sides bisect the disputed execution down to a single instruction, which an onchain VM re-executes to settle who was right. A claim that is successfully countered pays its bond to the party that countered it. No proof travels with the result: trust comes from the open challenge, with the Optimism Security Council as a backstop.
Visit OP Labs ↗
GitHub · Required status checks
GitHub
A branch protection rule can require that status checks, such as the test suite, pass before a pull request merges, and that commits are signed and verified; a ruleset can add the "Require code scanning results" rule with CodeQL as a required tool. Each required check can be tied to the GitHub App expected to report it, so "done" means passing checks from named verifiers, listed in the merge box. The check results live on GitHub, not in the git history; only the commit signatures travel with the code.
Visit GitHub ↗
A2A Protocol · Signed Agent Cards
Agentic AI Foundation / Linux Foundation (orig. Google)
A2A v1.0 lets a provider attach an optional JSON Web Signature to its Agent Card (the AgentCardSignature object), so a client agent can check that the card is untampered and comes from the claimed provider before it delegates work. The proof stops at identity: the spec's Task and Artifact objects carry no signature. Signing task outputs exists only in open community proposals on the A2A repo, the oldest a Content Integrity Profile that adds a hash and signature to artifacts, filed in October 2025 and tagged for Technical Steering Committee review.
Visit Agentic AI Foundation / Linux Foundation (orig. Google) ↗
Google Antigravity · /goal
Type /goal and an objective, and the docs ask you to write explicit completion criteria that name the evidence, such as "all tests in packages/api pass". Before concluding, the agent is instructed to map every deliverable in the request to concrete evidence (file contents, test results, build logs). Separately, in the App and IDE a finished implementation gets a walkthrough artifact, a summary of the changes that for browser tasks often carries screenshots and screen recordings. The audit is the agent's own: nothing is signed or re-checked by a third party.
Visit Google ↗
Research Frame
Why this pattern exists, and where it breaks.
Declare what "done" must prove up front, then attach an inspectable proof bundle to the result at completion — passed tests, checked sources, sign-offs — so the receiver opens the evidence before accepting it and the proof travels with the result.
A chat reply that says "done" is just text — there is no attached evidence to open, no way to ask "done against which criteria, checked by whom?", and nothing survives when the answer is copied onward.
Proof is only as good as its checks: gameable test suites or captured reviewers fake it, and a bundle only the producer can read defeats the point; the heavy-duty end — zk-SNARK traces, TEE attestations — buys auditability at real cost and latency, so reserve it for high-stakes or private work, and treat it as where delegation is heading, not a default that ships today.
Common questions
What people ask about this pattern.
When should I use the Verifiable Task Completion pattern?
+
When a result carries its own evidence, the receiver verifies it in seconds instead of trusting a checkbox that proves nothing once it is forwarded.
When should I avoid the Verifiable Task Completion pattern?
+
The task is low-stakes and the receiver can just look at the result themselves — attaching proof costs more than reading the output.
What problem does Verifiable Task Completion solve?
+
A task marked "done" is a label, not evidence — the receiver has to trust the producer's word, and that word carries nothing inspectable once the result is forwarded to someone who never saw the work.
Why is chat the wrong fit for this?
+
A chat reply that says "done" is just text — there is no attached evidence to open, no way to ask "done against which criteria, checked by whom?", and nothing survives when the answer is copied onward.
Grounded in Research
Not just opinion.
The papers, guidelines, and usability studies this pattern rests on.
Nenad Tomašev, Matija Franklin, Simon Osindero
Google DeepMind · 2026
Framework for safe and scalable delegation: cognitive friction, authority gradient, verifiable completion, and task-bid markets as the missing UX layer for cross-org agent work.
Google, now Agentic AI Foundation (Linux Foundation)
Industry standard · 2025
Open spec for inter-agent communication with optionally signed Agent Cards (JWS). It signs who an agent is, not what it delivered; task-outcome attestations are still open community proposals.
Related Patterns
Curated connections, not just neighbors.
Hand-picked relationships — what this pattern pairs with in practice, what it replaces, what it builds on, and what builds on it.
Often paired with
Action Audit & Undo
Action Audit & Undo shows each step the agent took; Verifiable Task Completion attaches proof the result met its bar.
Often paired with
Citation Trail
Citation Trail backs each claim with a source; Verifiable Task Completion backs the result with proof you can open.
Often paired with
AI Provenance
AI Provenance shows which AI-drafted spans a human reviewed; Verifiable Task Completion attaches proof the whole result met its bar.