When a coding agent reports that a task is complete, what exactly has the organization learned?
Perhaps the agent says the tests passed, the work stayed within scope, and the branch is ready to integrate. It may provide a lucid summary and a plausible explanation of every decision. None of that establishes the facts. It is still the account of the same system that performed the work.
This is the governance problem behind AI-assisted delivery. The issue is not whether an agent can produce useful code. It can. The issue is whether an organization can distinguish a useful proposal from an authorized change without relying on the agent's confidence, memory, or interpretation of its own actions.
My answer is to separate three authorities. The agent proposes and acts. Deterministic mechanisms establish what happened. A human judges whether the result should be integrated and remains accountable for that decision.
I use this model on my own projects through a pass harness I built for unattended coding agents. It has run that way for two months, with one operator: me. This is not evidence of a team rollout or a client outcome. It is evidence from a constrained operating practice that has had enough unattended runs to expose where trust is the wrong control.
Trust Is the Wrong Abstraction
Trust is useful between people because responsibility, context, and consequences travel with it. A coding agent has none of those properties in the organizational sense. It does not carry professional accountability. It cannot approve a risk exception on behalf of the company. It cannot be the owner of a production decision.
Nor should distrust mean treating every output as worthless. That would discard the value of the tool. The useful position is narrower: let the agent produce work, but do not let it certify the work it produced.
This distinction matters as volume grows. With one agent in one checkout while an engineer watches, the ordinary loop—inspect the diff, run the repository checks, review, decide—may be enough. With several agents working while the operator is absent, conversational assurance stops scaling. A polished completion message is not a control, however detailed it is.
The practical consequence is that every important claim needs an independent answer. “Tests passed” needs evidence bound to a precise commit. “This is all the work” needs an account of every commit. “The pass is complete” needs a closure rule that can refuse completion. “This may ship” needs a human decision made after reading both the change and its evidence.
Give Every Validation Claim an Address
A test result without an address is nearly useless. Which repository state did it cover? Was the tree clean, or did uncommitted fixes help it pass? Did the agent amend the commit afterwards? Did it run the expected checks, with the expected toolchain, or a weaker command that happened to share the same name?
In my harness, validation produces a receipt. The receipt identifies the repository, branch, commit, base commit, and validation phase. It records whether the working tree was clean before and after, the exact commands and exit codes, and immutable logs with their hashes. It also binds the result to a versioned command set and the effective configuration.
The phase is important. A green baseline before work begins cannot stand in for a final validation after integration. The lifecycle therefore distinguishes the known-good starting point, validation inside an executor's isolated worktree, an incremental check after each imported commit, and a final check of the complete integration branch.
The agent does not get to turn “I ran the tests” into “the tests passed.” A guard runs the plan and writes the receipt. A verifier compares that receipt with an expectation for the specific phase and commit. A syntactically valid file for the wrong commit is rejected. If the command catalog changes, old receipts expire rather than silently proving a weaker standard.
Failed receipts remain part of the record. When an integration fails and a correction follows, the evidence should show both the failure and the later passing state. A clean history in which nothing appears to have gone wrong is attractive and operationally misleading.
This is tamper-evident, not tamper-proof. In my setup, the supervisor and the agents run as the same user in the same container. The receipts protect against mistakes, drift, stale evidence, and accidental corner-cutting. They do not defeat a deliberately malicious process with the same filesystem access. Real protection against that threat requires a stronger privilege boundary, protected branches, signed commits, and human review.
That limitation is not an embarrassment. It is the threat model. Good governance states what a control proves and where it stops.
Validation Is Not Provenance
A green receipt proves that a recorded repository state passed a defined plan. It does not prove where that state came from or whether it contains the whole intended change.
That needs a second ledger: provenance accounting.
At the start of a pass, the harness freezes a base commit. At closure, it examines the range from that base to the commit proved by the final receipt. Every commit in that range must have exactly one explanation. In the normal case, an agent commit is imported one at a time and recorded as a mapping from its source commit to the resulting commit on the integration branch, together with the incremental receipt.
“Exactly once” works in both directions. A commit with no account means something landed without an identified origin. A commit with two accounts can conceal another commit with none. On the other side of the ledger, every commit produced by an agent must be integrated or explicitly superseded by a proved replacement. A clean branch is not enough if half an agent's work disappeared during recovery.
Signed commits contribute identity and integrity evidence under the organization's key policy. They do not prove that the code is correct. The provenance ledger contributes origin and completeness. It does not prove that the change is desirable. The validation receipts contribute reproducible check results. They do not prove that the checks were sufficient. These controls are valuable precisely because their claims do not overlap.
There are legitimate exceptions. An operator may make a reviewed commit directly on the integration branch during a pass. My harness allows that commit to be preserved with a reason, but only through a terminal-gated action the agent cannot invoke for itself. A corrective commit may replace a failed series, but equivalence is proved from the patches rather than accepted from a summary. Exceptions stay possible without becoming invisible.
Green Is Not Approval
The most dangerous misunderstanding is to turn better evidence into automatic approval.
In my unattended practice, review found four defects after format, lint, unit tests, build, and visual tests had all run successfully. One change would have run an expensive quality suite twice on every push. Another audited the caller's current directory instead of the repository. A heading-link implementation polluted the heading text. A visual mark reproduced an outline but omitted its filled center.
The receipts were honest. The selected checks had passed against the recorded commits. They simply did not assert those semantic details.
That is why machine proof and human judgment are complements, not substitutes. Deterministic evidence answers factual questions: what ran, against which state, with what result, and where each commit came from. Human review asks different questions: is this the right behavior, is the design coherent, is the risk acceptable, and should this change become part of the product?
The human decision should therefore sit after the evidence chain, not be hidden inside it. The operator reads the diff, the receipts, the provenance record, and any exceptions. Protected-branch policy and the delivery pipeline then enforce the organization's integration and release rules. The agent may recommend a decision; it cannot own it.
Make Refusal a Designed Outcome
A governance system is defined less by how it handles the nominal case than by what it refuses.
My harness does not end because a coordinating agent reports “completed.” Deterministic code re-reads the repository, checks the cleanup receipt against the current commit, requires a clean checkout, and verifies the provenance ledger. An unexplained commit, a mapping without a valid receipt, an unintegrated agent commit, or a resource the pass cannot close prevents closure.
Retries are bounded too. When recovery consumes its allowance, the pass stops and reports that human attention is required. Restarting the agent does not reset the accounting. State survives interruption so a process cannot obtain a fresh budget, lose a failed receipt, or forget which commits were already integrated merely by starting another conversation.
This is not about making the agent obedient. It is about making unsafe ambiguity unrepresentable as success. “Blocked” is a valid outcome. So is “no eligible work.” Preserving evidence for a human is better than manufacturing progress.
The harness also does not push. It prepares locally integrated, evidenced work; publication remains a separate operator decision. That separation is easy to overlook, but it is fundamental. Producing a candidate change and granting it organizational effect are different powers.
Claims Never to Accept on an Agent's Word
For a CTO or DSI, the applicable test is simple: list the claims your delivery process currently accepts from the same agent that performed the work, then replace each with evidence or an explicit human decision.
- “I completed the task.” Require a clean committed state, an explicit stopping condition, deterministic closure, and a record of anything blocked or left unintegrated.
- “The tests passed.” Require a validation receipt bound to the repository, branch, commit, base commit, phase, versioned command set, clean tree, exit codes, and retained logs.
- “I stayed within scope.” Require mechanical comparison of changed paths with the authorized write boundary, plus human review for any semantic exception. A prompt reminder is not a boundary.
- “These are all the commits involved.” Require provenance accounting in which every commit on the integration range has exactly one origin and every agent commit is mapped or proved superseded.
- “My correction replaces the failed work.” Keep the failed evidence and require an equivalence proof for the replacement, followed by fresh validation. Do not let the recovery rewrite the story.
- “The branch is ready to integrate.” Require incremental evidence after each import, a final receipt for the complete branch, commit-policy checks, and a clean repository. Treat the agent's recommendation as commentary.
- “The change is safe to ship.” Require code review, an accountable human integration decision, protected-branch controls, and the normal release pipeline. No receipt can transfer accountability to the model.
- “This exception is harmless.” Require a named human to approve it through a capability the agent does not hold, with a reason preserved in the record.
This list is more useful than a broad “human in the loop” policy. It names where the human acts, where deterministic code acts, and which statements remain merely agent claims.
Adopt the Property, Not My Harness
I would not prescribe this entire mechanism for every repository. One engineer supervising one agent may need no provenance ledger. Existing CI, a clean tree, small commits, and careful review can provide the necessary evidence with less machinery.
The additional controls earn their cost when supervision is lost: several writers operate concurrently, work continues unattended, integration happens before anyone can reconstruct the session, or the volume of generated change outruns informal review. The threshold is not “we use AI.” It is “we can no longer establish what happened by watching.”
Organizations can implement the properties differently. CI can produce the receipts. Separate workers can strengthen privilege boundaries. A merge queue can own integration. A policy engine can enforce write scopes. The mechanism is local; the governance rule is portable.
Start by identifying the claims that presently cross your integration boundary without independent evidence. Strengthen those boundaries before adding more agents. More generation on top of unverifiable delivery only increases review debt.
The One Idea Worth Keeping
An AI agent may propose a change and do the work. It must never be the authority that certifies its own result or grants that result organizational effect.
Use deterministic systems to establish the facts. Use human judgment to decide what those facts permit. Keep accountability with the person who integrates the change.