DEV Community: RIN WORK LAB

Before You Let an AI Agent Run Unattended Overnight: The Pre-Flight Checks That Actually Matter

RIN WORK LAB — Sat, 24 Oct 2026 00:39:08 +0000

Before You Let an AI Agent Run Unattended Overnight: The Pre-Flight Checks That Actually Matter

The first unattended run is the one everyone remembers. Not because it usually goes wrong — but because nobody can say what would have caught it if it had.

Most people prepare for an overnight agent run by improving the prompt. That is the equivalent of checking the weather by writing "please don't rain" on the calendar. The checks that matter are not in the prompt. They are in the setup around the agent, and every one of them can be done before tonight.

Here is the checklist we run before any agent gets its first night alone. Six items. None of them take long. Skipping any one of them has a specific failure attached to it — and these are not hypotheticals, they are the standard ways unattended runs go bad.

1. Pin the working directory — and prove it

The check: The agent's world for tonight is exactly one project directory. Start the session there. Use absolute paths in the brief, not relative ones. Then, before the real run, have the agent print its working directory, list what it can see, and confirm it cannot see the project next door.

Why it matters: Relative paths are the quiet killer. ../build from the wrong starting directory is a different folder than you intended, and the agent will not pause to wonder about it. A session that starts in the wrong place inherits the wrong files, the wrong config, and the wrong delete targets — all with complete confidence.

The failure it prevents: The cleanup that cleaned the wrong tree. The edit that landed in the production checkout instead of the staging one.

2. Test the destructive-command guard with the actual commands

The check: If you have a hook or permission rule that blocks recursive deletes, force pushes, and raw disk writes, do not just confirm it exists. Run the exact commands it claims to stop — aimed at a throwaway directory — and watch them get blocked.

Why it matters: Guards fail silently in embarrassing ways. A hook file without execute permission may never run at all, and nothing tells you. A guard written for rm -rf may not see git -C /somewhere clean -fdx, or the same command wrapped in bash -c. A guard you have not fired is a hope, not a guard.

The failure it prevents: Discovering at 7 a.m. that your safety net was decorative — it was installed, it was configured, and it never once engaged.

3. Make secrets unreachable, not just unread

The check: Deny the agent's tools access to .env, .ssh/, credential stores, and token files at the permission level — so the read fails no matter what the task seems to require. Then grep your logs and transcripts from a test run to confirm no secret-shaped strings ended up in them.

Why it matters: "Don't read the secrets file" is an instruction, and instructions lose to context. A config file the agent was asked to debug sits one directory away from the credentials it uses, and "just checking" is a very plausible next step. Worse, a secret that enters the context tends to leave with it — into logs, summaries, and commit messages.

The failure it prevents: Rotating every key you own on a Saturday morning because one of them turned up in a run log.

4. Set the runaway limits before the loop, not during it

The check: Give the session hard budgets: a maximum number of tool calls, a maximum number of shell commands, and a wall-clock limit. Write the stop conditions into the brief — what "done" looks like, and what "stuck" looks like. If your setup supports it, stop automatically when the same command fails the same way three times in a row.

Why it matters: A looping agent is not malicious, it is persistent. It will retry a failing approach with fresh enthusiasm for hours, spending money, hammering an API, or re-running a job that already ran. The time to decide how much persistence is too much is before the run, in numbers — not at 3 a.m., by waking up.

The failure it prevents: The duplicate execution — the job that "looked like it failed," got retried, and charged, emailed, or wrote twice.

5. Leave a kill switch, and a log you can read from your phone

The check: Two things. First, a way to stop the run that does not require negotiating with the agent: a stop file the wrapper checks between steps, or a process you can kill cleanly. Second, an append-only run log — one line per step, timestamped, written somewhere you can check without sitting down at the machine.

Why it matters: If you cannot stop it, it is not automation, it is a commitment. And if you cannot see it, you will learn about problems from their consequences instead of from the log. The log has a second job, too: making silence visible. The most dangerous failure is the job that simply never ran — no error, no alert, discovered weeks later from missing data. You can only catch an absence if you expected a presence.

