My agent kept getting worse after 24+ hours, and the fix was using less context, not more

I keep seeing the same failure mode in agent systems.

Someone wires up GPT-5, Claude, or another strong model, gives it a huge context window, and decides the safest thing is to keep everything:

• every user turn
• every tool call
• every failed plan
• every browser scrape
• every summary of every summary
• every giant JSON blob from n8n, Make, or Zapier

It feels safe.

Then the agent starts getting weird.

Not obviously broken. Just worse.

• slower replies
• random forgotten facts
• stale instructions winning over fresh ones
• more looping
• more irrelevant tool use
• less reliable execution

And the usual response is: maybe we need an even bigger context window.

I don’t think that’s the real problem.

The real problem is usually memory architecture.

I was digging through long-running agent failures and found a thread on r/openclaw where someone described an OpenClaw session that ran for more than a day and then basically collapsed under its own history. Their line was brutal:

“Eventually it came up with this same problem. once I see that COMPACTED HISTORY message no further chatting completes.”

That doesn’t sound like a model issue.

That sounds like the prompt became a landfill.

Big context windows do not save bad memory design

This is the part people miss.

You can degrade quality long before you hit the hard context limit.

LangChain’s memory docs say this pretty clearly: long conversations get harder even when they still fit inside the model’s window. The model gets distracted by stale or irrelevant content. Latency rises. Cost rises. Quality drifts.

That matches what a lot of us have seen with GPT-5, Claude, Qwen, and Llama.

The failure mode is not always overflow.

Sometimes it’s just context rot.

Why context rot shows up faster than people expect

A quick token gut check:

• 1 token is roughly 4 characters
• 100 tokens is roughly 75 words
• 1,500 words is around 2,000 tokens

So it doesn’t take much to bloat a prompt.

A couple of long tool traces.
A verbose API response.
A browser scrape.
A few summaries.
A giant workflow payload from n8n.

Now do that for hours.

If your agent runs in OpenClaw, LangGraph, Make, Zapier, or a custom loop, prompt bloat compounds fast.

Compaction is useful, but compaction-only is a trap

I’m not anti-summary.

You need summaries. You need compression. You need some form of compaction.

But if your strategy is:

1. append forever
2. summarize when it hurts
3. keep going

then you’ve built a polite failure machine.

That OpenClaw thread is a good example. The user tried the obvious recovery commands:

/new
/reset
/compact

And the session still didn’t recover cleanly.

Another commenter said:

“After a compact you may lose session state if the model is too slow or context was overloaded. You may have to start a new session.”

That’s the key point.

If compaction is the only thing keeping your agent alive, you’re already in a bad spot.

Compaction usually fails in 2 ways

1. Summary drift

The compressed version slowly stops matching what actually happened.

Small omissions become bad decisions later.

2. State loss

The summary keeps the story, but drops the working state:

• constraints
• tool outputs
• pending tasks
• user preferences
• partial results
• current plan

That’s why “just summarize harder” is not a serious design for always-on agents.

The architecture that works better

The pattern I trust now is simple:

• bounded live context
• separate long-term memory
• explicit token budgets
• hard reset rules

LangGraph makes this distinction nicely with short-term vs long-term memory.

Short-term memory is for the active thread.
It should stay close to the current task.
It should be bounded.

Long-term memory is separate.
It stores durable facts across sessions and threads.
You retrieve from it when needed instead of replaying everything every turn.

MemGPT pushes the same idea even harder. Its core insight is basically: stop pretending one giant prompt is enough. Use memory tiers like virtual memory.

That mental model is much better than “buy a bigger context window and pray.”

Comparing the 3 common approaches

Approach	What actually happens
Naive full-history prompting	Append every message and tool result to the prompt. Easy to build, but quality drifts, latency climbs, and stale context starts winning.
Compaction-only session management	Periodically summarize or compress history. Better than full replay, but vulnerable to summary drift and lost state.
Layered memory architecture	Keep a bounded active prompt and store durable facts separately. Harder upfront, but much more stable for long-running agents.

For always-on agents, layered memory wins.

Not because it’s fancy.

Because it stops the prompt from becoming the database.

What belongs in the live prompt

Only keep what the model needs right now.

Good candidates for live context

• current user request
• active plan
• last few relevant turns
• current tool outputs
• hard constraints for this session
• tiny working summary if needed

Good candidates for long-term memory

