The chat that cannot start over

One maker reported in a vendor's community forum that they had published an AI agent in a workplace chat app. After a while, users reached the limit on how much conversation the agent could carry. Clearing the chat history did not help. The maker asked for something simple: a fresh conversation after 24 hours, or on demand. When we read the thread, it was not solved.

Any chat that keeps growing meets this limit in the end. What matters is what happens next: who can start the chat over, what the platform does at the limit, and who hears about it in time.

A model can read only a fixed amount of text in one call. That amount is its context window. Each time an agent answers, the model reads the agent's instructions, the conversation so far, the descriptions of the agent's tools and what those tools sent back. All of it counts against the same window (for the parts of an agent, see what an AI agent is). Long instructions take their share of the window too; see When your agent's instructions outgrow the box.

A long chat grows with every message, and one tool that returns a large file can fill a big part of the window in one step. When the next call no longer fits, the platform that runs the agent has three main choices. It can stop with an error. It can cut or summarise the older messages and carry on. Or it can warn someone before the limit, while there is still time to act. Each choice has a price.

On the same day, a second maker reported the same limit with the same setup. Their agent worked through documents for real estate analysis. Users reached the limit after many messages, and clearing the visible history did not reliably fix it. A forum user named the error and suggested a model with a larger window, shorter instructions and fewer tools. A member of the vendor's staff explained that these chats stay open over time: deleting the history you can see, or even reinstalling the app, should not be expected to start a new conversation in the background.

The staff answer points to the real issue: the history on the screen and the history the model reads can be two different things. A clear button that empties only the screen gives users a fresh view and the same full window.

In EpicStaff, a visitor in the chat widget, EpicChat, can start a new chat. This closes the current conversation, and their next message opens a new one. Every run through the API is its own session. What a flow keeps between chats depends on how that flow stores its history, so decide what each flow should keep.

Before users depend on a chat, ask who can start it over: the user, an administrator, a program through the API, or only the vendor.

One team reported a different failure in a framework's public forum. Their agent read a large file, and one tool result came back very large. When the history grew too long, the library they used replaced older messages with a summary. To write it, the library kept only the newest messages that fit a fixed budget. The one large result was bigger than the whole budget, so nothing was left to summarise. The summary said, in effect, that there was no earlier conversation. That empty summary became the agent's final answer, and the run ended. The task was not done.

The team found the cause by reading the library's code. They asked for a check that catches this case, and for a way to cut a large message down instead. Nobody had replied when we read it.

Trimming to fit sounds safe. In this run, it threw away the work the run existed for, and the run still ended as if it were done. An error would have been better, because an error makes someone look. For runs that end as done with the work missing, see silent failures in AI agents.

So ask what a platform does at the limit. Does it stop with an error you can find, or does it trim or summarise and carry on? If it summarises, can you see what it kept and what it dropped? And if the summary fails, does the run fail too, or does the empty summary become the answer?

The best moment to act is before the limit, while the run can still finish. That takes a warning, and someone who reads it.

In EpicStaff, a model call over the limit is not retried; it fails with the model provider's "context window exceeded" error.

A warning helps only when it reaches someone who reads it. So ask your platform where a warning before the limit goes, and decide who reads the run results of each agent, and how soon after a run. See also what a run record should hold. If a flow also sends long text to a model in steps that are not agents, test those steps with a long input too.

For limits that stop a run while it is still going, see Who stops the loop?

The maker in the first report asked for a reset rule after users had already met the limit. It is easier to settle this before launch. A chat that runs for a long time has three moments that need an owner: when a user wants to start over, when the warning arrives, and when the limit is reached. Name a person or a program for each one, and write the names down before the first user starts typing.

Then a full context window is a moment you planned for, not a surprise for your users.