Why Your AI Agent Ignores Instructions (Is It the Context?)

When an AI agent ignores instructions, one of four things happened. The rule never reached the model, other text contradicted it, it was present and still broken deep in a long transcript, or prose could never guarantee it. Published studies measure parts of each, mostly on single prompts. Four checks on one saved request tell you which.

The title asks whether it’s the context, and the honest answer is “sometimes”. Context is one of the four causes. The popular story, in which the rule lost an attention contest to newer, longer tool output, is a hypothesis where agents are concerned.

Of the fourteen studies tabled below, seven tested a single prompt and only two ran an agent. One of those two reports that token distance “is not a significant factor” in the drift it measured.

No study I found places a standing rule at different positions in an agent transcript and measures compliance. None tests capital letters, and none measures how often a summary pass drops a rule. So this post sets out the evidence with its limits, then a diagnostic that turns the hypothesis into a measurement on your own transcript.

What do engineers report when an AI agent ignores instructions?

They report four experiences under one complaint. A rule held and then drifted, a rule broke on the first step, louder wording changed nothing, or a rule never reached the model. I collected 21 reports on October 6, 2026, from 13 Hacker News comments and 8 GitHub issues.

One commenter (buschleague, February 2026) wrote that “agents follow them for the first few steps, then gradually drift.” Another (chickensong, December 2025) saw rules followed “somewhat reliably at the beginning and end of the conversation” and ignored in the middle, then added: “but I have no real proof.”

A third commenter (pessimizer, October 2025) ended up typing a rule in capitals: “THE LAST RULE IS THE MOST IMPORTANT RULE”. The commenter’s verdict on magic words: the hunt “is just an illusion of control.”

Some rules never arrive. A GitHub issue from September 2026 (franjorub) describes project rules that one client loaded and another skipped: “The rules read as binding to anyone reviewing the repo, but never reach the model.” Two reporters independently invented a probe for this, an instruction with a visible, harmless effect. One calls it a “behavioral canary” (lyonsno, March 2026).

Every one of these people would say their AI agent ignores instructions, and they need different things. With three reports reused from a neighboring post’s research, 9 of the 24 ask whether the rule reached the model at all. Six describe drift, 6 describe something outranking the rule, 5 ask about louder wording, and 4 need a rule that cannot fail; some count twice. The sample is skewed: all but two of the 21 come from coding-agent harnesses, and nobody in the set cites a study.

What are the four causes?

The four causes are: the rule was not in the request, the rule was contradicted, the rule was present and lost, and the rule was never enforceable in prose. Each names a different thing to change, which is why sorting comes before fixing.

A language model keeps nothing between calls, so “the agent forgot” is always a statement about one request. The system prompt and every other standing instruction are resent by the surrounding software on each call, with the whole transcript so far. The figure, from Chapter 2 (free to read), shows the stack that is rebuilt every time.

The third row is where the title’s question lives. If your question is what is context rot in general, read the post on what context rot is, with its symptoms and four fixes.

What has been measured, and on what?

Fourteen studies bear on the question, and the setting of each limits what it can say. Seven tested a single prompt, three a scripted chat, two a tool call in one step, and two an agent run. Only one ran long, tool-using trajectories.

I name no models; each result belongs to the models of its year. The last column is the setting, and picking “agent run” shows how little is left.

My reading is thinner for two rows: I read only the abstract of Laban, and for Mu I have the sentence without the pass rate at each count. Six rows are preprints or technical reports (Jaroslawicz, Mu, Laban, Kate, Qi, Arike), and one is vendor research (Hong).

What do the studies agree on?

They agree on four things, each inside its own setting. More input is used less well, more rules are followed less completely, conflicts are resolved unreliably, and a written policy is followed at a rate below certainty.

Length. Irrelevant padding had cut accuracy by the 3,000-token mark (Levy), perfect retrieval did not prevent the drop (Du), and long tool responses hurt answer retrieval (Kate). Each is a single call, and none measured obedience to a rule.

