DEV Community: dengyier

The Biggest Barrier to Enterprise AI Agents Is Not Intelligence. It Is Delegation.

dengyier — Tue, 25 Aug 2026 07:11:33 +0000

An AI agent can now read a repository, modify code, run tests, prepare a release, update a ticket, and explain what it did.

That is already enough intelligence to complete a surprising amount of useful work.

Yet many companies still stop at the same boundary:

We are willing to let the agent assist. We are not yet willing to let it own the task.

The usual explanation is that the model needs to become more accurate. Sometimes that is true. But accuracy is no longer the whole problem.

The deeper barrier is delegation.

Can the company prove who assigned the work? What authority was granted? Which actions were forbidden? What actually happened? Which evidence supports the result? Who independently checked it? Who has the right to accept or reject the delivery?

If those questions are answered only by a chat transcript, a dashboard, or the agent's own summary, the organization has not delegated the work. It has created a new form of supervision.

Intelligence and delegation are different capabilities

Intelligence answers questions such as:

Can the agent understand the task?
Can it plan a sequence of actions?
Can it use the required tools?
Can it recover from ordinary errors?
Can it produce a useful result?

Delegation answers a different set of questions:

Who had the authority to assign this task?
What exactly was the agent permitted to do?
Which version of the task and policy governed the execution?
Can another party reconstruct what actually ran?
Who verifies the evidence?
Who accepts the commercial result?
What happens when the parties disagree?

A more capable model improves the first list. It does not automatically solve the second.

In fact, increasing capability can make the delegation problem more expensive. An agent that can only draft text has a small blast radius. An agent that can change production systems, commit code, approve invoices, contact customers, or purchase services creates a much larger one.

The more useful the agent becomes, the more important its authority boundary becomes.

Delegation is a contract, not a prompt

A prompt describes an intention. A delegation establishes an accountable relationship.

"Fix the checkout bug" is an intention.

A real delegation needs more structure:

the repository, issue, and acceptance criteria;
the tools and resources the agent may use;
the time, cost, and operational limits;
the actions reserved for human approval;
the evidence required for completion;
the party responsible for verification;
the party authorized to accept the delivery.

This does not mean every agent task needs a legal document. It means consequential work needs a machine-readable agreement that the runtime can enforce and another party can inspect.

Without that agreement, the organization is forced to rely on interpretation:

the manager interprets what the request meant;
the agent interprets which actions were allowed;
the operator interprets the agent's summary;
the customer interprets whether the result counts as complete;
the auditor reconstructs the event after the fact.

Every interpretation adds cost. Every missing boundary creates a future dispute.

The hidden cost is not execution. It is verification.

Agent economics are often presented as a comparison between machine time and human labor.

That comparison is incomplete.

The real cost of delegated work includes:

execution
+ supervision
+ evidence collection
+ result verification
+ exception handling
+ dispute resolution

An agent may complete a task in five minutes, while a senior engineer spends forty minutes reconstructing what changed and deciding whether the result is safe to accept.

The execution is cheap. The verification is expensive.

This is why a successful demo may not become a production workflow. The demo proves the agent can act. The enterprise still needs to know whether the action was authorized, whether the evidence is complete, and whether the result satisfies the business agreement.

When those answers require manual reconstruction, the cost of trust rises with every task.

A concrete example: delegating a production fix

Imagine a company delegates a production defect to a coding agent.

The agent is permitted to:

read the repository;
modify files in a defined scope;
run approved tests;
prepare a release candidate.

It is not permitted to deploy directly to production.

The agent completes the patch and reports:

All tests passed. Release ready.

That statement is useful, but it is not enough to accept the work.

The company still needs to establish:

Was this agent assigned to the correct work order?
Was the patch produced within the granted repository and file scope?
Which commands and tests actually ran?
Were the observed outputs bound to this exact patch?
Did an independent verifier evaluate the relevant evidence?
Did the authorized business or technical owner accept this exact result?

Notice that these are not model-intelligence questions. They are delegation and delivery questions.

A stronger model may write a better patch. It still should not be allowed to define its own authority, verify its own claims, and accept its own delivery.

The minimum trustworthy delegation chain

For consequential agent work, the minimum chain looks like this:

Intended work
    -> authorized capability
    -> pre-execution policy decision
    -> signed action receipt
    -> independent verification
    -> explicit acceptance or rejection

Each stage answers a different question.

1. Intended work

What outcome was requested, under which constraints, and with which acceptance criteria?

2. Authorized capability

Who delegated which tools, resources, scope, budget, and duration to the agent?

3. Pre-execution policy decision

Was this exact action allowed at the moment before it ran?

4. Signed action receipt

What did the execution environment observe, and how is that record bound to the request, actor, evidence, and prior events?

5. Independent verification

Does the evidence support the required technical judgment, including honest UNKNOWN outcomes when the evidence is insufficient?

6. Explicit acceptance or rejection

Does the authorized recipient accept this delivery as satisfying the work agreement?

Combining these stages into one "success" flag destroys useful information. Technical verification is not commercial acceptance. Permission to use a tool is not permission to achieve any result by any method. A valid signature is not proof that the underlying judgment was correct.

Where MCP fits — and where it does not

MCP is important because it standardizes how models and agent applications connect to tools, data, and services. Its authorization specification addresses protected access at the transport layer, including OAuth-based flows and resource-bound tokens.

That solves a necessary problem: may this client access this protected server?

It does not, by itself, establish the full work agreement between the parties. A transport token does not necessarily answer:

Was this specific business task authorized?
Did the action remain inside the agreed work order?
What evidence proves the requested outcome?
Who independently verified the result?
Who accepted the delivery?

This is not a criticism of MCP. It is a separation of responsibilities.

MCP connects agents to capabilities. A verifiable work protocol can bind those capabilities to an accountable delegation and acceptance chain.

How OpenWorkProof models delegation

OpenWorkProof 1.3.0 represents the chain with explicit protocol objects:

WorkOrder
    -> CapabilityGrant
    -> PolicyDecision
    -> ActionReceipt
    -> VerificationDecision
    -> AcceptanceDecision

The names matter because they prevent several different claims from collapsing into one.

WorkOrder freezes the requested work and acceptance boundary.
CapabilityGrant delegates a limited capability to a named subject.
PolicyDecision records whether a proposed action was allowed before execution.
ActionReceipt binds observed execution to the request and causal history.
VerificationDecision records an independent judgment about the evidence.
AcceptanceDecision preserves the recipient's authority to accept or reject the delivery.

The Human Agency Profile further narrows which actions an agent may take autonomously and which decisions remain reserved for a person. It can reduce authority, but it cannot silently expand the underlying work order or capability grant.

The resulting bundles can be verified offline without private keys. That matters when the customer, vendor, marketplace, or auditor does not share the same platform database.

OpenWorkProof does not make the agent smarter. It makes the agent's work safer to delegate.

What enterprises are actually buying

Companies do not buy signatures, hashes, or state machines because those technologies are interesting.

They buy lower delegation risk.

More specifically, they may pay for the ability to:

move agents from advisory work into higher-value execution;
reduce senior review time spent reconstructing activity;
preserve a common evidence package across organizational boundaries;
distinguish authorization, execution, verification, and acceptance;
reject a delivery without losing the underlying record;
investigate disputes without trusting a single vendor's dashboard;
change agent providers without losing the verification format.

This is the commercial value of an open protocol layer. It lowers the cost of proving that delegated work stayed inside an agreed boundary.

It does not eliminate the need for judgment. It makes judgment easier to exercise and harder to rewrite after the fact.

The adoption test is simple

The best market question is not:

Would your company like more trustworthy AI?

Almost everyone will say yes, and the answer reveals very little.

A better question is:

Which valuable task are you refusing to delegate to an agent today because you cannot reliably authorize, inspect, verify, or accept the work?

That question identifies the boundary between an impressive assistant and an accountable worker.

The next question is even more practical:

What minimum evidence would let you cross that boundary?

For one company, the answer may be a signed record of tool calls and test outputs. For another, it may require independent verification, human approval at a specific transition, or a portable acceptance package shared with a customer.

Those differences should shape the protocol and the product. They should not be hidden behind a universal "Agent completed" status.

What this is not

OpenWorkProof is not an Agent OS, an observability dashboard, a payment custodian, or a legal-compliance certificate.

It does not prove that an organization has adopted the protocol, paid for a deployment, transferred liability, or satisfied a regulator. Those are separate claims requiring separate evidence.

The current goal is narrower and more useful:

Make an agent's delegated work independently verifiable from authorization through acceptance.

If that layer becomes interoperable, agent runtimes, marketplaces, enterprise workflows, and settlement systems can build on top of it without inventing a new trust format for every transaction.

The future of enterprise agents depends on permission to trust

The enterprise AI market will not be won only by the agent that reasons best.

It will also be shaped by the system that makes consequential work safe to assign, cheap to verify, and clear to accept.

Intelligence creates the capacity to act.

Delegation creates the permission to rely on that action.

The companies that solve both will move agents beyond demos and copilots. The companies that solve only intelligence will continue to produce increasingly capable systems surrounded by increasingly expensive human supervision.

If you are building or buying enterprise agents, I would value your answer to two questions:

What high-value task are you still unwilling to delegate?
What evidence would make you comfortable accepting the result?

Explore OpenWorkProof on GitHub

References

Series

Agent Autonomy Has a Missing Layer: Verifiable Human Authority
The More Autonomous AI Agents Become, the More Humans Need the Final Say
A Signed AI Agent Receipt Can Still Be Wrong
Human Control Cannot Be a Checkbox in an Autonomous Agent System
The Biggest Barrier to Enterprise AI Agents Is Not Intelligence. It Is Delegation.

Human Control Cannot Be a Checkbox in an Autonomous Agent System

dengyier — Mon, 24 Aug 2026 14:57:02 +0000

An AI agent prepares a production deployment.

It has changed twelve files, run several checks, and produced a confident summary. The interface now shows a green button:

Human approval required

The operator clicks Approve.

It looks like a human remained in control. But what did that click actually mean?

Did the operator see the exact patch? Were all required checks executed? Did the agent disclose what it could not measure? Was deployment still blocked before the click? Could the operator reject or narrow the action? Can anyone later prove which person approved which version under which authority?

If those questions have no reliable answer, the button is not a control boundary. It is a ceremony.

As AI agents move from generating text to changing code, sending messages, purchasing services, and operating business systems, this distinction becomes important:

A button is an interface. Authority is a property of the system.

The checkbox version of human oversight

Many agent products add a human approval step near a consequential action. This is often useful, but the design can become superficial.

The weak pattern looks like this:

the agent chooses the action and constructs its own explanation;
the system presents a compressed summary;
a person clicks approve or reject;
the application stores an ordinary event log;
the agent continues.

The person is present, but presence alone does not establish control.

The approval may be bundled across unrelated actions. The summary may omit uncertainty. The person may not be the party authorized to accept the risk. The action may already have started. The audit log may be editable by the same system that produced it. The approval may not be bound to the exact request that was executed.

