Loop Drift: How Loops Break

Just because it works isn't enough

There is a strange blindness in technical systems: if something doesn't throw an error, we tend to assume it’s healthy. The cron ran, the script exited, the file was created, HTTP 200 was returned, the report arrived. From the outside, there is order.

But the success of a loop is not measured solely by its operation. Because a loop is not a one-off tool; it is a generator of recurring behavior. Every repetition fixes the character of the system a bit more. A loop running with the wrong metric can be more dangerous than a model that gives a wrong answer once; because it produces its error not in a single instance, but in a rhythm.

That’s why the first safety question in Loop Engineering is not: “Does this work?”

The more accurate question is: “Does this still serve the intent for which it was established?”

The difference seems small, but in practice, it is massive. The "does it work" question looks at the log. The "does it serve intent" question looks at the human, the context, and the result.

Where does drift begin?

From what I’ve seen, drift usually doesn't start with a dramatic breakdown. The system doesn't explode. No one generates an alarm. Instead, small shifts accumulate.

The first shift happens at the prompt layer. The instruction that was clear at the start gets patched as new needs arise. Between “add this too,” “check this as well,” and “sometimes look at this,” the loop's single-sentence intent fragments. After a while, the prompt stops being a living design decision and turns into a dumpster for small exceptions.

The second shift happens at the signal layer. The loop is still listening to the same sources, but your life is no longer in the same place. A source that was important three weeks ago might be noise today. A repo may no longer be active. A topic might be closed. A product idea may have matured and now requires sales or distribution research instead of general exploration. If the loop doesn't know this, it will continue to honestly report on the old world.

The third shift happens at the output layer. While the report format was born to facilitate decision-making, it can turn into a tool for self-justification over time. More items, more tables, more of a performative “look how hard I worked” tone. It starts producing reports that look good but don't reduce the decision burden. At this point, the loop isn't doing work; it’s demanding attention.

The fourth shift happens at the memory layer. If every output starts being written somewhere, the system becomes dependent on its own past. README, docs, skill, memory, backlog… They can all be valuable, but when the wrong thing becomes permanent, the loop starts referencing its own outdated assumptions in the future.

None of these shifts are a disaster on their own. The disaster is their silent normalization.

Early signs of intent loss

To understand that a loop is breaking, you first need to listen to its voice. Sometimes technical metrics look clean, but the tone of the report has changed.

There are a few practical signs I use:

Three agents, one surface: MORTY, SUMMER, and RICK work separately; the Patron sees a single decision surface.

                                                                    
                         UC AJAN, TEK YUZEY                         
                                                                    
                                                                    
    ┌───────────────┐                                               
    │ ◆ MORTY       │                            ┌──────────────┐   
    │  is yapar     │◆                           │ patron       │   
    │               │  ·  ┌───────────────┐      │              │   
    └───────────────┘    ·│ RICK          │      │  karar       │   
                             sentezler    │· · ◆ │              │   
    ┌───────────────┐    ·│               │      │  risk        │   
    │ SUMMER        │  ·  └───────────────┘      │              │   
    │  izler        │·                           │  next        │   
    │               │                            └──────────────┘   
    └───────────────┘                                               
                                                                    
                                                                    
            gorevler daginik olabilir; yuzey tek olmali             
                                                                    
                                                                    

Not preventing drift, but keeping it visible

The goal here is not to build a perfect loop. No such thing exists. Every loop drifts a certain amount as context changes. The important thing is not to see drift as a moral failure, but to monitor it like the natural entropy of the system.

My practical rule is this: every loop should have a small drift check next to it.

This check doesn't have to be a long document. In fact, it shouldn't be. Four questions are enough:

1. What intent does this loop serve today?
2. Is the signal it’s listening to still correct?
3. Does its output facilitate my decision?
4. Is what it writes to memory still valuable seven days later?

If the answers to these four questions become blurred, it’s necessary to shrink the loop rather than grow it. Adding more resources, calling more models, or asking for longer reports won't solve drift. Most of the time, it just makes it more expensive.

Sometimes the right move is to shut down the loop. Sometimes it’s to make it weekly. Sometimes it’s just to set it to read-only. And sometimes it’s to rewrite the intent and prune some of the old memory.

I don't want to break a working system. “Don't touch it, it works” is a good instinct. But if we don't occasionally ask what exactly it is “working” toward, the system will silently start steering itself.

Small protocol: Drift review

The smallest review format I find useful for my own loops is this:

LOOP:
ORIGINAL INTENT:
CURRENT OUTPUT:
STILL USEFUL? yes / no / narrower
DRIFT SEEN:
KEEP:
CHANGE:
STOP:

The beauty of this format is that it doesn't require technical details. It doesn't force a loop to defend itself; it just makes what it serves visible. If the ORIGINAL INTENT line remains empty, the answer is already clear: you first need to find the intent again.

A small example might look like this:

LOOP: weekly resource scan
ORIGINAL INTENT: finding a few clean signals for product and writing ideas
CURRENT OUTPUT: long list, few decisions
STILL USEFUL? narrower
DRIFT SEEN: number of resources increased, decision sentence weakened
KEEP: three good signals
CHANGE: reduce report to DID / SAW / NEEDS format
STOP: don't save raw lists with no archival value

I particularly like this for cron-based agents. Because cron creates a sense of “set it and forget it” in the human mind. However, a scheduled job requires more supervision over time, not less. A small error running every day can leave more permanent marks than a big wrong working once a month.

Conclusion: A loop's character is not left to chance

To me, this is partly why Loop Engineering differs from prompt engineering. In a prompt, you improve the quality of a moment. In a loop, you design the character of a repetitive behavior.

Character is not just a fancy metaphor. What does the system care about? What does it ignore? When does it go silent? When does it stop? When does it write to memory? When does it turn to the human? The sum of these produces a character over time.

Intent drift is the silent change of character.

That's why building a good loop isn't about writing the right prompt once and stepping aside. It's about looking into the system's eyes every now and then and asking:

“Are you still serving what I established, or have you just settled into a habit of your own?”

In the next post, I will take this to a more visible layer: the difference between a log and a report. Because knowing what the loop does is not enough; it needs to turn this into a surface on which a human can decide.

Next post: Visible loop: Not a log, but a decision surface.