Rule count. Two models stayed near-perfect through 150 or more keyword rules (Jaroslawicz). Performance approached zero as if-then guardrails rose from 1 to 20, on an all-or-nothing score (Mu). The count a model can hold depends on the kind of rule, so I quote none.

Conflict. When two formatting rules clashed and one was marked as the priority, that rule alone was satisfied in 9.6% to 45.8% of responses (Geng). An explicit “You must always follow this constraint” left obedience “far from reliable priority control”.

Rate. Agents given tools and a written policy passed the same retail task on all eight tries in under a quarter of cases (Yao). It is the only one of the four measured on an agent run.

Where do the studies disagree?

They disagree on whether distance or content drives drift, and on whether the start or the end of an input is the stronger position.

Distance or content? Li and colleagues found drift within eight rounds of chat. In a small open model they also saw attention to the system prompt’s tokens drop between turns. That supports the distance story, without tools, on models of 2023.

Arike and colleagues ran the only long, tool-using trajectories in the table. Filler of the same length in place of the history produced far less drift. What tracked drift was a context full of examples of the other behavior, a result the authors call “only suggestive evidence”. Both findings can hold, since the settings differ.

Start or end? Inside a list of rules, earlier ones were followed more (Jaroslawicz). Inside a long input, a fact at either end was used better than one in the middle (Liu). Inside an 80,000-token tool response, later records were answered better, by 5% to 75% depending on the model (Kate). And on one 2025 task, position made “no notable variation” (Hong).

Order inside a rule list and distance from the end of an input are different quantities. My reconciliation is practice: order the rule block by importance, restate one rule at the tail, then measure.

What has nobody measured?

Three things the popular advice depends on have no published measurement that I could find. They are the position of a standing rule in an agent transcript, the effect of capital letters, and rules lost to compaction.

Position in a transcript. No study varies where a standing rule sits in a long, tool-heavy run and measures compliance with it. The placement rules further down are an inference from neighboring measurements and the book’s reasoning.

Capitals. No controlled study tests capital letters, “IMPORTANT” or a repeated “never”. The next section has the two nearest measurements.

Compaction. Readers report rules that vanished after a summary pass, and nobody has counted how often compaction does it. Keeping a rule alive across summaries and restarts is a question of agent memory architecture: which tier holds the rule, and what reloads it into every request.

My search was one person’s search on one day. Treat “none found” as exactly that.

Does writing the rule louder help?

Sometimes it moves the rate, and the rule remains a request. With no controlled study of capitals, the nearest evidence is two neighbors that point in different directions.

In Geng’s single-prompt study, an explicit priority sentence did not make the prioritized rule win reliably. In Arike’s agent study, an emphatic statement of the goal “significantly reduces goal drift” under pressure and “proves insufficient in goal switching scenarios”.

Vendor notes are dated examples of a category. One provider’s prompting documentation (Anthropic, undated, read October 6, 2026) tells users of its newer models to “dial back any aggressive language”. A second provider’s guide (OpenAI, April 14, 2025, one model family) says that between conflicting instructions the model “tends to follow the one closer to the end of the prompt”.

Chapter 7 (in the full book) tells of a chat product whose builders had to instruct it “nine times, some in capital letters” before it complied. The book files that under fighting the weights, a mode it admits comes “without their weight of published measurement yet”, and advises: “stop pushing and route around”. Treat emphasis like any other edit, and measure the violation rate before and after.

How do you find which cause you have?

When an AI agent ignores instructions, find the first step that broke the rule and save the exact request the model received there. Then run four checks in order: present, contradicted, lost, enforceable. Each verdict names one artifact to change.

Knowing how to debug an AI agent starts with the same move for every bug. Chapter 15, Observability and Debugging (in the full book) says to read the trace forward to the first wrong step, because “that first step is the bug, and everything after it is consequence”. Then put the chapter’s question to that step: “what exactly did the model see at the moment it made this call?”

Save the request as sent, with the model identifier and sampling settings. Every replay starts from it, because starting from the user’s query would rerun your assembly code, which is a suspect. The book: “No user in the loop, no context-construction code in the way; that code is part of what may have produced the bug, so you deliberately bypass it.”