This produces a dangerous ambiguity: the organization can say a human approved the action, while the human cannot prove what they were asked to approve.

Human authority needs five properties

Human control becomes operational only when the system preserves five properties.

1. A named authority

"A human" is not a role.

The system should identify who has the right to authorize a capability, who may execute work, who verifies evidence, and who accepts the result. These can be different people or systems.

This matters because the developer who built an agent should not automatically become the customer who accepts its delivery. Likewise, an agent should not be allowed to execute, verify, and accept its own work simply because all three steps can be automated.

NIST's AI Risk Management Framework calls for organizations to define and differentiate roles and responsibilities for human and AI configurations. That distinction is not paperwork. It determines whose decision is valid when the stakes are real.

2. A decision before execution

An approval that arrives after an irreversible action is an explanation, not authorization.

The control must be evaluated before the protected operation starts. If an action is reserved for human judgment, the handler should receive zero calls until the required decision exists.

This sounds obvious, yet asynchronous queues, retries, cached permissions, and race conditions can quietly turn "approve before execution" into "approve near execution."

A real boundary must survive concurrency. If a person revokes permission while the agent is preparing an action, the system must not use an earlier authorization check to cross the newly closed boundary.

3. Enough evidence to make the decision meaningful

An approval screen should not merely show what the agent claims happened. It should expose what was requested, what was observed, which checks ran, which checks did not run, and what remains uncertain.

This connects directly to the previous article in this series: a signed receipt can still describe the wrong measurement. A human cannot exercise meaningful judgment if not measured is displayed as nothing wrong.

The person needs an evidence surface, not a confidence surface.

4. An enforceable ability to refuse, narrow, or stop

Human authority is not the right to watch an autonomous system. It is the ability to change what happens next.

Depending on the context, that may include the ability to:

reject a proposed action;
reserve a category of decisions for human review;
narrow the tools or scope an agent may use;
revoke an active delegation;
replace it with a stricter one;
interrupt execution safely;
decline final acceptance even when technical verification passed.

Article 14 of the EU AI Act describes human oversight for high-risk systems in similarly operational terms. It includes understanding system limitations, remaining aware of automation bias, disregarding or reversing output, intervening, and stopping the system. This article is not a legal analysis, and a protocol implementation does not establish compliance. The useful design lesson is that oversight must affect system behavior.

5. A record that can be independently checked

When a dispute occurs, a screenshot of an approval page is weak evidence.

A stronger record binds the decision to the exact work order, request, evidence, actor, authority, and time. It should be possible for another party to verify that record without trusting the agent that performed the work or the platform that displayed the button.

This is especially important across organizations. A customer, contractor, marketplace, insurer, or auditor may not share the same database or trust the same operator.

A practical example: an agent preparing a deployment

Consider an agent assigned to fix a production defect.

The work order permits four operations:

read the repository;
apply a patch;
run tests;
deploy the approved release.

The technical capability grant also includes those four operations. A traditional permission system may conclude that the agent can perform all of them.

But the responsible human may want a narrower arrangement:

repository reads and tests can run autonomously;
applying a patch requires review;
production deployment always remains a human decision.

That means effective permission should not equal the broadest capability available. It should equal the intersection of three boundaries:

WorkOrder permission
AND CapabilityGrant delegation
AND the active human authority profile

If any layer denies the operation, the operation does not run.

This model avoids two common mistakes.

The first is treating one approval as permanent consent for every later action. The second is forcing a person to approve every harmless step, which creates alert fatigue and turns oversight into habitual clicking.

Good human control is selective. It gives agents room to operate inside a defined boundary and preserves human judgment at consequential transitions.

Why more approval prompts can create less control

The obvious response to agent risk is to add more prompts. But a system that asks for approval too often trains people to approve without reading.

The problem is not simply the number of human interactions. It is whether each interaction carries a real decision.

A useful approval should answer:

What exact action is proposed?
Which work order and authority does it belong to?
What evidence supports it?
What uncertainty remains?
What changes if I reject it?
Can the agent route around my decision?
Will this decision be verifiable later?

If the interface cannot answer those questions, adding another checkbox does not add another layer of governance.

How OpenWorkProof is approaching this boundary

OpenWorkProof 1.3.0 includes a Human Agency Profile v0.1. It is an open protocol capability for expressing which actions an agent may take autonomously and which decisions remain reserved for a person.

The current design has several concrete rules:

the profile is bound to one frozen work order;
the designated Acceptor signs the profile;
the profile can narrow existing authority but cannot expand the work order or capability grant;
a reserved action fails before the handler runs with AGENCY_HUMAN_DECISION_REQUIRED;
signed transitions can revoke or replace the active profile;
an appeal records a request for review but never restores permission by itself;
a private-key-free bundle can be verified offline.

Verification and acceptance also remain separate. A Verifier may establish that evidence satisfies a defined technical judgment. The WorkOrder-bound Acceptor still decides whether to accept or reject the delivery.

This is intentionally narrower than a general policy engine or an "Agent OS." It does not score employees, transfer legal liability, hold funds, or certify regulatory compliance. The repository also does not prove customer adoption or payment. Those are separate facts that require separate evidence.

The aim is simpler: make the human boundary explicit enough for software to enforce and another party to verify.

The business consequence is cheaper delegation

Companies do not need cryptography for its own sake. They need to delegate important work without losing the ability to understand, limit, reject, and audit what was done.

Weak human oversight raises the cost of delegation in several ways:

senior staff must manually reconstruct agent activity;
customers dispute what they approved;
teams cannot distinguish technical verification from business acceptance;
vendors and buyers keep separate, incompatible audit records;
organizations restrict agents to low-value tasks because higher-value delegation feels unsafe.

A verifiable authority boundary does not eliminate these risks. It makes the underlying decisions inspectable. That can reduce the cost of review and make cross-organization agent work easier to accept.

This is the commercial reason human agency belongs in the protocol rather than only in the user interface.

Human-centered AI needs machine-readable boundaries

Fei-Fei Li has described AI as a responsibility and warned, "If we give up agency, it would be a freefall."

That principle becomes more demanding when agents can act.

Keeping humans at the center cannot mean adding a person-shaped icon to an automated pipeline. It must mean preserving a person's ability to define the boundary, understand the evidence, refuse the action, revise the delegation, and independently prove the decision later.

The next generation of agent systems will not be judged only by what agents can do. It will also be judged by whether people can still say:

You may do this, but not that.
Stop here.
Show me the evidence.
I do not accept this result.
This is the exact decision I made.

That is not a checkbox. It is authority.

If you build agent runtimes, approval workflows, MCP servers, or enterprise automation, I would value your view on two questions:

Which agent actions should always remain reserved for a named human authority?
What evidence would you need before a human approval could be treated as a real control boundary?

A Signed AI Agent Receipt Can Still Be Wrong

dengyier — Mon, 24 Aug 2026 12:19:10 +0000

Your AI agent returns a signed receipt:

0 defects found.

The signature is valid. The receipt has not been altered. The agent was authorized to run the check.

The result can still be wrong.

Perhaps the scanner hit a rate limit and silently converted eleven failures into eleven empty results. Perhaps a watchdog inspected 8 machines and issued a conclusion about 68. Perhaps a database health check ran select 1 successfully while the application was failing because a required column did not exist.

In every case, the software can produce a well-formed result. It can even sign that result correctly. What it cannot prove is that it measured the claim the business thinks it measured.

That distinction is becoming one of the most important problems in agent infrastructure:

authentic receipt != adequate measurement
authorized action != correct conclusion
zero findings != complete inspection

A signature answers only part of the question

Cryptographic signatures are valuable. They can prove who signed an object and whether its contents changed after signing.

They do not prove:

that the check actually ran
that it reached the intended target
that it measured the right population
that the sample supports the claimed conclusion
that exceptions were not converted into zeros
that a passing control answered the business question

This is the difference between provenance integrity and measurement integrity.

Provenance integrity asks:

Who made this statement, and was the statement altered?

Measurement integrity asks:

What was actually observed, how much of the target was covered, and is the conclusion justified by that observation?

An agent work protocol needs both. Otherwise, a signature can turn uncertainty into durable false confidence.

Three failures with the same shape

This article grew out of a thoughtful comment from Heinrich Neb on the first article in this series.

He described three incidents from one week.

First, a harvesting tool scanned 16 public repositories. Five returned hundreds of results. Eleven returned zero because the tool hit a rate limit and swallowed the exceptions. The output file was valid. The process exited successfully. A failure to observe became a factual claim that nothing existed.

Second, a production watchdog sampled 8 machines from a fleet of 68, then reported its verdict as if it covered all 68. The sample may have been measured correctly. The population-level conclusion was still unsupported.

Third, a database health endpoint returned success because select 1 worked. At the same time, application screens were failing because a required column did not exist. The check was not false. It answered the wrong question.

These are different systems, but the failure is the same:

not observed -> zero
partial observation -> full-population claim
proxy check -> business conclusion

The problem is not simply bad code. Many systems have only two result states. If the answer is not yes, the implementation eventually pushes it toward no. Silence becomes a value.

That is dangerous when the value controls a merge, deployment, payment, acceptance decision, or compliance report.

UNKNOWN must be an outcome, not an omission

There is a crucial difference between an UNKNOWN receipt and no receipt.

No receipt can mean many things:

the check never started
the process crashed
the target was unreachable
the verifier could not measure the claim
the result was created but lost in transport
the result was suppressed

Those states cannot safely be interpreted by a downstream system.

A signed UNKNOWN is different. It is an explicit epistemic statement:

A verification attempt occurred, but the available evidence does not justify VERIFIED or REFUTED.

That statement can carry a reason code, a measurement record, a timestamp, a verifier identity, and a causal link to the work being checked. It can be audited. It can also block acceptance without pretending that counter-evidence exists.

The protocol rule should be simple:

Every completed verification attempt produces a signed verdict. No receipt means no attestable outcome exists.

What OpenWorkProof already does

OpenWorkProof v0.5 already treats UNKNOWN as a signed, first-class verification decision.

Its verdict is three-valued:

VERIFIED
REFUTED
UNKNOWN

The verification logic can derive UNKNOWN when evidence is incomplete or unsuitable for the requested conclusion. Current examples include population drift, unavailable population evidence, control mismatch, unavailable control evidence, and insufficient verifier independence.

That is useful, but Heinrich's examples reveal a gap that should not be hidden.

The current protocol can sign the statement:

The evidence available is insufficient for this claim.

It does not yet provide one general measurement-status field that cleanly separates every operational cause, such as:

measurement_status:
  - measured
  - not_run
  - not_measurable
  - interrupted
  - incomplete

verdict:
  - VERIFIED
  - REFUTED
  - UNKNOWN

These fields should remain separate.

A check may be fully measured and still return UNKNOWN because the evidence is inconclusive. Another check may be incomplete because only 8 of 68 targets were observed. A third may never have run. Collapsing those cases makes diagnosis harder and creates opportunities for downstream systems to interpret absence as success.

This split is a design proposal, not a claim about what the current release already implements.