The failure it prevents: The run you watched go wrong in slow motion with no off switch — and the run that never happened at all.

6. Do the morning-after verification, every time

The check: When you wake up, do not read the agent's summary first. Read the destination. Check that the files it claims to have written actually exist, with the content it claims, in the place it claims. Compare the run log line count against the summary. If the job made a prediction or a claim ("this fixes the overlap"), check whether it held — and write down the verdict before you fix anything.

Why it matters: An agent's summary is a claim, not evidence. Writes fail partially: three of five files land, the fourth is truncated, the fifth went to the wrong path — and the summary says "done." Verification is what turns "the agent said so" into "checked." It is also how trust gets calibrated honestly: an agent that passes thirty verified mornings has earned more autonomy. One that has merely reported thirty good mornings has earned nothing.

The failure it prevents: Building the next three weeks of work on top of an output that was never actually there.

The checklist, condensed

Print this. Run it before the first unattended night, and re-run items 2–6 whenever the setup changes:

[ ] Working directory pinned to one project; absolute paths; contents verified
[ ] Destructive-command guard fired with the real commands, against a throwaway target
[ ] Secret paths denied at the permission level; logs grepped for leaks
[ ] Tool-call, shell-call, and wall-clock budgets set; stop conditions written down
[ ] Kill switch tested; append-only run log writing somewhere you can see it
[ ] Morning-after verification scheduled: read the destination, not the summary

One honest limitation, because it matters: pattern-based guards are defense in depth, not a sandbox. A sufficiently creative command can route around string matching, and any checklist — this one included — reduces risk rather than eliminating it. That is the actual deal with unattended machinery, in every field that runs it. The goal is not an agent that cannot fail. It is an agent whose failures are small, visible, and stoppable.

The free sample, and the full system

If you want the starting pieces, we put the smallest useful set into a free sample of our pack: the 10-point agent safety checklist, a minimal CLAUDE.md skeleton you can copy into a project today, and a working guard hook that blocks the most common destructive shell commands before they execute.

Free sample (pay what you want, $0 works):
https://rinworklab.gumroad.com/l/ai-agent-operations-safety-pack-free-sample

The full AI Agent Operations & Safety Pack is the system the checklist points at: the safety principles and staged permission model, the SKILL.md specification, the complete guardrail suite with permission profiles and its automated test suite, verification formats, always-on operations design (overlap prevention, missed-run policy, liveness monitoring), incident runbooks, and the four-gate rollout method for earning autonomy in stages.

Full pack (Standard $99 / Complete $179, 30-day refund):
https://rinworklab.gumroad.com/l/ai-agent-operations-safety-pack

Run the six checks tonight and your first unattended run is already safer than most. The pack is for when you want the whole discipline, written down, tested, and ready to hand to a team.

Written by RIN WORK LAB, from running unattended automations in production and from the manufacturing floor's discipline: safety first, one variable at a time, verify before you proceed.

Your Agent Deleted the Wrong Directory at 3 A.M. — and the Prompt Said 'Be Careful'

RIN WORK LAB — Fri, 23 Oct 2026 23:27:13 +0000

Your Agent Deleted the Wrong Directory at 3 A.M. — and the Prompt Said "Be Careful"

Every team running AI agents unattended has a version of this story.

The agent was told to clean up build artifacts. It did — plus a directory
one level too high, with total confidence, at 3 a.m. Or it read .env
into context while "just checking the config." Or a scheduled job ran
twice because the first run looked like it failed, so something retried
it — and two agents wrote to the same state at once.

And then there is the failure that makes no sound at all: the nightly
job that simply stopped running. No error, no alert. You find out three
weeks later, from the missing data.

None of these are model-quality problems. A smarter model would have
made the same mistakes, faster and with better prose. They are
operations problems — and operations problems are not fixed by
instructions.

Instructions are requests. Systems are enforcement.

"Be careful with deletions" in a prompt is a request. It competes with
every other token in the context, it decays over a long session, and it
loses to a plausible-sounding instruction buried in a file the agent was
asked to process.

