Proof · March 12, 2026 · 8 min read
How to Write Proof Requirements for AI Agent Work
Proof requirements define what done means. They protect the company from confident summaries and turn agent output into inspectable work.
Key takeaways
- Write proof before assignment, not after completion.
- Proof should match the work type: link, screenshot, diff, metric, source, or decision.
- Weak proof should create a follow-up issue instead of silently passing.
Done is not a feeling
Agents are good at producing confident completion notes. That is useful for readability and dangerous for operations. A task is not done because the agent says it is done. It is done when the required evidence exists and someone can inspect it.
Proof requirements make done objective. They tell the agent, reviewer, and founder what artifact must exist before status changes.
Write proof by work type
Different tasks need different proof. A code task needs branch, diff, tests, and maybe preview. A social post needs caption, media, channel, approval, and published link. A research task needs sources, summary, confidence, and decision impact. A CRM task needs records changed, fields sourced, and next action.
Generic proof requirements create generic output. Specific proof requirements make the agent's job clearer and the review faster.
Good proof includes what did not happen
A strong proof packet should also say what remains open. The worker may have drafted posts but not published because Instagram auth failed. It may have verified GitHub read access but not branch creation. It may have enriched accounts but not found email addresses with sufficient confidence.
This prevents false completion. Partial success is valuable if the system records the boundary and creates the next issue.
Proof should be saved, linked, and reusable
The proof should not live only in a comment. Important outputs belong in the library, attached to the source issue and connected to the agent, goal, roadmap item, or customer record. That way future work can reuse it.
A proof document also makes the company easier to audit. The founder can look back and understand why a decision was made without reconstructing the run from raw logs.
Reviewers need a rejection path
If proof is weak, the reviewer should not have to improvise. They should be able to mark 'needs work,' explain the gap, and send it back. The system should preserve the rejection as a lesson and, when appropriate, update the proof requirement for future tasks.
This turns quality control into training. Agents learn what the company accepts, and the organization becomes more precise over time.
Proof is the foundation of autonomy
The more reliable the proof loop, the more autonomy a company can grant. If agents consistently attach useful evidence, humans can approve faster and delegate more. If evidence is missing, autonomy should tighten.
That is why proof is not paperwork. It is the trust layer that lets AI labor become real company capacity.