A receipt should bind what was actually measured

A useful verification receipt should not contain only a verdict. It should bind the basis of the verdict.

At minimum, that means recording:

the declared population
the observed population
the sampling rule
measured coverage
exclusions and their reasons
verifier version and code identity
the control that was used
the negative-control result
the distinction between execution failure and epistemic uncertainty

Consider the 8-of-68 example.

This can be a truthful receipt:

Eight targets were measured under sampling rule S. No failure was found in those eight targets.

This is a different claim:

All 68 targets are healthy.

The second conclusion is valid only if the verification contract explicitly permits that inference and the sampling method satisfies its conditions. A signed result must not blur the two.

The uncomfortable question: can your test suite fail?

The same issue applies to verification systems themselves.

A large green test count proves that the registered tests passed in the recorded environment. It does not prove that the suite is representative. It does not prove that each guard would reject a realistic bad input. It does not prove that the benchmark supports the business claim being made.

So raw test count is not enough.

Verification infrastructure should also report falsifiability coverage:

Which conclusion-bearing guards were challenged?
Which known-bad inputs were used?
Did each guard reject the input?
Did it reject for the expected reason?
Which important failure modes remain untested?

OpenWorkProof already uses reason-bound negative controls in parts of its verification-integrity path. A mutation does not count as a successful control merely because something failed. The observed failure must match the registered failure semantics.

But this is a direction, not a victory declaration. Test count and falsifiability coverage should be reported separately.

Why a business should care

Companies do not buy signatures because signatures are elegant.

They care about avoiding expensive false green states:

accepting work that was not completely checked
merging code because a verifier tested the wrong scope
releasing payment for an unsupported conclusion
trusting a dashboard that silently converted errors into zeros
discovering later that nobody can explain what was actually measured

The commercial value of verifiable agent work is not "more cryptography." It is a lower cost of delegation without turning uncertainty into a certificate.

This is also why human final authority depends on honest machine uncertainty. A person cannot make a meaningful acceptance decision if the evidence surface hides the difference between nothing found and nothing measured.

Human control is not preserved merely because a person clicks the final button. It is preserved when the system tells that person the truth about what it knows, what it does not know, and what it never observed.

The protocol principle I would keep

The first two articles in this series argued that autonomous agents need verifiable human authority and that people should retain the final say at consequential boundaries.

This discussion adds a necessary condition:

The human's final say is meaningful only when uncertainty is a first-class, signed state.

OpenWorkProof is open source, and this measurement-status split is now a concrete design question for its next evolution.

If you build agent runtimes, evaluation systems, MCP servers, or automated delivery pipelines, I would value your view on two questions:

Should UNKNOWN always be a signed outcome for every completed verification attempt?
Which measurement states must be separated before a downstream system is allowed to accept, merge, deploy, or pay?

Explore OpenWorkProof on GitHub

Series

Agent Autonomy Has a Missing Layer: Verifiable Human Authority
The More Autonomous AI Agents Become, the More Humans Need the Final Say
A Signed AI Agent Receipt Can Still Be Wrong

The More Autonomous AI Agents Become, the More Humans Need the Final Say

dengyier — Mon, 24 Aug 2026 10:27:30 +0000

Human control should not mean approving every step.
It should mean that people retain the power to stop, reserve, revoke, and accept the actions that carry real consequences.

An agent that waits for approval before every tool call is not very autonomous. An agent that can do anything because someone once clicked "Allow" is not responsibly autonomous either.

This is the design tension. We want agents to handle more work, but we do not want capability to turn into a blank check.

In Part 1 of this series, I argued that agent autonomy is missing a layer of verifiable human authority. This article asks a narrower question: what does the human's final say look like when an agent is expected to operate without constant supervision?

"Human roles and responsibilities in decision making and overseeing AI systems need to be clearly defined and differentiated."

NIST AI Risk Management Framework, Appendix C

NIST also makes a useful distinction. Some systems may not need human oversight. Others specifically do. That sounds obvious, but many agent products still use one generic approval pattern for everything.

The wrong model of human control

When teams hear "human final say," they often picture a queue of confirmation dialogs. The agent proposes an action, a person clicks a button, and the same cycle repeats until everyone is tired of paying attention.

This does not produce meaningful control. It produces approval fatigue.

After enough prompts, people stop evaluating the action and start clearing the queue. The human remains technically present, but the system has trained that person to behave like an automatic approval service.

Weak control	Useful control
Ask before every action	Reserve actions that cross a defined risk boundary
Use "important" as an undefined prompt word	Specify tools, data, limits, deadlines, and effects
Record that a button was clicked	Bind the decision to an identity, task, and proposed action
Let the same system act, verify, and accept	Separate execution from final acceptance

The goal is not to maximize human involvement. The goal is to preserve human decision rights where the outcome becomes hard to reverse, externally visible, financially meaningful, or capable of harming someone else.

Final say is a boundary, not a meeting

A usable authority model needs four properties.

The decision maker is identifiable
The system knows which person or organizational role may authorize this class of action.
The intervention happens before execution
A reserved action pauses before the side effect, not after a retrospective alert.

The scope is explicit
The decision covers a named task, tool, target, limit, and time window.
The decision survives the interface
A third party can verify what was authorized without trusting the original product's dashboard.

None of these properties requires a committee. A person may approve an action in seconds. The important part is that the approval is precise enough for a machine to enforce and durable enough for another party to verify later.

This changes the role of the human. The person is no longer supervising the agent's every move. The person is defining the limits of autonomous work and deciding the few transitions that the system is not allowed to make alone.

A risk ladder for agent actions

OpenWorkProof resolves an action into three states before execution: allowed, reserved, or denied. The names are simple because the dispatcher needs an unambiguous answer.

State	Meaning	Example
Allowed	The current signed authority permits autonomous execution	Read an approved repository inside the active work order
Reserved	A designated human must make a fresh decision first	Apply a patch that changes the candidate work product
Denied	The action is outside the available authority	Deploy to production when the work order grants no production access

The local Human Agency example in OpenWorkProof currently demonstrates this distinction:

profile verified  : True
resolved status   : active
owp.repo_read     : delegated -> allowed
owp.apply_patch   : reserved -> AGENCY_HUMAN_DECISION_REQUIRED

The reserved patch does not execute and then ask for forgiveness. The dispatcher returns AGENCY_HUMAN_DECISION_REQUIRED before the handler starts.

This is how an agent can remain autonomous for routine work without receiving unlimited authority. Reading approved material may continue without interruption. Changing the deliverable crosses a boundary and pauses. Production deployment remains unavailable unless a new authority profile explicitly permits it.

Risk tiering is contextual. A repository read may be harmless in one work order and sensitive in another. The protocol records the decision boundary; it does not pretend that one global list can classify every organization.

Why a prompt cannot carry final authority

A prompt can tell an agent, "Ask me before doing anything important." The sentence is understandable to a person. It is weak as an authorization mechanism.

The model must decide what "important" means. A framework update can change how the instruction is interpreted. Another agent may never see the same conversation. The approval may remain inside a vendor log that the customer, verifier, or downstream partner cannot independently inspect.

A signed authority object behaves differently. It can bind the human decision to the work order, define the affected tools and targets, expire at a known time, and produce the same authorization result during offline verification.

What the WorkOrder permits
∩ What the CapabilityGrant delegates
∩ What the active HumanAgencyProfile allows

OpenWorkProof calls the third object a Human Agency Profile. It describes which part of the available capability a person is willing to let the agent use autonomously for this work.

Only the designated Acceptor can sign a profile transition. An appeal is a signed request for review. It does not restore permission, expand the scope, or turn a denied action into an allowed one by itself.

That last rule matters. If an agent could increase its own authority by filing an appeal, the safeguard would be decorative.

Keep the human out of the low-risk loop

Good oversight is selective. The human should see decisions that require judgment, not a transcript of everything the agent already did correctly.

A useful reserved-action request should answer concrete questions:

Which work order is active?
What exact action is waiting?
Which resource, tool, or external party will be affected?
What evidence and limits are already attached?
What happens if the human does nothing?

The final question is easy to miss. A reserved action needs a safe timeout. Silence should not become implicit permission.

The system should also make denial cheap. If approval takes one click but rejection requires a long explanation, the interface is pushing the human toward the outcome the agent prefers. A signed denial can be brief. The record only needs to make the authority decision clear.

NIST's AI RMF Core calls for documented roles, responsibilities, and lines of communication. For agent execution, those organizational rules need a machine-readable form. Otherwise the written policy and the runtime can drift apart.

What businesses gain from selective authority

An enterprise does not want to choose between full manual review and unlimited autonomy. Both are expensive. The first consumes staff time. The second creates a risk that can surface after the action is irreversible.

Selective authority lets a team expand the autonomous surface while keeping a smaller set of consequential transitions under human control.

Business requirement	Protocol behavior
Routine work should stay fast	Allowed actions execute without repeated approval
High-impact work needs accountable judgment	Reserved actions require a designated human signature
Agents must not negotiate their own permissions	Denied actions remain denied until an authorized profile changes
Delivery disputes need independent evidence	Authority and execution records can be verified offline

This does not prove that an agent's output is correct. It proves a narrower set of facts: which authority existed, which action was proposed, whether the runtime allowed it, and who made the decision at the reserved boundary.

Verification and acceptance remain separate. A Verifier may confirm that the evidence supports the result. The Acceptor still decides whether the work meets the agreed delivery standard.

What exists in OpenWorkProof today

OpenWorkProof is open source under Apache-2.0. The repository's 1.3.0 local candidate includes the Human Agency Profile, Acceptor-signed transitions, pre-execution resolution, signed appeals, and offline verification.

The recorded repository snapshot reports 4,265 required-live tests and 183 candidate tests with zero failures or skips. These are local engineering results for that code and environment. They do not prove customer adoption, paid use, production reliability in another organization, legal compliance, or external acceptance.

The publicly released package and MCP Registry version remain 1.2.0. The 1.3.0 candidate has not been publicly released at the time of writing.

Evidence boundary: the implementation and local verification exist. Commercial adoption and production deployment require separate evidence.

Autonomy needs a stopping rule

Agent autonomy should remove unnecessary supervision. It should not remove the human right to decide what the system may do on that person's or organization's behalf.

The practical design is not "human in every loop." It is a defined stopping rule: the agent proceeds within signed limits, pauses at reserved boundaries, and cannot cross a denied boundary by persuasion or convenience.

That gives the agent room to work. It also gives the human a final say that the runtime can enforce and an independent party can verify.

If you are building an agent runtime, which actions would you allow, reserve, or deny by default? I am especially interested in where developers place the boundary for code changes, external communications, production access, and financial actions.

Explore OpenWorkProof on GitHub

Sources and further reading

Agent Autonomy Has a Missing Layer: Verifiable Human Authority

dengyier — Mon, 24 Aug 2026 09:55:32 +0000

Autonomy is not just a capability question. It is a delegation question.
If an AI agent can act on our behalf, its authority should be explicit, bounded, signed, and independently verifiable.

