{"slug": "why-does-your-ai-coding-agent-start-forgetting-what-it-was-doing", "title": "Why Does Your AI Coding Agent Start Forgetting What It Was Doing?", "summary": "A developer has built Tokenectomy, a preprocessing layer that filters logs, stack traces, and tool output before they reach an AI coding agent, aiming to stop agents from re-investigating already-fixed issues during long debugging sessions. The developer argues that agent \"forgetting\" is often caused by noisy, stale context rather than a small context window, and that preserving a clear state of what is done versus still broken matters more than raw context capacity.", "body_md": "Why Does Your AI Coding Agent Start Forgetting What It Was Doing?\n\nI've been working with AI coding agents for quite a while, and there's one behavior that keeps bothering me.\n\nAt first, everything looks fine.\n\nThe agent understands the task, reads the error, finds the relevant file, makes a change, runs the test, and moves forward.\n\nThen, after several iterations, something strange can happen.\n\nThe agent starts going back to things that have already been fixed.\n\nIt reads old errors again.\n\nIt investigates files that are no longer relevant.\n\nSometimes, it even starts working on something that was already completed instead of focusing on the part that is still broken.\n\nAnd the first thing we usually think is:\n\n\"The model is getting stupid.\"\n\nBut I'm not convinced that's always the real problem.\n\nThe context gets messy\n\nWhen an AI coding agent works on a real software project, it doesn't only see the code.\n\nIt also sees a lot of other information:\n\nframework logs\n\nstack traces\n\ndependency output\n\ntool responses\n\nterminal output\n\nprevious errors\n\nrepeated information\n\nfiles from previous investigations\n\ndebugging attempts that are already finished\n\nAnd this happens over and over again.\n\nA long debugging session can look something like this:\n\nTask\n\n  ↓\n\nError\n\n  ↓\n\nTool call\n\n  ↓\n\nFramework logs\n\n  ↓\n\nStack trace\n\n  ↓\n\nRelevant code\n\n  ↓\n\nPatch\n\n  ↓\n\nTest\n\n  ↓\n\nNew error\n\n  ↓\n\nMore logs\n\n  ↓\n\nMore tool output\n\n  ↓\n\nAnother patch\n\n  ↓\n\nAnother test\n\n  ↓\n\n...\n\nThe agent keeps accumulating information.\n\nEventually, the problem may not be that the context window is too small.\n\nIt may simply be that the context has become too noisy.\n\nA bigger context window doesn't automatically solve this\n\nThis is something I've been thinking about for a while.\n\nEven if an LLM has a very large context window, an agent can still fill that context with information that is no longer useful.\n\nSo the question isn't only:\n\n\"How much information can the model handle?\"\n\nIt is also:\n\n\"How much of that information is actually useful right now?\"\n\nImagine an agent is debugging a large application.\n\nEarly in the process, it discovers a problem in the authentication middleware.\n\nIt fixes the issue.\n\nThe tests pass.\n\nThe agent moves on.\n\nTen iterations later, that entire investigation is still sitting somewhere in the conversation alongside old logs, tool outputs, stack traces, and previous debugging attempts.\n\nThe agent can still see it.\n\nBut the useful state is much simpler:\n\nAuthentication middleware\n\n→ DONE\n\nDatabase transaction\n\n→ STILL BROKEN\n\nThat distinction matters.\n\nIf everything remains in the context without a clear representation of what has already been resolved, the agent has to continuously work through information that may no longer be relevant to the current problem.\n\nAnd that's where things get interesting.\n\nThis is why I started building Tokenectomy\n\nTokenectomy started from a simple idea:\n\nWhat if we process the information before giving it to the agent?\n\nInstead of blindly passing everything produced by the environment back into the model, we can try to:\n\nremove unnecessary noise\n\nkeep the relevant information\n\nextract useful context\n\npreserve important state\n\nredact sensitive information\n\nreduce irrelevant output\n\nThe idea looks roughly like this:\n\nRaw Environment\n\n               │\n\n               ▼\n\n   ┌─────────────────────────┐\n\n   │ logs / stack traces      │\n\n   │ tool output / code       │\n\n   │ terminal output          │\n\n   └────────────┬────────────┘\n\n                │\n\n                ▼\n\n           Tokenectomy\n\n                │\n\n                ▼\n\n      Relevant Context + State\n\n                │\n\n                ▼\n\n           AI Agent\n\n                │\n\n                ▼\n\n          Action / Patch\n\n                │\n\n                ▼\n\n            Test / Run\n\n                │\n\n                └──────────► Feedback\n\nThe goal isn't to make the underlying model magically smarter.\n\nThe goal is to make the information surrounding the model more useful.\n\nTokenectomy isn't just about saving tokens\n\nThis is an important distinction.\n\nAt first glance, something that removes unnecessary context sounds like a token optimization tool.\n\nBut I'm more interested in what happens after the cleanup.\n\nIf an agent receives less irrelevant information, does it make fewer unnecessary tool calls?\n\nDoes it repeat fewer investigations?\n\nDoes it stay focused on the remaining problem for longer?\n\nDoes its performance degrade less as the debugging session becomes longer?\n\nThose are much more interesting questions to me than simply:\n\n\"How many tokens did we save?\"\n\nTokenectomy is evolving into an infrastructure/tooling layer for AI agents, with things like MCP tools, context processing, code analysis, patching, and an AI Gateway.\n\nBut the technology itself isn't really the interesting part.\n\nThe interesting part is the hypothesis behind it:\n\nCan better context management make an AI agent more reliable during long-running tasks?\n\nI'm not saying context noise is always the problem\n\nThis is important.\n\nI'm not claiming that every AI agent failure is caused by messy context.\n\nAgents can fail for many different reasons.\n\nThe model can misunderstand the task.\n\nA tool can return bad information.\n\nThe generated patch can be incorrect.\n\nThe test environment can be broken.\n\nThe agent can simply make a bad reasoning decision.\n\nContext noise is only one possible factor.\n\nBut I've repeatedly seen situations where an agent starts revisiting old work during long debugging sessions.\n\nSo instead of saying:\n\n\"AI agents forget because their context gets messy.\"\n\nI'd rather ask:\n\n\"What happens if we deliberately remove irrelevant context during a long debugging trajectory?\"\n\nThat's something we can actually test.\n\nLet's measure it\n\nIf this idea is real, it should show up in the data.\n\nFor example:\n\nHow many tokens are sent to the model?\n\nHow many iterations are required?\n\nHow often does the agent repeat completed work?\n\nHow often does it call irrelevant tools?\n\nHow often does it revisit previously resolved errors?\n\nDoes the final patch pass the tests?\n\nHow does performance change as the debugging session gets longer?\n\nDoes context cleaning reduce that degradation?\n\nThe goal isn't to make a nice-looking demo.\n\nThe goal is to find out whether this actually changes the behavior of an agent.\n\nThat's where Kronumos comes in\n\nI'm also building Kronumos, a specialized software-repair agent, to experiment with this idea in a more focused environment.\n\nKronumos isn't meant to be another general-purpose coding assistant.\n\nThe idea is much narrower:\n\nBug\n\n ↓\n\nUnderstand the failure\n\n ↓\n\nGet relevant context\n\n ↓\n\nAnalyze the code\n\n ↓\n\nGenerate a patch\n\n ↓\n\nRun tests\n\n ↓\n\nInspect the result\n\n ↓\n\nFix again if necessary\n\nThis gives me a controlled environment where I can experiment with different combinations of:\n\nmodel + context + tools + execution feedback.\n\nAnd that's the part I'm really interested in.\n\nI'm not trying to claim that a small model is inherently smarter than a much larger model.\n\nThat's not the question.\n\nThe question is:\n\nHow much can system design, specialized training, better context, and a proper feedback loop affect the performance of an AI agent?\n\nBecause sometimes the model might not be the only problem.\n\nSometimes, maybe, we're just giving it too much garbage.\n\nAnd that's the problem I'm trying to solve with Tokenectomy.\n\nI'd love to hear from other developers\n\nHave you ever had an AI coding agent suddenly start working on something it had already finished?\n\nOr had an agent repeatedly investigate an error that you thought was already resolved?\n\nI'm curious whether other people are seeing the same behavior in long-running coding sessions.", "url": "https://wpnews.pro/news/why-does-your-ai-coding-agent-start-forgetting-what-it-was-doing", "canonical_source": "https://dev.to/daffa2555/why-does-your-ai-coding-agent-start-forgetting-what-it-was-doing-fpp", "published_at": "2026-09-22 23:19:03+00:00", "updated_at": "2026-09-22 23:52:37.255985+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models", "developer-tools", "ai-infrastructure"], "entities": ["Tokenectomy"], "alternates": {"html": "https://wpnews.pro/news/why-does-your-ai-coding-agent-start-forgetting-what-it-was-doing", "markdown": "https://wpnews.pro/news/why-does-your-ai-coding-agent-start-forgetting-what-it-was-doing.md", "text": "https://wpnews.pro/news/why-does-your-ai-coding-agent-start-forgetting-what-it-was-doing.txt", "jsonld": "https://wpnews.pro/news/why-does-your-ai-coding-agent-start-forgetting-what-it-was-doing.jsonld"}}