The Gap Every Scheduled AI Agent Has

If you're running an AI coding agent on a recurring schedule against its own codebase — not just chatting with it interactively — there's a specific, easy-to-miss failure mode worth checking for before you trust it unattended: it can fix its own bugs and then forget it ever did.

The gap

By default, an AI coding agent that touches a git repo develops on its own fresh, isolated branch and won't push anywhere else without being told to. That's the right safety default for one-off interactive coding — you don't want an agent quietly rewriting your main branch while you're not watching.

It stops being safe the moment the same automation runs on a schedule, unattended, with no human reviewing anything afterward. Each scheduled run starts a brand-new session, fresh from main, on its own throwaway branch. If that session finds and fixes a bug in the underlying scripts, the fix lives only on that branch — one nobody will ever look at again. The next scheduled run has no idea it exists, and no way to find out.

The fix

Two layers, neither of which touches the automation's actual logic:

1. A standing rule in the repo's own root instructions

Most agent coding tools read some persistent instructions file at the start of every session (Claude Code uses CLAUDE.md). That's the one place guaranteed to be read regardless of which schedule, trigger, or human started the session — so it's the right place for this rule: verified code fixes get merged to main before the session ends, because an unmerged fix is as good as lost. Scoped narrowly — only fixes actually tested against live data, never anything speculative.

2. The same instruction, explicitly, in every recurring automation's own prompt

Belt and suspenders. The root-instructions rule covers any session working in the repo — but a scheduled routine's own stored prompt is worth stating it again in, right at the point the routine reports its results, since that's the exact moment a session knows whether it fixed something.

The prompt I now use, verbatim

If you change any code or script files in this repo, and you've tested the change and confirmed it actually works (ideally against live data, not just a dry run) — merge it to main before ending the session, rather than leaving it on an isolated branch. An unmerged fix is invisible to every future session and will likely get "rediscovered" and fixed again from scratch. A plain fast-forward push ( git push origin <branch>:main) is normal; force-pushing or rewriting history on main is not. If a fix is large, uncertain, or touches something you're not fully confident about, ask first instead of merging automatically.

If you're running more than one scheduled routine against the same repo, add it to each routine's own prompt directly, not just the shared instructions file — it costs a paragraph, and it's the difference between a bug fixed once and a bug fixed every time it's rediscovered.

How I found it

This isn't theoretical — it's how I caught it in my own finance-automation routine. Two real bugs (a PDF-extraction call sending the wrong content type to the Claude API, and a field-name mismatch that meant a bank account selection was never actually seen by the script) each got diagnosed, fixed, and tested by one session — and then diagnosed, fixed, and tested again from scratch by a different session the next day, neither aware the other's work existed. Same bugs, same fixes, two unmerged branches, nothing wrong with the diagnosis either time — the fix simply never reached where the next session started from.

One check on the old branch was enough to confirm it:

git log origin/main..origin/<branch>

The commits were sitting there, untouched, matching what had just been redone independently. The merge itself is boring on purpose — a verified fix with nothing built on top of it fast-forwards onto main cleanly, no rebase or force-push required. That's now built into how I set up every scheduled automation from the start, not bolted on after the fact.

Worth knowing if you're setting this up yourself

• This isn't unique to Claude Code. Any agent tool that develops on an isolated branch by default — most of them, for good reason — has the identical gap the moment you point it at a repo on a recurring, unattended schedule.
• Multiple concurrent routines on one repo is a related, milder version. Once you have more than one scheduled automation writing to the same main, pushes will occasionally land out of order — one routine's push rejected because another landed first. That's normal concurrent git usage, not a bug: fetch, merge, push again.

This is exactly the kind of quietly-expensive gap Dan's Systems checks for when setting up AI automation for a business — not the flashy part, but the part that decides whether the flashy part still works next week. If you're running (or thinking about running) an AI agent on a schedule, get in touch.