AI agents are moving from answering questions to changing the world around them. They can edit files, call APIs, operate business systems, deploy code, and coordinate with other agents. That is useful. It also changes the trust problem.

A chatbot can give a bad answer and a person can reject it. An agent can take an action before anyone notices that the instruction, permission, or acceptance standard was unclear.

"Technology does not exist in a vacuum."

Fei-Fei Li, quoted by Stanford Human-Centered AI

That sentence is especially important for agentic systems. Agent autonomy always exists inside a human, organizational, and economic context. Someone defines the task. Someone grants access. Someone bears the cost of failure. Someone decides whether the result counts as delivered.

My argument is simple: human authority should be a protocol property, not a checkbox in a product interface.

Autonomy changes the business question

Most discussion about agent autonomy starts with capability: Can the model plan? Can it use tools? Can it recover from errors? Can multiple agents collaborate?

Those are engineering questions. Once the agent touches real work, businesses ask a different set of questions:

Before execution

Who authorized this action?
What exact task and scope were approved?
Which tools, data, budget, and time window were permitted? After execution
What actually happened?
Did the evidence support the claimed result?
Who verified it, and who accepted delivery?

These questions are not solved by making the model smarter. They require a durable relationship between human intent, machine permission, observed execution, verification, and acceptance.

Without that relationship, autonomy becomes ambiguous delegation. The agent may be capable of acting, but nobody can later prove whether it was entitled to act in that way.

Why "human in the loop" is not enough

The Model Context Protocol is an important open standard for connecting AI applications to external systems. Its tool specification says that there should always be a human in the loop who can deny tool invocations. The same specification also makes clear that the protocol does not mandate one specific user interaction model.

That is a reasonable boundary for a connectivity protocol. MCP helps an agent discover and invoke tools. It should not be blamed for every governance problem above it.

But a confirmation dialog is not the same thing as verifiable human authority.

A UI approval can show	A verifiable authority layer must prove
A user clicked "Allow"	Which identity authorized which action under which work order
A tool call was displayed	Whether the call stayed inside the signed scope, limits, and deadline
A result appeared in the same product	Whether a third party can verify the evidence without trusting that product
A person reviewed something	Whether verification and business acceptance were performed by distinct authorities

A prompt such as "ask me before doing anything important" is useful behavioral guidance. It is not a portable authorization record. It can be interpreted differently by different models, lost across systems, or hidden inside a vendor's private event log.

The stronger the agent becomes, the less we should rely on informal intent as the only boundary.

What verifiable human authority looks like

OpenWorkProof is exploring this missing layer as an open protocol for agent work contracts and verifiable execution. Its Human Agency Profile treats human choice as a machine-verifiable authorization boundary.

The effective authority of an agent is not determined by one broad permission. It is the intersection of three signed objects:

WorkOrder
∩ CapabilityGrant
∩ HumanAgencyProfile
= allowed actions at this moment

WorkOrder defines the task, acceptance criteria, and delivery context.
CapabilityGrant defines which capabilities the system may grant to the agent.
HumanAgencyProfile records the human authority that remains active for this specific work.

Every proposed action can then resolve to one of three outcomes:

Allowed
The action is inside the current signed authority and may proceed.
Reserved
The action requires a fresh human decision before execution.
Denied
The action is outside the authority boundary and must not execute.

A reserved action returns AGENCY_HUMAN_DECISION_REQUIRED before execution. This is different from detecting a policy violation after the damage is done.

The profile is bound to a work order, signed by an Acceptor, and independently verifiable. An appeal is also explicit: it is a signed request for review, not a hidden mechanism that silently expands the agent's rights. Only an authorized, signed transition can supersede or revoke the active profile.

This design does not make the human infallible. It makes the delegation legible.

Verification is not acceptance

A cryptographic signature can prove who signed an object and whether it was altered. It cannot prove that the task was worth doing, that the test checked the right thing, or that the customer accepts the result.

That distinction matters enough to make it explicit:

VERIFIED != ACCEPTED != PAID
VERIFIED != SETTLED
VERIFIED != LEGAL AUDIT
VERIFIED != ADOPTION

In OpenWorkProof, a Verifier evaluates evidence. An Acceptor makes the independent delivery decision. The verifier can conclude that the available evidence supports a claim, while the acceptor can still reject the delivery because the work does not meet the agreed business standard.

This separation also exposes a harder problem: what if the receipt is authentic, but the judgment was based on the wrong test or the wrong population? Verification Integrity addresses that failure mode by preserving the evidence population and the control logic used by the verifier. When evidence is incomplete or the control does not match, the protocol can return UNKNOWN rather than manufacture confidence.

A signed receipt proves integrity and origin. It does not automatically prove correctness, customer acceptance, legal compliance, or payment.

Why a business would care

Businesses are unlikely to buy cryptography for its own sake. They pay when a system lowers the cost and risk of delegation.

Today, important agent work is often trapped between two weak choices. A company can keep a human manually checking every step, which removes much of the promised efficiency. Or it can trust the agent platform's own dashboard as the final account of what happened.

A portable work contract and evidence layer creates a third option. The company can delegate defined work while preserving independent proof of authority, execution, verification, and acceptance.

Business friction	Protocol-level response
Fear of giving an agent excessive permission	Task-bound, time-bound, capability-bound authority
Manual review of every action	Machine-verifiable receipts and reserved human decisions
Disputes over whether work was completed	Separate verification and acceptance records
Vendor dashboard as the only source of truth	Offline verification using portable signed bundles

The commercial promise is not "trust every agent." It is narrower and more useful: delegate important work without granting unlimited authority and without making the agent provider the sole judge of delivery.

What exists today

OpenWorkProof is open source under Apache-2.0. The repository currently contains a local 1.3.0 candidate with the Human Agency Profile, six-role key separation, signed protocol objects, offline verification, and distinct verification and acceptance decisions.

The local candidate has passed 4,265 required-live tests and 183 candidate tests with zero failures or skips in the recorded repository snapshot. These numbers are engineering evidence for that code and environment. They are not evidence of customer adoption, paid deployment, legal effect, or production reliability in another organization.

The currently published public package and MCP Registry version remain 1.2.0. The 1.3.0 candidate has not been released at the time of writing.

Evidence boundary: implementation and local verification exist. Customer adoption, payment, production deployment, and upstream standard adoption require separate evidence.

The design question for the agent ecosystem

Connectivity protocols make agents useful. Authority and acceptance protocols can make their work governable across organizational boundaries.

The open design question is where this layer should live. Should signed authority remain inside the host application? Should it travel with a tool request? Should an agent carry a portable human authority profile? Should execution receipts be understandable across MCP hosts, agent frameworks, and independent verifiers?

I do not think every tool call needs bureaucracy. Low-risk actions should remain cheap. But when an agent changes code, moves money, handles sensitive data, or delivers work across organizations, "the model decided" is not an adequate chain of authority.

Human agency should survive the transition from conversation to execution.

If you are building MCP servers, agent runtimes, approval systems, or multi-agent workflows, I would like to hear where you think verifiable human authority belongs.

Explore OpenWorkProof on GitHub

Sources and further reading

Two Verifiers, One Verdict: Closing the 'Self-Reported Exit Code' Hole

dengyier — Thu, 20 Aug 2026 02:11:03 +0000

Two Verifiers, One Verdict: Closing the "Self-Reported Exit Code" Hole

Repo: github.com/dengyier/OpenWorkProof
This update: 04e62d5..ec0e72e (29 commits across three phases; candidate inventory 837dbb10a3fdc4…)

The problem: "two sub-agents reviewed it" is not independence

In public code reviews of agent tooling, two objections keep coming back:

"Two sub-agents reviewing the same work is not independence." If both reviewers read the same log written by the same actor, they are two signatures on one story — not two executions of that story.
"The exit code is self-reported." An agent says tests all green. The report says so. The log says so. But nothing binds that claim to what actually ran. Nothing stops the agent from editing the test instead of the bug and then reporting green with a straight face.

OpenWorkProof v0.5 now answers both with the same mechanism: two independent verifiers must each execute the work and each sign their own result — and their conclusion-bearing fields must agree field by field, or no decision is formed at all.

What "dual verifier" means here

A high-risk decision (e.g. the kind you'd pay for) requires:

Two distinct verifier bindings — different keys, different subjects, different controllers, different execution contexts (all enforced at profile construction).
Each verifier covers every arm — positive arm, negative controls, population observations, scope evidence. One verifier doing the positive arm and another doing the negative arm is rejected ("split coverage").
Every conclusion-bearing field must converge: expectation_status, execution_status, mutation_status, reason_codes, action_receipt_ids, observed member count / population digest / required target ids, scope_expectation_status, population observations, control observation, and the evidence snapshot digest.
The decision references the full dual set. Commit, chain replay, and the offline delivery package all recompose from the decision's own references — so an appended later run can never break an already-committed decision, and a verifier can never cite its own older passing run to hide a newer failing one (the commit's stale gate requires the referenced set to equal exactly what prepare would load).

If the two verifiers disagree on any conclusion field, the decision cannot be formed — this is a documented temporary compromise (the frozen v0.5 decision model holds one reference per arm; a formal on-ledger divergence state is the v0.6 path).

Why this closes the "self-reported exit code" hole

The naive design compares the evidence snapshot digests the two verifiers cite. But evidence refs are self-signed metadata — a lying verifier can copy the honest one's refs verbatim and flip expectation_status. That was the hole. The fix is to compare every field that carries a conclusion, not just the pointer to evidence:

A verifier that fabricates an exit code now produces different conclusion fields from the honest verifier → divergence → no decision.
A verifier that cites its own old run to suppress a newer failing one is stopped at commit: the referenced set must equal the set prepare would load (newest per (arm, verifier)).
A verifier that signs but never produces results cannot turn a single-verifier UNKNOWN into a VERIFIED.

Each of these was demonstrated by an adversarial probe first (RED), then fixed minimally (GREEN), then re-attacked by an independent reviewer for seven rounds.

The 7-round audit

Both a specification reviewer and a quality/security reviewer (separate agents) attacked the implementation across seven rounds each. Every round was either a probe that reproduced an attack, or a confirmation that a previous attack now fails. Representative probes:

Probe	Attack	Result after fix
Copy refs + flip `expectation_status`	Lying verifier fabricates exit code	`VerificationInputError: high-risk verifiers diverged`
Cite old PASS + newest other-verifier	Suppress own newer FAILING run	Commit blocked: `references arm results that are not the current set`
Second verifier co-signs only	Single verifier + co-sign → VERIFIED	Commit rejected (recompose → UNKNOWN ≠ signature)
Append a newer converged round	Break replay of committed decision	Old decision replays from its own references; new decision supersedes
Same key twice	Impersonate dual verifiers	Shape gate rejects duplicate (arm, verifier) rows

Final state: required-live full gate 3543 passed / 0 failed / 0 skipped, candidate inventory rebuilt and bound, v0.1–v0.5 frozen schemas untouched.

Honest boundaries (kept)

