The local verification buyer's guide

"Local-first" matters more when AI agents start changing real work. The question is no longer only where your notes or records live. It is where the evidence for agent-authored work lives, who can inspect it, and whether a result can be checked without trusting a hosted dashboard.

This guide is for teams evaluating verification systems around AI agents.

What local verification should mean

A local verification system should give you three things:

1. The proof is yours. Attempts, artifacts, command output, screenshots, diffs, and receipts live in files or infrastructure you control.
2. The result is inspectable. A reviewer can see what the agent claimed, what changed, what checks ran, what passed, what failed, and what could not be checked.
3. The system works without trusting the agent. The completion claim and the verification decision are separate.

If one of those is missing, you may have an agent dashboard, but you do not have a verification system.

The questions to ask a vendor

1. Where do receipts live?

Ask where the durable record of each attempt and result is stored. A good answer names the local path, database, artifact store, or self-hosted service. A weak answer points only to the vendor's hosted activity feed.

2. Can the evidence be inspected outside the app?

Receipts should preserve enough structure that your team can audit them later. That means command names, exit codes, relevant logs, changed files, artifact references, timestamps, and reviewer decisions.

Screenshots and summaries are useful, but they should not replace raw proof when raw proof exists.

3. Is verification separate from the agent?

The agent can explain what it did. It should not be the only authority on whether the work is done.

Look for a verification step that can run tests, inspect diffs, check browser behavior, read CI, observe deployments, and preserve uncertainty when it cannot decide.

4. What happens offline?

Local verification should still let you inspect prior attempts and receipts without a network. Some evidence sources need network access, such as hosted CI or deployment logs, but the local result history should not disappear when a vendor service is down.

5. How do you leave?

Ask how to export attempts, evidence, and receipts. If leaving means screenshots, CSV fragments, or a support ticket, the proof trail is not really yours.

Red flags

• The system stores only chat transcripts.
• The agent's final message is treated as the result.
• CI status is shown without the command, commit, branch, or relevant output.
• Failed attempts are overwritten by retries.
• Screenshots exist but are not tied to the task, route, viewport, or result.
• Prompt or model changes are promoted without held-out comparison.
• Export gives you summaries but not evidence references.

How Excellent answers these

Excellent is built around attempts, checks, evidence, results, and receipts:

• It runs beside the agent and model you choose.
• It records what was requested, what the agent claimed, and what changed.
• It attaches proof from commands, browser checks, CI, deployments, diffs, and reviewer notes.
• It returns failed work with the exact evidence that failed.
• It keeps accepted results as receipts you can open later. Receipts stay on the machine that produced them and do not sync between teammates yet.
• It compares agent setup changes on held-out tasks before promotion.

You should not have to trust our marketing page for that. The docs and receipts should be the proof.

What this guide is, and is not

This is not a vendor ranking. It is a checklist for deciding whether a system can verify agent work in a way your team can audit.

The right tool depends on your workflow. The floor should be simple: the agent does the work, verification checks the work, and the evidence stays inspectable.