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

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:

1. Rich #4196 — a terminal formatting library bug. Full 9-step evidence chain from WorkOrder to offline verification.
2. 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.