Why AI agents need evidence

Useful agent work connects an answer to the clause, revision, calculation, and proposed effect that support it. If an agent recommends not renewing a supplier contract, the person responsible for that decision can verify the document, redo the calculation, and see exactly what would be sent.

Evidence connects sources, tools, transformations, decisions, and deliverable revisions; the V1 execution map shows where these operations run and which boundaries they cross.

Follow a recommendation through to its effect

Take one decision in a review of fifteen supplier contracts. A supplier contract renews on 1 March 2027 unless notice is given ninety days earlier. An amendment changes the annual cap. An accounting export contains actual spend, and an incident register records four service outages.

The agent recommends that the contract should not renew on its current terms. It prepares a decision memo, corrects the tracking table, and proposes a non-renewal message. For someone to act on that recommendation, six elements must remain connected:

1. the exact revisions of the contract and its amendment;
2. the extracted passages and spend cells used;
3. the deadline and projected-cost calculations;
4. the receipts from the tools that read, calculated, and produced the files;
5. the deliverable revision reviewed by the person;
6. the targeted decision and, if the message is sent, its delivery receipt.

This path changes review. A person no longer needs to repeat the whole analysis to check the date or amount. They can start from the recommendation, move back to the calculation, then open the exact clause and cell.

Retention focuses on what explains a material claim, effect, or revision. Useful evidence is structured, attributed, and causally connected.

Four distinct functions of evidence

These ideas answer different questions.

Provenance describes an item's origin and history: source file, retrieval date, digest, tool, produced revision, and selected model.

Justification exposes the verifiable elements supporting a conclusion: cited clauses, calculations, applied rules, missing data, and limitations.

A model explanation summarises why it proposes a conclusion. It guides review; the source and reproducible calculation provide verifiable material.

Truth remains a separate question. Exact provenance can lead back to a mistaken source, and a consistent justification can begin with an assumption that is no longer valid. Evidence shows what supports a conclusion and makes criticism possible.

loqy therefore prioritises provenance and justification. The agent can summarise why it proposes a conclusion, but trust comes from the reviewable objects alongside it. In the contract example, the date formula and original clause matter more than a detailed narrative of the model's thoughts.

This approach follows the general idea behind the W3C provenance model: represent entities, activities, and agents, then the relationships explaining how an outcome was produced. loqy adapts that idea to agent runs and a work interface.

Sources carry a revision identity

Evidence identifies the revision of contract.pdf that was actually read or its exact digest. The same principle applies to a web page, CSV export, or tool result.

When content enters the work, loqy records its identity and origin. A transformation creates a new revision instead of silently erasing the previous one. The decision memo and corrected table can therefore be compared with their earlier state.

This answers a common question after an incident: “what did the agent see at that moment?” Without stable revisions, the answer depends on the files as they exist now. With them, the material context can be reconstructed.

Retention remains proportionate. Large results do not need to be copied into every message. They can remain in canonical storage while the model context receives a bounded excerpt and exact reference. Evidence keeps the link to the complete result without saturating the conversation.

A tool call produces a receipt

When an agent runs a calculation, searches a page, or transforms a document, three elements stay together: the intention, admitted inputs, and result. That is the purpose of a tool receipt. In the supplier case, one receipt connects the ninety-day formula to the date read from the contract and the value written to the table.

A receipt records what was called, within which scope, and what came back. An API may return bad data, a page may be hostile, and a script may contain a defect; review can then focus on the right boundary.

Receipts also help handle failure. If a tool reports an error without changing the outside world, the agent can try another approach. If external state may have changed, the situation is different.

Consider the non-renewal message. The connection drops immediately after the request. Retrying automatically might create a duplicate. Treating the send as failed might hide a message that already left. loqy must mark the effect as uncertain, reconcile its state when the connector supports it, and ask for a decision when safe reconciliation is impossible.

After a crash, recovery reconciles the state of a pending external effect before another attempt. Continuity therefore preserves the uniqueness of its consequences.

A human decision is a precise event

“Yes, go ahead” in a conversation might answer a question, approve wording, or simply express agreement. Authorisation therefore targets a precise typed request.

