I do not trust done unless it arrives carrying something.
That sounds cranky until you have resumed enough agent work after the room has gone quiet. The summary says the change landed. The tone is confident. The little closing paragraph has that clean-shirt smell of software optimism. Then you ask the dull questions: which files, which source state, which proof, which held cases, which stronger claims still blocked. Half the time, that is where the shine comes off.
This is not because proof is holy. Proof can be stale, thin, pointed at the wrong directory, or wearing a hat it did not earn. A validator can pass while counting the wrong thing. A test can prove one predicate and leave the actual risk standing in the corner with its arms crossed. Anyone who has shipped under pressure knows the smell of that kind of green. It is the smell of a gate latch clicking while the fence behind it lies flat.
Still, I want the receipt.
In older software work, proof often felt like something that happened near the end: a CI run, a review check, a release note, a screenshot, a ticket moved into the civilized column. Important, yes, but downstream from the work. In agentic work, that separation starts to fail. The agent does not merely write code or draft text. It reads source, chooses paths, mutates files, invokes tools, summarizes evidence, and persuades the human that some state has been reached. If the proof is not part of the object, the object is half fog.
The useful question is not whether the agent sounded capable. The useful question is whether the work can show what it touched, what it inspected before touching it, what command or review path supports the claim, what remained held, and what authority still sits outside the run. Without that, done is a little mystery box of confidence, and I have had enough mystery boxes for one lifetime.
Proof-carrying development is my name for the less glamorous discipline: every meaningful agent closeout should be treated as a claim with attached evidence. The final answer is not a victory lap. It is a receipt. Not the decorative kind that exists only to make the report look grown, but the useful kind that lets the next person resume without transcript archaeology and cold coffee.
That receipt should say:
- what changed;
- what source state was inspected;
- what proof ran;
- what the proof can support;
- what stayed held;
- what stronger state remains blocked;
- what the next responsible action is.
The list is not ceremony for ceremony's sake. A quick factual command can get a quick answer, and nobody needs a parade for date. Blast radius should govern paperwork. But a code change, release gate, evidence packet, research draft, or publication-adjacent artifact needs a stronger closeout because the downstream consequences are stronger. The larger the claim, the more the receipt has to carry.
The local research basis is aggregate and bounded. The Research Papers archive draws from private Codex work and portfolio workflows where agents inspect files, run shell commands, update plans, validate packages, and report state. The raw corpus stays private by default. What can travel publicly is the method lesson: agentic work leaves operational evidence, and that evidence becomes useful only when it is bound to a claim.
A shell command in a transcript is just an event until the closeout says what it proved. A diff is just a change until the closeout names the touched surfaces. A test pass is just a bounded predicate until the closeout says what remains outside it. A clean package gate is just local validation until the closeout keeps publication, release, source-permission, legal/privacy, and external authority states separate.
This changes the product surface. If agent products are trust products, the user is not buying only speed. The user is buying the ability to delegate without losing the thread of responsibility. A good agent interface should not bury proof in logs and ask the human to infer the claim from tone. It should put evidence, state, and next action close enough together that the user can see what kind of done they have.
It also changes how the agent behaves upstream. If the closeout must name source state, the agent is more likely to inspect source state. If the receipt must include proof, the agent is more likely to run proof. If the claim ceiling must be explicit, the agent is less likely to turn local validation into release readiness while everyone is tired and ready to clap.
That is the quiet magic of good paperwork: not that it redeems the soul, God help us, but that it makes bad shortcuts harder to hide.
I am not saying a receipt makes the work correct. Receipts can be wrong, stale, incomplete, or misunderstood. A passing command does not prove quality in the abstract. A large tool-call corpus does not prove productivity. A clean local package does not prove public safety. A release-adjacent artifact does not prove launch.
I am saying that proof is part of the thing the system must deliver so authority can be exercised honestly somewhere else. Without the receipt, the next person inherits confidence without handles. With it, done becomes a bounded operating state.
My operating rule is simple: I do not believe in done without a receipt.
Source note: based on Proof-Carrying Development: Agentic Code Work as Claims With Attached Evidence by A.G. Mauro and C.A. Harris.
Claim boundary: this is a public-explainer blog draft for a local agent-work method. It does not prove productivity, correctness, general model quality, public safety, publication approval, public release, or claims about all agents, all teams, or all software work.
Source trail: related archive work includes Evidence-Bound Evaluation, Metrics Are Not Authority, From Receipt to Non-Authority Trace, and Shipability as Evidence.