AI Infrastructure

Field guide · free, no email required

The Deployment Readiness Review.

A standalone review for any agent that can change external state, from the book Designed to Be Debugged. Scale the depth to the consequence of the action: a text-formatting assistant may need only basic traceability; an agent that changes production infrastructure, communicates with customers, moves funds, or modifies access should face a much stronger gate.

01

Define the deployment claim

Write one falsifiable sentence: this agent may perform these actions, for these users, within this environment, up to this consequence limit, because this evidence shows that required controls and recovery paths work. If the claim cannot name an operating context and authority boundary, it is too broad to approve.

  • The permitted actions and prohibited actions are explicit.
  • The risk tier and consequence limit are named.
  • Stop conditions are measurable.
  • The residual-risk owner is a person or accountable function.
  • Material changes that invalidate approval are listed.
02

Bind identity, authority, and provenance

For every consequential run, record the identities and versions of the user, agent, model, prompt, policy, tools, memory, knowledge sources, credentials, evaluators, and approvals.

  • Delegated authority is narrower than the requesting identity's maximum privilege.
  • Credentials are issued just in time and expire promptly.
  • Model, policy, prompt, and tool versions can be reconstructed.
  • Retrieved evidence carries a timestamp and source identity.
  • Human approvals identify the approver, scope, decision, and expiry.
  • Evidence retention and deletion rules are documented.
03

Separate the action states

Do not infer execution from model language. Record these states independently: Planned, Requested, Authorized, Attempted, Executed (the target system durably committed the operation — acknowledging or queueing is not enough), Observed, and Verified.

  • Every transition has an event identifier and timestamp.
  • A failed or timed-out state cannot be reported as success.
  • Verification uses a source other than the agent's own claim where feasible.
  • Partial completion and compensating actions are visible.
04

Inspect the causal trace

The trace should connect the original request to the observed outcome without pretending to expose a model's private mental state.

  • Request, goal, constraints, and success criteria are preserved.
  • Evidence and context age are visible.
  • Tool intentions, arguments, responses, and errors are correlated.
  • Policy decisions and approval checkpoints are explicit spans or events.
  • External state deltas are recorded at the correct system boundary.
  • Sensitive content is redacted without destroying investigative value.
  • Missing telemetry is itself a visible failure condition.
05

Put control outside the model

An agent should not be the sole authority deciding whether its own high-impact action is acceptable.

  • Least privilege and least agency are enforced externally.
  • Budgets limit cost, duration, recursion, and action count.
  • Sandboxes and egress controls bound the environment.
  • Invariants prevent forbidden state transitions.
  • High-risk actions require independent approval or a second control.
  • Circuit breakers, kill switches, and credential revocation work under load.
  • The system can quarantine an agent without destroying evidence.
06

Test failure, not only success

Run at least six synthetic scenarios — ambiguous authority, stale context, partial or misleading tool output, conflicting incentives, missing telemetry, and a high-impact irreversible action. Measure four outcomes: Completion (did the legitimate task succeed?), Recovery (did the system return to a safe state?), Restraint (did the agent stop or ask when evidence was inadequate?), and Inspectability (can an independent reviewer reconstruct what happened?).

  • Scenarios cover the highest-consequence paths, not only common paths.
  • Tests include model, tool, memory, policy, credential, and telemetry failures.
  • Negative results are retained and influence the deployment claim.
  • Repeated-run consistency is measured.
  • The evaluation harness and evaluator versions are pinned.
  • Coverage gaps are named instead of averaged away.
07

Prove recovery

Recovery is a designed capability, not a sentence in an incident plan.

  • Checkpoints exist before irreversible or high-cost actions.
  • Rollback and compensating transactions have been exercised.
  • External credentials can be revoked quickly.
  • The blast radius can be enumerated from trace and provenance data.
  • Incident responders can preserve evidence while containing the system.
  • A degraded safe mode exists when telemetry or policy services fail.
08

Maintain a living assurance case

A readiness review expires when the system changes materially.

  • Every claim links to current evidence, a threshold, and an owner.
  • Evidence has a freshness date and revalidation trigger.
  • Model, prompt, policy, tool, memory, or data changes trigger targeted reruns.
  • Independent reviewers can challenge assumptions and inspect raw artifacts.
  • Exceptions are time-bounded and visible.
  • Approval can be withdrawn automatically when a critical control or telemetry path is unavailable.

The final go / no-go question

Do not ask only, can the agent complete the task? Ask whether, if it acts incorrectly tomorrow, we can detect the boundary crossing, stop further harm, determine what changed, recover safely, and produce evidence strong enough to improve the system and defend the deployment decision.

Decision rule:if the answer depends on a transcript, an operator's memory, or a model's explanation of itself, the system is not ready for consequential autonomy.

From Designed to Be Debugged: Why Autonomous AI Needs State Capture, Replay, and Escalation Before It Can Be Trusted — First Research Edition v1.0.3, research cutoff July 10, 2026. Share this page freely; it is deliberately ungated.

About the book