This proves the protocol requires dual-verifier convergence. It does not prove any actual delivery went through dual verification, that verifiers are honest, or that no collusion happened (the trust model assumes at least one honest verifier).
Divergence currently means "no decision" (combination failure), not an on-ledger UNKNOWN — the frozen decision model can't hold two references per arm. This is a documented temporary compromise; a formal DUAL_VERIFIER_DIVERGENCE state is the v0.6 path.
No customer adoption, no paid work, no upstream adoption (all not_evidenced).

Try it (5 minutes, offline)

git clone https://github.com/dengyier/OpenWorkProof
cd OpenWorkProof
python -m pip install -e .
python tests/evidence-bundles/verify_evidence_bundle.py \
  tests/evidence-bundles/rich-4196-integrity-v05-delivery-package.json

Then break it: change one byte anywhere in the evidence chain and watch the verdict stop being VERIFIED.

OpenWorkProof is a Python protocol layer that makes agent work authorizable, verifiable, and offline-replayable. Apache-2.0. Sponsors welcome.

Want a verification report for one of your agent deliveries? Free first sample — you give a delivery, we produce a report you can replay offline in 5 minutes.

I Built a Self-Evolving Knowledge Base — Here's the Architecture

dengyier — Tue, 18 Aug 2026 13:45:40 +0000

I've spent years accumulating notes across a dozen Obsidian vaults — projects, clients, research, half-finished ideas. Like most people, my "second brain" slowly became a second graveyard: searchable, yes, but it never did anything on its own. It certainly never got smarter.

A few weeks ago I decided to fix that. I wanted a knowledge base that:

remembers across sessions (not just a fresh AI agent re-reading everything each time),
pulls in the outside world (news, papers, releases — with real sources, not hallucinated summaries),
distills that into a stable, personalized knowledge core,
runs a daily production loop that's recoverable if it crashes halfway,
and — the hard part — actually evolves when I give it feedback.

This post is the architecture that came out of it. It's built on plain Markdown (Obsidian) plus a handful of open-source tools, and the honest conclusion at the end is probably the most useful part.

The core idea: Markdown is the truth source, everything else is derived

The first rule, and the one that saved me repeatedly: the Markdown files are the only source of truth. The database, the index, the embeddings, the summaries — all of it can be deleted and rebuilt. If every service dies tomorrow, the vault still opens and reads fine.

That single decision made every later step safe. You can rebuild the brain from scratch, you can move directories, you can break a tool — the knowledge survives.

The five layers

I reorganized everything into five top-level layers, each with one job:

Layer	Job	Rule
`00_资源库` (Resources)	Raw evidence	Read-only. Never edited.
`01_主题Wiki` (Topic Wiki)	Stable knowledge, methods, cases	Distilled, cited, confidence-tagged
`02_项目库` (Projects)	Active projects & decisions	Status always explicit
`03_输出库` (Outputs)	Real, usable deliverables	A draft is not an output
`04_系统维护` (System)	Rules, profiles, state, feedback, logs	The nervous system

The root directory keeps only three things: AGENTS.md, the home page, and an inbox. Everything else has a home.

Layer 1: Long-term memory (cross-session retrieval)

The goal: a brand-new AI session should be able to answer a question by querying memory first, then verifying against the original file — not by re-reading 700 files.

I used GBrain — Garry Tan's open-source agent brain. It runs on PGLite (Postgres-in-WASM), so there's no server and no Docker. The whole thing is a single local file.

# install (Bun is required)
bun install -g github:garrytan/gbrain
gbrain init                 # PGLite, zero config
gbrain import ~/vault/ --no-embed
gbrain search "who pays for this and how fast"

The import was honest about what it did and didn't index: it skipped dot-directories (nested .git, .venv) and README/index files, and I verified the exact count reconciliation rather than trusting it. Idempotency was tested by re-running the import — 0 new pages, 0 errors.

Key insight: I run it keyless. Keyword search + agent-written memory costs $0 and sends nothing to a third party. Semantic search (embeddings) is a paid upgrade you can add later, but the core loop works without it.

Layer 2: The outside world (a personal knowledge radar)

A knowledge base that never gets new input rots. I added Horizon — an AI-powered news radar that fetches RSS/Hacker News/GitHub, deduplicates, scores with an LLM, and generates bilingual daily briefings.

# Python + uv
git clone https://github.com/Thysrael/Horizon.git
uv sync
uv run horizon --hours 24

I started with six sources (official RSS + one high-signal personal blog), and configured it to output to the Resources layer with per-item metadata: unique ID, title, author, publish time, source URL, source type, fetch time — with the AI summary stored separately from the original, never mixed.

Two honesty tests mattered more than the happy path:

A failing source must report "fetch failed", not "nothing new". One of my feeds returned HTTP 403 — the system logged it as a failure, I swapped it out. Silence would have been a lie.
An AI-provider failure must not lose the raw material. With no API key set, it fetched everything first and then failed loudly at the scoring step. Raw data was preserved either way.

The distillation: from notes to knowledge cards

This is where most systems stop — they store, but they don't think. I built templates for eight card types (resource / knowledge / project / decision / output / feedback / evolution-proposal / case-closure), each with mandatory fields:

title, type, status, created, updated, source, confidence, sensitivity

And every card's body separates facts from judgments from opportunities from risks — with a source link back to the original note, a confidence level, and an explicit invalidation condition ("what would make this wrong?").

Then I distilled a core sample of my vault into real cards. The discipline that made it work: nothing without a source gets promoted to fact — it gets demoted to "hypothesis". Contradictions are stored side by side, not merged. The original files are never moved or overwritten.

The personalized layer: a career pack built from your evidence, not stereotypes

Instead of assuming what "a consultant" or "a creator" should do, the system generates a career pack from your own history: your stated role, your real deliverables, your rejected work, your explicit preferences.

Each rule in the pack carries its evidence and an invalidation condition. For example, one of my confirmed rules:

"First ask: who pays, what do they buy, how fast do they pay, what does delivery cost — before discussing market size or vision."

That's not a generic platitude — it's extracted from my own project records where I repeatedly watched "local artifacts complete" vs "customer accepted and paid" be two entirely different gates.

The important safeguard: without real historical material, the pack stays a candidate, never active. No invented persona.

The production loop + a recoverable state machine

The daily loop is: precheck → ingest → distill → link → route → produce → feedback → close. Every round must end in exactly one of three closures: a real output, stable knowledge, or an explicit drop.

I then wrapped it in a state machine that makes it crash-safe:

