AI Agent Observability Is Not Enough. You Need an Evidence Plane.

Varun Pratap Bhardwaj presenting the Evidence Plane reference architecture

Six months after an AI agent approves a refund, changes a repository, or produces a board report, can you prove what happened?

Not reconstruct it from chat history. Not ask the developer who built the prompt. Prove which model and configuration ran, which instructions were active, which passages supported each claim, which authority allowed the action, which evaluator approved it, and which artifact reached production.

Most agent stacks cannot answer that set of questions. They may have excellent tracing. You can see the latency, tokens, model calls, retrieval spans and tool invocations. That telemetry helps diagnose a slow or failed run. It does not prove that the run deserved to succeed.

Production agent systems need another architectural layer alongside the data plane and control plane. They need an evidence plane.

The evidence plane binds a run to its behavioural inputs, sources, delegated authority, policy decisions, evaluations, deployable artifacts and observed outcome. Its output is a decision-shaped receipt that another person or system can inspect without trusting the producing agent's narration.

I am calling this layer the Evidence Plane. The name and receipt contract are an architectural synthesis, not an existing industry standard. The mechanisms underneath them are established patterns: structured telemetry, delegated authorization, policy enforcement, artifact provenance, independent evaluation and admission control.

Logs are telemetry, not evidence

Consider a trace that says:

search -> open -> read -> answer

Useful. We know the agent used retrieval and produced a response.

Now ask the evidence questions:

Which exact document version did it read?
Which passage supports which claim?
Did the cited passage entail the claim, or merely mention the topic?
Which prompt, skill bundle and tool contract shaped the answer?
Did a separately versioned evaluator check the result?
Could the producing agent modify the record used to judge it?

A trace database may contain enough raw material to investigate those questions. That does not make the trace an evidence system. Evidence needs stable identities, explicit relationships and a schema shaped around the decision somebody must defend later. OpenTelemetry's GenAI conventions already define structured fields for provider identity and retrieved documents; an evidence plane links those observations to the claim, decision and outcome they are meant to support. (OpenTelemetry GenAI attributes)

Software systems already make this distinction. Application logs tell an operator that a payment request ran. A payment ledger records what was committed. Distributed traces show which services participated. An authorization decision records why access was allowed. A software attestation binds a deployed artifact to a build and verification path.

Agents need the same separation. Observability explains execution. Evidence supports belief and accountability.

The three-plane architecture

An agent architecture becomes easier to reason about when its responsibilities are separated into three planes.

The data plane performs the work. It runs model inference, retrieves documents, calls tools and produces side effects.

The control plane decides how the work should run. It selects models, routes requests, applies budgets, schedules retries, evaluates policy and terminates loops.

The evidence plane records and binds the facts needed to evaluate the run. It resolves the versioned manifest, collects source provenance, records policy decisions, invokes independent evaluation, tracks artifact lineage and emits the final receipt.

The three-plane architecture for production AI agents

The evidence plane should not be another tool the producing agent can rewrite freely. It needs separation of duties. A worker may submit a proposal and its supporting material. A policy decision point decides whether the requested action fits the grant. An evaluator judges the proposal against a versioned contract. A receipt writer records the outcome through an append-only or tamper-evident path appropriate to the system's risk.

That does not mean every receipt belongs on a blockchain or in a new database. A transactional outbox feeding an access-controlled event store may be enough. Content-addressed objects in existing storage may be enough. The design requirement is simpler: the producing agent must not be able to manufacture its own approval or silently replace the artifacts that approval referred to.

The minimum useful run receipt

An evidence plane needs a contract. Here is a compact TypeScript shape for one production run:

type RunReceipt = {
  schemaVersion: "1.0";
  runId: string;
  purpose: string;
  initiatedAt: string;

  subject: {
    principalId: string;
    agentId: string;
    workloadId: string;
    delegationId: string;
    grantedScopes: string[];
  };

  manifest: {
    modelProvider: string;
    modelId: string;
    modelConfigHash: string;
    systemPromptHash: string;
    skillBundleHash: string;
    toolContractHash: string;
  };

  sources: Array<{
    uri: string;
    retrievedAt: string;
    contentDigest: string;
    passageRefs: string[];
    supportedClaimIds: string[];
  }>;

  policyDecisions: Array<{
    action: string;
    target: string;
    decision: "allow" | "deny" | "require_review";
    policyVersion: string;
  }>;

  evaluations: Array<{
    suiteId: string;
    suiteVersion: string;
    evaluatorId: string;
    independentFromProducer: boolean;
    verdict: "pass" | "fail" | "review";
  }>;

  outcome: {
    status: "committed" | "rejected" | "compensated";
    artifactDigest?: string;
    terminationReason: string;
    tokenCost: number;
  };
};

Four details do most of the architectural work.

