DEV Community: dengyier

When an AI agent says 'I ran the tests and they passed' — do you trust it?

dengyier — Fri, 07 Aug 2026 18:59:19 +0000

This isn't a product pitch.

I'm genuinely stuck on a trust problem and I want to know how others think about it.

The scenario

You have a multi-agent setup. One agent writes code. Another runs tests. A third reviews the results.

Agent B says: "I ran the test suite. 247 passed, 0 failed."

Agent C asks: "How do I know you actually ran them?"

What happens next?

In most setups I've seen — nothing. Agent C just trusts Agent B.

Why this bothers me

We built agents to automate work. But we didn't build a way for agents to verify each other's claims.

When a human colleague says "I ran the tests," you can:

Check the CI pipeline
Look at the test report
Ask them to share the terminal output

When an agent says it... what do you check?

The agent's own log? That's the agent vouching for itself.

The middleware log? Now you're trusting the middleware, not the agent.

The CI pipeline? Only works if the agent actually triggered CI — and even then, you're trusting that the agent ran the right tests against the right code.

The deeper question

In a multi-agent system, who is the source of truth?

Not the agent — agents can hallucinate.

Not the middleware — middleware can be compromised.

Not the logs — logs can be truncated or tampered with.

I keep arriving at the same answer: the truth has to be cryptographically verifiable, not socially trusted.

But I'm not sure if that's overengineering.

What I'm thinking about

What if every agent tool call produced a signed receipt?

Not a log entry. A cryptographically signed receipt that binds:

Who authorized the call (role + key)
What was called (tool + parameters)
When it happened (timestamp within a freshness window)
What the result was (output digest)
What evidence was produced (patch, test report, manifest)

And what if an independent verifier could replay all those receipts offline — without touching the live system — and confirm the entire chain is internally consistent?

No trust required. Just math.

The part I'm unsure about

This sounds good in theory. But in practice:

Would developers actually adopt a protocol that adds signing overhead to every tool call?
Is SQLite sufficient as an authoritative ledger, or does this need distributed storage from day one?
Six roles (Manager, Developer, Verifier, Maintainer, Acceptor, Human) — is that real-world necessary or academic over-engineering?

I have opinions on all three. But I'm more interested in yours.

So here's my question

If you were building a multi-agent system tomorrow, would you rather:

A. Trust the agents and the middleware, and accept that verification is best-effort

B. Add a cryptographic layer that makes every tool call independently verifiable, at the cost of complexity

Or is there a C I'm not seeing?

I don't have a product to sell here. I've been prototyping this and I want to know if I'm solving a real problem or an imaginary one.

What would convince you to add verification to your agent pipeline?

Even if your answer is "nothing" — I want to hear it.

Agents can generate results — but on what authority do we accept delivery?

dengyier — Fri, 07 Aug 2026 18:48:44 +0000

30-Second Overview

MCP connects agents to tools. A2A connects agents to agents. AgentTeams orchestrates agent collaboration.

But when an agent says "I'm done," no existing layer answers:

What authorization backs this work?
Did every step stay within scope and quota?
Do tests, patches, and reports form a complete causal chain?
Who has the authority to accept or reject the outcome?
In a dispute, can a third party verify all the facts offline, without connecting to any party's system?

OpenWorkProof fills this gap: contracts, authorization, evidence, and acceptance for agent work.

It doesn't try to make agents smarter. It makes their work authorizable, constrainable,
verifiable, and acceptable — and rejectable when the evidence falls short.

A contrarian thesis: the primary bottleneck for multi-agent systems isn't model capability
— it's accountability, authority, evidence, and acceptance. Without these, agents can
generate results, but they can't become delegatable, auditable, billable production actors.

Why OpenWorkProof

Who Needs It

Role	Pain Point	What OpenWorkProof Provides
Agent platform / framework builders	Agents can call tools, but can't prove "this call was authorized"	Signed AgentRequest + PolicyDecision pre-authorization — every call carries machine-checkable authorization evidence
Enterprise IT / compliance teams	EU AI Act high-risk provisions require proof that agents are authorized, constrained, and auditable	Complete signed authorization chain, quota tracking, offline third-party verification for audit requirements
Multi-agent orchestrators	Delegated permissions can't decay or be held accountable	CapabilityGrant with atomic attenuation — child grants can only shrink, never expand
Delivery reviewers / acceptors	Agent claims completion but the causal link between tests, patches, and reports is opaque	Causal replay layer + policy replay layer + five-input offline verifier — the full evidence chain is reproducible
Dispute arbitrators	Need to review facts without connecting to any party's system	`validate_grant_chain` — pure offline signature verification, only needs the evidence bundle + public keys

Why Now

The market has turned. Gartner predicts 40% of enterprise software will embed AI agents
by end of 2026 (below 5% in 2025). The EU AI Act's high-risk provisions are already in effect
— organizations that can't prove their agents are "authorized, constrained, and auditable"
face real legal risk.

