A little while back I wrote about Paloma and how my wife has been using it. One failure came up a few times: the model would get stuck repeating itself until someone stopped it. Worse, stopping it did not always get the conversation moving again.
The model was Qwen, which tends to respond well to explicit, declarative constraints. That mattered because the loops appeared after long sessions that had already gone through several rounds of context compaction.
The recovery path was replaying the failure
Paloma already had a loop detector. It recognized repeated output, interrupted generation, and restarted the model with a recovery instruction.
The detector was doing its job. After stopping the model, the harness assembled another context containing the loop it had just caught. It had identified a failed generation path, then sent it back to the model as context. The model resumed from the end of the pattern instead of moving away from it.
Conversation history is usually worth preserving. It carries the user's request, prior decisions, and tool results forward. A detected loop belongs in a different category. The harness may need a brief record that generation was interrupted for repetition, but the repeated span itself is failed output. It should not dominate the next working context.
Recovery needs to change the state that produced the failure. That is a harness responsibility, not a request for the model to overcome its own recent example.
A suggestion did not carry enough authority
The recovery instruction made the second mistake obvious:
You might want to try another approach.
That is natural language between people. It was weak guidance for a model already embedded in a strongly reinforced pattern inside a large context.
I changed might to must so the model received a clear constraint, and the harness stopped placing the loop in front of it as the immediate example to continue.
The useful lesson is narrower than “write stronger prompts.” A response is composed of the full context, the order in which it appears, and the authority the application assigns to each instruction. Must worked because breaking the loop was a real recovery requirement.
Priority is a limited resource
The tempting response is to label every important sentence MUST, NEVER, or some other capitalized command. That removes the distinction that made must useful.
Some instructions are invariants: do not expose a secret, do not act without the required approval, stop a detected loop. They describe outcomes the harness cannot accept. They need a clear source, scope, and durable place in the assembled context. The harness enforces that boundary.
Other instructions are preferences. An answer may need to be concise, use a particular voice, or favor one tool where the evidence allows it. Those are valuable defaults, though a direct request or a higher-authority constraint can override them.
When preferences and invariants arrive as the same kind of emphatic sentence, the model has little help distinguishing them. The operator loses that distinction too. A broken hard rule should point to a violated contract.
Context growth makes this a harness problem
Long sessions force the application to decide what survives. Compaction decides which history remains. Retrieval decides which memories return. Prompt assembly decides what appears together and in what order.
An instruction hierarchy has to survive those decisions. Hard constraints cannot be buried in a summary of historical preferences. Failed output cannot be carried forward without marking it as failed. Preferences should remain scoped to the work they govern instead of competing with every instruction on every request.
The looping bug started as an annoying conversation failure. It exposed a more general rule for model-backed systems: recovery, context selection, and instruction priority are one design problem. MUST is useful precisely because the harness gives it a small number of jobs that cannot be negotiated away.
The one-line version
MUST is useful precisely because the harness gives it a scarce job: expressing a hard constraint that must survive context growth, recovery, and competing preferences.