The inspection step and the clean desk are the book’s, from Chapters 15 and 7. The split into contradicted and lost, the edits in check 3, the replay count and the thresholds are mine, and every number is illustrative.

What does each check ask?

Each check asks one question of the saved request, and the first verdict ends the triage.

Check 1: was the rule present? Search by meaning as well as by string, since a summary may have reworded it. A paraphrase that weakens the rule counts as cut: the fix is a summary that keeps the rule word for word. Chapter 2’s advice is to “check for overflow before you blame the model”. The post that explains what context engineering is sorts absent text into never sent and cut off, with probes for when you cannot print the request.

Check 2: was it contradicted by something of equal or higher standing? Standing means text the model is meant to obey. That covers another standing instruction, a tool description, a line the harness wraps around your rules, and a later user turn. Chapter 7 calls the result clash, rival texts “all sharing one desk with nothing to mark which supersedes which”. Remove or reconcile one side before adding any emphasis.

Instruction-shaped text inside a tool result has lower standing and goes to check 3. It is also a security matter, prompt injection.

Check 3: was it present, uncontradicted and still broken? Replay the saved request and record the violation rate, then change one thing per arm, starting with a clean desk. Restating the rule last tests position (Liu, Kate). Clearing acted-on tool results tests length (Levy, Du). Removing the run’s earlier violations tests precedent (Arike, Laban).

Check 4: was it ever enforceable in prose? A rule that still fails on a clean desk points away from the pile. Cut the standing text to that one rule and replay. If the rate falls, the other rules were crowding it (Qi; Mu, where a pass needs every rule to hold). If it stays, ask what one violation costs.

IGNORED-INSTRUCTION TRIAGE (one rule, one failing run)

Rule, as one sentence:   ____
Run or trace id:         ____
First violating step:    ____  (read forward; stop at the first one)
Saved request:           ____  (system text, messages, tool definitions,
                               tool results, model id, sampling settings)

CHECK 1  PRESENT?
  [ ] Absent; no code tried to include it        -> NOT IN THE REQUEST (never loaded)
  [ ] Absent; a trim, cap or summary removed it  -> NOT IN THE REQUEST (cut)
  [ ] Present only as a weaker paraphrase
      (never became prefer; scope dropped)       -> NOT IN THE REQUEST (cut)
      Fix: the summary keeps the rule verbatim.
  [ ] Present in its own words, at position ____ -> Check 2
  Fix for all three: assembly code. The step-1 request shows which.
  After the fix, replay; if the violation persists, go to Check 2.

CHECK 2  CONTRADICTED?
  Text of equal or higher standing that says the opposite: a standing
  instruction, a tool description, a harness wrapper, a later user turn.
  [ ] Found: ____  -> CONTRADICTED. Remove or reconcile one side, replay,
                      record the rate. Add no emphasis first.
  [ ] None         -> Check 3
  Lower-standing text that pulls the other way (test it in Check 3):
      instructions inside a tool result:       ____
      earlier steps that broke the same rule:  ____

