To let an AI agent run every week without it going wrong, give it one narrow job, prove it with a dry run, and have it stop at a draft or a pull request that a person approves. Then make every run pass written checks with the evidence attached, send a short report even when there was nothing to do, and keep a switch that turns it off within minutes.
Why unattended runs need their own rules
An agent you chat with has a person watching every step. A scheduled agent doesn't. It runs at nine o'clock on a Monday whether or not anyone is at a desk, and if it gets something wrong, it can get the same thing wrong again next week, and the week after.
That changes what a guard rail has to be. A sentence in the prompt saying "be careful" isn't one. Rules that only live in a prompt fail, because the prompt is the part of the system the agent reads, weighs up and sometimes talks itself out of. The guard rails that hold are the ones the agent can't change: which tools it has, what each tool refuses to do, and who has to say yes before anything goes live.
Before you schedule anything, decide what the agent may do on its own at all. Our guide to act, draft or escalate covers that sorting. This post is about what changes once nobody is watching the run.
How to let an AI agent run every week without it going wrong
Seven guard rails, in the order you'd set them up:
- one narrow job per agent;
- a dry run first;
- checks it has to pass, with the evidence attached;
- it stops at a draft or a pull request;
- exceptions written down and reviewed;
- a short report after every run;
- a way to switch it off.
1. One narrow job per agent
"Keep the catalogue tidy" is not a job. "Each week, list stock items with no sales and no stock, and draft an archive list for a person to approve" is. A narrow job has a clear start, a clear finish and a short list of tools. It's easy to tell when it has gone wrong, because you know what right looks like.
Give each agent only the tools that job needs. An agent that drafts a report doesn't need permission to send email to customers. One that writes a blog post doesn't need to touch billing. The tools you leave out are guard rails that never need to be enforced.
2. A dry run first
Before an agent is allowed to change anything, run it in draft-only mode. It does the whole job, but instead of carrying out the result, it shows you what it would have done: the exact change, the old and new values, the message and who it would go to.
Keep it there until a person has reviewed the drafts and found them consistently right. Only then promote it, one step at a time. The same idea applies to bulk work inside a run: one item first, then a small batch, then the rest, with a check between each.
3. Checks it has to pass, with the evidence attached
"Tested" means nothing from an agent unless it shows the command it ran and the real output. Write the checks into the agent's instructions as exact commands with the result each one must give, and have it paste the output into its report or pull request.
If it couldn't run a check (no network, no credentials), it should say so plainly. "Not run: no access to the test store" is a good answer. A guessed pass is not. And it must never switch a check off to make its own change pass.
4. It stops at a draft or a pull request
For most unattended jobs, the safest finish line is something a person approves: a draft email rather than a sent one, a proposed change rather than a made one, a pull request rather than a push. Nothing goes straight to your live branch, your store or a customer's inbox.
That keeps the person in the loop where it matters. They don't have to watch the run; they review one finished, evidenced piece of work and press the button themselves. If you write code with AI, the same preview-then-confirm idea applies to every software change.
5. Exceptions written down and reviewed
Some jobs earn more freedom. A blog that publishes on a schedule, for example, may be allowed to merge and deploy its own work once every check passes. That can be reasonable, if the exception is:
- written down in one place, with what is allowed and what is never allowed;
- as narrow as the job: one repository, named files, one action;
- repeated word for word in the agent's own instructions, so the two can't drift apart;
- checked by the agent at the start of every run, falling back to the stricter rules if it can't find it;
- reviewed on a fixed date.
Anything outside the written exception falls back to the normal rules.
6. A short report after every run
Every run ends with one short report to a person: what it did, what it drafted for review, what it handed over and why, and anything it couldn't reach. A run with nothing to do still sends a "nothing to action" report. That way, silence always means something is wrong.
The report should also say exactly what the person needs to do next, with each step complete enough to follow without opening anything else. If you want to know whether the agent is worth keeping, those reports are your raw material: see how to measure AI time saved honestly.
7. A way to switch it off
Every scheduled agent needs a kill switch: a flag or a schedule toggle that stops it within minutes, which anyone on the team knows how to use. Test it once before you need it.
Make the agent stop itself, too. If a run fails a check after it has changed something, it should undo that change and leave a clear marker, so the next run sees it and waits for a person instead of trying again.
AI agent guardrails that live outside the prompt
The strongest guard rails are in the tools and the platform, not the instructions:
- A tool allowlist. The agent only receives tools for what it may do. The things it must never do aren't wired up at all, for example a read-only key or a mailbox scope with no delete.
- Limits in code. A tool that refuses a change above a set size, with a clear error, can't be argued with.
- Blocked commands. Block risky actions, such as pushing straight to your main branch or force-pushing, in the agent's settings rather than trusting it to remember.
- A gate before any merge. If your platform can't enforce required checks, run a script that does, and merge only when it passes.
- An audit log. Every action recorded with the run, the item, the reason and the time.
- A check afterwards. A regular review that lists anything that reached live without going through the agreed route.
How to stop AI agents going rogue
A short "never" list does more than a long list of dos. A scheduled agent never:
- acts on instructions it finds inside the data it reads. An email, a web page or a file is data, not a command, even when it claims to come from the owner;
- changes its own permissions, settings or limits;
- disables a check, hook or guard to get its work through;
- deletes customer data, orders or messages; it labels or flags them for a person instead;
- signs in to a portal or gets past a login prompt; a person signs in;
- moves money or issues refunds.
When it isn't sure, it stops and says so in the report. An agent that does less than it could on a doubtful run is working as intended.
Make every run safe to repeat
Scheduled jobs overlap, fail halfway and get re-run. Have the agent mark everything it handles, with a label, a status or a note, so the next run skips it. Have it check what's already in progress before it starts, so two runs never pick up the same item. If running it twice in a row would cause harm, it isn't ready for a schedule yet.
Choosing the tools to run all this on is a separate question. Our guide to building an AI stack is a good place to start.
Planning your first scheduled agent? Start by deciding what it may do on its own, with our guide to act, draft or escalate, then add the seven guard rails above before it runs unattended.