What actually stops a bad tool call is a mechanism that does not depend
on the model remembering to be careful:

A hook that inspects the command before it executes and blocks the destructive ones — recursive deletes aimed outside the project, raw writes to block devices, curl | sh.
Permission rules that deny secret paths outright, so .env, .ssh/, and credential stores are not readable in the first place, no matter what the task seems to require.
A session budget — tool calls, shell calls, elapsed time — so a looping agent stops itself instead of running until the bill or the damage says otherwise.
Confirmation gates for irreversible, shared-state operations: force pushes, protected branches, production deploys. Not blocked — but never silent.

This is not new thinking. It is how every other discipline that runs
machinery unattended already works. Nobody writes "please be careful"
on a factory press and calls it a safety system. There is a guard, a
lockout procedure, and a checklist — because the cost of the bad day is
asymmetric.

The five pieces of an agent operating system

Running agents in production, we ended up with the same five layers
every time. None of them is glamorous. All of them earn their keep.

1. Written principles and prohibitions. Not in your head — in the
instruction file the agent actually reads. Absolute prohibitions
(production data, secrets, external sending, money movement), read
scope vs. write scope as separate lists, and a staged permission model:
read-only → drafting → approval → limited autonomy, with promotions
earned by evidence, not granted by optimism.

2. Guardrails (enforcement code). Hooks and permission profiles
that physically stop dangerous calls. In our case, for Claude Code:
a destructive-command guard, a secrets guard, a git/production
confirmation guard, and a session-budget guard — with ready-made
settings profiles for each permission phase. Ours were verified by
live-fire testing on Claude Code 2.1.309, and they ship with their
test suite, because a guard you have not tested against the commands
it claims to stop is a hope, not a guard.

3. Verification. Writes are read back from their destination, or
they are unverified — not "done." And when an operation makes a claim
("this change will fix the overlap problem"), the claim is recorded
in gradable form before the outcome is known, then graded later:
HIT, MISS, HOLD, or INVALID. Editing the prediction after seeing the
result is how operations fool themselves.

4. Always-on discipline. Scheduling that prevents overlap and
decides in advance what a missed run means (skip it, catch up once,
catch up all). State files with a single writer and atomic updates. A
run log you monitor for absence — silence is an alarm, not a relief.

5. Runbooks and rollout gates. The first five minutes of an
incident, written before the incident: runaway agent, duplicate
execution, partial failure, silent failure. And a road to production
with gates — Backtest → Shadow → Limited Production → Full
Automation — each with pass criteria and, just as important, demotion
rules for when an automation has to go back a stage.

Be honest about the limits

Pattern-based hooks are defense in depth, not a sandbox. A determined
or sufficiently confused agent can route around string matching; the
pack we built says so in its own documentation, because a guardrail
whose limits you don't know is decoration. The point of the layers is
that no single mistake — one misread instruction, one bad retry, one
silent scheduler — gets to become the incident by itself.

Try the free sample

We put the smallest useful pieces into a free sample:

the 10-point agent safety checklist,
a minimal CLAUDE.md skeleton you can copy into a project today,
a working sample hook that blocks the most common destructive shell commands before they execute.

Free sample (pay what you want, $0 works):
https://rinworklab.gumroad.com/l/ai-agent-operations-safety-pack-free-sample

The full AI Agent Operations & Safety Pack turns those samples
into the complete system — the principles, the SKILL.md specification,
the full guardrail suite with permission profiles and its 137-case
test suite, verification formats, always-on operations design,
incident runbooks, and the four-gate rollout method:

Full pack (Standard $99 / Complete $179, 30-day refund):
https://rinworklab.gumroad.com/l/ai-agent-operations-safety-pack

No guarantees — there aren't any, here or anywhere. Just fewer 3 a.m.
incidents, and failures that show up where you can see them.

Written by RIN WORK LAB, from running unattended automations in
production and from the manufacturing floor's discipline: safety
first, one variable at a time, verify before you proceed.