# Why an AI agent should keep the evidence in view

When software answers a question, a plausible response may be enough to continue a conversation. When an AI agent changes a file, runs code, compares contracts, or prepares an external action, plausibility is not enough. You need to know what it used, what it did, and what remains uncertain.

That is why evidence is a product surface in loqy, not a debug log hidden behind an expert setting. Sources, tool results, decisions, and versions of a deliverable should remain connected to the work that produced them.

## A result needs a trail

Consider a request to review a group of contracts. A useful agent can extract obligations and flag exceptions, but the review only becomes dependable when each important claim can lead back to the relevant clause. If code was used to calculate dates or totals, the calculation and its inputs should be available. If a document was revised, the person reviewing it should be able to distinguish the proposed version from the approved one.

The same principle applies to research. Links alone are not sufficient if the agent cannot show which statement came from which source, when a page was accessed, or where sources disagree. Evidence turns a fluent summary into work that can be checked.

## Decisions are part of the record

An agent also needs to show where its authority stops. Preparing a list of actions is different from exporting that list to a shared folder. Drafting an email is different from sending it. A precise approval should name the effect and the destination, rather than relying on a vague prompt that could be interpreted as permission.

Keeping that decision attached to the run protects both sides of the interaction. The person can see what they approved; the product can avoid pretending that generated text grants authority.

This is also why loqy separates ongoing communication, tracked tasks, and individual execution attempts. They relate to one another, but they do not become an undifferentiated activity stream. A recovered run should still be the same attempt. A retry should be identifiable as a successor. Evidence needs stable anchors.

## Evidence is not surveillance

More records are not automatically better. An evidence model should collect what is necessary to understand the work, not turn private content into maintainer telemetry. Product diagnostics, customer-owned operational traces, and optional maintainer crash reporting have different purposes and should remain separate.

Local-first architecture helps: the detailed work trail can stay on the user’s device by default. When something must be shared for support, the safe path is a bounded diagnostic that excludes documents, credentials, tokens, and unrelated personal data.

An AI agent earns trust through behavior that can be inspected. Keeping the evidence in view does not eliminate judgment, but it gives people the material they need to exercise it.