Why AI agents ignore their instructions, and how to make rules stick

An AI agent ignores a standing rule for ordinary reasons. The rule is one line in a file too long to follow, or it was said once in a chat that has since been summarised, or it contradicts another rule, or nothing outside the agent stops it. The fix is to put each rule where it holds: a short instructions file for what applies to every task, a skill for each procedure, and a check the agent can't skip for anything that must never happen.

This guide is for anyone who gives an agent standing rules, whatever the tool. The examples are public posts from the last few weeks.

Why does an agent ignore rules you've already given it?

Because to the agent, a rule is text it reads, not a setting it obeys. Claude Code's documentation says so about its own instructions file: "Claude treats CLAUDE.md files as context, not enforced configuration". The same is true of an AGENTS.md file, a system prompt or a memory note, in any tool. The agent weighs your rule against everything else in front of it, and sometimes the rule loses.

People describe the same few patterns:

• Saying the same things every day. One developer using Claude Code and Codex: "all I do is type the same things over and over: 'Don't touch that file.' 'That helper already exists.' 'We don't do it that way here.'"
• A rule dropped within minutes. A Hermes user who'd set a rule for the format of the agent's Discord messages, tagging the recipient: "After three messages, it already has dropped totally that rule".
• A file too long to follow. A project's main instructions file grew past 400 lines, "plus the agent started ignoring half the instructions anyway".
• Decisions lost in a summary. One long session had been compacted 62 times, and "the summary had kept 0 of 12 older decisions".
• More done than asked. An agent asked to move one class at a climbing gym from 6:30 to 7:00 also rewrote a waiver and put back three old prices. "My prompt literally said only change the time."

Each of these has a cause you can fix: a file that's too long, a rule that was only said, rules that disagree, a rule too vague to check, and a rule with nothing behind it.

How long should an agent's instructions file be?

Short enough that every line matters on every task. Claude Code's docs give a number: "target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence." Codex reads AGENTS.md files from the project root down and "stops adding files once the combined size reaches the limit defined by project_doc_max_bytes (32 KiB by default)", so instructions past that size may never reach the agent at all.

Research points the same way. A study of how language models use long inputs found that "performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts". A rule on line 240 of 400 is in the middle.

To shorten a file without losing anything:

1. Keep in the main file only what applies to every task: the agent's job, what it must never do, what "done" means, and how to run the checks. For a new agent, five lines is a good start.
2. Move rules for one part of the work into that folder. Many coding agents also read an instructions file in the folder they're working in. The AGENTS.md format puts it this way: "Agents automatically read the nearest file in the directory tree, so the closest one takes precedence". The developer with the 400-line file cut it to about 80 this way.
3. Move procedures into skills (below). How to cut a release or write the weekly report doesn't need to be read on every task.
4. Delete what no longer applies, and look for rules that contradict each other. Claude Code's docs: "if two instructions contradict each other, Claude may pick one arbitrarily".
5. Make each rule checkable. The same docs: "“Use 2-space indentation” works better than “format code nicely.”"

Where should a rule live so the agent doesn't forget it?

In a file the agent reads at the start of every session, never only in the chat. Long conversations get summarised to make room, and the summary keeps what it judges important, which may not be your rule. Claude Code's docs describe both sides: the project's main instructions file "survives compaction: after /compact, Claude re-reads it from disk", while an instruction that disappeared "was given only in conversation" or sits in a file that hasn't loaded yet.

Two habits follow:

• Turn corrections into lines in the file. When you correct the agent in the chat, ask it to add the rule to its instructions file, then read the line it wrote. A correction said once lasts as long as the conversation does.
• Keep a decisions file. One developer whose agent kept proposing ideas they'd already ruled out started a notes file of decisions, dead ends and open loops, read at the start of each run and added to at the end. "the dead ends turned out to be the most valuable part, they kill repeat suggestions"

If you run HostNest, a team of Claude agents, each agent's memory, instructions and skills are plain files on your own server, and you can read every one.

When should a rule be a skill instead?

When it's a procedure for one kind of task rather than something that applies to everything. A skill is "a folder containing a SKILL.md file that teaches an agent a specific task or domain, along with any scripts or reference material it needs". It's an open standard: Anthropic says "More than 70 agent platforms, including ChatGPT, Cursor, GitHub Copilot, and VS Code, have integrated Agent Skills", and on 22 Oct 2026 it gave the standard to the Agentic AI Foundation under the Linux Foundation.

Skills keep the main file short because the agent loads them in stages. The specification says the name and description, about 100 tokens, "are loaded at startup for all skills", and the full instructions only when the skill is used. Twenty procedures cost the agent twenty short descriptions until it needs one.

That makes the description the part that decides whether the skill is used at all. The specification's own example of a good one: "Extracts text and tables from PDF files, fills PDF forms, and merges multiple PDFs. Use when working with PDF documents or when the user mentions PDFs, forms, or document extraction." Its poor one: "Helps with PDFs." Say what the skill does and when to use it, in the words you'd use when asking.

How do you make a rule the agent can't break?

Take it out of the agent's instructions and put it in a check that runs whatever the agent decides. Instructions ask; a check refuses.

• Hooks in the agent tool. Claude Code's hooks "execute as shell commands at fixed lifecycle events and apply regardless of what Claude decides to do". Codex has hooks too: before a tool runs, a hook can "block or rewrite the call".
• A git hook, which works with any agent. Git runs a pre-commit script before every commit, and "Exiting with a non-zero status from this script causes the git commit command to abort before creating a commit". It can be skipped with --no-verify, so block that flag in the agent's permissions or run the same check again in CI.
• Your tests and CI. A rule that a test checks holds whichever agent wrote the code, and whichever person.

Good candidates are the rules you'd least like to find broken: files the agent must never edit, secrets that must never be committed, tests that must pass before a commit, a branch nobody pushes to directly. Keep them in the instructions file as well, so the agent knows the rule before the check stops it.

A checklist

1. Keep the main instructions file under about 200 lines, and every line about every task.
2. Put rules for one folder in that folder's file.
3. Turn procedures into skills, each with a description that says when to use it.
4. Write each correction into the file, not only into the chat.
5. Remove rules that contradict each other, and make each one checkable.
6. Turn the rules that must never break into hooks, git hooks or tests.