The default way to build with a language model is to hand it the whole job at once. One long prompt holds the role, the rules, the history, the safety boundaries and the immediate request, all in a single context, and the model is asked to keep faith with every part of it at every step. It works, until the context grows. Then the trouble begins, and it begins quietly.
The previous notes in this series traced why. Attention is flat, so the conditions that should govern behaviour end up competing with ordinary content rather than governing it. As a conversation accumulates, that content multiplies and the governing conditions are gradually crowded out. Behaviour drifts, not because the model was argued out of its instructions, but because the instructions were slowly out-weighed. This note is about the unit we build with to keep that from happening.
What an atomic loop is
An atomic behavioural loop is the smallest self-contained unit of useful behaviour: a short cycle of perceiving, deciding, acting and checking, scoped to do one thing well. It is atomic in the literal sense. It does a single job, it carries only the context that job requires, and it can be reasoned about, tested and trusted on its own. It is a loop because it does not simply emit an answer and move on; it takes in a situation, forms a judgement, acts, and then checks the result against the conditions it was given before anything is allowed to proceed.
The important move is what happens to context. In the monolithic approach, context belongs to the conversation, one ever-growing window that every step has to share. In the atomic approach, context belongs to the loop. Each loop is handed a tight, deliberate slice of context: the task in front of it, the constraints that govern it, and nothing else. The conditions that should hold travel with the unit of work, close to it, where they cannot be diluted by material that has nothing to do with the decision at hand.
The conditions that govern a behaviour should travel with it, not compete with everything else in one shared window.
Why small and bounded beats large and open
This is not a tidiness preference. It is the same point about adherence, applied at the level of system design. A governing condition placed in a small, bounded context is a condition that cannot be out-voted, because there is nothing irrelevant in the window to out-vote it. Bounded context is not a retrieval trick for fitting more into the model. It is an alignment primitive. It is the mechanism by which a value, a role boundary or a safety constraint stays load-bearing instead of fading as the exchange lengthens.
It also changes where failure lives. In one long context, a small drift early on propagates silently through everything that follows; by the time it shows, its origin is lost. When work is decomposed into atomic loops, each with its own check, drift is caught locally, at the step that produced it, before it can travel. A loop that fails its own check does not hand its mistake downstream. Past a certain level of complexity, this is decisive: a set of bounded, checked passes holds its accuracy where a single open-ended pass quietly degrades.
Modelled on how people actually work
The reason to build this way is not only architectural. It is how skilled people operate. An experienced clinician does not hold the entirety of a case in mind as one undifferentiated mass; they run small, practised routines, a check for risk, a check for understanding, a return to the boundary of their role, each triggered at the right moment and each carrying its own focus. An experienced salesperson does the same: qualify, then research, then frame, then verify, in bounded moves rather than one continuous improvisation. Expertise, looked at closely, is very often a repertoire of small, reliable loops, and the judgement of when to run which.
This is why our work is interdisciplinary rather than purely technical. To model how an expert behaves in a domain, you have to understand how that expert actually thinks, where their attention goes, how they decide under uncertainty, where the boundaries of safe practice sit. That draws on psychology and mental health as much as on philosophy and engineering. We are not trying to reproduce how a machine predicts the next token. We are trying to build a cognitive model of how a capable, careful person works, and then express that model as behaviour a system can run faithfully.
How loops compose into adherence
Atomic loops are not the whole system; they are what the whole system is made of. They compose. A workflow becomes a sequence and a structure of loops, each bounded, each checked, with the governing conditions re-established as work moves from one to the next rather than left to erode across a single long pass. Where a stretch of work is demanding, it is divided rather than crammed, so that no one step is asked to hold more than it can keep faithful to.
Adherence, then, is not a property we hope the model maintains across an ever-lengthening conversation. It is a property we build, loop by loop, out of units small enough to stay faithful and structured enough to compose. The same approach serves a commercial pipeline, where the cost of drift is a wasted account or an off-brand message, and a high-sensitivity setting, where the cost of drift is a crossed boundary that matters. Different domains, the same discipline: keep the unit of behaviour small, keep its context bounded, check it before you build on it.
It is an unglamorous idea, and we think it is the right one. Reliable behaviour at scale is not one large mind holding everything at once. It is many small loops, each keeping faith with its own conditions, assembled with care into something that holds.