CORE DIRECTORY // SYSTEM.USER.DIANA_ISMAIL
Labs by Diana — Experiments that ship.
Side projects that got out of hand. AI tools built for problems I kept tripping over — now live, now yours.
Action Classification by Reversibility - The Authorisation Model I Actually Run
ARTICLE_043
PUBLISHED
2026.08.02
READ
~9 MIN
I've run the trust formula - track record times reversibility times blast radius - as my fleet's authorisation model for a while now: which agents execute without review, which route every output through me first, which sit somewhere in between depending on the specific task. That model is documented, it's operational, and it predates any outside evidence that it was the right call. This article isn't the discovery of reversibility as a governance concept. It's what happened when I found a case study that runs the same model at a different scale, with one mechanic built further than mine.
Nate B. Jones documented rebuilding his wife's website with a crew of roughly two dozen agents, for about eight dollars, in an afternoon - a companion video walkthrough of the same rebuild puts the agents across four model families - and the system caught a fabricating agent, a cheating agent, and a mistake by its own supervising agent, without a human stepping in to catch any of them. I've built a version of that interception layer. Mine still ends at a human decision. This article unpacks the mechanic, maps it against what I actually run, and names the gap honestly.
The_Formula,_Not_a_Framework
Track record times reversibility times blast radius is not a framework I adopted after reading about multi-agent governance somewhere. It's the formula I already use to decide which of my twelve agents ship without review and which ones I check before anything goes live. Tom, Nix, and Jo run autonomous; their track record is established, their work is either reversible or low-blast-radius by design. Vera and Lena route through me on every output, always, because the cost of a wrong call in either of their domains is high enough that autonomy isn't the right default yet. Sable and a handful of others sit in the middle, their tier set by task type rather than by identity. Security-adjacent work always gets reviewed; everything else runs on track record.
None of that changed when I found a documented case study running a version of the same model. What changed is that I now have external evidence the model generalises past my own fleet, and one concrete mechanic in that case study that goes further than anything I've built.
The_Formula,_Already_Running
I named this formula and the three-tier system it produces in an earlier piece, The Control Plane Problem, and I won't re-walk that argument here. What matters for this article is the axis the title is actually about: reversibility. Not "is this agent trustworthy" in the abstract, but "how cheaply can this specific action be undone if the agent gets it wrong."
That's the question my trust tiers actually encode, even though "trust tier" makes it sound like a judgement about the agent rather than the action. The Labs twin's MAINTENANCE_MODE flag, which short-circuits every LLM call at the flip of an environment variable, no redeploy required, is a reversibility control - it exists because some failures need to be undoable in seconds, not after a diagnosis. GEOAudit's global_halt flag, gating all new runs through a single chokepoint, is the same logic applied at a different layer, in a different project. The batch operations gate I run before any structurally identical change ships across multiple repos or files requires stating the reversal procedure before the first item executes - not after. Reversibility isn't a property I check once and file away. It's the thing I check before I decide how much review an action needs.
The_Case_Study
Nate B. Jones's "Agent-Shaped Work" documents a small, sharply concrete demonstration of the same principle running at a different scale: a crew of roughly two dozen agents rebuilt his wife's website in a single afternoon for about eight dollars. A companion video walkthrough of the same rebuild describes the crew as running across four model families.
The part of the case study that earns its place in this article isn't the cost or the headcount. It's what the system caught on its own. In the course of the rebuild, the agent swarm identified a fabricating agent, a cheating agent, and a mistake made by its own supervising agent - all three without a person intervening to catch any of them. Jones's framing for the design principle behind this is worth quoting directly: structure untrustworthy agents so their failures get caught by arithmetic instead of by you. The full procedural detail of how that interception layer is built sits behind a paywall I haven't cleared, so I'm not going to describe mechanics I can't verify. What's publicly confirmed is enough to be useful: multiple agents, reviewing each other's work as a structural property of the system, catching failures - including a failure by the agent meant to be doing the supervising - with no human review step in the loop at all.
The_Mechanic,_Mapped
Here's the honest comparison: what I run is structurally similar, and functionally short of it.
Every Labs article that reaches publish goes through a five-specialist review gate - Tom on fact-checking, Reid on positioning, Vera on copy, Cleo on structure, Jo on operational accuracy - dispatched in parallel, each returning a verdict of ship, minor fix, or hold. That's peer review by agents, structurally close to what Jones's swarm was doing when it flagged the fabricator and the cheat. Where mine diverges: every "hold" or "minor fix" verdict has to be resolved by an explicit instruction from me, given in the current session. Inferred consent doesn't count, and an agent's own confidence in its output is never sufficient authorisation to skip that step. The interception happens; the resolution doesn't. My system is built to catch problems automatically and then stop and wait for a person. Jones's twenty-agent crew, on the publicly confirmed evidence, kept going.
That's not a design flaw I'm rushing to fix. Reversibility is exactly why the two systems can reasonably differ here: a Labs article that ships with a factual error is more expensive to unwind - it's public, it's dated, it's indexed - than most of what a twenty-agent website rebuild produces in an afternoon for eight dollars. The formula says gate harder when the blast radius is higher and the reversal is slower. My publish gate gating on a human decision rather than resolving itself automatically is the formula working as intended, not a place where I haven't caught up yet. But it does mean I have a documented example, now, of what full autonomous resolution looks like at the interception layer - not just detection - and that's worth having in view even for the categories of my own work where I'm not ready to remove the person from the loop.
A Playground experiment currently in the brief stage - a Reversibility Approval Gate demo - is built to make this mechanic concrete: middleware that intercepts a mock tool call, classifies it by reversibility, and requires approval above a set threshold. It hasn't shipped. I'll link it here once it has, rather than describe a build that doesn't exist yet.
What_the_Case_Study_Actually_Validates
I want to be precise about the claim, because it's easy to overstate what one case study proves. It doesn't prove reversibility-tiered authorisation is the correct model - I already believed that before I found it, on the evidence of running it. What it does is confirm the model isn't a solo-operator workaround, scaled down from something that only works with a real security team behind it. A twenty-agent crew assembled to save an afternoon and eight dollars ran the same underlying logic - classify the action, gate by what it costs to undo - and it worked well enough to catch its own supervisor's mistake without anyone watching.
That's the actual value of external validation. Not permission to keep doing what I was already doing. Confirmation that the shape of the answer generalises past the specific fleet I built it for.
KEY_TAKEAWAYS
TAKEAWAY_01
Reversibility-tiered authorisation is not a discovery this article is making; it's the operating model behind Diana's fleet trust tiers, documented and running before any external case study existed to validate it. The distinction matters: a piece framed as "I found this pattern" under-claims what's actually true, which is closer to "I already run this, and here's the first outside evidence it holds at a different scale."
TAKEAWAY_02
The most useful thing an external case study can do for an existing operating model is show you a mechanic you haven't built yet, not just confirm the ones you have. Diana's publish gate catches problems the same way a case study's agent swarm does - through structural, multi-agent review rather than a single pass - but resolution still requires an explicit human decision. The case study's swarm resolved autonomously, including catching a mistake by its own supervising agent. That gap is not evidence of a design flaw; it's the reversibility formula correctly assigning more caution to higher-cost, harder-to-reverse actions. But it is a concrete target for what "further along the same axis" actually looks like.
TAKEAWAY_03
Precision means using a source's own wording, not paraphrasing it into a rounder or more convenient number. This article's case study figures come from two distinct sources describing the same rebuild differently - the Substack teaser's "about two dozen" and the video's "20+ agents, four model families" - and the more defensible move is using each source's own framing for the claim it actually supports, rather than merging them into a single figure neither source states outright. Being explicit about which claim comes from which source, and what's paywalled versus publicly confirmed, is what keeps a piece like this honest.
RELATED