single-instance lock (two agents can't run the same round),
a run_id, target date, and input-list hash written at start,
every phase idempotent,
resume from a recovery point after interruption (no duplicate artifacts),
"missed a day" is recorded as pending catch-up, not system failure,
skip if already closed within 24h.

Then I ran fault injection: a source failing, the brain failing, a mid-run kill, two simultaneous instances, an interruption between state-write and output-write, and a missed schedule. All six recovered correctly. That's the difference between "automation that runs when nothing goes wrong" and "automation you can actually trust."

Quality gates that fail loudly

Finally, a set of gates that run against the vault and fail loudly on violations:

resource layer never overwritten,
secret scan (no API keys in the repo),
every card has a source + valid dates,
facts separated from judgments,
no duplicate outputs,
exactly one closure per round,
brain index consistency,
a draft must never be marked "published".

I tested these against both clean samples (8/8 pass) and deliberately broken samples (missing source, missing sections, a draft masquerading as delivered) — the gates caught all of them.

The honest part

Here's the thing nobody tells you: you cannot automate self-evolution into existence.

The system's evolution loop — feedback → proposal → approval → rule upgrade → measurable behavior change — only activates on real feedback. A single opinion doesn't change global rules; a repeated signal or real outcome data does. I built the entire mechanism, but it sits idle until I actually use the outputs and say "this worked / this didn't."

The tutorial I followed was explicit about this, and it's the most valuable lesson of the whole build:

Without 30 days of real running, without real feedback on outputs, without an activated personal pack, you should describe the system as "same-tier architecture and loop, but your own instance" — not a finished product.

That's exactly where mine is: the architecture, the loop, and the gates are all built and tested. The evolving part starts the day I start giving it honest feedback.

Takeaways

Make Markdown the truth source — everything else becomes safely disposable.
Separate memory, ingestion, distillation, and production into layers with one job each.
Test the failure paths, not just the happy path — a tool that fakes "nothing new" is worse than one that crashes loudly.
Distill with sources and confidence, never with vibes — and demote unsourced claims to hypotheses.
Self-evolution is a feedback problem, not an engineering problem. You can build the loop, but only you can feed it.

The stack is all open source: Obsidian, GBrain, Horizon, PGLite, and a couple of small Python scripts for the state machine and quality gates. None of the interesting parts are proprietary — the interesting part is the discipline.

What's your knowledge base doing for you that you're not doing for it?

I Asked 'Do You Trust an Agent That Says the Tests Passed?' — 68 Comments Later, Here's What I Learned

dengyier — Mon, 17 Aug 2026 09:26:47 +0000

I Asked "Do You Trust an Agent That Says the Tests Passed?" — 68 Comments Later, Here's What I Learned

On August 7 I posted a question that had been nagging me: when an AI agent says "I ran the tests and they passed," on what authority do you accept the delivery?

It got 68 comments. The interesting part: almost nobody argued about whether to trust the agent. The comments kept circling a much harder question underneath. Three of them kept coming back, over and over.

1. "Proving the test ran isn't the same as proving the test could catch the bug."

This was the sharpest one. As @glenallen put it:

The harder problem isn't proving that a test command executed; it's proving that the test was capable of catching the failure it was supposed to catch.

@sizzlebop said it in one line: "the bigger issue is if the 'test' actually tests anything."

That's a negative-control problem. A test that has never once failed is indistinguishable from a test that can't fail. So we made it a first-class requirement: every verifiable claim must carry a registered negative control, and that control must fail for the registered reason — the right exit code, the right failure signature. "Failed by accident" does not count as "failed as designed."

2. "It can report green because the thing it should have checked never got checked."

@julianneagu:

I've seen tools report green simply because the thing they needed to check never made it into the input set.

That's the empty-input / population problem — a pipeline that selects zero tests and calls it success. So we bind the eligible population before selection: if the executor saw N eligible tests and the selector picked zero, the verdict is not VERIFIED. Selecting nothing is not "done."

3. "Immutable evidence ≠ immutable truth."

@mansio turned a comment into a design aphorism: "immutable evidence ≠ immutable truth." A tamper-proof record of a wrong conclusion is still a wrong conclusion.

That's why our verdict is three-valued — VERIFIED / REFUTED / UNKNOWN — and why @reidmarlow's observation landed hard:

The UNKNOWN exit code is the bit I wish more agent tooling copied… making uncertainty a first-class verdict.

When the evidence can't support a conclusion, we say so, instead of quietly teaching callers to retry until the dashboard is green.

What we did with those three answers

An independent third-round audit (2 critical + 5 important findings), each closed attack-by-attack: first write the attack, watch it pass, then make the smallest fix that rejects it.
A five-minute challenge so you can verify it yourself — we changed exactly one byte in a delivery that still claims VERIFIED, and one command catches it: find the tampered byte.

The parts we have not solved — because our own readers said so

The comment section was also the most honest roadmap I've been handed:

@navid_gh_gh: "the complexity is unacceptable… I want the process to be fast."
@designbynaima: "cryptographic receipts for every single tool call sounds like it'd kill adoption."
@skillselion: "a deliberately broken fixture becomes a merely invalid one two schema migrations later" — the rot problem.

Those aren't rebuttals. They're the next milestones.

The question I'd ask you now

The comments forced a better question on me. Not "can I trust the agent?" but:

Can the test fail for the right reason — and can I re-run the evidence myself, offline, without trusting anyone's server?

If you're carrying that question too, the challenge is five minutes: dev.to/dengyier/i-tampered-with-a-verified-ai-agent-delivery.

If you've been burned — "tests green but it shipped broken," "the agent claimed it finished but didn't" — tell me how you caught it. That's the input I'm actually collecting.

I Tampered With a 'VERIFIED' AI-Agent Delivery. Can You Find It in 5 Minutes?

dengyier — Sun, 16 Aug 2026 14:57:20 +0000

You're paying an agent (or a freelancer, or an internal pipeline) to do work.
The agent says: "all tests pass, the change is verified."

A few things that already happen, in public, today:

An agent "fixed the test instead of the bug" — tests passed, production broke. (Product Hunt vibecoding thread)
An agent claimed it finished a codebase analysis while only doing 21% of it. (claude-code #3376)
An agent reviewed its own code and passed itself — and it was wrong. (dev.to)

The common thread is not "the test was bad." It's: nobody independently re-verified what the
agent actually did, offline, without trusting the agent's own machine.

The challenge

Here is a frozen delivery package that claims VERIFIED. It is a real,
offline-replayable evidence chain: signed work order → signed scope → signed
arm results → three-state decision (VERIFIED / REFUTED / UNKNOWN), including
which population was eligible before selection and whether the negative
control failed for the registered reason.

I changed exactly one byte in it. It still claims VERIFIED.

Your job, in under 5 minutes, without editing any source code:

git clone https://github.com/dengyier/OpenWorkProof
cd OpenWorkProof
python -m pip install -e .          # installs the protocol from source
python tests/evidence-bundles/verify_evidence_bundle.py \
  tests/evidence-bundles/rich-4196-integrity-v05-delivery-package.json

Then answer two questions:

What did I tamper with? (Which file / which field.)
Why does the verifier still catch it? (What breaks first — the byte hash, or the signature / decision chain?)

No network. No ledger. No Docker. No agent's server to trust.

Why this matters

This is not a benchmark. It is a verification-of-the-verifier artifact. The
protocol (OpenWorkProof) freezes four
things per unit of work — authorization, scope evidence, eligible population
completeness (selecting zero tests is not "done"), and negative-control
semantics ("failed by accident" ≠ "failed as designed") — into a chain you can
replay offline.

Two claims I am not making, honestly:

This is a self-owned demo (a real Rich #4196 regression), not evidence of any customer adoption, payment, or deployment. Those are not_evidenced.
It is a complement to identity / payment rails, not a payment or settlement system.

The real ask

I'm collecting the failure modes people actually hit when they can't verify an
agent's work. If you've been burned — "tests were green but it shipped broken",
"the agent claimed it finished but didn't", "I re-ran it myself because I didn't
trust the report" — tell me in the comments, in one line: what happened, and how
you caught it (or didn't).

That's the input I actually want. The challenge is just the appetizer.

Verifying the Verifier: How an Independent Audit Hardened OpenWorkProof v0.5

dengyier — Sat, 15 Aug 2026 16:06:28 +0000

What this is for (the 30-second version for everyone)

Increasingly, the person "doing the work" is an agent, and the person "checking the work" is also an agent. The moment you pay, merge, deploy, or ship on an agent's say-so, you have a new question: who verifies the verifier?

OpenWorkProof is a Python protocol layer that answers that question with evidence instead of vibes. It takes one unit of agent work — a task, a git change, a test run — and freezes four things into a signed, append-only, offline-replayable chain:

Authorization — who was allowed to do this work, signed by keys.
Scope — exactly which files and which tests were claimed, and what was actually observed; the two must be byte-identical.
Population completeness — if the engine saw N eligible tests but the selector picked zero, that run does not pass. (Call this the "tested nothing, reported green" blind spot.)
Negative-control semantics — a deliberately injected mutation must not merely fail; it must fail for the registered reason (error code / predicate signature). "Failed by accident" ≠ "failed as designed".

The verdict is deliberately three-valued and monotonic: VERIFIED, REFUTED, UNKNOWN — where UNKNOWN is a safe conclusion, not a crash. The CLI is fail-closed: VERIFIED=0, UNKNOWN=3, REFUTED=4.

For business readers: this is not a payment rail, not an auto-settlement system, and not a claim that any customer adopted it. It is a protocol capability, demonstrated on our own work item (Rich #4196). What it buys you is a concrete answer to "what exactly was verified, by whom, against which inputs — and can I replay that myself without trusting anyone's server?"

Why v0.5 is designed this way

v0.3 proved "claimed scope == observed scope, exactly." The design of v0.5 follows from two attacks v0.3 could not see:

The population blind spot. An executor sees many eligible tests; a selector may legally choose a subset — or zero. A run that selects nothing ends successfully and, under older semantics, looked green. v0.5 therefore binds what was eligible, what was excluded, and why into the signed selector spec, and requires a positive match before VERIFIED is reachable.
Negative-control corruption. A registered mutation "failing" is meaningless unless the failure signature matches the registered one. v0.5 stores the signature and requires observed == signed == expected before a control arm is proven.

Two engineering principles carry the rest of the design:

Never trust the agent's self-report. Every decision is recomposed from canonical signed rows and re-signed; a plain JSON report with a self-hash is treated as untrusted input, not truth.
Evidence must survive offline. Deliveries are bundles you can re-verify with no network and no original ledger, against an immutable candidate inventory — a supply-chain record bound to exact source bytes and fully-qualified image digests. Any source change invalidates the old inventory by construction.

The audit: we invited someone to break it

After the implementation was "done," we commissioned an independent external review — and it declined to take our word for anything. It reproduced attacks by hand and returned 2 Critical + 5 Important + minors:

Critical 1 — offline package authenticity. The scope-coverage-report.json was self-hashed JSON. The customer-private view replayed the signed objects and then threw away the recomputed decision, returning fields from the report instead; the public/diagnostic views had no signed objects at all yet could still return READY_FOR_ACCEPTANCE. Reproduction: tamper the report's decision, re-sync the manifest hash/size — signature verification still passes; a public package can be forged into VERIFIED from zero.
Critical 2 — selector inputs not frozen. The git selector's spec digest omitted allowlist/excluded/required locators; pytest's omitted selector_args/required_node_ids; the pytest adapter treated any stdout line containing :: as an authoritative node id. Reproduction: two different allowlists (or argument sets) with identical output produced byte-identical observations and evidence — both satisfied.
Important 1 — decision loading checked only the Decision ↔ parent ID link; it never loaded or validated Arm Results, never recomposed, never checked committed_at. Deleting every Arm Result row still loaded VERIFIED.
Important 2 — control evidence PROVEN required only non-empty refs + a self-reported matching signature: any {"arm": "negative"} JSON could be proven.
Important 3 — Path.resolve() dereferenced .venv/bin/python into the base interpreter; -m pytest lost site-packages and died with ModuleNotFoundError.
Important 4 — the CLI could exit 0 on UNKNOWN/REFUTED, and audit-explain/compare bypassed the v0.5 derived functions.
Important 5 — several matrix entries "existed as test names" without covering what they claimed; the plan referenced phantom test filenames.

How we closed it: attack tests first (RED → minimal fix → dual review)

Every finding was handled the same way: write an attack-shaped test, confirm it is RED against the old code, apply the smallest fix, commit, then have two independent sub-agents review — one against the spec, one for quality/security. Critical and Important findings blocked progress until closed.

Batch A — offline packages trust only replayed signed truth. The customer-private verdict now comes solely from the recomposed, signature-verified Decision; the report is compared field-by-field against the replay and any divergence fails closed. Public/diagnostic views — which carry no signed redacted attestation — return UNAUTHENTICATED / NOT_READY. Attack tests: forged report decision + synced manifest; from-zero forgery of a public package.
Batch B — freeze every selector input into the digest. Allow/exclude/require parameters are canonicalized into selector_spec_digest for both selectors; node ids come only from a controlled canonical collector (a closed JSON file written at pytest_collection_finish); stdout is never parsed. Reviewers then demonstrated two further bypasses — a nested conftest.py (trylast hook) and a root-level pytest.py shadowing the real pytest — closed with conftest-free refusal and -I isolation, each with its own regression test.
Batch C — decision history is fully replayed at every entry point. _load_current_decision_v05 now loads canonical Arm Results by parent chain, validates each row (id/digest/authority/signature/evidence), recomposes every chain link from its predecessor requiring identical signing bytes, and enforces canonical committed_at plus causal/monotonic ordering (leap seconds rejected). Attack tests: deleted parent rows, row swaps, timestamp tampering, relation drift.
Batch D — a closed control-evidence resolver. A 9-key canonical document (openworkproof-control-evidence/0.5) is now the only accepted shape; ledger and offline package share one resolver; proven requires evidence fact == signed observation == registered expectation. Attack tests: legacy blob shapes, contradictory facts, missing evidence.
Batch E — respect the venv launcher. Keep the absolute invocation path (no final-symlink dereference), bind the real target, pyvenv.cfg, and executable digest separately; a real .venv regression test drives a real pytest collection.
Batch F — CLI parity. Unified exit map (VERIFIED=0 / UNKNOWN=3 / REFUTED=4, unrecognized values fail closed to 3); audit-explain/compare reuse the v0.5 derived functions; end-to-end CLI tests cover all three verdicts.
Batch G — matrix, supply chain, and plan truth. Added fault injection (insert / before-COMMIT / readback) and same-id concurrency for Profile/Arm/Decision, physical tampering across all six v0.5 table families; the archive converter rejects duplicate tar members, absolute paths, and .., and derives platform from the real config; eliminated pytest tmpdir cleanup noise; corrected phantom test filenames and the _ledger_delivery_protocol text in the plan.

Re-freezing the release: immutable inventory + five gates

Because any source change invalidates the old inventory (by design), we rebuilt the candidate after the minors closed:

Candidate inventory: supply-chain/images/candidates/d460c876a7f3046fd1d338951d964bce6d1a6be1.json (fully qualified docker.io/openworkproof/execution-test@sha256:2acf4820…)
focused v0.5: 370 passed
frozen v0.2–v0.4 compatibility: 216 passed
portable full suite: 3348 passed / 0 failed / 6 skipped
candidate live-Docker suites: 173 passed
required-live full run: 3456 passed / 0 failed / 0 skipped, zero warnings
Rich #4196 offline delivery bundle: VERIFICATION PASSED (no network, no original ledger)

What this does not claim

Green tests and offline replays do not equal customer adoption, paid SOW, deposits, upstream adoption, or commercial validation — those states remain not_evidenced. OpenWorkProof is a complementary layer: it freezes authorization, scope evidence, population completeness, and negative-control semantics for one unit of work. It does not replace MCP/A2A interoperability or identity, and it does not execute payment or settlement.

If you have been burned by "the agent said it verified it," we'd like to hear from you — and we invite independent reproduction of both the attack tests and the candidate supply chain.

OpenWorkProof Protocol Specification

dengyier — Wed, 12 Aug 2026 14:53:14 +0000

This specification is the product of a public design conversation (2026-08-08 → 2026-08-12) across LinkedIn and Dev.to. Every primitive below was shaped by named community contributions; each section cites its origin. The protocol's governing principle, stated by the community and adopted here:

Verification must itself be tested. A check that never fails has never been checked.

1. Purpose

OpenWorkProof is a protocol for verifying AI agent work: producing signed, auditable evidence that a piece of agent execution happened as claimed, and that the verifier producing that evidence is capable of detecting failure.

Two distinct claims are always separated in this protocol:

Claim	Mechanism	Meaning
Authenticity	Signature over a receipt	This work was executed and attested as stated
Verifier capability	Negative control arm in the receipt	The verifier would have caught a lie

Signatures alone prove the first. They say nothing about the second — the ln.strip() lesson (Section 4.1).

2. Scope & Non-Goals

In scope:

Receipt formats for verified executions (positive arm + negative arm).
Guard definitions and guard inventory semantics.
Negative control contracts (provocation contract, digest pinning).
Population manifests (sampling honesty).
Temporal validity: retraction, policy state, scope change.
Trust model and bootstrap.

Non-goals (for now):

Model evaluation or benchmarking (evals measure models; we measure executions).
Tracing / observability (logs record what happened; receipts let third parties verify it).
Attestation of environment (TEE / enclave proofs prove where something ran, not that it was correct).
Policy judgment semantics (that is the JPS layer; OWP carries authorization bindings).

3. Terminology

Term	Definition
Guard	A verification check: command + assertion + expected failure behavior
Guard inventory	The set of guards an operator runs, classified proven / unproven / broken
Negative control	A deliberately broken input, run on every CI pass, asserting the guard goes red
Provocation contract	The formal spec of what a negative control provokes (exit code, stderr pattern, schema scope)
Receipt	Signed evidence of one verification event
Positive arm	The "did it pass" side of a receipt: test suite, result, population
Negative arm	The "would it catch a lie" side: control fixture, control result, control target
Population manifest	The honest enumeration of what a check was supposed to examine
Eligible seen	Pre-selection count: what reached the gate
Selection loss	The auditable gap between `eligible_seen` and `population_size`
Rot	Silent decay of a check's capability while output stays green (three kinds: guard, control, population)

4. Failure Model

The protocol exists because verification can be green and structurally meaningless. The failure model is explicit.

4.1 Structural death (`ln.strip()`)

A production gateway ran a signed, audited check that reported verified: true on every run for months. The bug: a stray newline pushed an assert below a return, so the assertion never executed. Exit code 0. Verdict verified.

Measured impact (fintech engineer's post, 2026-08-09):

Status	Count
Guards total	40
Proven (can detect failure)	7
Broken	0
Unproven	33

Five of eight caller-test shapes produced false passes. The agent had "passed 2,283 tests" and failed in production.

Lesson: the verifier is part of the system being verified. It must be tested with inputs designed to make it fail.

4.2 The three decay modes (rot)

Even with negative controls in place, a check can go silently dead three ways (community taxonomy, 2026-08-12):

Rot	Failure	Countermeasure	Origin
Guard rot	Guard stops catching real failures	Continuous negative control on every CI pass	Max Quimby
Control rot	Control stops testing the right failure (recall/precision of the test itself)	Digest pinning + `control_schema_version`	Skillselion
Population rot	Guard examines the wrong population, or none at all	`eligible_seen` in the population manifest	Tom Jones

All three can produce a green checkmark while being structurally meaningless. All three need different countermeasures.

4.3 Catch-rate measurability (23 of 41)

Production data (Ethan Walker, 2026-08-12): a gate caught 23 of 41 known degradations — a 56% catch rate — across eleven green weeks in which nobody asked what fraction it catches.

Lesson: every guard must be measurable against known-bad inputs. The negative control is the cheap, proactive version of the expensive forensic replay Ethan had to do retroactively.

5. Core Primitives

5.1 Guard & Guard Inventory

A guard is a check plus a control:

guard:
  id: gw_check_response_shape
  description: "Every gateway response matches the documented schema"
  command: "check_response.sh"
  assertion: "schema_validate $INPUT"
  status: unproven        # proven | unproven | broken — set by control runs
  controls: [gw_control_null_handling]

The guard inventory is a published, versioned list — not a private detail. It is the unit of honesty:

guard_inventory:
  schema_version: "1.0"
  generated_at: 2026-08-12T00:00:00Z
  totals:
    guards: 40
    proven: 7
    unproven: 33
    broken: 0
  guards: [ ... ]

"Proven" is defined operationally: a guard is proven only while its negative control fails as expected. The moment the control passes (green on broken input), the guard is reclassified unproven or broken. Proven is a time-decaying label, not a permanent badge (Max Quimby: guard rot).

5.2 Negative Control (provocation contract)

A negative control pins the exact broken input and the exact expected failure, and scopes itself to schema versions (Skillselion: control rot / digest pinning):

negative_control:
  fixture_digest: sha256:abc123...            # The exact broken input
  expected_failure_digest: sha256:def456...   # The exact failure signature
  control_schema_version: 2                   # For schema migration tracking
  control_spec:
    target_schema_version: ">=1.0, <3.0"      # Valid for these schema versions
    provocation_type: null_handling           # What class of failure it tests
    expected_exit_code: non-zero              # Minimum bar
    expected_stderr_pattern: "NullPointerException"  # Specific signal

Rules:

Pin by digest, never by path. The fixture and the expected failure are referenced by digest so "proven" is a verifiable claim, not a historical observation.
Every control declares its provocation type. A control that stops testing the right failure class (recall) or that tolerates wrong failures (precision) is control rot — detected by comparing control_schema_version and expected_failure_digest over time.
A control is valid only within its target_schema_version range. Two schema migrations later, the old control is not silently reused — it must be re-blessed.

5.3 Population Manifest (sampling honesty)

A guard's scope must be auditable. The manifest distinguishes what reached the gate from what passed selection (Tom Jones, third round):

population_manifest:
  selection_rule: "threads we have commented in"   # What we HOLD
  eligible_seen: 400                               # What reached the gate (pre-selection)
  population_size: 12                              # What passed selection (post-selection)
  population_digest: <merkle_root>                 # Tamper-evident enumeration
  sampling_rate: 1.0                               # 100% = no sampling
  effective_from: <timestamp>                      # When the rule was authoritative

Semantics:

eligible_seen — pre-selection count: did the collector even see the things it was supposed to check?
population_size — post-selection count: of the things it saw, how many passed the filter?
The gap is selection loss — the auditable delta that turns a silent failure into a detectable one.

Canonical decision table (Tom Jones):

Scenario	`eligible_seen`	`population_size`	Meaning
Healthy instrument	0	0	Nothing to do, nothing expected
Broken collector	400	0	400 things should have been checked, 0 were

Without eligible_seen, both scenarios produce the same receipt. With it, the broken case is a live, self-reporting rot signal on the day it happens — not at the next review.

Operational rule: check the set you HOLD, not the set you FETCHED. The selection_rule must be defined over the population you intend to cover, and eligible_seen proves the collector reached it.

Reference scenarios (included in Appendix A with attribution): the thread monitor and the sampler.

5.4 Receipt — DualArmReceipt v1

The signed unit of verification. One payload, two arms (Cophy Origin: the receipt–content gap; Mikhail: dual-arm verification):

dual_arm_receipt:
  schema_version: "1.0"
  claim:
    task_id: owp-task-20260812-001
    description: "Refund processed for order R-4491"
    result: done
    output_digest: sha256:9f8e...               # What was actually produced
  positive_arm:
    test_suite_digest: sha256:77aa...
    test_result: pass
    population_manifest:                       # 5.3 — what the pass covered
      selection_rule: "refunds with amount > 0"
      eligible_seen: 113
      population_size: 113
      population_digest: sha256:31cd...
      sampling_rate: 1.0
      effective_from: 2026-08-12T00:00:00Z
  negative_arm:                                # 5.2 — would the verifier catch a lie?
    control_fixture_digest: sha256:abc123...
    control_result: fail-as-expected
    control_schema_version: 2
    control_target: guard:gw_check_response_shape
  signature:
    algorithm: ed25519
    key_id: owp-key-issuer-01
    value: 0x...

Rules:

A receipt without a negative arm is a log, not evidence. The negative arm is what lets a third party check the verifier's capability — it answers "would this receipt have screamed on a lie?"
File existence ≠ content correctness. A receipt must pin output_digest (what was produced), not merely record that a file exists.
control_target ties the control to the specific guard it proves, so arm and guard cannot drift apart.

5.5 Temporal Validity — RetractionReceipt v0.2

A receipt is a bounded claim: "this was true under these conditions at this time" (Suraj Suradkar). Obsolescence is tracked, not hidden.

retraction_receipt:
  parent_receipt_id: owp-receipt-20260812-001
  retraction_auth: <PolicyDecision>            # Independent trust boundary; co-signed
  propagation_class: none | downstream_causal | same_predicate
  semantic_cause:                              # Open, versioned enum
    category: superseded_by | refuted_by | scope_changed
    superseding_receipt_id: owp-receipt-20260812-009
    valid_until: 2026-08-20T00:00:00Z

Categories (Suraj, refining Mikhail's v0.2):

Category	Meaning	Consequence
`superseded_by`	Decision was correct then, no longer current	Old receipts: not invalid, bounded
`refuted_by`	Old evidence was wrong	Old receipts: retrospective scope loss
`scope_changed`	Population/policy shifted	Old receipts: incomplete relative to new scope

Design constraints (Mikhail):

REVOKED / SUPERSEDED / EXPIRED are overlapping flags, not a mutually exclusive enum — a receipt can be superseded and expired simultaneously.
retraction_auth is an independent trust boundary: the key that issued a guarantee should not be able to unilaterally cancel it (co-signed by a non-issuer).
propagation_class lives in the protocol layer; semantic_cause in the application layer.

5.6 Policy-State Registry & PolicyAnchor

Policies and their checkpoints are versioned in a monotonic registry (Brian Jin, rounds 2–3):

policy_checkpoint:
  policy_id: pol-refund-eligibility
  revision: 4
  artifact_digest: sha256:e0b1...
  effective_from: 2026-08-12T00:00:00Z
  previous_checkpoint_digest: sha256:c2a9...    # Monotonic chain
  signature:
    key_id: owp-key-policy-01
    value: 0x...

Monotonic revision chain: every checkpoint references its predecessor, so policy authority has a tamper-evident history.
Dual timestamps on receipts: a receipt's validity has an execution time (when the agent ran) and a policy time (which policy revision was authoritative). If a policy is retracted, anchored receipts become retrospectively scoped — bounded, not invalid.
PolicyAnchor sits at Layer −1 of the stack (Section 8): it is the point where authority itself is pinned, not an output of the verification pipeline.

6. Verification Flow (end-to-end)

┌─ Every CI pass ─────────────────────────────────────────────┐
│ 1. Define  guard + negative_control (provocation contract)   │
│ 2. Run positive arm:   suite → test_result, population_manifest
│ 3. Run negative arm:   broken fixture → control_result        │
│    — control must FAIL as expected, else guard reclassified   │
│ 4. Package DualArmReceipt (claim + positive + negative)       │
│ 5. Sign with issuer key; publish to registry                  │
│ 6. On policy/scope change: emit RetractionReceipt             │
└──────────────────────────────────────────────────────────────┘

Outputs:

A guard inventory updated every run (proven/unproven/broken counts).
A receipt chain with temporal validity.
A policy registry with monotonic revisions.

7. Trust Model & Bootstrap

Minimal bootstrap: a trusted authority key + a signed initial checkpoint. Nothing more is required to start; nothing less is honest.
Single-operator registry is a consistency proof, not a uniqueness proof: it proves all checkpoints descend from one chain; it does not prove no other chain exists. Multi-operator/multi-key registries are a future work item.
Transparency log: checkpoints are appended publicly so that retroactive editing is detectable even by parties who do not trust the operator.
Retraction authority is independent (5.5): the issuer cannot unilaterally revoke its own guarantees.

8. Layered Architecture

Causal order (community-corrected model; PolicyAnchor is Layer −1, not the top):

Layer	Concern	Primitive
Policy history / authority	What rules were in force when	Policy-State Registry, PolicyAnchor
Judgment	What decision was authorized	JPS layer (external)
Execution	What the agent did	claim + output_digest
Evidence	That verification worked	DualArmReceipt (positive + negative arm)

Evidence is the result of the pipeline; authority is its input. Confusing the two was the original ln.strip() error — evidence was signed while authority was dead.

9. Verification Maturity Model (Level 0–5)

(Glen Allen: "verification must itself be tested".)

Level	State	Signal
0	Trust the agent's own report	No independent evidence
1	Logs exist	"It ran" (unverifiable claim)
2	Signed receipts	Authenticity proven
3	Negative controls	Verifier capability proven for fixtures
4	Continuous controls + guard inventory published	Capability continuously re-proven; rot visible
5	Controls are themselves tested (control rot guarded)	The verifier's verifier is verified

Target for production adoption: Level 4, with Level 5 as the differentiator.

10. Adoption Path (two tiers)

(Sri Ramya: layered adoption — execution evidence first, signed receipts second.)

Tier 1 — Human-verifiable evidence: logs, video, replay. Zero protocol cost; establishes the habit of "show the work."
Tier 2 — Machine-verifiable receipts: signed DualArmReceipts, continuous controls, published inventory. What this specification defines.

Teams adopt Tier 1 first; Tier 2 is the upgrade path, not the entry requirement.

11. Open Questions

eligible_seen: is it total events or matched events? Do we need a third count, total_seen?
Multi-operator registry: how do independent signers converge on one chain?
control_schema_version migration: what is the deprecation protocol for a control whose target_schema_version range expires?
Interaction between TEE attestation and the negative arm: does environment attestation strengthen or complicate control claims?
The semantic_cause enum: who curates versions, and how do downstream consumers handle unknown values?

12. Acknowledgements

This specification was co-designed in public. Contributions by:

The fintech engineer behind ln.strip() — the 40/7/33 guard inventory and the negative control that exposed structural death
Ethan Walker — 23 of 41, eleven green weeks, catch-rate measurability (4.3)
JinHyuk Sung — false-Done measurements motivating verifier capability as a first-class claim
Max Quimby — guard rot, continuous negative control (4.2)
Tom Jones — population manifest, eligible_seen, FETCHED vs HOLD, reference scenarios (5.3, Appendix A)
Skillselion — control rot, digest pinning, provocation contract (5.2)
Glen Allen — verification must itself be tested, maturity model (§9)
Suraj Suradkar — decision lifecycle, bounded claims, retraction categories (5.5)
Cophy Origin — receipt–content gap, DualArmReceipt (5.4)
Brian Jin — Policy-State Registry, bootstrap, PolicyAnchor (5.6, §7)
Mikhail — RetractionReceipt v0.2, dual-arm verification, independent retraction auth (5.5)
Sri Ramya — two-tier adoption path (§10)

Appendix A. Reference Scenarios (population manifest)

Attributed to Tom Jones (2026-08-12), canonical for the population manifest:

Scenario 1 — The thread monitor. A sampler configured to measure, on 100% of eligible events, how often two models agree on correctness. Four days produced zero rows, while the box served 113–209 requests/day. Every part of the receipt was valid: selection rule correct, tool ran, exit 0, signature valid. The population was empty because the eligible shape was too narrow. eligible_seen = 400, population_size = 0 exposes the broken collector the day it happens.

Scenario 2 — The sampler. An invite sampler claims to have sampled 12 threads. Without a manifest, the claim is unfalsifiable. With selection_rule + eligible_seen + population_size:

"You sampled 12 of 400" invites an argument. "You sampled 12" ends one.

Appendix B. Schema Versioning Policy

Every YAML primitive carries a schema_version.
negative_control.control_schema_version tracks migration of control fixtures; a control is only valid within control_spec.target_schema_version.
Receipts pin the schema versions of both arms, so old receipts remain interpretable after migration.
Breaking changes require a new major schema version; old versions remain valid for verification but are deprecated for issuance.

When Your AI Agent Passes 2,283 Tests — And Still Fails in Production

dengyier — Mon, 10 Aug 2026 14:20:13 +0000

A real-world production bug, a protocol-design insight from the community, and why cryptographic signatures alone can't save you.

Two weeks ago, I posted on LinkedIn about OpenWorkProof, a verification protocol for AI agent work. I expected maybe a dozen likes. I did not expect a global community of engineers, protocol designers, and security researchers to spend 72 hours dismantling our assumptions in public — and then rebuilding them into something better.

One comment, from a senior engineer at a large fintech company, stands out as the single most valuable piece of feedback we've ever received. He described a production bug that had survived for months:

The Verifier That Couldn't Fail

Their gateway ran a verification check on every API response. The check was signed, audited, and reported verified: true on every run. For months, nobody questioned it.

Then someone wrote a negative control: a deliberately broken input designed to provoke a failure. The check should have returned verified: false. It didn't.

The bug was a single line: ln.strip(). A stray newline character had pushed an assert statement after a return — nested inside a function body where it would never execute. Exit code: 0. Gateway verdict: verified.

Eight different caller-test shapes ran against this check. Five of them produced false passes.

The numbers he shared are sobering:

Status	Count
Guards total	40
Proven (can detect failure)	7
Broken	0
Unproven	33

No agent lied. No log was tampered with. Every signature would have verified. The checker was structurally incapable of failing.

That's not a bug. That's a category error.

What Signatures Can't Prove

This is the gap we've been wrestling with for weeks — and the community has now named it with precision.

A cryptographic signature can prove three things:

Who signed the claim
When the claim was signed
That the claim hasn't been tampered with since signing

It cannot prove that the claim was correct.

The ln.strip() bug illustrates this perfectly. The signature verified that the check ran. It verified that the exit code was 0. It verified that the result hadn't been altered. Every cryptographic guarantee held. The answer was still wrong.

This is what ANP2, another community contributor, called the difference between reproducibility and falsifiability. Reproducibility proves the same bytes ran in the same environment and produced the same output. It does not prove that the output was meaningful. A test suite that always exits 0 — frozen by digest, authored by an independent source, executed in verifier mode — will produce perfectly valid signatures in perpetuity. Every digest will match. Every chain will verify. Nothing will be tested.

Mikhail, who has contributed some of the most precise protocol-design insights in the entire thread, captured this with an aphorism that has become our design principle: immutable evidence ≠ immutable truth. A receipt can prove a thing happened. It cannot prove the thing was right.

The Missing Layer: Negative Controls

The fintech engineer's response to his own bug was elegant in its simplicity: every guard must declare a negative control that must exit non-zero.

This is not a nice-to-have. It is a prerequisite for meaningful verification. A check that cannot demonstrate it can fail is a check whose passing results tell you nothing.

In protocol terms, this translates to what we're now calling dual-arm verification. Any claim-bearing receipt must reference two things:

Arm 1: A pinned test suite that passes (proves the system works on the happy path)
Arm 2: A pinned mutant or negative control that fails (proves the instrumentation has discriminative power)

The verifier checks both arms independently. Arm 1 passing proves the claim is consistent. Arm 2 failing proves the claim is discriminating. Either arm failing its expected outcome invalidates the receipt.

This isn't theoretical. It's been battle-tested. The engineer's team now runs 40 guards with 7 fully proven, 0 broken, and 33 still unproven. The 33 is the honest number — a constant reminder of how much verification infrastructure still cannot demonstrate it works on anything but the happy path.

The Four Layers of Verification Trust

After integrating feedback from the entire thread, here's how we've come to understand the verification stack for AI agent work:

Problem	Solution Layer	What It Proves
"Does this check have discriminative power?"	Negative controls	The checker can actually fail
"Was this the check that was actually run?"	Receipt chain (digest binding)	The claimed execution matches the actual execution
"Was the result altered after execution?"	Cryptographic signatures	Integrity of the evidence chain
"Who authorized this check to run in the first place?"	PolicyDecision (capability grant)	Authority, scope, and time window

Each layer solves a failure mode that the layer below it cannot see. A system with negative controls but no signatures is vulnerable to tampering. A system with signatures but no negative controls is vulnerable to — well, to ln.strip().

What This Means for AI Agent Verification

The AI agent ecosystem is rapidly building infrastructure for connecting agents to tools (MCP) and agents to agents (A2A). But neither protocol addresses the verification gap. They answer what an agent can do. They don't answer whether what it did was correct, authorized, and auditable.

This is where verification protocols like OpenWorkProof enter the picture. But the key insight from this community discussion is that verification without falsifiability is theater. A receipt chain that can't distinguish between "the check ran" and "the check worked" is just expensive logging.

The minimum viable verification stack for any AI agent producing claims is:

Negative controls that prove the verification instrumentation itself can detect failure
Receipt chains that bind every execution step to a specific config, environment, and authorization
Independent recomposition that allows any third party to reconstruct the execution environment and re-verify without trusting the original executor
Retraction receipts that allow previously accepted claims to be marked as refuted — because even correctly verified claims can become wrong as context shifts

Thanks to Tom Jones, ANP2, Mikhail, Giulio D'Erme, Zira, Brian Jin, Puneet, and the rest of the LinkedIn thread for the feedback that drove these insights.