AI Evidence in Action

An agent can act. A person can see what happened. The evidence can be independently verified.

Comment

Inspiration

AI agents are starting to do things on the web, not just read it. That raises a question I kept coming back to: if an agent says an action succeeded, what does the person supervising it actually have to work with?

A chat message that says “done” is not the same thing as evidence. And if another source disagrees, I do not want the system to guess which one is right.

That is the idea behind AI Evidence in Action.

The demo uses a synthetic refund because it is easy to understand, but the real subject is human supervision of AI actions on the web.

What it does

The page exposes four WebMCP tools:

  • request_refund
  • get_evidence
  • compare_evidence
  • verify_evidence

An agent can use those tools directly in the same application the human is watching. As the agent works, the page shows the tool-call timeline, what the demo site reported, what the demo destination reported, where the records match or conflict, and what verification can and cannot establish.

There are three bounded outcomes:

  • AGREEMENT
  • DISAGREEMENT
  • INSUFFICIENT EVIDENCE

The demo never guesses which source is correct.

The records are signed with standard Ed25519 public-key cryptography over SHA-256 commitments. The verifier checks the signatures, makes sure the two records actually belong to the same claim, and then independently recomputes the whole comparison.

There is also a Test tamper detection control. It makes a throwaway copy of the evidence, changes one comparison value, leaves the signed records untouched, and runs that altered copy through the real verifier. The verifier rejects the changed copy while the original evidence remains verified.

Everything in the challenge scenario is synthetic. Both demo sources are operated in the same deployment by the same demonstration operator, and the page says that plainly. The signatures establish integrity and demo-key attribution; they do not prove that a real-world refund happened.

Why WebMCP fits this use case

What interested me about WebMCP is that the agent does not need a separate hidden integration or an API console that the human never sees. The webpage itself can expose bounded tools through document.modelContext, and the agent can act through the same application state the human is supervising.

That creates a much better interaction model for this problem.

The agent can act, but the person can still see the evidence appear, inspect the source records, follow the comparison, and take over if needed. The application does not ask the human to re-enter information it already learned from earlier tool calls.

For this demo, the useful pattern is simple:

act → record → compare → verify

Without WebMCP, I could still build an API behind the page, but the important part of this project would be missing: the shared surface between the human, the agent, and the website.

How I built it

I kept the project deliberately small and public-safe: vanilla JavaScript, HTML, and CSS in the browser, a Netlify function for the synthetic signed records, and a standalone Node.js verifier that can check a downloaded evidence bundle without contacting the site.

The WebMCP tools are registered directly with document.modelContext.registerTool(...). I tested the final implementation in Chrome for Testing 152 with WebMCP enabled. All four tools were registered, discovered, and executed through the native WebMCP runtime.

The evidence verifier checks three separate things:

  1. Integrity — recompute the SHA-256 commitment and verify each Ed25519 signature against the published demo public keys.
  2. Pairing — require the signed claim_id, request_id, and scenario to match before two records can be compared.
  3. Comparison consistency — recompute the complete comparison from the verified records and compare it with what was recorded.

The final build has 162 automated tests, including browser-facing tests for the shared evidence flow, mobile layout, pair-splice rejection, full-comparison tamper detection, and the local tamper demonstration.

Challenges I ran into

I am not a coder by background, so a big part of this project was learning where a convincing demo can accidentally claim more than it proves.

The hardest part was not getting an agent to call a tool. It was defining the evidence honestly.

A website saying “success” does not prove an external outcome. A valid signature does not make the signed statement true. A missing second record does not mean failure. And two individually valid records do not belong together just because they both have valid signatures.

Those distinctions led to several changes during the build. I added explicit pair binding, made the comparison independently recomputable, and treated missing evidence as its own result instead of forcing it into success or failure.

One of the most useful tests came late in the project. I took two genuinely production-signed records from different claims and combined them. Every signature was valid, but the verifier still refused the pair as CLAIM_PAIR_MISMATCH. That was exactly the behavior I wanted.

Accomplishments I’m proud of

I am proudest of the fact that disagreement is visible rather than smoothed over.

In the main demo, the site can report SUCCESS_DECLARED while the destination reports ACTION_ABSENT. The page shows that specific mismatch to both the human and the agent instead of turning it into a confidence score or pretending to know which source is right.

I also like that the verification is not trapped inside the originating page. A person can download the evidence bundle and the verifier and check it again offline using only the published public keys.

The tamper test is another part I am glad we added. The recorded and recomputed verdict can remain exactly the same, but changing a lower-level comparison value is still detected. That makes the verification claim much more concrete than simply saying “the signatures are valid.”

What I learned

WebMCP makes the webpage itself a useful shared workspace between a person and an AI agent.

The bigger lesson for me is that agent UX should not stop at “the agent completed the task.” As agents take more consequential actions, people need to be able to see what happened, see what the available evidence actually supports, and distinguish that from what remains unknown.

Uncertainty needs an honest result too. Sometimes the right answer really is INSUFFICIENT EVIDENCE.

What’s next

This challenge project is intentionally narrow. The scenario is simulated; the evidence workflow is real.

The interaction pattern is what I want to keep exploring: a human and an agent working in the same application, with visible evidence that can be checked independently instead of simply trusted.

The agent can act. The human can see what happened. And the evidence can be independently verified.

Built With

Share this project:

Updates

Submission history