Why Does Your AI Coding Agent Start Forgetting What It Was Doing?
I've been working with AI coding agents for quite a while, and there's one behavior that keeps bothering me.
At first, everything looks fine.
The agent understands the task, reads the error, finds the relevant file, makes a change, runs the test, and moves forward.
Then, after several iterations, something strange can happen.
The agent starts going back to things that have already been fixed.
It reads old errors again.
It investigates files that are no longer relevant.
Sometimes, it even starts working on something that was already completed instead of focusing on the part that is still broken.
And the first thing we usually think is:
"The model is getting stupid."
But I'm not convinced that's always the real problem.
The context gets messy
When an AI coding agent works on a real software project, it doesn't only see the code.
It also sees a lot of other information:
framework logs
stack traces
dependency output
tool responses
terminal output
previous errors
repeated information
files from previous investigations
debugging attempts that are already finished
And this happens over and over again.
A long debugging session can look something like this:
Task
↓
Error
↓
Tool call
↓
Framework logs
↓
Stack trace
↓
Relevant code
↓
Patch
↓
Test
↓
New error
↓
More logs
↓
More tool output
↓
Another patch
↓
Another test
↓
...
The agent keeps accumulating information.
Eventually, the problem may not be that the context window is too small.
It may simply be that the context has become too noisy.
A bigger context window doesn't automatically solve this
This is something I've been thinking about for a while.
Even if an LLM has a very large context window, an agent can still fill that context with information that is no longer useful.
So the question isn't only:
"How much information can the model handle?"
It is also:
"How much of that information is actually useful right now?"
Imagine an agent is debugging a large application.
Early in the process, it discovers a problem in the authentication middleware.
It fixes the issue.
The tests pass.
The agent moves on.
Ten iterations later, that entire investigation is still sitting somewhere in the conversation alongside old logs, tool outputs, stack traces, and previous debugging attempts.
The agent can still see it.
But the useful state is much simpler:
Authentication middleware
→ DONE
Database transaction
→ STILL BROKEN
That distinction matters.
If 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.
And that's where things get interesting.
This is why I started building Tokenectomy
Tokenectomy started from a simple idea:
What if we process the information before giving it to the agent?
Instead of blindly passing everything produced by the environment back into the model, we can try to:
remove unnecessary noise
keep the relevant information
extract useful context
preserve important state
redact sensitive information
reduce irrelevant output
The idea looks roughly like this:
Raw Environment
│
▼
┌─────────────────────────┐
│ logs / stack traces │
│ tool output / code │
│ terminal output │
└────────────┬────────────┘
│
▼
Tokenectomy
│
▼
Relevant Context + State
│
▼
AI Agent
│
▼
Action / Patch
│
▼
Test / Run
│
└──────────► Feedback
The goal isn't to make the underlying model magically smarter.
The goal is to make the information surrounding the model more useful.
Tokenectomy isn't just about saving tokens
This is an important distinction.
At first glance, something that removes unnecessary context sounds like a token optimization tool.
But I'm more interested in what happens after the cleanup.
If an agent receives less irrelevant information, does it make fewer unnecessary tool calls?
Does it repeat fewer investigations?
Does it stay focused on the remaining problem for longer?
Does its performance degrade less as the debugging session becomes longer?
Those are much more interesting questions to me than simply:
"How many tokens did we save?"
Tokenectomy is evolving into an infrastructure/tooling layer for AI agents, with things like MCP tools, context processing, code analysis, patching, and an AI Gateway.
But the technology itself isn't really the interesting part.
The interesting part is the hypothesis behind it:
Can better context management make an AI agent more reliable during long-running tasks?
I'm not saying context noise is always the problem
This is important.
I'm not claiming that every AI agent failure is caused by messy context.
Agents can fail for many different reasons.
The model can misunderstand the task.
A tool can return bad information.
The generated patch can be incorrect.
The test environment can be broken.
The agent can simply make a bad reasoning decision.
Context noise is only one possible factor.
But I've repeatedly seen situations where an agent starts revisiting old work during long debugging sessions.
So instead of saying:
"AI agents forget because their context gets messy."
I'd rather ask:
"What happens if we deliberately remove irrelevant context during a long debugging trajectory?"
That's something we can actually test.
Let's measure it
If this idea is real, it should show up in the data.
For example:
How many tokens are sent to the model?
How many iterations are required?
How often does the agent repeat completed work?
How often does it call irrelevant tools?
How often does it revisit previously resolved errors?
Does the final patch pass the tests?
How does performance change as the debugging session gets longer?
Does context cleaning reduce that degradation?
The goal isn't to make a nice-looking demo.
The goal is to find out whether this actually changes the behavior of an agent.
That's where Kronumos comes in
I'm also building Kronumos, a specialized software-repair agent, to experiment with this idea in a more focused environment.
Kronumos isn't meant to be another general-purpose coding assistant.
The idea is much narrower:
Bug
↓
Understand the failure
↓
Get relevant context
↓
Analyze the code
↓
Generate a patch
↓
Run tests
↓
Inspect the result
↓
Fix again if necessary
This gives me a controlled environment where I can experiment with different combinations of:
model + context + tools + execution feedback.
And that's the part I'm really interested in.
I'm not trying to claim that a small model is inherently smarter than a much larger model.
That's not the question.
The question is:
How much can system design, specialized training, better context, and a proper feedback loop affect the performance of an AI agent?
Because sometimes the model might not be the only problem.
Sometimes, maybe, we're just giving it too much garbage.
And that's the problem I'm trying to solve with Tokenectomy.
I'd love to hear from other developers
Have you ever had an AI coding agent suddenly start working on something it had already finished?
Or had an agent repeatedly investigate an error that you thought was already resolved?
I'm curious whether other people are seeing the same behavior in long-running coding sessions.
Top comments (0)