First, the manifest identifies every input that can change behaviour. A model name is not enough. A different system prompt, skill bundle, tool schema, decoding configuration or safety wrapper can change the agent even when the model identifier stays fixed.

Second, sources are bound to claims at passage level. Saving a homepage URL does not prove that the page supports the sentence. The receipt needs a content digest, retrieval time and the passage references that sponsor specific claims.

Third, the human principal and software actor remain separate. The user may initiate a task, but the agent performs the action. A delegated grant should preserve both identities and narrow the allowed scope as work passes to another service or agent.

Fourth, the outcome records the artifact that actually escaped the system. A proposal can pass evaluation and still fail during commit. A model can pass before conversion and change after quantization. The receipt must identify the committed output or deployed artifact, not only the ancestor that entered the pipeline.

Receipts should not become a second privacy incident. Raw prompts, personal data and confidential documents may not belong in a broadly available audit store. Store digests and access-controlled pointers when duplication would widen exposure. Integrity proves that captured material has not changed. It does not prove that the material was true.

One run, one linked chain of custody

Do not wait for incident review to assemble the receipt. Build it while the run still has the identities, source coordinates and policy decisions in hand.

One run producing a linked chain of evidence

The sequence begins with intent. The system resolves a versioned manifest before model execution. An authority service exchanges the initiating identity for a short-lived, scoped grant. Retrieval produces source digests and claim-to-passage mappings. The agent produces a proposal rather than an irreversible side effect. Independent checks evaluate source support, behaviour and policy. Only then does the system commit.

The rejection path matters as much as the happy path. A failed source check, behavioural contract or policy decision should create a rejection receipt with the same identifiers as an approved run. Otherwise failures disappear into logs while only successes become durable records.

The outcome path also needs a compensation state. Some operations succeed remotely and fail locally, or commit before the receipt writer observes the response. An idempotency key and a transactional-outbox pattern can keep the side effect and evidence event tied together. Where compensation is impossible, the authorization and human-review gate must move before the irreversible action.

Five boundaries where evidence breaks

I am not proposing one more platform that must own the whole stack. The Evidence Plane is a set of contracts at boundaries where an AI result can lose its meaning.

Evaluation boundary: protect the test from the producer

Google DeepMind, MLCommons, Singapore AISI, OpenMined and AVERI recently described a double-blind evaluation pilot. The evaluator could keep private benchmark prompts hidden from the model owner while the model owner kept proprietary weights hidden from the evaluator inside a hardware-protected environment. The mechanism addresses a real conflict: confidential tests are less useful when model providers can see and optimize against them, while evaluators may not be trusted with frontier weights. (Google DeepMind · MLCommons)

The Evidence Plane does not require this infrastructure for every application. It does require the same separation. Keep hidden evaluation partitions away from the prompt-authoring loop. Version the suite. Record the exact candidate that ran. Use an evaluator that cannot rewrite the producer's output or the test.

Transformation boundary: certify what you deploy

A new paper on quantization-triggered backdoors reports models that passed the authors' source-precision checks but activated targeted behaviour after lower-precision compression. This is a new, paper-reported result and has not been independently replicated. Its architecture lesson does not depend on treating the reported effect size as settled: validation attached to a source checkpoint does not automatically attach to every transformed artifact derived from it. (paper)

Quantization, adapter merging, format conversion, runtime wrapping and safety layers all produce new behavioural candidates. Assign each one a digest. Run the required regression, security and behavioural gates against the object that will ship.

Retrieval boundary: bind claims to passages

Mistral's documented Agentic Search interface exposes search, open, navigate, read and grep operations. The mechanism lets an agent move beyond initial retrieved chunks and inspect a long document or several sources before answering. Mistral's performance figures remain vendor-reported; the useful architecture is the inspectable search path. (Mistral · Search Toolkit)

Record that path without confusing activity with proof. The receipt should preserve which passages support which claims, plus enough document identity to detect later change. An agent can search extensively and still cherry-pick. A separately evaluated claim-to-passage mapping is the enforcement gate.

Authority boundary: preserve the principal and the actor

NIST recommends treating agents as distinct entities with their own identifiers, credentials and entitlements bound to the user or system operating them. Microsoft and AWS documentation make the same separation concrete through user-delegated, workload, application and agent identity patterns. OAuth Token Exchange supplies the underlying impersonation and delegation vocabulary, including the actor involved in a delegated chain. (NIST · Microsoft · AWS · RFC 8693)

Do not hand an agent a human session and call it delegation. Exchange the initiating identity for a scoped, short-lived grant that names the software actor. Enforce the grant at the tool or resource boundary. Record the policy version and decision in the receipt.

Supplier boundary: portability requires behavioural proof

A router can change model providers without changing application code. That does not prove that the workflow remained behaviourally equivalent.

