Skip to content
Menu
All work

AgentOps: AI agents you can audit

AgentOps audits whether a codebase's architecture decisions still match the code. In its first full run it targeted 219 ADRs, accepted 146 verdicts and rejected 37, and every accepted claim quotes evidence the model was actually shown.

file
C-01
for
My own tool, run on a production codebase
role
Sole author
period
2026
status
Live
every accepted verdict traced to frozen evidence
evidence-backed
accepted / rejected by the validator, 2026-09-28 run of 219
146 / 37
byte-identical rebuilds, one-command rollback
reproducible

01ADRs rot

Architecture Decision Records are written once and trusted for years. The code moves on. Nobody goes back to check, so the records drift from what is actually running.

ADRs indexed
183
no Status line at all
20
still said Proposed or Accepted
78
many for work that had already shipped
CI guards on ADRs
structural only
nothing checked content against the code
Snapshot, 2026-08-14, before AgentOps: 183 ADRs indexed (219 targeted by the 2026-09-28 run; 221 monitored today)

A wrong ADR is worse than none. Engineers and coding agents read it as truth and build on it. I wanted a tool that tells me, per decision, whether the record still holds, and shows its working.

02The pipeline

It is not an agent framework. Gather context deterministically, make one model call with a JSON schema, write the artefacts. Only one step guesses.

FIG. 1AgentOps pipeline

deterministicmodel callgate
AgentOps pipelineSix steps: gather, freeze, plan, judge, validate, gate. Only judge calls a model. The gate accepted 146 verdicts and rejected 37.01Gatherdeterministic02Freezedeterministic03Plandeterministic04Judgemodel call05Validatedeterministic06Gategate146 accepted37 rejected
  1. 01GatherCode excerpts, route graphs, live database schema and infra facts refreshed from the cloud account. No model.
  2. 02FreezeThe evidence bundle is sealed with a sha256 receipt per file, plus pin and freshness attestations.
  3. 03PlanA manifest freezes the release, component hashes, models, effort, the pinned commit and the budgets.
  4. 04JudgeOne schema-bound call per ADR: CURRENT, DRIFTED, STATUS_WRONG, OBSOLETE or INSUFFICIENT_EVIDENCE, each finding quoting evidence.
  5. 05ValidateEvery quote is traced back to the evidence the model saw. Anything that can't be traced is rejected.
  6. 06GateSuccess needs positive provenance. A missing receipt counts as failed, never as accepted.
Six steps. Five are deterministic. One model call per decision.run 2026-09-28 · 186 dispatched

Models are frontier OpenAI and Gemini models with tiered escalation: a first call, bounded repair attempts, then a stronger tier.

03The validator is the product

Models will cite things that aren't there. So the model never decides what counts. The validator does.

  • Each quote is checked segment by segment against the evidence corpus the model was shown. The ADR text and the instructions are excluded, so the model can't quote the claim back as proof of itself.
  • Segments have a minimum length and must appear in order within a line. Passages stitched together from too many fragments are rejected.
  • A claim that something is "planned" needs a past or future marker that governs the artefact and names it. Otherwise it is rejected as an unsupported excuse for drift.
ADRs targeted
219
210 runnable, 9 blocked
dispatched
186
a provider rate limit stopped the run; 24 pending
accepted by the validator
146
71 DRIFTED · 57 CURRENT · 18 STATUS_WRONG
rejected by the validator
37
failed
3
First corpus run: what came back
marker does not govern the artefact
42
quote does not name the artefact
19
missing past/future marker
17
stitched passage
7
untraceable evidence
6
non-verbatim claim evidence
5
Rule hits on the 37 rejections (one rejection can trip several rules)

I reviewed a sample afterwards. Most scope rejections were genuine grounding errors by the model that the rules correctly stopped. One rule, in-order quoting across lines, was too strict. I narrowed it under review and replayed: 5 of the 6 affected ADRs cleared.

04Operating it like production

An audit nobody can reproduce is an opinion. So the harness runs like a production system, with the same discipline I'd want from a payments service.

  • Frozen manifests. The plan freezes the release directory, component hashes, models, effort and pinned commit. The run re-verifies all of it before any dispatch.
  • Budgets. Model invocations, prompt and output tokens, attempts per ADR, wall time and HTTP retries are enforced before each dispatch and across restarts. Unknown usage is charged at the worst case. Quota and billing errors stop the run at once; rate limits are honoured and paced.
  • Crash safety. Each attempt gets its own directory and an OS-released lease. Timeouts kill the whole process session. Resume refuses to start beside a live orphan, and cleanup holds survive a reboot.
  • Releases and rollback. Releases are byte-identical rebuilds of a pinned commit, checked on the host against a 4,574-file manifest. Deploy is an atomic symlink switch under a host lock. The three newest releases are kept, so rollback is one command.
assertions
802
all green
acceptance guarantees
155 / 155
evidence
72
scoring
35
reproduction
29
answer acceptance
14
attempt identity
3
accounting
2
Release suite on a clean checkout

05What I got wrong

The first version looked like it worked. An early review showed the deterministic layer, the part I trusted most, was wrong.

  • The gatherer assumed the Status line sat on line 2 of every ADR. That one assumption fabricated a finding on 165 of 195 ADRs.
  • A suppressed cloud auth failure was reported as "0 Kubernetes clusters". The tool stated a falsehood about production with full confidence.
  • Batch selection ran before ledger filtering, so some batches audited zero ADRs and still reported success.

06How I measure it, and what I haven't

I don't publish an accuracy number until it has been independently judged against a pre-registered sample. That study is in progress. Until it is scored, this page has no accuracy figure.

source bytes sent
−66.7%
a third-party evidence-selection model vs full gathering
complete-reference delivery
11 / 46
same as the baseline
counter-evidence delivered
3 / 4
same as the baseline
downstream audit quality
not measured
Evidence selector test, frozen 24-ADR development set

Read that precisely. The selector sent 66.7% fewer source bytes at equal measured coverage. I did not measure whether the audit verdicts were as good with the smaller context. The same evaluation found the selector was not fit for implementation judgement (2 of 9), and I recorded that as a NO_GO.

  • Pre-registered protocols. The sample, labels and scoring rules are frozen before results exist.
  • Samples chosen by hash, not by me.
  • Independent judging. Labels come from a reviewer who is not the author.
  • Blind sets, mutation benchmarks, repeatability sets and Wilson intervals.

07Run economics

ADRs dispatched
186
model calls
336
prompt tokens
7.53M
output tokens
2.21M
total tokens
~9.7M
First corpus run, about 12 hours

Under two calls per ADR on average. That is what one schema-bound call per decision buys you, compared with an agent loop that wanders the repo.

08How I apply it for clients

The ADR audit is one use. The pattern underneath, deterministic evidence, one bounded model call, a validator that decides and receipts for everything, fits most places a model's output needs to be trusted.

  • Architecture drift audit. I run this approach on your repository and hand back DRIFTED and STALE decisions, each with traced evidence.
  • Agent reliability harness. Frozen evidence, receipts, validation, budgets and rollback around the agents you already run.
  • Evaluation design. Pre-registered protocols, independent labels and honest intervals, so the number you report survives scrutiny.

Get in touch if your agents need to be auditable.

stack · Python · OpenAI + Gemini · JSON Schema · SQLite · GCP

Need a senior AI engineer who can own delivery?

Tell me what you're building and where it breaks. I reply to every message myself.

Contract CTO · Principal AI engineering · Forward-deployed AI engineering · Enterprise AI architecture