Git as an agent trust substrate
The problem. When several AI agents collaborate on an action that is irreversible and outward-facing (publishing, deploying, sending), you cannot rely on any agent being honest: an agent that generated the work is the worst possible judge of whether it should ship, and an agent asked "did you comply?" can simply answer yes. Chaining agent-reviews-agent doesn't fix it — same-model-family reviewers share blind spots (the slop-is-a-context-deficit experiment's caveat: judges of the same family miss the same things), and none of it is tamper-evident.
The pattern, stated precisely (corrected 2026-07-16). The authority is not git — it is a re-runnable deterministic check. The irreducible mechanism is: the gate re-runs a deterministic lint on the artifact rather than trusting any agent's self-report. Git's essential job is a separate, specific one: content-addressing, to bind the artifact that was checked to the artifact that ships (closing the time-of-check-to-time-of-use gap). Everything else git contributes is valuable but replaceable.
- Separation of powers across roles. generator (produces) · auditor (runs the lint + commits the record) · publisher (acts only on a verified, content-addressed record). No role can do another's job.
- The gate's integrity comes from the re-run, not from git. The publisher does not believe a pass status — it re-runs the deterministic lint (or verifies the committed lint result against the committed artifact). An agent cannot talk its way past a check that is re-executed; the "reads git" framing in the first draft over-attributed this to git. Git is incidental to the pass/fail; the re-run is what buys the trust.
- Where git IS load-bearing — the TOCTOU gap. Without content-addressing, an agent can pass the lint on artifact v1 and then ship a swapped-in, non-compliant v2 (checked one thing, published another). Git closes this: the publisher ships exactly the artifact whose content hash was committed and linted. To get this you need content-addressing + immutability — i.e. git or an equivalent. This, not the pass/fail, is the reason git is in the loop.
- Hard rules are code; soft judgment is an agent. Mechanical, diff-checkable rules (completeness, format, provenance, rate) live in the deterministic lint an agent cannot argue past. An agent's judgment (taste, register) is advisory only, never a gate — sidestepping same-family collusion.
Git's other contributions — real, but replaceable. Tamper-evident dated provenance (a signed append-only log would also do); the persistent ordered history that history-dependent checks read (velocity cooldown, dedup, plateau — any ordered store works, git log is merely convenient); zero-tooling human audit/revert (git log/diff/revert). For a git-native operator these are nearly free, which is why git is the pragmatic substrate even though only the content-addressing is logically necessary.
The decoupling this licenses. If the threat model has no swap vector — publish and audit happen in one atomic step with no gap an agent can exploit — then git isn't needed for the gate at all, and degrades to pure audit storage. The gate is: deterministic re-run + (content-addressing iff a TOCTOU gap exists). Git is one way to get the second clause, not the source of the first.
The generalization of a familiar idea. This is "constraints mechanized, not socialized" (the vault owner's engineering principle) applied to agent collaboration: instead of trusting agents to follow rules, make the rules a re-run the agents' output must pass, anchored to the exact content that ships. It is CI-gated (continuous-integration) deployment, re-cast for a world where the workers are language models: the pipeline doesn't trust the committer, it re-runs the check on the committed content — and the commit hash is what stops a swap between check and deploy.
The re-run is a spawned agent — "verification is spawn an agent" (2026-07-16). The re-run is not "the same process re-invokes the function"; it is embodied as a freshly-spawned, clean-context agent that shells out to the deterministic lint on the committed content. Two reasons the spawn matters, not just the re-execution: (1) the clean context prevents same-context collusion — the verifier shares no state, no rationalization, no half-built story with the generator that produced the artifact (this is executor-acceptance-test applied at the publish gate: a clean agent, citation-or-fail); (2) the machine's verification surface is uniform — every gate, deterministic or judgment, is "spawn an agent to re-check," so there is exactly one trust primitive to reason about. The deterministic lint is what that spawned agent runs; the spawn is who runs it.
The build discipline that falls out — "if it can't be re-verified, it doesn't go in." Because verification is a spawned-agent re-run, a component earns its place in the machine only if such a re-run can check it. A field that no re-run can confirm (an unfalsifiable claim, an un-checkable "trust me") is not made a soft-advisory nicety — it is left out. This keeps the machine's every gate falsifiable by the one primitive, and is why the fix for a "law 1 isn't enforced in code" worry is not to add a hash-equality assertion but to note that the publisher-agent already re-runs on the committed (hashed) content: the re-run, not a bespoke check, is the enforcement.
Where it's instantiated. utter-manual — the publisher, a freshly-spawned agent, re-runs the mechanical lint on the auditor's committed ledger record and publishes the irreversible act (posting to a real account) only on a clean result, so an agent cannot talk its way to publishing non-compliant content.
The substrate spans human↔agent, not just agent↔agent (2026-07-16). Where a step needs taste (the residual the lint can't check — is this video good, does it represent me), the human is the judge, and their "yes" is bound the same way: recorded as a token whose content-hash must match the committed artifact (human-gated-publish, utter-manual's publish.human_approval). The publisher's gate becomes two locks — a deterministic re-run PASS and a human approve on the matching hash. So the same content-addressing that stops an agent shipping something other than what was checked also stops the machine shipping something other than what the human blessed: approve-the-exact-bytes, for a person, is as tamper-proof as re-run-the-exact-bytes for the lint. The trust primitive (content-addressed authorization) is uniform across the deterministic gate and the human gate.
The limit. The substrate guarantees compliance with declared rules and no-swap-between-check-and-ship — not correctness of the rules. A wrong lint spec ships wrong-but-compliant work. And the hard/soft split means anything that can only be judged by taste (not a diff-checkable rule) still rests on the advisory agent + the human sign-off, not the gate. The pattern moves trust from "the agents are honest" to "the rules are right and the human watches the constitutional diffs" — a strictly better place to put it, not a place with no trust at all.
Kin: slop-is-a-context-deficit (why agent-judges-agent isn't enough) · executor-acceptance-test (the spawned-clean-agent re-check, here made the publish gate) · trust-follows-provenance (verify by re-derivation, not assent) · utter-manual (the instantiation) · the vault's own pre-commit lints (the same philosophy at the note level).
Source: design 2026-07-16, generalized from the utter-manual architecture; the pattern that let irreversible outward actions be delegated to untrusted agents