How to Use Rules Files So the Agent Stops Repeating Itself

The agent reformats the same date string for the fourth time in one session. It apologizes, it corrects itself, and then two turns later it does the identical thing again. The human on the other end of the chat has now typed the date format preference twice, in two different phrasings, and is starting to suspect the model has the memory of a goldfish with a head injury.

This is the specific failure that rules files exist to prevent. Not the spectacular failures, the hallucinated citations or the confidently wrong API call. Those get attention. The grind of small, repeated corrections is what poisons a working session, and it is what a well-built rules file addresses directly.

A rules file, for anyone arriving without the vocabulary, is a persistent instruction document loaded into an agent's context before a task begins. It sits alongside the prompt and the conversation history. It says things like "use ISO 8601 dates," "the project uses tabs, not spaces," "answer in British English," "never touch files under /migrations." The agent reads it every time, and in theory it shapes every response.

In theory.

The agent forgets because the rules file is a pile, not a document

The most common reason an agent repeats itself is not that the rules file is missing. It is that the rules file has grown into a sediment layer. Someone added a note about commit message style in January. Someone else appended a paragraph about error handling in March. By summer the file is 400 lines of accumulated grievance, half of it contradictory, and the agent is trying to satisfy all of it at once.

When instructions conflict, the model does something reasonable and unhelpful: it averages. It picks whichever rule seems most salient in the moment, which means a rule stated once in paragraph 14 competes against a rule stated three times in paragraphs 2, 9, and 22. Repetition wins. Specificity loses. The date format preference gets buried under a wall of prose about tone.

A rules file that works looks like a reference card, not an essay. Short declarative lines. One rule per line. No throat-clearing, no context paragraphs explaining why the rule exists, no anecdote about the incident that prompted it.

Prose buries the rule that matters

Consider the difference. A rules file written as prose reads: "When generating code for this project, please keep in mind that we've standardized on Python 3.11 and the team has agreed to use type hints throughout, so please make sure to include them."

The same rule as a line item reads: "Python 3.11. Type hints on all function signatures."

The second version is four times shorter and roughly four times more likely to survive. Instructions that are easy to scan are easy to follow. Instructions buried in a subordinate clause are easy to drop. The agent is not reading for pleasure; it is pattern-matching against a wall of tokens, and every unnecessary word is noise competing with signal.

Strip the hedging too. "Please try to," "where possible," "if convenient" all read as optional. If a rule matters, state it flat. If it does not matter, delete it. A rules file full of softeners trains the agent to treat everything as a suggestion.

Negative rules need a positive replacement

"Don't use em dashes" is a rule the agent will violate for a specific reason: it has no alternative behavior attached. Told only what not to do, the model defaults to its strongest prior, which is the very behavior the rule forbids. The prohibition loses to the habit.

The fix is to pair every negative with a concrete substitute. "No em dashes. Use commas or parentheses." Now the model has somewhere to go. "Don't over-explain. Two sentences maximum for simple answers." The constraint has a shape.

The same applies to scope rules. "Never modify files outside /src" is weaker than "Write only inside /src. If a fix requires touching /config, stop and report it." The second version tells the agent what to do when the rule is under pressure, which is the moment rules actually get tested.

Put the format rules at the end, not the middle

Models exhibit a well-documented positional bias: material near the beginning and end of a long context gets more attention than material in the middle. A rules file that places the critical formatting constraints in paragraph 30 of a 50-paragraph document is placing them precisely where they will be least effective.

Practical ordering: put the absolute hard constraints first (the things that break the build if violated), the behavioral preferences in the middle, and the output formatting rules last. The formatting rules are the ones most likely to be repeated across turns, so they belong in the high-attention tail.

If the rules file is long enough that ordering matters, it is probably long enough to split. A 200-line file covering code style, tone, architecture, and deployment is four files pretending to be one. Split it. Load only what the current task needs.

The repeated correction is a missing example

Some rules fail because they are too abstract. "Write in a concise style" is a rule the agent will interpret differently every turn. "Match the tone of the examples below" followed by three short sample paragraphs is a rule that anchors. One example does more work than five adjectives.

The same holds for formatting. If the agent keeps reformatting dates, do not write "use consistent date formatting." Paste the exact target format as a literal string: "2024-03-15." Show the shape. Models copy patterns far more reliably than they follow descriptions of patterns.

This is where the repetition problem gets diagnosed rather than patched. An agent that keeps making the same correction is telling the rules author something specific: the instruction exists but the exemplar does not. Add the exemplar. The repetition usually stops.

Rules that contradict the system prompt get quietly dropped

A rules file does not sit at the top of the hierarchy. The system prompt does. When the rules file says "respond in plain text" and the system prompt says "format responses as structured JSON," the agent will follow the system prompt and the rules file will appear to have been ignored.

This produces a frustrating debugging session where the rules file looks correct, the conversation looks correct, and the output is still wrong. The contradiction is invisible from inside the rules file. The fix is to audit both documents together, side by side, and resolve every conflict explicitly. A rules file cannot override the platform; it can only fill the gaps the platform leaves open.

Conflicts inside the rules file itself cause the same quiet failure. Two rules about indentation, two rules about date format, two rules about whether to ask clarifying questions: the agent picks one and the author never learns which. Grep the file for near-duplicates before adding a new rule. The duplicate is usually the older one that should have been deleted months ago.

Version the rules file like code, because it is code

The rules file is the highest-leverage document in an agent workflow and it is usually the least maintained. It lives in a wiki page nobody reads, or a Google Doc with three competing comment threads, or a text file in someone's home directory. When the agent misbehaves, nobody can tell whether the rule changed or the model did.

Put it in the repo. Give it a changelog. When a rule gets added, note the incident that prompted it in the commit message, not in the file. When a rule gets removed, note why. Six months later, the diff history is the only reliable record of what the agent has already been taught and what it keeps forgetting.

There is a useful diagnostic in that history. A rule that gets added, removed, and re-added is a rule the agent cannot follow consistently, which usually means it is fighting the model's prior too hard. Either accept the behavior or build a stronger scaffold around it. Re-adding the same line for the third time is not a fix; it is a note that the approach is not working.

When the agent still repeats itself, check the context window

One more failure mode, and it is the least obvious. The rules file is perfect, the ordering is right, the examples are in place, and the agent still drifts after twenty turns. In long sessions, earlier context gets truncated or summarized, and the rules file can fall out of the active window entirely.

The tell is timing. If the repetition starts around a specific turn count rather than immediately, the problem is context decay, not rule quality. The remedies are structural: keep the rules file short enough to survive summarization, re-inject the critical constraints at the start of a new task segment, or split long sessions into shorter ones with a fresh load.

An agent that repeats itself is usually not stubborn. It is working from a document that is too long, too soft, too abstract, or too far back in the window. The date format at the top of this piece got corrected four times because the rule lived in paragraph 14 of a file nobody had pruned since January. Move it to the last line, cut the file in half, and the fifth correction never happens.