The Single Source of Truth Pattern for Autonomous Agent Runs
47 routes. 33 pages. 27 hours. $110.
One autonomous agent porting a Laravel app to Go and Next.js.
That's the result. Here's the pattern that made it work.
The drift problem
An agent running for 27 hours without human intervention will drift. Not because the model is bad, but because it has nothing to check itself against.
You've seen this in shorter runs. The agent makes a change. The change introduces a bug. The agent tries to fix the bug by modifying the same file. Three iterations later, it's confidently solving a problem it created while ignoring the original task.
The drift accelerates when the agent can touch its own instructions. If the to-do list is editable, the agent will edit it. If the specification is in a file it can modify, it will "helpfully" update the spec to match what it built instead of what you asked for.
Without an anchor, models hallucinate and tasks break down into nonsense.
The pattern: immutable reference
The fix is structural, not prompting. You need a file the agent can read but never modify.
"You need to have a single source of truth... you need to have something that Roo Code will never touch but is always verifiable by Roo Code. So that's just to make sure the model can never ever get confused about what the instruction is."
Shank,
In the 27-hour porting run, the legacy Laravel codebase served as that anchor. The agent could:
- Read the existing routes and business logic
- Run the existing tests
- Verify its Go/Next.js output against real behavior
But it could not modify the Laravel source. The business logic was verified by checking against something the agent had no permission to change.
The receipts
Out of 47 routes specified in the to-do prompt and 33 React pages planned, 39 routes and 32 pages worked out of the box.
That's 83% route success and 97% page success for a 27-hour autonomous run.
"This full 27 hour run basically only cost me about $110 all in."
Shank,
The cost matters. $110 for a migration that would take a human team days or weeks of context-switching between two codebases.
The tradeoff
The pattern requires upfront work. You need to:
- Identify what the agent should never modify (the reference)
- Configure permissions so it cannot accidentally touch the reference
- Structure prompts so the agent knows to verify against the reference
This is more setup than "run and hope." But for long autonomous runs, the alternative is watching the agent drift into nonsense around hour four.
The immutable reference also means you need a codebase worth verifying against. If your legacy code has no tests, no clear routes, no consistent structure, the agent has nothing stable to check. The pattern works best when the source of truth is actually trustworthy.
Immutable reference vs. unanchored runs
| Dimension | Unanchored approach | Immutable reference pattern |
|---|---|---|
| Drift prevention | Relies on model coherence across thousands of calls | Agent verifies against an unchangeable source |
| Instruction stability | Agent may "helpfully" edit specs to match output | Specs remain outside write permissions |
| Verification method | Manual review at the end | Continuous self-checking against reference |
| Long-run success rate | Degrades significantly after 4-6 hours | Maintains 83%+ success over 27 hours |
| Setup cost | Minimal | Requires identifying and protecting reference files |
How Roo Code closes the loop with immutable references
Roo Code's architecture enables the immutable reference pattern through its permission system and verification workflow. When you configure file restrictions, Roo Code respects those boundaries while still reading from protected sources to verify its work.
The pattern works because Roo Code closes the loop: it proposes changes, runs tests against the reference implementation, and iterates based on real results rather than assumptions. With BYOK (bring your own key), you control costs directly while running extended autonomous sessions.
For long autonomous runs, Roo Code can read your legacy codebase as ground truth, generate new code, run verification tests, and iterate on failures - all while being structurally prevented from modifying the source of truth.
Why this matters for your workflow
The pattern scales beyond porting projects. Any task where the agent runs for extended periods benefits from an immutable anchor:
- Migration: the source codebase is the reference
- Refactoring: the test suite is the reference
- Feature implementation: the spec document (in a read-only location) is the reference
- Documentation generation: the code itself is the reference (treat docs as output, code as canonical)
The key question before any long autonomous run: what can the agent verify against that it cannot change?
If the answer is "nothing," you're relying on the model to stay coherent across thousands of tool calls. That's not a bet that pays off at hour 20.
Give the agent an anchor. Keep the source of truth outside its write permissions.
Frequently asked questions
Stop being the human glue between PRs
Cloud Agents review code, catch issues, and suggest fixes before you open the diff. You review the results, not the process.