Trust-Ladder Deployer: Staged-Autonomy Governance for Production Agents

Overview#

The fastest way to lose an enterprise AI pilot is to ask for production write access on day one. Regulated buyers do not grant it, and they are right not to: an agent that has not earned trust has not produced the calibration data or the audit trail that would justify the grant. So the mature deployments climb a ladder instead. The agent starts read-only, recommending fixes a human applies. It earns auto-routing. It earns sandboxed remediation. Only then does it earn live action. Each rung produces the evidence the next one depends on, and skipping rungs is a named enterprise-AI failure mode.

Trust-Ladder Deployer is our scaffold for running that climb as engineering rather than as a slide. It runs one agent at four escalating permission rungs and makes every promotion an earned, evidenced event. It binds the tool set and approval policy at each rung so a call the rung does not permit is refused and logged, not silently allowed. It records every action tagged with the rung it ran at, in an append-only SQLite trail. It gates each promotion on an eval that has to actually clear the bar, replays high-blast-radius fixes through a sandbox judge before the top rung, and demotes the agent automatically the moment measured accuracy drifts below the rung’s threshold.

Figure 1 - Earn trust before expanding scope: One agent, four rungs of rising blast radius. Read-only recommends, auto-route triages, sandbox-validate executes fixes only in a replica, live-act remediates in production. An eval gates every promotion, and a measured accuracy drop auto-demotes the agent one rung toward safety. The whole climb is the deliverable.

The Problem#

Autonomy is usually granted as a binary. The agent is either behind a human on every action or it is loose in production, and the jump between those two states is a leap of faith backed by a demo. That is exactly the decision a regulated buyer will not sign, because a demo is not calibration data and a leap of faith is not an audit trail. The result is stalled pilots: the agent works in the sandbox, nobody can defend giving it production write access, and the project dies at the last mile.

Worse, the governance that does exist is often theater. A “human in the loop” that rubber-stamps every action is not a control, it is a bottleneck that trains people to click approve. A promotion tied to a calendar (“it has been running two weeks, ship it”) has enforced nothing. And an autonomy grant with no monitoring behind it assumes the agent that was accurate last month is accurate today, which is the assumption drift quietly breaks.

KEY INSIGHT: The unit of governance is not the individual action, it is the permission rung. You do not review every fix an agent proposes; you decide how much autonomy the agent has earned, gate that decision on evidence, and monitor the grant so it can be revoked automatically. The ladder is the control, the audit trail is the proof.

What We Built: Five Moving Parts#

The scaffold is five parts under one config. The ladder config declares the four rungs, each with its bound tool set, approval policy, accuracy threshold, and how many observations count as evidence. The permission binder enforces it: an agent at a rung can call only that rung’s tools, and a forbidden call is refused and recorded rather than silently dropped. The audit log records every action with its rung, approval policy, tool, args, and outcome, plus the full promotion and demotion history, append-only in SQLite. The promotion gates advance the agent only when it clears the target rung’s eval, an accuracy gate for the lower jumps and a sandbox-replay judge for the rung 3 to 4 jump. The drift monitor watches accuracy at the top rung and auto-demotes when it slips.

The contract the client’s agent has to satisfy is deliberately tiny: a name, and a propose(observation) that returns a proposed action. The scaffold never calls a model. It only ever asks the agent to propose, then binds, logs, gates, and monitors around that proposal. That is what keeps the core model-agnostic and what lets a client drop their own agent in without rewriting it.

Figure 2 - The artifact a client signs against: The self-contained HTML governance report, generated straight from the audit log. Summary cards count actions, refusals, promotions, blocked promotions, and auto-demotions; the activity-by-rung table shows where the agent spent its autonomy; and the promotion history makes the blocked promotion visible, an agent held at 0.720 accuracy against a 0.950 bar. A blocked promotion is the ladder working, not failing. The whole report is one file with zero external references, safe to email or archive.