The space is being validated by capital. In H1 2026, over $65M was publicly raised in
the agent trust infrastructure category:

Project	Funding	Layer
Catena Labs	$48M (a16z-led)	Agent identity + payment protocol
GenLayer	$7.5M	Verifiable judgment + on-chain identity
OpenBox AI	$5M	Runtime governance (identity/authorization)
t54 Labs	$5M (Franklin Templeton / Ripple)	Agent financial trust layer

These projects solve "who is acting" and "how money moves" — the identity and payment layers.

OpenWorkProof solves the layer they all leave untouched: what authority backs this work,
why the process is trustworthy, and what makes the outcome acceptable — the work-contract layer.
The two are complementary, not competitive.

An analogy: OAuth defined "how humans authorize apps," spawning a $10B+ market
(Okta / Auth0). OpenWorkProof defines "how humans authorize agent work and accept results."

Core Principles

Proof-Carrying Work: actions must carry machine-checkable authorization and result evidence
No-Cloning Authority: child grants can only attenuate or consume — never replicate equivalent or greater permissions
Multi-Scale Proof Composition: local credentials can only form an acceptable global proof when causality, evidence dimensions, correlation disclosure, and global conditions are simultaneously satisfied
Fail Closed: unverifiable permissions, signatures, history, state, or evidence must never resolve as success
Offline Third-Party Verification: validate_grant_chain enables third parties to verify the entire signed authorization history without connecting to any party's system

I built a protocol so AI agents can't just say 'trust me'

dengyier — Fri, 07 Aug 2026 14:03:53 +0000

A few months ago I was wiring up a multi-agent pipeline where one agent writes code, another reviews it, and a third deploys it. Everything worked great in the demo.

Then I asked a simple question: if the review agent says "looks good," how do I actually know it ran the tests?

I couldn't answer it. Neither could MCP, A2A, or any framework I looked at.

The gap nobody talks about

MCP connects agents to tools. A2A connects agents to agents. These solve connectivity. But connectivity isn't accountability.

When agent #2 says "I verified the patch," there's no protocol-level way to answer:

Was this action authorized, or did the agent just decide to do it?
Is there a causal chain from the patch to the test results?
Can a third party replay the evidence without trusting any participant?

What I built

OpenWorkProof is a protocol layer (not a framework) that adds three things to agent work:

1. Signed authorization before execution

Every tool call carries a PolicyDecision — a machine-checkable proof that this specific action was authorized, within quota, and within scope:

from openworkproof import policy

auth_ctx = policy.derive_authorization_context(
    work_order=work_order, grants=grants, receipts=receipts,
    request=signed_request, arguments=args,
    execution_facts=facts, checkpoint=checkpoint,
)
decision = policy.authorize_tool_call(auth_ctx)
# decision.allowed == False → don't execute, produce deny receipt

2. Evidence chain with causal integrity

Every action produces an ActionReceipt that binds the authorization decision, quota changes, and evidence references. The causal graph enforces exact parent sets — you can't skip steps or fabricate history.

3. Offline third-party verification

This is the part I'm most proud of. Any third party can verify the entire evidence chain with just the evidence bundle and public keys — no connection to any live system needed:

from openworkproof.acceptance import verify_acceptance_bundle

result = verify_acceptance_bundle(
    work_order=work_order, report=report,
    effective_grants=grants, receipts=receipts,
    committed_evidence=evidence,
    acceptance_receipt=signed, public_keys=keys,
)
# Pure function. Zero I/O. Fully deterministic.

How it works in practice

Six roles, each with their own Ed25519 keypair:

Role	What they do
Maintainer	Creates the WorkOrder, issues root grant
Manager	Issues scoped child grants, composes proofs
Developer	Executes authorized tool calls
Verifier	Independently re-runs tests
Sidecar	Assigns trusted execution facts
Acceptor	Signs final accept/reject (external key)

State flow: running → locally_verified → proof_ready → awaiting_human → accepted

Real bugs, real validation

I tested this against two real open-source issues:

Rich #4196 — a terminal formatting library bug. Full 9-step evidence chain from WorkOrder to offline verification.
Dify #33013 — a TypeError in Dify's QuestionClassifierNode. Same protocol, different project type. Proved it's not tied to one kind of codebase.

Both end-to-end demos pass: 2,283 tests, 0 failures.

Try it

pip install openworkproof

Source: https://github.com/dengyier/OpenWorkProof

Honest limitations

This is v1.0. The protocol core is solid, but:

Only repo_read, apply_patch, and run_tests have full handler implementations — other tool calls need handler closures
No formal security audit yet
The "Sidecar" role currently requires manual execution-fact assignment

I'm not claiming this is production-ready for your enterprise. I'm claiming the protocol design is sound and the implementation proves it.

What's next

Looking for feedback on:

Does the 6-role model map to your multi-agent setup?
Is offline verification actually useful for your compliance needs?
What tool call handlers would you need first?

Issues and discussions welcome on GitHub.