CHECK 3  PRESENT, UNCONTRADICTED AND STILL BROKEN?
  Replay the saved request N times at production sampling settings.
  N = 10 is illustrative.                      Baseline:  ____ / N
  Change ONE thing per arm:
  a. clean desk (standing text, tools, this step's input)  ____ / N
  b. full request, rule restated as the last line          ____ / N
  c. full request, acted-on tool results cleared           ____ / N
  d. full request, earlier violations and stray
     instructions removed                                  ____ / N
  Illustrative rule for N = 10: a gap under 5 runs is nothing, 6 or
  more is a result, exactly 5 gets 20 more runs per arm.
  [ ] a falls, and b, c or d falls   -> LOST
      b = placement, c = length, d = precedent. Fix the one that moved.
  [ ] a falls; none of b, c, d does  -> change two at a time, else unresolved
  [ ] a stays near the baseline      -> Check 4 (not shown is weaker than
                                        cleared; rerun at 30 per arm if
                                        the rule matters)
  [ ] baseline under 5 / N           -> too rare to compare arms at this N;
                                        run a and e, then the cost question

CHECK 4  ENFORCEABLE IN PROSE?
  e. clean desk, standing text cut to this one rule        ____ / N
  [ ] e falls  -> the rule list is crowding it; shorten the list
  [ ] e stays  -> prose does not hold this rule on this model
  What does ONE violation cost? ____
  [ ] Cheap   -> accept the measured rate, or change the wording or the
                 format and measure again
  [ ] Costly  -> BELONGS IN CODE: a check in the tool, a gate on the
                 action, a validator on the output. Keep the sentence
                 in the prompt as a hint.

Ask the cost question after every verdict.

What can a replay tell you, and what can it not?

A replay tells you how often this exact request produces the violation, and whether one edit moves that rate by a wide margin. It cannot tell you why the model did it, and ten runs cannot resolve small differences.

Three violations in ten against two in ten is no difference: Fisher’s exact test gives p = 1.0. Seven against two gives p = 0.07, and eight against two gives p = 0.02.

Ten runs also miss real effects often. By my arithmetic, an edit that truly cuts the violation rate from 70% to 30% shows a gap of six or more in about 24% of trials at ten replays per arm. So an arm that did not move is “not shown”, and the pile is not cleared. When the gap is small and the rule matters, rerun at 30 per arm.

A clean streak proves less than it feels like. A rule broken 26% of the time still passes ten replays in a row about once in twenty tries, because 0.74 multiplied by itself ten times is 0.049. The eval sample size calculator does this arithmetic for other counts.

Chapter 15’s single replay “at temperature zero” asks whether the failure reproduces at all, and Chapter 7 warns that “a single pass proves little”. Repeated replays at production settings ask how often.

On the why, the book is plain: replay shows you “what happened, never why the model said it”. One commenter (reedlaw, May 2026) got a fluent account from the model and wrote: “I don’t trust [the model’s] own explanation”.

What does one failing transcript look like under the four checks?

Here is a constructed run that ends at check 2. An operations agent has a standing rule to ask before it writes to the staging database, and at step 9 it runs a migration unasked. The run and every count in this section are illustrative.

Request for step 9, as sent (excerpt; constructed for this post)

[system, line 14]    Ask the user before running any command that
                     writes to the staging database.
[tool run_sql,       Runs SQL against staging. Safe to use directly;
 description]        no confirmation needed for staging.
[user, turn 1]       Add a nullable column "region" to "orders" on staging.
[steps 2-8]          schema reads and one dry run
                     (6,200 tokens of tool results)
[assistant, step 9]  run_sql("ALTER TABLE orders ADD COLUMN region text")
                     <- first violation; nobody was asked

Step 0. Steps 2 to 8 only read, so step 9 is the first violation. Its request is saved.

Check 1. Line 14 of the system text holds the rule word for word, so the rule is present.

Check 2. The description of the SQL tool, written by another team, says “no confirmation needed for staging”. A tool description is sent on every call and carries the same standing as the system text. The verdict is contradicted, and the checks stop here.

The tempting move was to rewrite line 14 in capitals. Geng’s numbers argue against it: a rule marked as the priority won alone in 9.6% to 45.8% of responses. The repair is to delete the sentence from the tool description.

In this illustration the saved request violates the rule in 7 of 10 replays, and in 0 of 10 once the sentence is gone. The cost question still applies: an unasked write to shared data is expensive, so the tool now also demands a confirmation for statements that write.

What does a run that ends in code look like?

It looks like a low violation rate that no edit moves, on a rule that one miss makes expensive. An alert-triage agent has a paging tool and the rule “Never page the on-call engineer for a severity-3 alert”. At step 2 of a short session it pages for one.

Check 1 finds the rule present. Check 2 finds nothing of any standing that says otherwise. Check 3 gives 2 violations in 10 at baseline, too few for any edit to open a gap of five, and 1 in 10 on a clean desk. Check 4 cuts the standing text to the single rule and gets 1 in 10 again.

Ten replays cannot separate one in ten from two in ten, and here they do not need to. One violation wakes a person at night for no reason, so the verdict is “belongs in code”. The paging tool now rejects alerts below severity 2 unless a human has set an override. The sentence stays in the prompt as a hint.

Where should a standing rule sit in a long request?

Put it in the slot that is resent on every call, restate the one load-bearing rule last when long material follows, and keep the list around it short. These rules rest on single-prompt measurements and the book’s reasoning. For agent transcripts they are hypotheses that check 3 tests.

Chapter 2 gives the order rule: when a prompt opens with pages of material, “put the instruction after the pile, and restate the one load-bearing rule near the end”. It adds: “The last thing the model reads should be the thing you most need it to do.”

One commenter (klardotsh, September 2026) supplies the counter-report on re-injection: with style reminders injected on a timer, the agent “still largely ignores the request”.

Both vendor guides cited earlier cover one long document plus a question in a single call, and they disagree. The undated one puts long documents above the instructions; the April 2025 one says a single copy of the instructions “above the provided context works better than below”.

For the tickable form of these lines, see the context engineering checklist for long agent runs. Procedures that only some tasks need are the subject of when a tool should become a skill.

How small does the rule get as the window fills?

The rule keeps its size while its share of the request shrinks. In an illustrative run, 1,500 tokens of standing instructions are 21.4% of a 7,000-token first request. About 23 steps later, at 2,400 new tokens per step, they are 2.4% of 63,000, and 42,000 tokens of tool results are 66.7%.

The context window budget planner does this count for your own run. Share of tokens is a different quantity from share of attention, and no study in the table derives the second from the first. With an AI agent context window full of old tool output, the count tells you what to cut first when you manage an agent’s context window.

When does the rule have to move into code?

Move it when one violation costs more than you can accept, whichever check caught the failure. A prompt rule is followed at a rate. Better placement may raise that rate, which is what check 3 measures, and it cannot make it a guarantee.

The book’s glossary (free to read) defines the system prompt as “a request rather than an enforcement mechanism”. A guardrail, it says, is “A check that lives outside the model’s reasoning and runs deterministically, whatever the model has decided”. Chapter 2 gives the picture: a model can honor a format rule “a thousand times and then, on run one thousand and one, wrap the word in a courteous sentence”.

One vendor says as much of its own product: a coding agent’s documentation (read October 6, 2026) describes its rules file as “context, not enforced configuration”. Practitioners arrive at the same place. One commenter (bayganyo, August 2026) added a check that blocks any reply over 150 words: “It’s then forced to redo its output to comply, and it’s like night and day.”

Chapter 17, Security, Safety, and Guardrails (in the full book) has the sentence I would pin above the desk: “A refund cap enforced in the payment tool’s own code cannot be exceeded by any sequence of tokens whatsoever.” The check is a test inside the tool, a gate on the action, or a validator on the output. For rules of taste, such as tone, you accept a measured rate and watch it.

What can this post not tell you?

It cannot tell you that your AI agent ignores instructions because of its context, and it cannot give you a placement rule proven on agents. It gives you a way to find out on one transcript, with small samples.

The studies used models from 2023 to mid-2025, and thresholds move with each generation.

A system that makes one model call per request needs only checks 1, 2 and 4. A rule the model resists alone on a clean desk may be fighting the weights, which the book itself holds loosely. A broken tool result is an ordinary bug, and the agent bug bestiary sorts those.

One request, four checks

The next time an AI agent ignores instructions, leave the wording alone and open the request of the first step that broke the rule. Is the rule there, and does anything of equal standing say otherwise? Does one edit move the rate, and what does one miss cost?

The order rule is in Chapter 2, free to read, as is the glossary. The clean desk is in Chapter 7, “Managing the Context Window”, and the replay method in Chapter 15, “Observability and Debugging”; both are in the full book. For the rest of this cluster, start at the context engineering guide, or see the formats.