Key Result: Every Promotion Was Earned, and One Was Refused#

The headline is the scaffold’s own re-runnable scenario on a safe synthetic-database demo, an agent driven through all four rungs with every promotion eval-gated. Three promotions took effect and one was blocked:

1
BLOCKED  rung 2 -> 3  gate=accuracy        acc=0.720  below threshold 0.950 over 50 obs
2
PROMOTED rung 1 -> 2  gate=accuracy        acc=1.000  meets threshold 0.900 over 20 obs
3
PROMOTED rung 2 -> 3  gate=accuracy        acc=1.000  meets threshold 0.950 over 50 obs
4
PROMOTED rung 3 -> 4  gate=sandbox_replay  acc=1.000  all 4 remediations verified across 4 classes

Figure 3 - No promotion without evidence: A promotion request meets a gate, not a calendar. The lower rung jumps are checked by an accuracy gate: measured accuracy over N observations against a threshold that rises with blast radius. The rung 3 to 4 jump routes through a sandbox-replay judge that verifies each proposed fix class by class. An agent below the bar is blocked and the block is logged, which is the ladder doing its job.

The blocked promotion is the point. A governance gate that only ever waves runs through is a rubber stamp, and a rubber stamp is worse than no ladder because it launders an unready agent as a governed one. The thresholds in the default ladder rise with blast radius, 0.85, 0.90, 0.95, 0.97, so the bar gets harder exactly where the cost of a mistake gets higher. The rung 3 to 4 jump does not use the accuracy gate at all: it replays each proposed remediation in an isolated replica and verifies the corrected value class by class before it will promote.

The Rung-3 Sandbox Boundary Is Real#

Rung 3 is where the agent starts executing fixes instead of recommending them, so the boundary that keeps those fixes out of production has to be real or the rung proves nothing. It is. A rung-3 remediation lands in an isolated replica, and the same record in production is provably untouched:

1
record           rec-0120
2
raw (dirty)      '  ALICE.SMITH@EXAMPLE.COM  '
3
proposed fix     'alice.smith@example.com'
4
replica value    'alice.smith@example.com'      <- the fix landed here
5
production value  '  ALICE.SMITH@EXAMPLE.COM  '  <- provably untouched
6
boundary held:   True

Figure 4 - The fix lands in the replica, production is untouched: A rung-3 remediation executes against an isolated replica copy of the data. The corrected value lands there; the same record in production keeps its original value, verified after the fact. The sandbox-replay judge replays each proposed fix and checks the result class by class, and only a clean replay promotes the agent to live action. The core ships a tempdir replica that demonstrates the boundary; a Docker adapter bind-mounts the replica into an ephemeral, network-disabled container for stronger isolation, and production is never mounted.

Key Result: Auto-Demote Kept Bad Writes Out of Production#

Reaching the top rung does not end governance, because the agent that was accurate at promotion can drift. The drift monitor keys off measured accuracy over a sliding window, not a hand-thrown switch, so a demotion fires on a genuine degradation. The measured payoff is a head-to-head: the same seeded accuracy drop run twice, once behind the monitor and once without it.

1
seeded fault rate 20% at rung 4 (threshold 97%), window 25, 60 observations
2

3
MONITORED  demoted at observation 24, landed at rung 3 (sandbox); 9 bad writes reached production
4
BASELINE   no monitor, stayed at rung 4 (live);                  16 bad writes reached production
5

6
The auto-demote kept 7 bad writes out of production that the un-monitored baseline let through.

Figure 5 - The monitor is the difference between 9 bad writes and 16: Both runs face the same seeded 20% fault rate at the live rung. The monitored run detects the drift over its window and demotes the agent to the safer sandbox rung at observation 24, capping the damage at 9 bad production writes. The un-monitored baseline never notices and lets 16 through. The demotion is logged and reversible: to climb back, the agent has to clear the promotion gate again, which is exactly what justifies letting it hold the top rung in the first place.

