Foreword

If you use Agent frequently, you've probably encountered this situation.

With the same model, the initial responses are fast and the reasoning is clear; but as the conversation grows longer, it starts replying slowly, may forget what was discussed earlier, and sometimes might even misunderstand requirements.

Many people think the model is failing, but what has actually changed is the Context.

The model determines the upper limit of an Agent's capability, while Context management affects whether that capability can be sustained and delivered consistently.

Context Is Not Just Chat History

Many people assume Context is just the chat history.

In reality, chat history is only one part of it.

Every time an Agent calls a model, the content actually sent typically includes:

• System Prompt
• Current Prompt
• Historical conversation
• Currently read code
• Memory
• Project rules
• Others

These elements together form the information the model can currently see, which is the Context.

So, Context is more like the Agent's current working environment, not a chat log.

Why Does Context Keep Growing?

Because every time a task is completed, new information is added to the next round of Context.

For example, a simple requirement change might cause the Agent to read multiple code files, invoke tools like the terminal and Git, query project documentation, and record new chat content. This information doesn't disappear automatically; it accumulates layer by layer.

As development progresses, Context grows continuously. Eventually, the content sent to the model in a single request might become:

System Prompt + Historical conversation + Project code + Tool return results + Memory + Current requirement

In other words, every time the model answers, it needs to re-understand the entire working environment. It's like an assistant who, before answering every question, has to re-examine everything on the desk.

Why Does Larger Context Sometimes Lead to Worse Results?

Many people think that the larger the Context, the more information the model knows, and the better the results should be.

But what truly affects performance is not the length of the Context, but the amount of effective information.

For example, a session first discusses a database, then modifies project configuration, and finally starts developing a page. When the Agent modifies a component, much of the earlier content is already irrelevant to the current task.

This irrelevant information doesn't make the model "dumber," but it increases the cost of comprehension. Common symptoms include:

• Slower response speed;
• Easier to miss details;
• Occasionally mixing up different tasks, leading to off-target answers.

Therefore, Context is not about having more, but about being more relevant.

Is a Large Context Window Problem-Free?

Many models now support 128K, 200K, or even 1M context windows.

But the Context Window is more about capacity than efficiency.

It's like a two-thousand-page book: although all the content is there, finding information on a specific page still takes time.

The model is similar.

Therefore, even if the Context Window is large, if it's filled with historical tasks, irrelevant code, and repetitive information, answer quality can still be affected.

How to Manage Context

One Feature, One Conversation

Try not to put different tasks into the same conversation.

Splitting tasks keeps each conversation relatively clean.

Periodically Organize Context

After completing a phase, have the Agent output a summary of the current feature.

Next time, continue directly based on the summary, rather than relying on dozens of rounds of historical chat.

Solidify Repetitive Processes into Skills

This is something I've come to appreciate more deeply later on.

Many processes are repeated daily.

If you re-describe them every time, it not only wastes time but also continuously increases Context.

A better approach is to organize these fixed processes into Skills, or solidify them into long-term configurations like AGENTS.md or Rules.

This way, the Agent only needs to know "execute according to this Skill" each time, rather than re-understanding the entire process.

Essentially, this means extracting stable information from the chat history, loading it only when needed, instead of letting it pile up in the Context.

Reduce Irrelevant Information

Try to narrow the Agent's scope of work.

For example, if you've already determined that the problem lies in a specific module, directly tell the Agent to modify the corresponding file, or provide relevant code snippets, rather than having it re-scan the entire project every time.

The more focused the information given to the model, the easier it is for it to understand your real needs, and the less interference from irrelevant information in the Context.

Often, a clean, relevant Context is more valuable than a lengthy one full of noise.

Final Thoughts

A good Agent workflow isn't about constantly piling information into the chat history, but about putting different information in the right places: rules go to Rules, repetitive processes are solidified into Skills, project knowledge goes to Memory or RAG, and the current Session only focuses on the task at hand.

The model determines the upper limit of an Agent's capability, and Context management determines whether the model can sustain and efficiently deliver that capability.