A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.
Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample
My agent checks its tests with mutation testing. It changes one line of the real code, runs the tests, and expects at least one test to fail. A mutant that no test catches means a test is missing.
The mutants run in a copy of the repository, not in the real one. There is one more guard. Before and after each mutant, the check records the modification time and size of the files in the real data folder, where the ledgers live. If anything there changed, it stops and prints which files changed. A mutant should never reach real data, so a change there is treated as a possible leak.
The stop
The agent had registered eight mutants for a new judge function and the lines that connect it to the command that prints every experiment's verdict. On the first run, one mutant was caught. Then the check stopped: the real data folder had changed.
The two changed files were Threads ledgers: one written at 10:40:20 and one at 10:41:11.
Leak or not?
Before treating it as a leak, the agent looked at the clock. The machine runs a scheduled task that collects Threads data four times a day: 10:40, 13:40, 16:40 and 21:10. Its last run time was 10:40:01. The two files were written 19 and 70 seconds after that.
The agent also confirmed that the source folders showed the same uncommitted changes as at the start, and nothing new.
So the writes came from the scheduled task. The mutant had not leaked. The guard did what it was built for: it saw a change it could not explain and refused to continue. Working out the reason was a separate step.
The next scheduled run was at 13:40. The agent ran the remaining seven mutants before then. All seven were caught, with none surviving. Together with the first run, that makes eight of eight.
The same stop, a session earlier
This was the second time in two sessions. In the session before, the check stopped for a reason the agent had caused itself. It had started a real data collection run at the same time as the mutation check, and the collection updated the ledgers.
Both stops were correct. In both cases the cause was something else writing to the real ledgers while the check was running.
The rules
- A guard that stops is asking a question. Answer it with evidence, such as file times and task run times. Don't guess, and don't turn the guard off.
- Know what else writes to your data, and when. Scheduled tasks are part of the environment your checks run in.
- Don't run collectors and checks that watch the same data at the same time. Run the check in the gap between scheduled writes.
Where this comes from. Every post here comes from one setup I run daily: a CLAUDE.md, memory files the agent reads before it touches anything, and a separate auditor agent that returns PASS or FAIL. The first 3 chapters of the book that walks through it are free as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample
The full edition is 11 chapters plus 4 ready-to-use templates (CLAUDE.md starter, memory files, auditor checklist, measurement guide) and a hands-on section for every chapter, $19 as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code
Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.
Top comments (0)