KEY INSIGHT: An autonomy grant you cannot revoke automatically is not a grant, it is a bet. The demote is the other half of the promote. It is what turns “the agent earned this rung” from a one-time judgment into a continuously re-tested one, and it is the specific mechanism that let the monitored run keep seven writes out of production the baseline could not.

What It Does Not Do#

These caveats travel with every client-facing deliverable, because they are the difference between a defensible governance story and an overstated one.

• The scaffold governs autonomy; it does not make the agent accurate. The ladder decides how much scope a given accuracy has earned. If the agent is wrong, the ladder holds it at a safer rung and demotes it faster; it does not fix the underlying model.
• Eval quality caps the whole ladder. A weak promotion gate promotes an unready agent with a rubber stamp. The demo shows the gate blocking a seeded regression precisely because a gate that never blocks is the failure mode, not a feature. The gate is only as good as the ground truth behind it, which is the client’s to supply.
• The measured numbers are the scaffold’s own, on a safe synthetic-database demo. The blocked promotion, the sandbox boundary proof, and the 7-writes-prevented figure regenerate on demand, but they are measurements of the demo domain, not a client’s production accuracy. Every threshold is a tuned starting point, re-tuned per workload, never ground truth.
• The tempdir sandbox demonstrates the boundary; production wants the Docker adapter. The core’s process-isolated replica proves a fix does not reach production. A real deployment should run the stronger container-isolated adapter, which is shipped but kept out of the core’s dependency graph.

Platform Portability#

The core is model-agnostic by construction. The rung state machine, the permission binder, the audit log, and the drift monitor import no model SDK, and the one runtime dependency is Pydantic. The only place the project may touch a model is the optional environmental-parity judge behind a judge extra, which gates only the rung 3 to 4 promotion and imports its SDK lazily. The Docker sandbox lives behind a separate docker extra on the same lazy-import discipline. A plain install stays light and portable, and a client can swap in their own ladder config, their own agent, and their own tool implementations while the binder, audit, promotion, and drift machinery stay unchanged. We position it publicly as a vendor-neutral agent-governance scaffold, not a feature of any one harness.

As a Consulting Engagement#

Trust-Ladder Deployer is the instrument behind our Staged-Autonomy Governance playbook, the engagement that gets a stalled enterprise agent pilot unstuck at the last mile. We map the client’s agent onto a ladder, read-only through live-act, with the tool set and approval policy defined per rung; wire the binder and the rung-tagged audit log; define the eval that gates each promotion against the client’s own ground truth; stand up the sandbox boundary before any live rung; and turn on the drift monitor once the agent reaches production. The deliverable a security or compliance owner signs against is the self-contained governance report: every action tagged with its rung, every promotion evidenced, every blocked promotion and auto-demotion on the record. It composes with our other reliability work, an ingest classifier is a natural rung-1 safety gate, and a rung tenure exports as a scored trajectory our TraceKit tooling can trend over time.

It is the autonomy-governance leg of a reliability practice that also covers cost, trajectory, and deliverable quality. It composes cleanly with its sibling projects: TraceKit measures the token bill and grades the execution trajectory, ContextLedger cuts the bill, RubricGate grades the final artifact against a rubric, and Trust-Ladder Deployer governs how much autonomy the agent is allowed to hold and revokes it automatically when accuracy slips. TraceKit says the run was healthy, RubricGate says the output is correct, and Trust-Ladder says the agent has earned the scope it is acting with.

Technologies#

The throughline: enterprises earn agent autonomy one rung at a time, and the earning has to be evidenced. Trust-Ladder Deployer binds the permissions at each rung, gates every promotion on an eval that actually blocks an unready agent, isolates high-blast-radius fixes in a real sandbox, and auto-demotes the moment accuracy drifts, producing the rung-tagged audit trail that justifies every grant of scope.