DEV Community

dengyier
dengyier

Posted on

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

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

Top comments (2)

Collapse
 
deanlee profile image
Dean Lee

The useful boundary is acceptance, not completion. A patch, report, or agent run should ship with the claim it is making, the authority it used, and the evidence that would falsify it. Otherwise the buyer is just purchasing confidence from a black box.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.