What is Loop Engineering? From Prompt to System
I recently learned the name for something I've been building unconsciously for a while: not a one-time good answer, but repetitive loops that preserve intent.
I’ve also started seeing the term "Loop Engineering" frequently in recent weeks. Initially, I brushed it aside, as I’m not particularly excited by another label turning into a trend. But the term stuck with me because what it described wasn’t new to me. For about a month, the arrangement I had established with MORTY was exactly this: agents that research at specific intervals, catch signals, feed what they find back to themselves, and produce products or drafts from it. The name came later; the practice was already there.
I’m not writing this post to explain a trend. On the contrary, I’m writing because I’ve realized that a problem I’ve been feeling my way through for a while finally has a name. While establishing those agent loops, I always had the same question in mind: why does explaining a task well to a model feel so different from building a system that performs that task correctly on its own over time? Loop Engineering gave me a clean framework to think about this difference. And let’s be honest: I’m still learning this by doing it. What I’m about to share isn’t a finished theory, but notes from a practice that works but is still maturing.
I can best explain that difference like this. A good prompt really works: you get a clearer answer, you explain less, and the model understands you faster. But when you do the same task for the third, fifth, tenth time, you notice something strange—the problem is no longer the quality of the answer. The problem is that you have to rebuild the thought that produces that answer from scratch every single time. That’s exactly where you move from writing prompts to building systems.
·
AKSAM NOTUNDAN SABAH KARARINA
┌─────────────────┐ ┌────────────────┐ ┌─────────────────┐
│ ◆ aksam │ │ MORTY │ │ sabah │
│ │ │ │ │ │
│ kisa not │◆ · sinyal arar │· · ben okurum │
│ fikir kacmasin │ │ taslak birakir│ │ karar bende │
│ │ │ │ │ │
└─────────────────┘ └────────────────┘ └─────────────────┘
┌──────────────────────────────────────────────────────┐
│ yasayan dongu │
│ ◆ niyet -> · arama -> · taslak -> ◇ karar │
│ hafiza: sadece yarina degerse kalir │
└──────────────────────────────────────────────────────┘
Loop burada soyut bir şema değil; akşam yakalanan niyet, gece çalışan ajan ve sabah insana dönen karar yüzeyi.
The Problem: Loss of intent when moving from prompt to system
A one-time prompt is a momentary flash of intelligence. For that moment, you keep the context in your head, you know what you want, and you scan the output with your own eyes. The problem begins when that moment needs to be repeated. The second time you do the same task, you rebuild the context; the third time, you forget the boundaries; the fifth time, the format shifts. Every repetition means a bit more erosion of your intent.
At some point, this repetition stops being annoying and turns into an architectural signal. Because the question is no longer "how do I write a better prompt?" The question is: instead of describing this task every time, how do I turn it into a system that carries my intent? I felt this most with MORTY during signal scanning. Telling an agent "scan these resources, extract the relevant ones" is a prompt. But if you want this to run every day, with the same criteria, the same quality threshold, and while maintaining my approval, it means you are designing a system, not a sentence.
I see this on the same axis as the System Debugging post I wrote before. There, the goal was to turn mental noise and volatile RAM—those thoughts that evaporate inside your head—into a physical, processable output; using debugging like a methodology to turn chaos into architecture. Loop Engineering takes the same job a step further: there you solidified the thought once, here you spread that solidification over time. Because the issue is tied to the difference between a one-time prompt and a loop that runs for months—between intent and automation. In a one-time prompt, you carry the intent. When moving to automation, you delegate that burden to the system, and something leaks during the handover.
·
CIZGI DONGUYE BUKULUR
┌───────────────────┐ ┌───────────────────┐
│ prompt │ │ cevap │
│ │ │ │
│ input -> output │◆ · · · · ◆ · · · │ burada biter │
└───────────────────┘ └───────────────────┘
·
┌──────────────────────────────────────────────┐
│ loop niyeti tasir │
│ ◆ niyet · sinyal · rapor │
│ │
│ ◇ karar -> geri besleme │
└──────────────────────────────────────────────┘
Tek seferlik cevap yetmediğinde çizgi bükülür; bağlam, karar ve geri besleme aynı sisteme taşınır.
A prompt is a line: it enters, exits, and ends. A loop is a cycle: it repeats over time, and as it repeats, it gains a character. A line has speed but no memory. A loop, when well-established, has both rhythm and memory. This is why you need to think of what produces behavior not as a single sentence, but as a small system—because you will live with it not once, but for months.
The System: What parts make up a loop?
Looking back at the arrangement I built, I saw that every effective loop consists of the same five parts. I extracted this later by taking apart things that worked; I didn't design it from the start.
1. Intent — Who does this loop serve?
Every loop must start with an intent. What burden does it reduce? What decision does it make visible? Does it increase my clarity, speed, or safety? If I can't give a clear answer to this question, I don't build automation; because a loop established without an answer appears to be doing work but actually just produces more elegant noise. For example, the intent of the signal loop in MORTY is very narrow: to filter and bring me a few headlines that might be useful to me every day from resources I’m too lazy to scan myself. Nothing more.
2. Signal — What is the loop listening to?
A loop is triggered by a signal. This signal can be time—every morning, every evening, every week. It can be a repo change, a voice note, an RSS feed, an email, or a short command I send. In my arrangement, most signals are tied either to the calendar or to a new incoming resource: SUMMER monitors changes throughout the day, MORTY scans at specific intervals, and I intervene occasionally with a voice note. If the signal is blurred, the loop will be blurred too; a system listening to the wrong thing will knock on the wrong door at the right time.
3. Interpreter — How is the signal interpreted?
This is where the real work happens. The layer that turns the raw signal into meaning: system instructions, agent role, RUNE brief, risk class. In System Debugging, I explained that dumping raw data alone is not enough, that an interpretation step is required to turn that noise into a pattern. The same applies to a loop—an agent that lacks a framework for interpreting signals might still execute actions, but it won't produce meaning. The difference between "this headline appeared" and "why this headline might be important for this project of yours" lies entirely in the quality of this layer.
4. Output — What does it produce?
Output doesn't always have to be a file, a commit, or an action. Most of the time, the most valuable output is a short report, sometimes the sentence "nothing noteworthy today," and sometimes stopping to say "Patron, this is risky." MORTY's daily scan leaves me with a summary of a few lines and a few raw product ideas on most days; I filter most of them, one sticks. Good output doesn't do the work for me; it facilitates my next decision.
5. Feedback / Memory — What becomes permanent?
Not every output is memory, nor should it be. The power of a loop is not in storing everything, but in distilling the right thing. Some information goes to the README, some stays within the docs, some turns into a skill, some lives only in that session and is forgotten. As the system grows, what gains value is not the volume of memory, but the selectivity that knows what to keep and what to discard. A loop where you establish the feed incorrectly starts taking its own noise for real signal over time.
The Protocol: Where will the agent stop, and where will the human remain?
When establishing a loop, the most critical decision is not what the automation will do, but where it will stop.
In my system, the rule I repeatedly try to establish is this: first read, then report, then ask if necessary.
The human side provides the intent, draws the boundary, determines the risk threshold, and makes the final decision. The agent side reads, compares, summarizes, suggests, and stops at risky points. The clearer the shared protocol between them, the more reliable the loop becomes.
·
AJANIN DURDUGU YER
◆ read-only -> calisabilir
· local draft -> raporla ┌──────────────────┐
│ insan kapisi │
· repo write -> kapsam net │ │
│ riskte sor │
◇ external -> onay◆ · · · · ◆ │
│ sinir ciz │
◆ service -> riskli dur │ │
└──────────────────┘
· secret -> dokunma
İyi loop sadece koşmaz; riskli yerde durur ve insan kararını doğru noktaya çağırır.
This list might look like a technical safety note, but it is actually the ethics of the loop.
The agent's power is not just its ability to write files, run commands, or look at the web. The real power lies in knowing when to stop.
Philosophical dimension: Is intent preserved while form changes?
I use Spinoza's idea of conatus as a practical test here: Does a system increase or decrease my power of existence?
If a loop produces more notifications, more tracking burden, more fake progress, it is not serving me. It might be working, but it’s not increasing my power. In fact, quite the opposite, it’s making my attention dependent on its own rhythm.
A good loop is not the system that makes me do more things. It’s the system that takes the unnecessary things from my mind and puts the critical things in front of me.
In System Debugging, chaotic thought and refined output were two different forms of the same thought. Here, prompt and loop are also two different forms of the same intent. Prompt is the momentary form. Loop is the form spread over time.
The question is: Is the essence preserved while the form changes?
Practical Setup: Build your first loop small
You don’t need a three-machine agent network for this. My arrangement got there over the years, always growing from a single small loop. The first version must be small; in fact, being boring is a good sign, because exciting first versions usually promise too much and scatter intent.
Choose a task like a weekly repo summary, daily project check, voice note processing, news scanning, or blog draft preparation. In areas involving finance, service management, or credentials, the first version should be read-only.
·
RAPOR BIR KARAR YUZEYIDIR
┌──────────────────────┐ ┌───────────────────────┐
│ ham log │ │ DID / SAW / NEEDS │
│ │ │ ◆ DID: tarandi │
│ ok │ │ │
│ │ │ · SAW: sinyal var │
│ done │ ◆ · · · · │ │
│ │ · │ · RISK: dusuk │
│ 200 │ │ │
│ │ │ ◇ NEEDS: karar │
│ ... │ │ │
└──────────────────────┘ └──◆ NEXT: kucuk adim───┘
Ham log değil: ne yaptı, ne gördü, nerede risk var, senden ne istiyor?
This format is simple but powerful. It makes visible what the loop did, what it saw, where it saw risk, what it wants from you, and the next small step.
Don’t let it write files. Don’t let it send external messages. Don’t let it restart services. Let it only read, summarize, and ask for a decision if necessary. Visibility first, then automation.
Then write the approval gate. When can it proceed on its own? When should it ask? When should it explicitly say "this is risky" and stop?
Finally, set the memory rule: Will this information still be valuable seven days later? Should it go to the README, the docs, a skill, or should it remain only as a temporary report?
Where are we going?
Agents are becoming a bit more capable every month. I see this clearly in my own arrangement: I no longer need to explain to the model most of the steps I used to describe manually a year ago. But there’s something counterintuitive here. The more capable the model becomes, the more the advantage of being able to write good prompts erodes. When everyone can get a good answer, "good answer" no longer sets anyone apart.
In the AI era, the biggest risk is not losing your job, but realizing that you never established your own rhythm of production. When you remain dependent on external systems not just for your livelihood but also for meaning, feedback, and direction, the quality of the model becomes secondary. If you don't have your own loop in hand, you're working according to someone else's rhythm.
That’s why I think the next advantage won't be in the question of "who writes the best prompt." The advantage will belong to those who can combine four elements in a single cycle: agency (a will that applies its own judgment), taste (the ability to distinguish signal from noise), feedback (honest course correction that returns to the system), and persistence (the patience to run these cycles over and over). This is exactly the part the model can't handle—decisions about what to listen to, where to stop, and what things touch your life. These don't fit into a prompt; they emerge only from the work you live, from your own raw material.
·
BIR SONRAKI AVANTAJ
┌───────────────┐ ┌───────────────┐
│ ◆ irade │ │ zevk │
│ yon sec │ │ gurultuyu ele │
└───────────────┘ ┌───────────────────┐ └───────────────┘
│ dongu │
│ yasayan is │
│ │
└───────────────────┘
┌───────────────┐ ┌───────────────┐
│ geri bildirim │ │ sabir │
│ sonucu oku │ │ tekrar et │
└───────────────┘ └───────────────┘
avantaj = bu dortluyu ayni dongude kurmak
Bir sonraki avantaj zeki bir prompt değil; irade, zevk, geri bildirim ve sabrın aynı döngüde çalışması.
The honest part of the job is this: I’m also learning this by living it. Some of the loops I built work, some I tore down and threw away, some I shut down because they tried to bind me to their own rhythm. I’m not building a perfect system; I’m building an arrangement that carries my intent a bit better each time and produces fewer surprises.
That’s why I want to spread this into a seven-part series. This first post establishes the concept; in the following six posts, I will unpack the layers of the loop one by one:
- Loss of intent: How loops break
- Visible loop: Not a log, but a decision surface
- Human-agent protocol: A system that knows where to stop
- Rhythm design: A cron job is not a clock, it’s a nervous system
- Loop memory: What should stay, what should be deleted?
- Build your own loop: Start small, grow visibly
Next post: Loop Drift: How Loops Break
Because every system that produces behavior eventually has a character. My real concern is not leaving that character to chance.
I recently learned the name for something I've been building unconsciously for a while: not a one-time good answer, but repetitive loops that preserve intent.