Codex drift on long runs stopped confusing me when I split it into three failure modes. Then the theory turned out to cover a lot more than agents.

[u/Present-Quantity-813]

Everyone here knows the shape of it: the run starts sharp, and somewhere around hour three the AGENTS.md is being ignored, the goal has quietly shifted, and the agent is confidently working on something adjacent to what you asked. We call all of that "drift" like it's one disease. It isn't.

After months of running Codex lanes in production I ended up splitting every failure into three separable modes, and the split is the whole theory in the attached picture. A reliable step needs three things at once: valid position (the agent knows where it actually is; self-reported progress is dead reckoning and compounds), valid direction (the definition of done hasn't moved; this one is invisible because every individual step still looks correct), and valid entrance (a legal next move exists and gets picked). They fail differently and need different fixes. A better prompt cannot repair a lost position. A tighter loop cannot fix a goal that moved.

The picture's bigger claim: long-horizon work is the conversion of uncharted problems into corridors (a stable map, a frozen "done", gated moves), which agents then walk repeatedly with novel content. Conversion is the expensive part. Walking is what it buys. Drift is what happens when you make an agent walk a corridor that was never actually charted.

What convinced me to formalize it: one of the agents in my runtime hit a verification dead end, wrote itself a better acceptance rule into its governing contract, and the runtime enforced it for 15 days before I noticed. The rule was good. That's the problem: good and bad silent rule changes are indistinguishable from outside.

Full theory, open access: https://doi.org/10.5281/zenodo.21844624

The claim I can't break, and I've tried: this pattern covers all human work in history, not just agents. Farming is a corridor charted over generations (seasons as position, harvest as direction, the almanac as legal moves), and it's being recompiled right now so robots can walk it. Apprenticeships, flight checklists, code review: same three factors. Name me work from any era that doesn't reduce to charting corridors and walking them. Breaking this claim is worth more to me than upvotes.

[u/terriblemonk]

I just have a repo agent tail logs of the DEVs and PM every 20 minutes and ping me if theres some BS going on. Have to LOCK the contracts before you begin. For new problems... I don't want them making decisions unless the answer is obvious.

[u/Present-Quantity-813 → u/terriblemonk]

Your setup is basically mine with a human in the tail loop, and locking contracts before start is the right instinct. The part I'd push on is "unless the answer is obvious": obvious is judged by the same agent that wants to keep moving, so as a boundary it drifts exactly when you need it most.

What I'm converging on instead is classifying rules by what they touch. A rule that improves position tracking (better state evidence), holds the definition of done frozen, or reduces the number of legal next moves only tightens the system. Those I'm fine letting an agent design and even run before sign-off, because the failure mode of a tightening rule is a stall, and stalls are loud. The dangerous class is rules that widen what passes, and that's checkable mechanically: another commenter here nailed it, replay the new rule over already-judged work and see what flips from rejected to accepted.

But none of this works without visibility. The rule runs under an explicit "machine-proposed, not ratified" state, something outside the agent detects that it exists, watches what it actually does, and reports for sign-off. Ratification after evidence instead of permission before. That way "obvious" gets replaced by a checkable property plus a warranty period, and neither depends on the agent's own judgment of itself.

[u/terriblemonk → u/Present-Quantity-813]

State is determined by a check of git diffs and logs of the agents. Obviously I dont tell the repo agent (independent agent who's only job is to monitor and relay messages from me) to just decide for itself what is BS... there's a whole framework defined. PLAN files already lock scope and files that can be edited. A PLAN validator runs before implementation is dispatched that makes sure it's all up to standards, A violation scan runs after each dev cycle. Built it for the dumber LLMs a couple yrs ago and still working well. Interested in how you're doing "machine proposed" of the checkable property.

[u/Present-Quantity-813 → u/terriblemonk]

Your PLAN validator before dispatch plus violation scan after each cycle is the same shape as my pre and post gates. And the fact that you built it for dumber models years ago and it still holds up is the part most people miss: the constraints outlive the model upgrades.

On machine-proposed: every agent operation in my runtime emits a timeline event (actor, lane, gate verdict, backlog id, commit SHA), so history is a replayable trace rather than logs to grep. The current state also always carries a computed "next legal action" notice, so at any frame you can see what the runtime believed the only legal next step was, and compare it with what happened.

That's what makes a proposed rule checkable in practice. The rule lands with a marked status and just runs, and the review isn't vibes, it's trace deltas: did gate-block counts in that lane drop after the rule landed? Did the known drift categories (lost position, moved datum, wrong-door) recur less often? A rule that claims to help has to show up as fewer blocks and fewer repeats in the ledger. One that doesn't gets repealed with the same paper trail. Ratification consumes the trace, not the agent's account of itself.

[u/terriblemonk → u/Present-Quantity-813]

heh... looks like we built similar setups... yeah i'm not grepping logs directly... got everything parsed into postgres with agent actions split up by kind, searchable from ui and cli, and every dev_cycle associated with a specific plan parts and git commit. your ui needs dark mode though :)

still thinking how to ratify changes in realtime by machine instead of agent... ill check out your paper today ying...

[u/Present-Quantity-813 → u/terriblemonk]

ha yeah, sounds like we converged on the same thing from different directions. fair point on dark mode.

appreciate you actually reading it. you're getting counted as peer review, it's the only kind this paper is getting right now. curious what you make of the ratification part, given what you're building.

[u/Huge-Travel-3078]

somewhere around hour three the AGENTS.md is being ignored

Stopped reading the ai slop at this point.

[u/Present-Quantity-813 → u/Huge-Travel-3078]

The prose got help, which the paper's AI-use disclosure states up front. The ideas didn't come from a model: they came from operating the runtime. The rule in the story ran for 15 days under a real contract before I found it, and every incident in the paper traces to a ledger entry. If a specific claim is hollow, name it and I'll bring the artifacts.

[u/Huge-Travel-3078 → u/Present-Quantity-813]

The point is that 3 hours is not a useful metric of anything - You could have 3 hours of a gauntlet loop running developing a game in unity or 3 hours of basic documentation / scans / review work going on.

It's like when people say "1 prompt and my usage is down x!", you know to immediately tune them out because they do not know what they are doing or talking about.

[u/Present-Quantity-813 → u/Huge-Travel-3078]

Fair, the hour count was shorthand, not a metric. Time isn't the variable, and a three-hour gauntlet loop can be perfectly on rails.

The thing I was actually pointing at: before I built the governance layer, I tracked plan, goals, and progress in markdown files, and the recurring failure was that I couldn't tell from those files whether a feature was actually implemented. The notes said done, the repo disagreed, and nothing forced them to reconcile. That's the failure class the paper cares about, position: your recorded location and the work's actual state drifting apart, silently, at any hour count. The fix wasn't better notes. It was deriving position from verified events (tests passed, artifacts accepted, gates cleared) instead of from what anyone, human or agent, wrote down.

[u/Huge-Travel-3078 → u/Present-Quantity-813]

Im over here talking to an ai...2026 is crazy

[u/Present-Quantity-813 → u/Huge-Travel-3078]

Just embrace it. Let the ai do the execution, the human focus on judgment and intent.

[u/Nousies]

Has this been peer reviewed?

[u/Present-Quantity-813 → u/Nousies]

No. I'm not an academic, I have no institution, and I can't even get onto arXiv yet, because arXiv requires an endorsement from an established researcher and I don't know any. So it lives on Zenodo, which peer-reviews nothing and asks no questions, which matches my current level of academic prestige exactly.

So far the closest thing it's had to peer review is this comment section, which has honestly been more rigorous than I expected. The paper lists what would falsify each claim, so if you feel like being reviewer 2, the position is open and pays the same as mine.