Your AI Agent Doesn't Need More Prompts. It Needs an Operating System.

If you run an AI agent on anything real — a production repo, a scheduled job, a business process — you already know the feeling. The agent is capable and fast, and most of the time it does exactly what you meant. The problem is the other times, and they have a specific shape.

Agents delete the wrong directory with total confidence. They pull a.env file into context because it looked relevant. They run a job twice because the first run "looked like it failed." And the most dangerous failure makes no sound at all: the scheduled job that simply never ran, discovered three weeks later.

The usual response is to add more instructions. "Be careful." "Always confirm before deleting." This does not work, and it is worth understanding why: instructions are requests the model interprets in context, and context is exactly what goes wrong in an incident. The fix is not a better prompt. The fix is an operating system around the agent — controls that hold even when the model is having a bad day.

Here is the checklist I now run before any agent of mine is allowed to work unattended. It is distilled from operating always-on automations in production, and from an older discipline: manufacturing lines, where safety first and one variable at a time are not slogans but survival rules.

1. Write the absolute prohibitions down. Not "try to avoid," but a short, explicit list of never-events: never delete outside the workspace, never read credential files into context, never force-push, never spend money without approval. If a prohibition only exists in your head, the agent does not have it. Put it in the project file the agent reads first, and keep it short enough that it is never ambiguous.

2. Widen permissions in stages, and classify tasks by risk. An agent should earn autonomy. The stages I use: read-only first, then drafting (it prepares, a human sends), then approval-based actions, then limited autonomy for a narrow, named set of operations. Each stage has explicit entry criteria. Crucially, risk is classified per task, not per agent — the same agent can be read-only for your finances and autonomous for your file organization.

3. Enforce with mechanisms, not memory. Anything that matters should be enforced by something that does not depend on the model remembering. In Claude Code, hooks can physically block destructive command patterns and protect secret paths before a tool call executes. Permission profiles can require confirmation for the operations you listed as never-events. These pattern-based controls are defense in depth, not a sandbox — any honest write-up should say so — but they convert a whole class of "the model forgot" accidents into non-events.

4. Verify by reading back, and grade predictions before outcomes are known. When an agent says "done," the only trustworthy version of that sentence is a read-back: the file exists, the bytes match, the numbers reconcile. Separately, when an agent makes a judgment call — a forecast, a recommendation — ask it to state the claim in gradable form before the outcome is known, then grade it later: hit, miss, or invalid. This one habit eliminates most retrospective self-deception, yours and the model's.

5. Design schedules so that silence is an alarm. Unattended jobs fail quietly. Decide in advance what a missed run means: skip it, catch up once, or catch up all — and log every run to a simple append-only file you can monitor. A job that leaves no trace when it dies will eventually die at the worst possible time. Liveness monitoring turns "nothing happened" into a signal.

6. Write the runbook before the incident. The first five minutes of an agent incident are not the time to improvise. Four runbooks cover most of reality: the runaway loop, the duplicate execution, the partial failure, and the silent failure. Each needs a stop mechanism (a kill switch the agent itself respects), a state check, and a record template — because the incident record is what turns one bad night into a permanent prevention.

7. Roll out through gates, not enthusiasm. Borrow the staging discipline from any field where mistakes are expensive: backtest, then shadow (the agent acts, nothing ships), then limited production at small size, then full automation. Each gate gets pass criteria and demotion rules. An automation that misbehaves in limited production goes back a gate; it does not get a warning and a promotion.

None of this makes an agent "safe" in the absolute sense, and you should distrust anyone who promises that. What it does is move the failures from the catastrophic, silent kind to the visible, recoverable kind — which, in operations, is most of what safety ever means.

I maintain a packaged version of these materials — the AI Agent Operations & Safety Pack (principles, the CLAUDE.md/AGENTS.md skeletons, working Claude Code guardrail hooks with permission profiles, verification formats, runbooks, and the rollout checklist), built from the production setup described above. There is a free sample if you want to see the format first: https://rinworklab.gumroad.com/l/ai-agent-operations-safety-pack