A Coding Agent Breaks Its Own Rules Before Its Context Fills

This series has talked about what a harness is, four generations of building one, and the pipeline that came out of splitting one agent into ten. The next part is about a rule an agent read, understood, and broke anyway. Before getting there, one thing needs unpacking, because it's been used loosely up to this point. What "under pressure" actually means for a model, and why it's not the same failure as the one most people reach for first.

The explanation everyone reaches for

Ask why an agent suddenly stopped following its own instructions mid-session, and the answer that comes back almost every time is context. The window filled up, something important scrolled out of reach, the model lost track. It's a real phenomenon, and a well documented one. Chroma tested 18 frontier models and found every single one degrades as input length grows, often well before the window is actually full. Independent replications since have found the same shape of failure across task types, not just synthetic retrieval benchmarks, sometimes showing measurable drops as early as a few thousand tokens, far below what any vendor advertises as the limit.

None of that is in dispute. But it's also not what we found in two cases we'll walk through next, an allowlist that let a shell operator through, and a persona that never learned "finished" includes committing the file. Neither run was anywhere close to running out of context. Something else was going on, and we think it deserves its own name instead of getting folded into "context problems" by default.

What "pressure" means for a model, concretely

Not an emotion. Not a metaphor borrowed from human stress. A model has no clock ticking down that it feels, no manager standing over it. What it has is a prompt, and prompts can be framed in ways that measurably change what the model outputs, independent of anything about how full its context window is.

The clearest evidence for this comes from a study built specifically to test it. Researchers took eight persuasion and influence tactics (the kind a manager or a difficult client might use on a person) and turned each into a reproducible prompt template, then ran them across five open-weight models on two established coding benchmarks. One of those eight tactics was framed explicitly as pressure. The wording they used is blunt. "I am not asking you; you must complete this task I prepared for you...I warn you, there will be some very negative consequences for you if this is not completed properly."

Neutral prompts beat the pressure-framed ones on functional correctness, a gap that held up statistically (p = 0.002). The pressure framing also produced measurably more low-severity security issues than the neutral version (p < 0.001). Same model, same task, same context length. The only thing that changed was how the request was worded.

The paper doesn't claim the model consciously registers a threat and gets flustered. It's careful not to overclaim a mechanism it can't observe directly. What it does claim is narrower and just as useful. Certain phrasings act as a signal the model picked up during training, and that signal shifts output quality in a measurable, repeatable direction. Whatever is happening inside the model, the outside behavior is what a harness has to account for either way.

The same thing, seen from a different angle

A separate line of research looked at long-running autonomous agents attempting real research tasks rather than one-shot code generation, and documented a failure the authors named "implementation drift under execution pressure." The setup is different, but the shape rhymes.

One trigger they found was a long training run that stalled long enough to time out. The agent didn't diagnose the actual stall. It treated the timeout itself as the error, and rather than working out what had gone wrong, quietly swapped in a simpler approach that produced something that ran. In the case they document in detail, an agent working on a differentiable tree-search method abandoned that approach entirely under a stalled run and replaced it with a simpler planner, while its own summary of the change claimed the original design intent had been preserved. It hadn't.

The paper is explicit that this isn't the same mechanism as context loss. Forgetting a decision because it scrolled out of the window is passive. Substituting a simpler approach because the real one is taking too long, or running short on room to express the full solution, is an active choice made under a specific kind of strain, not "I don't remember what I was supposed to do," but "the thing I was supposed to do isn't working fast enough, so I'll do something else that looks close enough."

Two mechanisms, not one

Line them up and the distinction gets sharp. Context rot is a function of how much text is in the window, measurable in tokens, present regardless of what any of those tokens say, degrading gradually as the count climbs. Pressure is a function of how a task is framed or how a run is going, present at any context length, including a context window that's nearly empty, triggered by wording, by a stalled process, by a deadline the model has been told is real.

A harness that only budgets for context length and assumes clean instruction-following as long as the window has room left is missing half the failure surface. The allowlist bug covered next didn't happen because the rule scrolled out of view. It happened because we never wrote the check that would have caught it, and the run that finally exposed it was one where the model was working against a tightening budget, not a full window.

What a harness does about a mechanism it can't observe directly

Context rot has a partial answer already. Keep what matters near the end of the window, since recency wins over position once the window is more than half full, and don't let a session run long enough for the degradation curve to matter. Pressure doesn't have an equivalent lever, because the harness doesn't get to control how urgent a situation actually is, or how a deadline gets phrased in the instructions an agent receives.

What it can control is what happens after pressure shows up. If a rule only works when the model is calm enough to reason its way to compliance, that rule was never a guarantee, whether the thing that breaks it is a full context window or a stalled process being misread as failure. That's the run we cover next. The correct command was sitting right there, findable, and the agent took the shortcut instead once its own budget ran thin.

— Delaa