DEV Community

Arun KT
Arun KT

Posted on

My AI agents kept re-verifying the same work. So I made verification a signed, reusable object

#ai #opensource #agents #webdev

Here's a pattern I kept hitting while running a small fleet of agents:

Agent A needs market data. It finds a paid API, checks that the endpoint is alive, checks the price, makes the call. Twenty minutes later Agent B needs market data. It finds the same API… and checks that the endpoint is alive, checks the price. Same check, same result, new tokens, new latency, new cost. Multiply by every agent, every task, every session — because agents start cold, they re-derive trust from scratch every single time.

Humans solved this ages ago. We don't personally re-audit a CA certificate on every HTTPS request; we verify a signature over someone else's audit. Agents have no equivalent. Every agent is its own tiny, wasteful certificate authority.

Verification as an object, not an act

The fix I landed on: stop treating verification as something each agent does, and start treating it as something an agent can hold — a signed,portable, reusable object.

Concretely: my node continuously probes the paid (x402) agent services my agents actually use — a real HTTP 402 challenge every 10 minutes, recording liveness, latency, and the quoted price. Each probe is published as an attestation:

{
  "payload": {
    "type": "erabi.x402.probe/0.1",
    "slug": "exa-search",
    "ts": "{{ts}}",
    "alive": true,
    "http_status": 402,
    "latency_ms": {{latency}},
    "price_usd": {{price}},
    "window_24h": { "probes": {{probes}}, "uptime_pct": {{uptime}} }
  },
  "sig": "ed25519:…",
  "key": "…"
}
Enter fullscreen mode Exit fullscreen mode

The signature is a detached ed25519 over the canonicalized payload (RFC 8785), verifiable against the node's published key. An agent that wants to know "is this API worth paying?" fetches this, verifies one signature, and moves on. No probe, no burned call, no re-derived trust:

curl https://erabi-production.up.railway.app/index/v1/services/exa-search/attestation
Enter fullscreen mode Exit fullscreen mode

What {{N_days}} days of not re-verifying looks like

The index currently covers 16 real pay-per-call services (search,
browser automation, market data, inference…). Some things the data
already surfaced:

  • {{finding_1 — e.g. "a service listed as live on the x402 Bazaar has been dead for the entire measurement window"}}
  • {{finding_2 — e.g. "p50 latencies differ by 8x between services at the same price point"}}
  • {{finding_3 — e.g. "one service silently changed its quoted price mid-week — the attestation history caught it"}}

Everything is public: the human view at
https://erabi-explorer.vercel.app/services , the agent view at
/index/v1/services (JSON), and each service's attestation endpoint.

The bigger point

"Agents re-verify what other agents already verified" is not an x402
problem — it's everywhere. Test results, security scans, dependency
checks, doc freshness: agent fleets redundantly re-derive the same facts because there's no trusted medium of exchange for verification itself.

Signed attestations are that medium. Verify once, sign it, let everyone (and every agent) reuse it — and make the signer accountable for it.

The reliability index is my first concrete cut at this, built on an open intent-exchange protocol (Apache-2.0, https://github.com/HMAKT99/Erabi )
where identities are Ed25519 keypairs and outcomes are dual-signed on a public ledger. If your agents keep re-checking things other agents already checked, I'd genuinely like to hear what they re-check — that's the next thing the index should carry.

Top comments (1)

Collapse
 
jugeni profile image
Mike Czerwinski •

The CA analogy carries one more step than you pushed it: what makes a CA reusable is not the signature, it is that the signer has nothing riding on the answer. A service's own status page is also a signed attestation; nobody accepts it as verification, because signer and subject are the same party. Your index works because the prober is a third party that can be caught: anyone can re-run the 402 challenge and diff against the published number.

So the property I would write into the spec is falsifiable-by-replay, not just signed. Ship the probe recipe inside the attestation. A signature proves who said it; a replay proves it could have been true. The day your index has competitors, that is the difference between an audit and a reputation.

To your closing question: the fact my agents keep re-deriving is "has this source changed since I captured it". A decision store full of clipped facts rots quietly as the sources move. A content-hash-at-timestamp attestation over cited sources would retire a whole class of re-reads.