Prompts, tool calling, refusal behaviour, structured output and context handling can differ across providers. A fallback should receive production traffic only after the same acceptance contract passes on the candidate provider. The Evidence Plane binds each routing decision to the manifest and evaluation result used to authorize promotion.

Provider libraries such as Vercel's AI SDK standardize the interface used to call different models. MCP standardizes another boundary: how hosts, clients and servers connect tools and context. Both are useful interface contracts. Neither proves two providers will make the same decision under the same agent policy. (Vercel AI SDK provider architecture · MCP architecture)

A safe execution skeleton

The runtime pattern is preview, authorize, then commit:

const manifest = await registry.resolve({
  prompt: "refund-agent@7",
  skills: ["refund-policy@12"],
  tools: ["payments@4"],
  model: "approved-primary"
});

const grant = await authority.exchange(userToken, {
  actor: "refund-agent",
  scopes: ["orders:read", "refunds:propose"],
  expiresIn: "10m"
});

const proposal = await agent.plan(input, { manifest, grant });

const sourceCheck = await evidence.verifyClaimSupport(proposal.claims);
const behaviorCheck = await evaluator.run("refund-contract@9", proposal);
const policy = await policyEngine.authorize(proposal, grant);

if (!sourceCheck.pass || !behaviorCheck.pass || policy !== "allow") {
  return receipts.reject({ proposal, sourceCheck, behaviorCheck, policy });
}

const result = await payments.commit(proposal.action, {
  idempotencyKey: proposal.id
});

return receipts.commit({ manifest, grant, proposal, result });

plan() is not a magical rollback mechanism. The tool adapter must support a non-mutating proposal or preview contract. If the downstream system cannot preview, reserve the authority decision and human review for the last point before the side effect. If the operation can be compensated, record the compensation owner and result rather than pretending the first commit disappeared.

The evaluator also needs independence by design. A different model name is not enough when producer and judge share prompts, context, tools or training lineage. Give the evaluator only the evidence and criteria it needs. Remove write tools. Keep the contract version separate from the proposal. Escalate correlated uncertainty instead of averaging it into confidence.

Certification follows the artifact

An AI artifact usually changes several times between a research checkpoint and production:

base checkpoint -> adapter merge -> quantization -> runtime wrapper
                -> container image -> production alias

Every arrow creates a new identity.

Certification must follow the exact deployable AI artifact

The invalid shortcut is common: test the base checkpoint, transform it several times, and let the original pass follow the descendants. A trustworthy promotion path attaches regression, security and behavioural results to the exact deployable digest. The production alias moves only after that candidate passes. SLSA provenance provides useful vocabulary for binding an attestation to the artifact that was built, the materials and the build process. It does not certify AI behaviour by itself; the behavioural gate remains a separate requirement. (SLSA provenance)

The same rule applies above the model. Changing a system prompt, skill bundle, tool contract or provider fallback creates a new behavioural manifest even when the container image remains unchanged. The Evidence Plane gives that manifest a stable identity and makes promotion conditional on the required gates.

Failure modes to design against

Failure	Weak implementation	Required control
Benchmark leakage	Prompt author sees every test	Hidden partition and separate evaluator
Self-grading	Producer emits its own pass	Independent gate without write tools
Prompt or skill drift	Store only the model name	Version or hash all behavioural inputs
Citation laundering	Save a source homepage	Bind claims to passages and content digests
Human credential reuse	Agent uses the user's session	Distinct workload identity and delegated scope
Silent failover	Router changes provider	Acceptance contract before traffic promotion
Post-test mutation	Quantize after certification	Re-certify the deployable artifact
Audit-log archaeology	Store every trace event	Decision-shaped receipt with a stable schema

Build the smallest useful Evidence Plane on Monday

Start with one consequential workflow, not an enterprise platform programme.

Freeze a versioned manifest containing the model configuration, prompt, skills and tool contracts. Add one pre-commit gate for the failure that would matter most. Record one outcome object tied to the proposed action and exact artifact. Then reconstruct the run without opening chat history or asking the developer what happened.

If reconstruction requires three dashboards and one person's memory, the workflow still has telemetry rather than evidence.

Qualixar implements parts of this pattern in separate tools. AgentAssert defines behavioural contracts and independent gates. bounded-loops supplies budgets, termination rules and evidence-bearing completion for iterative work. SuperLocalMemory provides scoped state, provenance and durable reconstruction across runs.

These tools are reference implementations of parts of the architecture. The larger design remains vendor-neutral: identify every behaviour-changing input, bind every consequential decision to evidence, and make the producing agent unable to approve its own work.

Issue #13 of the AI Reliability Engineering newsletter tracks the research and releases that forced this architecture into view, including double-blind evaluation, transformed-model failures, agent identity, evidence-aware retrieval and governed skills.

The newsletter is the field report. This is the architecture it points toward.