In loqy, a consequential action is represented by a typed request linked to the run and exact evidence. For the non-renewal, the decision card shows the recipient, subject, message body, attachments, calculated deadline, and memo revision. A response targets that precise request. An idempotency key connects the request, payload, and effect so that a double click or reconnection cannot apply the action twice.

If the file, destination, or another piece of evidence changes before the answer, the approval becomes stale. The person must review the new revision. Authority cannot be detached from what it authorised.

loqy works within existing bounds and reserves decisions for effects that need them. Reading an authorised file, calculating a total, or preparing a draft stays within the current scope. Publishing, deleting, sending, or widening access crosses another boundary.

The agent can therefore progress within clear bounds and present an exact decision when those bounds must change.

Evidence follows every deliverable revision

In the contract review, the agent first produces a table and memo. The user corrects the annual cap because the clause refers to an amendment. The agent applies the correction, recalculates the summary, and creates another revision. The previous send request automatically becomes stale because it referred to different content.

If the final deliverable simply overwrites the old file, three facts disappear: the initial proposal, the human correction, and the correction's effect on the result. Linked revisions can instead distinguish:

• content extracted by the model;
• deterministic transformations;
• changes proposed by the agent;
• human corrections or decisions;
• the verified and delivered version.

The final stage verifies more than file creation: format, requested constraints, references, and known limitations. A workbook must open and contain the expected sheets. A report must cite its sources. A code change must pass the relevant checks. The deliverable remains a proposal until the expected verification or decision occurs.

This chain reduces the cost of locating an error, understanding its propagation, and producing a corrected revision.

Model and provider belong in attribution

Two models can produce different answers from the same context. A provider can update a hosted model. A local model can change release or quantisation.

Every run therefore has an immutable model identity. For local inference, it includes the artefact and configuration. For hosted inference, it includes the provider and admitted identifier. A model or provider change applies to a new run and never rewrites attribution for the previous one.

This information supports revision comparison, defect reproduction, and understanding which processing conditions applied. It also contributes to portability: work can outlive a model while retaining the exact model, provider, and configuration associated with each revision. The work exit path depends on that continuity.

Evidence and telemetry are separate planes

The detailed work trace belongs to the user and stays local by default. It may contain documents, excerpts, calculations, and sensitive decisions. Maintainer telemetry follows a separate plane.

loqy separates three planes:

1. work evidence, retained so the user can understand and resume activity;
2. customer-owned operational diagnostics, used to administer the customer's own environment;
3. technical signals optionally sent to the maintainer, limited to what is required to diagnose a crash or improve the product.

An ordinary technical diagnostic remains free of work content: application version, component state, error codes, and the necessary technical events. If a person chooses to share content to obtain support, that sharing must be separate, explicit, inspectable, and revocable. Authentication material, tokens, and secrets remain excluded.

This separation is essential to trust: evidence visible inside the application stays in the user's work plane.

The application must provide its own evidence

Traceability also covers the distributed application: which source produced this version, which components does it contain, and how can a user verify its integrity?

loqy distinguishes reproducibility of the unsigned payload from integrity of the distributed release. Apple signing and notarisation add identities and trusted timestamps, so the final file is not necessarily byte-for-byte identical to a local reconstruction. Release provenance instead links source code, locked inputs, unsigned payload, signature, software bill of materials, and published deliverable.

Open source makes the architecture inspectable. Reproducibility relates the binary to that source. Signing identifies the distributed release. These mechanisms become stronger when evidence connects them.

Trust remains a human judgement

At the end of the review, the user receives more than a filled table. They receive a revision that can be navigated in both directions: from contract to recommendation and from recommendation back to contract. Calculations have inputs, actions have receipts, decisions have scope, and corrections have history.

Documents may conflict, a public source may be outdated, and a model may misread a clause. Evidence gives human judgement precise material for resolving the difference.

A trustworthy agent makes visible what supports the result, what changed, what remains uncertain, and what still needs a decision.

Sources and method

• W3C, PROV Overview
• loqy, contextual human decisions
• loqy, target architecture and revision chain
• loqy, Live Artifacts and publication provenance
• loqy, reproducible builds and release provenance
• NIST, AI Risk Management Framework