The best engineers have stopped writing one-off prompts and started writing loops: systems that prompt an agent, check the output, and decide the next step until the work is done. LoopRails is rails for those loops in two senses. Like Ruby on Rails, it gives you conventions and a working scaffold so you build a loop fast. Like guardrails, it keeps the loop safe to run unattended, with a human at the decisions that actually matter. Fast to build, safe to run.
RAIL · Reversible · Authorized · Interruptible · Logged
Enter your email and I'll send you the LoopRails Kit: the fill-in templates that take an agent loop from idea to safely running, plus the one-page cheat sheet. New essays on loop engineering after that.
No spam. Unsubscribe anytime. The templates are also free to read on the Kit page.
Two questions decide how to oversee any action: how bad it is if the action goes wrong (the consequence), and whether a person can actually catch and stop the mistake in time (the controllability). The hardest corner is high consequence plus low controllability, where asking a human to review just gives you a rubber stamp. Tap a corner to see what to do.
When the stakes are high but a person can't reliably catch the mistake in time, a confirmation prompt only produces a rubber stamp, and a scapegoat when it goes wrong. So don't rely on review. Prevent the bad outcome: make the action reversible, limit how far the damage can spread (the blast radius), run it in a sandbox (an isolated, contained environment), force a deliberate decision, or block the action and hand it to someone who can decide.
Do: Sandbox-First · Capability Lock · make it reversible · escalate
These failures are real and well-documented, in aviation, medicine, finance, and 2026 studies of AI coding agents. Each card shows what goes wrong and the design change that prevents it. Press “See the fix” on any card.
Apply these to each action your agent can take, not to the system as a whole. They double as four questions for standup: Did we grade this action? How is it guarded? What do we show the person reviewing it? Have we checked the oversight actually works?
Rate each action by how far harm could spread, whether it can be undone, and how bad it is if wrong. That gives a grade from G0 (trivial) to G3 (critical).
Match the controls to the grade. Where a person can't realistically catch the mistake in time, prevent the bad outcome instead of asking them to review it.
Design the review moment well: make the action and its consequences clear, show where the request came from, help the person spot problems, and don't spend more of their attention than the action is worth.
Test whether people actually catch errors, not just whether a review step exists. Attack your own oversight the way you'd attack the agent.
Answer four questions about an action your agent is about to take. LoopRails gives you its grade, the right level of control, and a warning if asking a human to review it would just be a rubber stamp.
RAIL is a checklist of four properties any well-governed action should keep: Reversible, Authorized, Interruptible, Logged.
You can undo it, or the damage is contained. Save hard stop-and-ask gates for the few actions that truly can't be undone.
Read in depth →The agent has only the permissions it needs for this grade, no more. For high-stakes actions, whoever proposes the action isn't the one who approves it.
Read in depth →Anyone can stop it, a teammate, an automated monitor, even the end user, and a single kill switch halts everything at once, no questions asked. Make stopping cheap and blame-free so people actually do it.
Read in depth →It leaves a record you can inspect later, so you can prove the oversight actually catches mistakes, not just that it exists.
Read in depth →The method is tool-agnostic, but the controls are real settings. Here's where each step lives in common agent platforms, so "prevent, don't review" becomes a specific switch to flip, not a slogan.
| Platform | Grade decide what to gate | Guard prevent / sandbox | Interrupt stop it in time | Log prove it |
|---|---|---|---|---|
| Claude Code | Permission rules allow/ask/deny per tool; gate by risk in hooks A-2 |
Sandboxed bash, no-network containers, plan mode; /rewind checkpoints undo covers edits, not bash side-effects A-4 |
Esc interrupts mid-run; kill the session | Session transcript; a hook can log every tool call |
| Cursor | Command allowlist + auto-run toggle the denylist is a UX affordance, not a boundary A-14 | Run in a devcontainer/sandbox; keep auto-run off for writes & shell | Stop button; revert through git | Lean on git history as the audit trail |
| GitHub Copilot agent | Tool/command approval prompts; org & repo policies | Runs in an ephemeral Actions sandbox; PR review before merge is built-in maker-checker | Cancel the workflow run | Actions logs + PR & commit history |
| Bedrock Agents + Guardrails | Action groups with require confirmation; Guardrails policies per topic/PII | IAM least-privilege on action Lambdas; VPC isolation; Guardrails block denied content | Stop the invocation; disable the agent alias | CloudTrail + CloudWatch model-invocation logging |
| LangGraph / LangChain | interrupt() before chosen tool calls; route by risk in the graph A-8 |
Checkpointer gives durable pause/resume + a human-approval node; run tools in sandboxed executors | Interrupt and don't resume; cancel the run | LangSmith tracing + checkpoint history |
| n8n | Toggle Human review per tool (v2.6+), gate high-risk tools (send / modify / delete), auto-run the rest | Scope each tool's credentials; isolate the instance the gate is approve/deny, so prevent irreversible actions, don't just review | Workflow pauses for approval via Slack / Telegram / Chat; Deny cancels; stop the execution | Per-execution run history |
Platform features as of mid-2026 and they change often, verify against current docs. The pattern that survives every release: a denylist of commands is not a sandbox A-14.
Named designs you can point to in a meeting, most borrowed from industries that have already learned these lessons the hard way, plus the recurring mistakes you want to be able to name and stop.
Five questions, about a minute. You'll get a level from 0 to 4, and the single change that would move you up fastest.
Copy-paste artifacts so the framework leaves this page with you, one for your agents, one for your pull requests, one for the wall.
Three levels of depth, each one click away. Start with the playbook; follow the citations as far down as you want to go.
The hands-on field guide: a cheat sheet, the pattern and anti-pattern decks, questions to ask in standup, and ready-made recipes.
Open the playbook →The full method (sections 0-10): the consequence-vs-controllability model, the grades, the autonomy ladder, how a single oversight moment is structured, and how to validate it.
Open the framework →366 annotated sources across 17 topics, aviation, medicine, finance, AI safety, and human-computer interaction. Every claim on this site traces back here.
Open the codex →The loop is the unit of work now. LoopRails helps you build one the way Ruby on Rails made web apps fast, with conventions and a working scaffold, and it gives you the guardrails to run it unattended without getting hurt. Start with the principles, grab the starter, keep the templates close. The patterns here are grounded in research, collected in the Loop Engineering Codex.
Ten principles for loops that are fast to build and safe to run.
A real, runnable guarded loop: verifier, caps, action grades, kill switch. Python, no dependencies.
Done-condition spec, Loop Card, guardrails checklist, model-adaptation worksheet.
Build the loop (Define, Build, Verify), then keep a human at the end (Grade, Guard, Run, Learn). The grade is the hinge that lets a loop be fast and safe at once.
From prompts to context to harnesses to loops, and why the verifier is the hard part.
Read →Goal and done-conditions, the verifier, memory in a file, subagents, and guardrails on by default.
Read →Test-fixing, refactor, data-cleaning, and experiment loops, each with a done-condition and a verifier.
Read →An automated check, not your gut, decides whether each change improved things.
Read →The research on verification functions: the strength spectrum, reward hacking, and whether the verifier replaces the spec.
Read →An inner loop converges on the verifier; an outer loop clarifies intent. How loop engineering closes the delivery gap without waterfall.
Read →Real wins and failures, with the numbers: DeepSeek-R1, AlphaCodium, o3, SWE-agent, and reward hacking. The verifier and the cost.
Read →What goes in the window each turn, and how to keep a loop effective instead of drifting.
Read →Every tool and skill you connect spends context and lowers accuracy. How many is too many, backed by research.
Read →Predict what an action will do before the loop commits to it, as a preview, a planner, and an offline eval.
Read →When more agents help, when they just add failure surface, and the oversight each one needs.
Read →How to adapt the model under your loop, and when each option is worth the cost.
Read →What you can and can't change on a closed API model versus an open-weight one.
Read →Grade what the loop can do, cap the blast radius, and stop it when it runs away.
Read →Turns, spend, score trend, and the signals that trip the circuit breaker.
Read →Retries, rollback, checkpoints, and resuming a crashed run, from durable execution and agent research.
Read →The recipe side of LoopRails. The ways to design an agent and design RAG, in plain English, each recipe with the same four lines: what it is, when to reach for it, how it fails, and how to fix it. Open the Cookbook →
Chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer.
Read →ReAct, reflection, plan-and-execute, tool use, memory, single vs multi-agent.
Read →Chunking, embeddings, hybrid search, reranking, query transforms, filtering.
Read →Contextual retrieval, agentic RAG, corrective RAG, self-RAG, GraphRAG, evaluation.
Read →Practical, sourced deep-dives on overseeing AI agents, what to gate, what to prevent, and how to make oversight actually work.
How agents take actions on their own, and why oversight must govern actions, not outputs.
Read →What HITL means for AI agents, the three forms it takes, and when it's the wrong tool.
Read →When a human in the loop actually adds safety, and when it's false comfort.
Read →How to decide what to gate, and build approval gates that aren't rubber stamps.
Read →Sandboxes, kill switches, least privilege, and more, matched to the risk.
Read →A 2026 study of 17,022 agent skills, and why no human catches the leak.
Read →LoopRails decides how much human oversight each action needs. The BRACE Framework is its security counterpart, practical controls for the agent's configuration and infrastructure (nine controls plus three observability requirements). Use them together: oversight design on top, a security baseline underneath.
Explore the BRACE Framework ↗Human-in-the-loop (HITL) means a person reviews, approves, or can intervene in an AI system's actions before or while they take effect. For AI agents it usually appears as an approval prompt before a risky action, an edit/review step, or an interrupt-and-resume control. LoopRails argues the key question isn't whether a human is "in the loop," but whether they can realistically catch a mistake in time. Read the full guide →
Not automatically. In a 2026 study of AI coding agents, requiring plan approval reduced risky actions, but humans still caught a bad action only ~9-26% of the time. An approval click stops some mistakes but barely improves a person's odds of noticing one. Real AI safety comes from matching the control to the action and preventing outcomes a human can't catch. See the evidence →
When the action is high-consequence and a human can realistically catch the mistake in time. If the stakes are high but a person can't catch it, because it's too fast, too subtle, or too frequent, an approval gate becomes a rubber stamp. In that case, prevent the action instead: make it reversible, sandbox it, or cap its blast radius. Grade an action →
Human-in-the-loop means the person is part of each action (review/approve before it proceeds). Human-on-the-loop means the system runs autonomously while a human monitors and can intervene or stop it. LoopRails treats the human as the escalation tier and reserves in-the-loop approval for actions where review genuinely catches errors. Compare the modes →
LoopRails uses four steps: Grade each action by consequence (G0-G3), Guard it with controls that match the grade, Show the reviewer the real action and consequences (not a tidy summary), and Prove the oversight catches seeded errors. Every governed action should stay Reversible, Authorized, Interruptible, and Logged (RAIL). Read the framework →
The lethal trifecta is when an AI agent has all three of: access to private data, exposure to untrusted content, and a way to send data out. Together they enable data exfiltration via prompt injection. Removing any one leg, for example, making the agent read-only or cutting its network access, is the cheapest guardrail. How it works →