There's a particular way an AI coding agent goes bad. Not a crash, not an error. It just gets duller. Halfway through a long session it forgets a c...
For further actions, you may consider blocking this person and/or reporting abuse
This matches what I hit on a long agentic coding session yesterday. The fix that worked for me is upstream of clearing: I do not let the agent accumulate the reasoning in the first place.
I run consensus-critical work in phases, recon, plan, implement, and force the agent to write each phase out to a markdown artifact, then I review it and it carries forward the artifact, not the full back-and-forth that produced it. The transcript of how it figured something out is the heavy part you measured, and most of it is not load-bearing once the conclusion is written down. So the desk stays clear because the thinking lives on disk, not in the window.
The other thing that helps: re-ground against source each phase instead of trusting earlier context. If the agent re-reads the actual file before editing it, a slightly stale window matters less, because the ground truth is the repo, not the conversation.
Agreed hard on measure-before-cutting though. I almost blamed MCP for a slowdown once too, and it was history.
"The thinking lives on disk, not in the window" is the upgrade to what I wrote. My post was about clearing accumulated reasoning; you're pointing out the reasoning never had to accumulate in the first place. The transcript of how it reached a conclusion is the heavy part, and you're right that almost none of it is load-bearing once the conclusion is written down. Clearing is paying down a cost; phasing to disk is never taking it on. Same move as the handoff, just done continuously instead of once at the end.
The re-ground-against-source point is the half I'd underweighted, and it changes what "stale context" even means. If the agent re-reads the actual file before editing, the window being slightly out of date stops being dangerous, because the window was never the source of truth, the repo was. That's the quiet failure mode behind a lot of "the agent got dumber" reports: not that the window filled up, but that the agent started trusting its own summary of the file over the file. Re-reading collapses that gap every phase. Artifact for the conclusions, repo for the ground truth, window for neither. Good thread, this is the version of the idea I'll be stealing.
Clearing is paying down a cost; phasing to disk is never taking it on" is a cleaner framing than I had it. That is the distinction exactly.
On the re-grounding half: the failure I kept hitting is subtler than a stale window. It is the agent trusting its own summary of a file over the file, like you said, but the dangerous version is when the summary is mostly right. A summary that is obviously stale gets caught. One that is 90 percent right is what slips a wrong edit through, because nothing trips an alarm. So I stopped treating re-read as a freshness check and started treating it as mandatory before any edit, every phase, no exceptions, even when the window "should" be current. The window being right most of the time is what makes trusting it dangerous.
The part I am still working: re-reading the file gives you ground truth on the code, but not on the decisions. The repo tells you what the code is, not which approach you already rejected and why. That is the gap a plain re-read does not close, and it is where the decision-state record you and the others in this thread are circling has to carry the weight the repo cannot.
"The thinking lives on disk, not in the window" — that's the upgrade in one line.
Extending it to the judgment layer: not just thinking, decisions too. A decision with a lifecycle status (proposed → accepted → locked) on disk means the next session doesn't re-litigate it from window memory — it consults state. Same principle as your reply, different artifact. Same reason it works: the window stops being asked to hold what it was never good at holding.
This is the line that reframes the whole thread. Extending it: the repo holds code truth, but there's a parallel store needed for judgment truth — which architectural calls got made, which got reversed, which are locked. Without it, every session re-litigates the same decisions because the model has no record they were settled.
Your artifact-first pattern carries this implicitly (each phase becomes an inspectable record). Making the decision-state explicit and addressable — separate from code, separate from prose summaries — is the missing layer for me.
"Parallel store for judgment truth" is the right name for it, and the reason it has to be separate from the repo is that the two stores have different lifecycles. Code truth is overwritten, the latest commit wins and history is archive. Judgment truth is additive, a rejected approach stays relevant precisely because it was rejected, and a future session needs to see the rejection, not just the survivor. A git log does not carry that, it shows what won, not what was ruled out and why.
Where I have landed: the decision record needs the reversed and superseded entries to stay first-class and addressable, not pruned, because the value is in the path not the endpoint. The thing I am still wrestling is keeping it from rotting. A decision store nobody trusts is worse than none, because the model cites a stale "locked" entry with false authority. So the addressability you are after only pays off if the status stays honest, which loops back to the operator-owned-transition point from the other branch of this thread. Same missing layer, and the hard part is not building it, it is keeping it true.
Measuring the context window before blaming MCP is the right instinct. A lot of tool-problem debugging is really context decay, stale instructions, or the model compressing away the one constraint that mattered. I like treating context as an observable resource instead of a vague feeling that the agent got worse.
"An observable resource instead of a vague feeling" is exactly the shift I was after. The moment you can read the breakdown, "the agent got worse" stops being a mood and becomes a measurement you can act on. Half the time the tool was never the problem; the instruction you set early got buried, or the model compressed away the one constraint that mattered, and you'd never see that by staring at the tools.
The compression case you name is the sneaky one, because it looks identical to the model "forgetting." The constraint was there, it was real, and it got squeezed out to make room. Which is the same lesson from another angle: don't trust the felt sense of what went wrong, read where the tokens actually went. Tools get blamed because they're visible; context decay does its damage quietly.
Yes, compression failure is nasty because it looks like personality drift from the outside. The model still sounds coherent, but the constraint that made the run safe is no longer active enough to steer behavior.
That is why I like explicit state checks: what instructions are still loaded, what artifacts are pinned, what budget is left, and what was summarized away.
"Looks like personality drift from the outside" is the exact trap. The voice survives compression, so it sounds fine, and the thing that's gone is invisible because it never showed up in the prose to begin with. You stop trusting tone as evidence once you've been burned by that once.
Your explicit-state-check list is the part I'd put on a wall: what's still loaded, what's pinned, what budget's left, what got summarized away. That last one is the quiet killer, because a summary reads as complete even when it dropped the one line that was steering the run. Checking what got compressed out is harder than checking what's present, and it's usually the one that matters. Good thread.
Yes, checking what disappeared is the hard half.
One practical trick is to make the summary list its omissions: "dropped raw logs, intermediate candidates, rejected branches, unresolved uncertainty." It is not perfect, but it gives the next agent a reason to distrust the summary in the right places.
Compression is safest when it admits what it compressed away.
Making the summary declare its own omissions is the most practical fix in this whole thread, because it attacks the exact thing that makes compression invisible: the dropped constraint never showed up in the prose, so the only way to see it is to force the prose to name what it left out. "Dropped raw logs, rejected branches, unresolved uncertainty" turns an absence into a line you can actually read.
"Compression is safest when it admits what it compressed away" is the sentence I'm keeping. It reframes the summary from a clean artifact into an honest one, and honest beats clean here, because a clean summary that silently dropped the steering constraint is more dangerous than a messy one that flags the gap. The omission list is basically the summary leaving its own audit trail, telling the next agent where to distrust it. That's the discipline. Good thread.
The measure-before-cutting instinct is the whole game here. I've watched people rip out MCP servers when the real drift was a 40k-token transcript nobody trimmed, and the per-category breakdown is the part most tools just don't show you. Did seeing it change how you structure long sessions, or only what you cut?
The 40k-token transcript nobody trimmed is the exact shape of it, and you're right that the per-category breakdown is the part almost nothing surfaces. Without it you're not measuring, you're just picking the component you already suspected.
To your question: it changed structure more than it changed what I cut. Cutting was the first reaction, but once I could see that history was the slice that grows, the better move was to stop letting it grow that far in the first place. So now I scope sessions tighter. One task per session, hand off a summary, start clean, instead of running one long thread and trimming it after it's already heavy. The trim is reactive, it's paying down a cost after you've taken it on. Structuring for shorter sessions is preventive, you never let the transcript reach 40k. Seeing the breakdown is what moved me from cutting after the fact to structuring so there's less to cut. What about you, did the visibility change how you start sessions, or mostly what you remove from them?
It changed how I start more than what I remove. Once I saw history is the slice that keeps growing, the better move stopped being "trim the heavy session" and became "never let it get heavy": one task per session, hand off a short summary, start clean. Trimming pays down a cost you already took on, but shorter sessions mean you never hit 40k to begin with.
This resonates with something I’ve noticed as well.
We often talk about context windows as a capacity problem, but in practice they’re also an attention-allocation problem. Not all tokens have equal value. A 5,000-token transcript full of exploration, dead ends, and outdated assumptions can be less useful than a 500-token summary containing the current constraints and decisions. What makes this interesting is that the challenge starts to look less like memory management and more like knowledge management. The question becomes: what information deserves to stay in active context, and what should be compressed into a higher-level representation?
In that sense, context engineering is starting to feel a lot like software architecture.
The shift from capacity to attention-allocation is the right frame, and it opens a follow-up: where does the constraint go when it's not "in attention" anymore?
The safest answer I've found is not "summarize it" but "relocate it" — into a separate store the model consults at session boundary. A locked decision in that store isn't compressed-with-disclosure (which can still drift via paraphrase), it's moved at full fidelity, with the model told to read it before answering. Different mechanism than admitting-what-was-omitted, same anti-amnesia property, but the constraint stays exact instead of getting summarized.
Relocate over summarize is the right call, and full fidelity is what makes it safe. The caveat I'd add: moving the decision at full fidelity fixes paraphrase drift but not staleness. An exact locked decision that got reversed later is more dangerous than a fuzzy summary, because it reads authoritative and the model has no reason to doubt it. So the store needs status (locked, reversed, open) as much as it needs fidelity. The two are orthogonal: fidelity keeps the wording exact, status keeps the entry honest. You want both, or the model faithfully reads back a settled-looking call that nobody ever un-locked.
The orthogonality is the move I missed. Fidelity without status is a high-resolution lie — the relocated decision reads more confidently than a summary would, which makes the staleness failure worse, not safer. You're right that those have to travel together.
The way I've been keeping them linked: every locked entry carries a verifiable_by pointer at the test or scan that justifies it. If the diagnostic still passes, the lock holds. If it breaks, the entry auto-flags as stale instead of getting silently re-read as authoritative. Fidelity stays exact in the store; status gets challenged from outside the store. That's the only way I've found to stop the operator from being the bottleneck on un-locking — manual flipping breaks under session length, every time.
Where I'm still uncertain: how aggressive the auto-flag should be. False positives turn the lock into noise (operator starts ignoring stale flags). False negatives keep authoritative lies in circulation. Have you found a threshold that holds, or does it stay task-by-task?
The shift from capacity to attention-allocation is the part I undersold in the post. I measured which slice was biggest and stopped there, but you're right that size is the crude proxy. A 5,000-token transcript of dead ends can actively cost you, not just by taking room, but by diluting the few hundred tokens that actually carry the current constraints. Big and useful aren't the same axis.
The knowledge-management reframe is where it gets real. Once you accept that tokens have unequal value, "keep the session short" is too blunt. The better move is deciding what gets promoted into a compact, high-level representation and what stays raw, which is exactly the summarize-and-hand-off step, just named properly. And the architecture comparison holds: you're drawing module boundaries, deciding what's interface and what's implementation detail the caller shouldn't hold. Context engineering as deciding what deserves to stay loaded. That's a better frame than the one I wrote to.
The 'read the breakdown before you cut anything' point is the whole thing, and it generalizes past context windows. The instinct is always to blame the newest component (MCP here), and the actual cost is usually the boring accumulated thing nobody switched on. I hit the same with long agent sessions: the transcript is the weight, and the fix is exactly your handoff-the-summary move, carry the gist into a fresh session, not the full back-and-forth. The desk-not-filing-cabinet line is the right model. Measure first, cut the slice that's actually large, and accept last time's culprit isn't a rule.
"It generalizes past context windows" is the part I didn't say out loud but should have. The pattern isn't about tokens, it's about where attention goes when something degrades: the newest, most nameable component gets blamed because it's visible, and the boring accumulated thing gets a pass because nobody switched it on. That's true of context windows, slow test suites, bloated CI, almost any system that quietly fills up.
The one line I keep coming back to is your last one: last time's culprit isn't a rule. That's the whole discipline, really. The moment you turn "it was history that time" into "it's always history," you're back to guessing, just with a more specific guess. The only durable move is to measure again, because the boring thing that fills up is rarely the same boring thing twice. Good read on it.
Last time's culprit isn't a rule' being the whole discipline is exactly it, the moment you promote one measurement into a law, you're guessing again with extra confidence. The newest nameable component takes the blame, the boring accumulated thing skates because nobody switched it on, and it's the same across context windows, CI, test suites, all of it. Measure again every time, because the thing that fills up is rarely the same thing twice. Good exchange, this one's going to stick with me.
"Guessing again with extra confidence" is the sharpest way anyone's put it in this thread. That's the trap exactly: the law feels like progress, but it's just a more confident version of the thing measuring was supposed to replace. Glad this one's sticking with you, it's sticking with me too. Thanks for the exchange.
The most useful takeaway here is the reminder to measure before optimizing. It's easy to blame the newest component in the stack MCP, tools, memory systems when behavior degrades, but bottlenecks are often much less exciting.
The "context window as a desk, not a filing cabinet" analogy is spot on. Long-running agent sessions accumulate hidden costs, and conversation history often becomes the biggest source of context pressure without anyone noticing.
A good lesson for AI builders in general: when quality drops, inspect where tokens are actually being spent before redesigning the system around assumptions. The diagnosis is often more valuable than the fix.
"The diagnosis is often more valuable than the fix" is the line I'll keep from this. The fix in my case was almost boring, shorten the session, hand off a summary. What had value was finding out that history, not the component I'd have bet on, was the weight. The fix took a minute; the measurement changed what I'd reach for next time.
And you put your finger on why the newest component gets blamed: it's the one you can picture, the one with a name and a config. Conversation history has no on-switch, so it doesn't feel like a thing you added, which is exactly why it grows unwatched. Boring bottlenecks win because nobody's looking at them. Measuring is mostly just agreeing to look where it isn't interesting.
One thing that stands out to me is that context pressure is not purely a token-budget problem; it’s also an information-quality problem.
Two sessions can consume the same number of tokens and produce very different outcomes. A context filled with outdated assumptions, abandoned approaches, and exploratory noise can be more harmful than a much smaller context containing only current decisions and constraints.
This is why I increasingly see context engineering as a form of information architecture. The challenge isn’t just fitting information into the window, but continuously deciding what remains operational knowledge, what becomes summarized knowledge, and what should be discarded entirely.
Measuring token allocation tells us where the space goes. Understanding information value tells us what deserves to stay.
"Measuring tells you where the space went; understanding value tells you what deserves to stay" is the sharper version of what I was reaching for. My post measured the symptom. You named the discipline under it. Two sessions burning the same token count can land in completely different places, and the difference is the quality of what's loaded, not the quantity.
The information-architecture frame is the part I'll carry. Token budget asks "does it fit." Information value asks "should it still be here," and those come apart fast: a context can be half-full and still poisoned by abandoned approaches the model keeps treating as live. The hard, ongoing call is exactly the three buckets you drew, operational, summarized, discarded, and almost nothing in the tooling helps you decide which is which. That's a human judgment for now. Good thread.
The desk analogy maps directly onto something we ran into building Blogboat, our AI blog writing tool. When users run a full AI session to draft, then revise, then re-prompt for tone in the same context, the later outputs get noticeably muddier than if they started a fresh session for each distinct task.
We ended up designing around it: treat each block-level edit as its own bounded context rather than a continuation of the original draft session. The AI doesn't "know" what came before it rewrote section 3. That sounds like a limitation but it's actually cleaner — the edit is evaluated on its own terms, not on the accumulated noise of all the earlier turns.
Your measure-first principle is the one more tools need to surface. Most writing AI just hides the context plumbing entirely, which means users never learn why quality drops late in a session. The breakdown you described is exactly the kind of visibility that would help them course-correct.
Treating each block edit as its own bounded context instead of a continuation is the move, and I like that you framed the forgetting as a feature rather than a workaround. It is one. "The AI doesn't know what came before it rewrote section 3" sounds like a limitation right up until you notice the alternative is the edit inheriting every earlier turn's noise whether or not it's relevant. Bounded context isn't the model knowing less, it's the model not being steered by things that have nothing to do with the current edit.
Your last point is the one I'd underline hardest. Hiding the context plumbing entirely is what keeps users stuck, because the quality drop feels like the AI randomly getting worse, with no visible cause to act on. They can't course-correct a thing they can't see. Surfacing even a rough breakdown turns "it got dumb" into "the session got long, start fresh," which is a move the user can actually make. The tools that expose the plumbing are teaching the user the one habit that fixes it; the ones that hide it are quietly training learned helplessness. Good example to bring in, the bounded-edit design is the same lesson from the product side.
This is a really clean breakdown of something people usually hand-wave as “model got worse” when it is actually just context economics.
The part that stands out is your observation about conversation history being the dominant cost. It is almost invisible because it feels like “free continuity,” but in reality it is the fastest-growing line item in long exploratory sessions. The desk vs filing cabinet analogy nails it especially because most workflows implicitly treat the window like storage, not workspace.
Also agree with your caution on MCP assumptions. People tend to over-index on the most “architecturally interesting” component (tools, agents, servers) and under-check the boring accumulators like chat history, retrieved snippets, or repeated system instructions.
Curious, have you experimented with hybrid continuity, like keeping a rolling structured state instead of full summaries? It seems like that might preserve reasoning quality even better than plain summarization.
Good question, and honest answer: I haven't run rolling structured state as my default. What I actually do is closer to plain summarize-and-restart, so I'm speaking to the idea more than from a worn-in setup with it. That said, I think you're right that it preserves reasoning better, with one tradeoff worth naming. A summary lets you decide what mattered after the fact, loosely. A structured state makes you commit to a schema up front, so anything you didn't think to give a field early gets no seat later. It trades drift for omission: the structured store won't quietly rewrite your early constraint, but it will quietly drop the thing your schema had no slot for. So the question I'd want answered before adopting it is which failure I'd rather debug three months out, a constraint that drifted or one that was never captured. For the constraints I know are load-bearing, structured wins easily. For exploratory work where I don't yet know what will matter, the loose summary has saved me more than once. I suspect the real answer is hybrid in the literal sense: structured state for the locked decisions, a thin summary for everything still in flux.
The summarize-and-carry-forward step is the right move, but the summary itself is the next trap: a freeform recap is its own lossy compression, and it tends to drop exactly the early constraint that mattered, the same way the long session does. What helped me was making that carried-over memory typed instead of a blob: decisions in one file, open questions in another, assumptions in a third, with a rule that decisions and open questions always get written at the end of a task. The next session reads structure, not a paragraph the model happened to keep. I run this less for coding and more for longer business workflows where sessions are days apart, so the desk is always cold and the cabinet is the only thing I trust. The honest cost is drift: the files start to contradict each other over time, so you need a periodic pass to reconcile them or the cabinet fills with stale entries. When you carry the gist forward, how do you keep the summary from quietly compressing away the constraint you set in the first ten minutes?
Short answer: I stopped trusting the summary to carry the constraint at all. The recap is allowed to compress the narrative, but the first-ten-minutes constraints don't go through it. They live in a small fixed block, written verbatim when I set them, and that block gets prepended every session ahead of the summary. So the question isn't "how do I keep the summary from dropping the constraint" but "how do I keep the constraint out of the summary's jurisdiction." A recap is lossy by design, so I don't ask it to hold the one thing I can't afford to lose. Your typed-file split is the same instinct, just sorted by kind instead of by lifespan. On the reconcile cost you named: I only reconcile the constraint block, and only when something in it actually gets revoked. The narrative files I let rot, because they were always disposable.
Good framing. The agent often does not get dumber. The context gets messier.
Before blaming MCP, it is worth checking token usage, noisy tool outputs, stale instructions, and whether too many tools are enabled.
"The agent doesn't get dumber, the context gets messier" is a cleaner way to say it than my whole title. The list you give is the right order to check too, and the sneaky one is stale instructions, because they look fine sitting in the window while quietly steering nothing. Cheap to check, easy to miss. Good addition.
Strong write-up. The part that resonated with me most was treating context as something observable instead of something you only feel after quality drops. In my own agent workflows, the biggest gains usually come from shortening the session boundary and carrying forward a deliberate handoff, not from ripping out tools. Your desk-vs-filing-cabinet framing explains that tradeoff really well.
That match between your workflow and the post is the part I find reassuring, because it means it isn't just my setup. The deliberate handoff is the move people skip, I think, because it feels like overhead in the moment. Ripping out a tool feels like progress, you can see the thing leave. Writing a clean handoff feels like extra work for no visible gain, right up until the session you start clean runs noticeably sharper than the one you dragged the whole transcript into. The gain is real, it's just deferred, which is exactly why the visible-but-wrong fix wins by default. Appreciate you reading it.
This is a great reminder that context issues are not always where we expect them to be but the bigger lesson is the debugging mindset: inspect the context budget before optimizing the setup. Otherwise it is easy to remove tools, keep the real bottleneck and convince yourself you improved the workflow.
Do you think agents should expose this breakdown by default during long sessions?
Glad the debugging-mindset part landed. That was the part I cared about most.
On showing the breakdown by default, I'm torn. A number that's always on screen tends to get ignored, the way you stop noticing a progress bar. It was useful to me because I went in with a specific question, "what's actually filling this," not because it happened to be in front of me.
So what I'd want is the cheap version of both: keep the full breakdown one command away, always, and have the agent poke me when one slice (usually history) gets big, instead of asking me to watch a dashboard. An interruption gets me to look; a dashboard I'd stop checking within the hour.
There's a quieter risk in always-on too. It pushes people to cut things reflexively, which is the move the post warns against. Seeing the numbers only helps if "read before you cut" comes with them. So I'd say make it easy to inspect, for sure. Default-on, I'm less sure.
I do the same as well on the part of letting AI summarizing the whole chat in one prompt before moving on a fresh chat. It's a hassle when it slows down and you are currently in the flow of learning new things, verifying documents, and testing simple code. So the rule I set for myself is that if I saw some slight slowdown, I would immediately move to a fresh chat. I just copy and paste my written "summarize this chat" prompt from my notepad to keep things faster.
The saved-prompt-in-a-notepad trick is the part that makes this actually stick. The summarize-and-restart idea is easy to agree with, but in the middle of a flow nobody wants to write the handoff prompt from scratch, so they just push the slow session further. Having it one paste away removes the friction that would otherwise make you skip it.
The one thing I've added: I try to move at the first slight slowdown like you do, rather than waiting for it to get bad, because the summary you write early is cleaner than the one you write from a session that's already bloated. Once the context is heavy, even the summary it generates starts dragging the noise along with it. Early handoff, smaller and sharper summary. Sounds like you're already there.
@butialrj what you are mentioning is correct but I'm just not that disciplined yet to make prompt summaries each time before it slows down hahaha. But that is a good habit to follow. Sometimes I just notice that my chat is longer when it slows down, that's basically my indicator, but yeah I will try and do yours as well.