Full Pro free for 7 days, no credit card. Start free →
← All posts
September 28, 2026 · 6 min read

A Bigger Context Window Won't Save Your Scheduled Agent. Only Memory Will

A Bigger Context Window Won't Save Your Scheduled Agent. Only Memory Will Think of your scheduled agent's context window as a desk. Every run, someone clears the desk completely, sits the agent down, and hands it a stack of papers. That stack is all it gets. The agent does its work, the run ends, and everything gets swept into the trash again. Meanwhile, across the room, there is a filing cabinet that never gets used. That cabinet is memory. Most automation setups keep buying bigger desks inst

A Bigger Context Window Won't Save Your Scheduled Agent. Only Memory Will

Think of your scheduled agent's context window as a desk. Every run, someone clears the desk completely, sits the agent down, and hands it a stack of papers. That stack is all it gets. The agent does its work, the run ends, and everything gets swept into the trash again.

Meanwhile, across the room, there is a filing cabinet that never gets used. That cabinet is memory. Most automation setups keep buying bigger desks instead of opening the cabinet.

This is the mix-up that keeps scheduled agents amnesiac: assuming that more context, which is what is on the desk right now, is the same as memory, which is what survives between desks.

Why the desk can never be big enough

The instinct is understandable. When an agent forgets something important from last Tuesday, the fix that suggests itself is to put last Tuesday on the desk too. Then the Wednesday run. Then the whole transcript. The prompt grows and grows, and the agent seems a little warmer for a while.

Then reality catches up. Researchers (Liu et al., TACL 2024) documented what they called the "lost in the middle" effect: even models built for very long contexts get noticeably worse at using information buried in the middle of the input. Attention concentrates at the boundaries. So your 1M-token context window is not a superpower. It is a desk so large that the agent cannot see most of what is on it. The information is technically present and practically unusable.

Anthropic's context engineering work makes the same point from the practitioner side: context is a finite resource that has to be curated. Deciding what belongs on the desk is the job. A bigger desk does not do the deciding for you.

Scheduled agents have it worst

Interactive agents at least keep their desk for the duration of a chat session. Scheduled agents do not even get that. An n8n workflow fires at 6 AM, the agent gets one shot at its task, and thirty seconds later the machine is gone. There is no session. There is no "earlier in this conversation." There is only the stack of papers someone left on the desk and the total blankness underneath it.

This is why the amnesia pattern is so stubborn in automation work. Every run is a first run. The agent re-derives the same conventions, re-guesses the same output formats, and re-makes the same mistakes that were corrected three runs ago, because corrections die with the run that produced them.

The cabinet has to be organized, not just big

If buying a bigger desk fails, the next instinct is to throw everything into the cabinet: full transcripts of every run, every tool output, every message. A complete archive. Surely nothing gets forgotten if everything gets kept.

Nothing gets found, either. An archive is not a memory. Memory is selective by definition: it keeps what still matters and lets the rest go. A cabinet stuffed with every piece of paper ever produced is barely better than the trash.

The distinction that matters most is between a transcript and a conclusion. A transcript records that on Tuesday the agent fetched twelve pages, mis-scored three of them, got corrected, and produced a report. The memory-worthy part is small: which sources turned out to be junk, what the scoring rules became after the correction, and the exact report format that finally worked. Maybe two hundred words. That is what belongs in the cabinet. The twelve fetched pages do not.

And the cabinet needs a sense of time. Rules change. A statement that was true in June can be false in September, and a memory layer that retrieves both versions with no opinion is just a more confusing way to forget. Whatever stores the memory has to know which version is current.

What the loop looks like in practice

Forget frameworks for a moment. The working pattern has exactly two moves.

At the end of a run, write down what the next run needs to know. Decisions, corrections, failures and their causes, formats that worked. Short, factual, current. At the start of the next run, read back only what is relevant to this run. A compact briefing, not the archive.

Take a weekly lead-research agent as an example. The briefing it reads at 6 AM might be: the scoring rubric as it stands after last month's correction, the two data sources that consistently return junk, the three fields every prospect record must have, and the note that the output sheet changed format in August. Everything it needs to not start blind. Nothing it needs to dig through.

Notice that this works precisely because it does not depend on any single tool. The cabinet is not n8n's feature or Make's feature. It sits outside the workflow, and any tool that can reach it over MCP gets the same memory. That is the whole idea: one memory, every tool, every run, so the agent's knowledge stops being trapped inside whatever platform happened to wake it up.

The version where you don't build the cabinet

Building the loop yourself is honest work: a store, an extraction step, a retrieval step, and the ongoing discipline of keeping what gets written current. For some teams that is the right call. For everyone else, the tax is the maintenance, not the build.

The hosted alternative is Vilix AI. It is cloud-hosted, so there is zero infrastructure to manage and nothing to babysit at 6 AM. It connects over MCP, so the same memory is available to every tool and every agent you run, not just one platform's workflow. It keeps full conversation history, not just extracted facts, so a future run can revisit the actual reasoning behind a past decision instead of guessing from a summary. The free plan is free forever, the Pro trial runs seven days with no credit card required, and your data stays portable: export it all or delete it whenever you want.

The cabinet does not have to be a project. It can be a line item.

Stop buying desks

Your scheduled agent does not forget because its context window is too small. It forgets because nobody gave it anything that survives the run. More context is a bigger desk. Memory is the cabinet. Once you see the difference, the fix stops being mysterious.

Open the cabinet. Write down the ten things your agent re-learns every run. Read them back at startup. That is the whole trick, and it is the only one that works.

Give your scheduled agents one memory that follows them across every tool. Vilix AI is cloud-hosted with zero infrastructure for you to manage, keeps your full conversation history, and connects over MCP. Free forever, 7-day Pro trial with no credit card, export or delete anytime: vilix.ai.

Try Vilix Pro free for 7 days

Persistent memory across ChatGPT, Claude, and the AI tools you already use in Vilix AI.

Get started free
Keep reading
Supabase for Scheduled Agent Memory: Where It Wins, Where It Breaks

Supabase for Scheduled Agent Memory: Where It Wins, Where It Breaks Every scheduled agent has the same unanswered question: where do its memories live between runs? Not in the prompt; the prompt is rebuilt from scratch every run. Not in the workflow tool; n8n executions and Zapier runs are stateless by design. The memory has to live somewhere outside the agent, somewhere the next run can reach. Supabase keeps winning this argument among automation operators, and it is worth understanding why:

Your Scheduled Agent's Memory Is Rotting. Here Is When to Wipe It

Your Scheduled Agent's Memory Is Rotting. Here Is When to Wipe It Somewhere in your automation stack, a scheduled agent is getting dumber, and nobody scheduled the thing that would have prevented it. Think about how scheduled agents actually live. A Friday invoice-chasing agent wakes up, checks memory for who it already contacted, sends follow-ups, and saves the new state. A morning briefing agent loads yesterday's context and drafts the standup note. Every run is a read, a think, a write. And

Your Cache Is Cold Every Morning: Why Prompt Caching Can't Replace Agent Memory

Your Cache Is Cold Every Morning: Why Prompt Caching Can't Replace Agent Memory A quick experiment you can run without touching a line of code: look at what the model providers promise about prompt caching, and look at what your scheduled agents actually need. Then compare the two lists. The provider promises cheaper reprocessing of identical text, for a few minutes at a time. Your agent needs to wake up tomorrow and still know what it learned today. Those are not the same thing, and no amount