Evidence Manifests for Agent Work

The final answer is the least reliable place to store proof.

A model can summarize the work beautifully. It can sound measured, transparent, and confident. It can mention tests, cite files, and explain tradeoffs. But if the evidence lives only inside that answer, the system has made verification depend on the same narrative that wants to be believed.

Agent work needs a durable evidence manifest.

An evidence manifest is a structured record of what the task required, which sources were used, which artifacts were produced, which checks ran, which decisions were made, what was excluded, and what uncertainty remains. It is not a transcript. It is the inspection surface for completion.

The manifest lets a human, verifier, or future agent understand why the system considered the work done without replaying every token.

That makes completion auditable instead of conversational.

The Manifest Starts With the Claim

Every manifest should begin with the completion claim.

What did the agent believe it accomplished? Fixed a bug. Drafted a response. Classified a case. Prepared a migration. Summarized a document. Recommended a policy change.

The claim should be specific enough to test. “Improved the checkout flow” is vague. “Added address validation before payment submission and verified the empty-address path with a targeted test” is inspectable.

This claim becomes the anchor for the rest of the manifest. Evidence that does not support the claim is background. Evidence that contradicts it must be resolved or surfaced.

Without a clear claim, the manifest becomes a scrapbook.

Sources Need Provenance

Agents often consume information from files, tickets, documents, logs, search results, user messages, and tool outputs. The manifest should record which sources were used and why they were trusted.

Useful provenance includes location, version, timestamp, owner, authority level, freshness, and retrieval method. A policy document from the current repository has different weight from a cached snippet in a previous conversation. A log query from the last fifteen minutes has different meaning from an incident summary written yesterday.

The point is not to record everything the model saw. It is to identify the evidence that mattered.

When later behavior is questioned, provenance lets the team distinguish bad reasoning from bad inputs.

Artifacts Should Be Addressable

If the agent changed something, the manifest should point to the artifact.

A diff, draft, generated file, report, ticket comment, database migration, test output, screenshot, or approval record should have an addressable location. The final answer can summarize it, but the manifest should let a reviewer inspect the object itself.

This is especially important when work moves across agents. A planner may produce a task spec. An implementer produces a patch. A verifier produces test evidence. A human approves the result. Each artifact needs identity outside the chat.

Addressable artifacts prevent the system from depending on remembered intent.

Checks Must Include Their Scope

“Tests passed” is not enough.

Which tests? Against which revision? In what environment? Were they selected by the agent, required by policy, or run automatically? What did they not cover?

The manifest should record check scope because verification evidence has boundaries. A unit test may support one invariant and say nothing about integration behavior. A linter may catch syntax and miss product logic. A schema validation may prove shape and miss truth.

Good manifests pair each check with the claim it supports. They also record skipped checks and the reason.

This keeps verification honest without demanding impossible certainty.

Decisions Deserve Their Own Records

Agents make decisions that are easy to lose in prose.

They choose one design over another, exclude a source, escalate or continue, use a smaller model, ask for approval, decline a tool call, or stop after a budget is exhausted. These decisions shape the work as much as the final artifact.

The manifest should record important decisions with alternatives considered, evidence used, and consequence. It does not need to capture every thought. It should capture the transitions a future reviewer would need to understand or challenge.

Decision records are especially valuable when the system behaved correctly by not acting. A clean stop can be hard to appreciate without a record of why continuation was unsafe.

Exclusions Are Evidence Too

What the agent deliberately did not use can matter as much as what it used.

Maybe a retrieved document was stale. Maybe a user-provided instruction conflicted with policy. Maybe a tool result came from the wrong environment. Maybe a file looked relevant but belonged to a deprecated path.

Exclusions help reviewers see that the agent was not merely lucky. They also make prompt injection and context pollution more visible. If untrusted content tried to issue instructions, the manifest can record that it was treated as data and excluded from authority.

This turns context engineering into an auditable practice.

Uncertainty Should Survive the Final Answer

Agents are often pressured to close with confidence.

The manifest should preserve unresolved uncertainty even when the final answer is concise. Missing data, assumptions, residual risk, untested paths, and pending human decisions should remain visible.

This is not pessimism. It is operational truth.

A future agent resuming the work needs to know which parts were proven and which parts were accepted with caveats. A human owner needs to know whether follow-up is optional polish or a real risk.

Uncertainty that survives in the manifest is less likely to become hidden debt.

Build Manifests Into the Harness

Asking the model to write a manifest at the end is a start. It is not enough.

The harness should populate parts of the manifest as work happens: tool calls, source versions, approvals, generated artifacts, test commands, capability tokens, retry events, and verification results. The model can explain decisions and connect evidence to claims, but the system should record objective events directly.

This reduces fabrication and makes the manifest cheaper to produce.

The strongest evidence is captured before the final story is written.

Completion Is a Record, Not a Feeling

Agent systems become trustworthy when completion can be inspected.

The final response still matters. Users need a readable summary. But the product should not depend on eloquence as proof.

An evidence manifest gives the system a durable shape: claim, sources, artifacts, checks, decisions, exclusions, and uncertainty. It lets humans review faster, verifiers disagree more clearly, and future agents resume with less guesswork.

The work is not done because the model says it is done.

It is done when the manifest can withstand inspection.