• user preferences
• project facts
• stable environment details
• completed artifacts
• decisions that should survive resets
• facts that matter across sessions

Things you should usually throw away

Yes, actually throw them away.

• verbose tool logs
• failed reasoning branches
• duplicate summaries
• stale plans
• old error traces after recovery
• every intermediate browser scrape chunk

If your agent truly needs all of that forever, the design is probably wrong.

My practical reset rules

A lot of teams treat reset as failure.

I think reset is a feature.

Humans do this too. We start a fresh thread, write a handoff note, and continue with the important bits.

For agents, I use boring rules on purpose:

1. Set a hard token budget for live context
2. Compact once, not endlessly
3. If quality drops after compaction, start a new session
4. Persist durable facts before reset
5. Reload only what the next task actually needs

That last step matters more than people think.

A fresh session with the right retrieved memory often beats a bloated “continuous” session with 10x more context.

Add QA around memory behavior, not just outputs

Most teams evaluate final answers and ignore the prompt assembly process that created them.

That’s a mistake.

If you care about agent reliability, track memory behavior directly.

Metrics worth logging

• token count before each model call
• number of compactions per session
• retrieval hits vs misses
• latency growth over session age
• stale fact reuse
• reset recovery success

Even a tiny token counter helps.

import tiktoken

model_name = "gpt-4o-mini"
text = assembled_prompt

enc = tiktoken.encoding_for_model(model_name)
num_tokens = len(enc.encode(text))

print(f"Prompt tokens: {num_tokens}")

That snippet is more useful than a lot of dashboards because it forces you to admit the prompt has a budget.

A simple memory pipeline that works in practice

Here’s a lightweight pattern for agent loops:

def build_prompt(user_request, recent_turns, active_plan, tool_outputs, retrieved_memory):
    return {
        "user_request": user_request,
        "recent_turns": recent_turns[-6:],
        "active_plan": active_plan,
        "tool_outputs": tool_outputs[-3:],
        "retrieved_memory": retrieved_memory[:5],
    }


def should_reset(prompt_tokens, compactions, quality_drop):
    if prompt_tokens > 24000:
        return True
    if compactions >= 1 and quality_drop:
        return True
    return False

Not magical.

Just disciplined.

If you run agents in automation tools, this problem gets expensive fast

This matters even more if you’re running agents inside n8n, Make, Zapier, OpenClaw, or custom automations.

Those systems tend to generate a lot of junk context:

• serialized workflow state
• repeated tool payloads
• large JSON responses
• browser text dumps
• repeated retries

That’s bad for quality.

It’s also bad for cost if you’re paying per token.

A badly designed always-on agent doesn’t just get worse over time. It also gets more expensive over time.

That’s one reason flat-rate infrastructure is so appealing for agent workloads. When you’re iterating on memory architecture, testing resets, and running long-lived automations, per-token billing punishes experimentation.

Standard Compute is interesting here because it gives you an OpenAI-compatible API with unlimited compute at a flat monthly price. If you’re building agents that run 24/7, that pricing model makes a lot more sense than babysitting token spend every time your workflow loops, retries, or over-contexts itself.

You still need good architecture.

But at least you’re not paying a tax for every memory mistake while you fix it.

Bigger windows are still useful. They’re just not architecture.

Huge context windows absolutely help.

If you’re doing:

• codebase analysis
• legal review
• one-shot research synthesis
• large document comparison

then broad in-session visibility is great.

But for always-on agents, giant windows are like extra RAM in a server.

Helpful? Yes.
Necessary sometimes? Also yes.
A substitute for memory design? No.

That’s the main lesson I took from OpenClaw failures, LangGraph’s memory model, and MemGPT’s design direction.

The winning strategy is not “remember everything.”

It’s:

• remember the right things
• store them in the right place
• keep them for the right amount of time

If your agent starts acting haunted after a long session, don’t blame GPT-5 or Claude first.

Blame the architecture.

Then make the prompt smaller.

Practical checklist

If you want the short version, use this:

# agent memory checklist
[ ] set a max live-context token budget
[ ] separate short-term state from long-term memory
[ ] keep only recent relevant turns in prompt
[ ] store durable facts outside the prompt
[ ] compact once, not repeatedly
[ ] reset sessions on quality drop
[ ] measure prompt tokens every call
[ ] log retrieval quality and stale-context failures

That checklist will save you more pain than upgrading to the next giant context window.