How Much Memory Should Your Scheduled AI Agent Load Per Run?

Your scheduled agent wakes up at 7am, reads the entire memory file you built for it, and gets dumber for it. The file started as a tidy set of instructions. Three months later it is a 40,000-word document containing every decision, correction, log note, and edge case the agent ever encountered. The run loads all of it, every morning, and the agent still manages to misread the one paragraph that matters.

The instinct is to feed the agent more context. The fix is usually the opposite: decide, deliberately, how much memory each run gets. A scheduled agent does not need to remember everything. It needs to remember the right things, in the right order, at a size you could defend on a budget sheet.

The two ways to get this wrong

The first failure mode is the memory dump. Every run loads the whole history: every past session, every correction, every note. This costs real money, and scheduled runs multiply it. An agent that runs hourly and injects 30,000 tokens of memory per run burns through roughly 21 million memory tokens a month before it does a single unit of work. That is the direct cost. The quieter cost is quality: models reliably use only 60 to 70 percent of their context window before accuracy on buried details starts to slip, a pattern researchers call lost in the middle. The one correction you wrote in March sits at token 24,000. The model reads it and forgets it.

The second failure mode is the amnesiac run. Nothing loads except the prompt. The agent is cheap and consistent, and it re-learns the same lessons every day. It re-flags the report you already approved, asks for the credential you already provisioned, and treats every run like the first. Operators usually bounce between these two poles: dump everything, watch the bill and the errors, then strip it down to nothing and watch the agent forget.

There is a middle that actually works, and it has a shape.

The three-layer budget

Think of per-run memory as three layers with three budgets, not one pile.

Layer 1: always load. Identity and standing rules. Who the agent is, what it does, the conventions that never change. This is small, 1,000 to 2,000 tokens, and it goes into every run verbatim. If something changes here rarely, it earns its place here.

Layer 2: retrieve per run. The recent, relevant past: what last run did, the corrections you gave this week, the open items that carry over. This is not loaded by default; it is fetched by meaning. The run asks the memory layer for what is relevant to today's task and gets 3,000 to 5,000 tokens back. This is the layer most operators skip entirely, jumping straight from always-load rules to the full dump.

Layer 3: on demand. The full history, sitting behind a search. The run almost never loads this. When it hits something unfamiliar, it queries for it. Deep history is an archive with a door, not a backpack the agent carries everywhere.

Total per-run budget for a typical scheduled automation: 5,000 to 10,000 tokens of memory. That is enough to carry identity, this week's corrections, and yesterday's outcomes, without drowning the run in March's trivia.

Retrieval quality decides whether the budget works

A budget only holds if retrieval is good enough to trust. The reason operators dump everything is usually not ambition; it is distrust. They once tried loading only the relevant bits, the retrieval missed the one correction that mattered, and the run failed. So they went back to loading everything, accepting the cost to avoid the miss.

This is where the memory layer earns its keep. Retrieval that mixes semantic search with keyword search finds both the conceptually related ("the report format discussion") and the exact ("invoice INV-2026-0413"). When the run can reliably pull the five memories that matter, the 5,000-token budget stops feeling risky. The failure mode to watch is not under-loading; it is retrieval that silently returns nothing and a run that proceeds anyway. A good pattern: the run checks that retrieval returned results for the current task, and says so in its log.

Consolidation is what keeps the budget honest

A budget degrades if the memory behind it grows without maintenance. Memories need timestamps and a sense of shelf life. "The current database schema" expires differently from "we decided to migrate off that vendor." Without pruning, the retrieval layer starts returning six-month-old snapshots with the same confidence as yesterday's findings, and the run has no way to tell which is which.

Consolidation does not have to be exotic: periodically merge related memories, archive resolved debugging traces, delete superseded decisions. Some of this the agent can do itself in a quiet weekly run. The point is that the budget in the previous section only means something if the store it draws from stays clean.

What this looks like with a hosted memory layer

This whole pattern gets simpler when memory lives in one hosted layer instead of files the run has to load wholesale. Each scheduled run calls get_context and receives the semantically relevant slice of its own history: last run's outcomes, this week's corrections, the standing rules. The run calls save_turn when it finishes, so tomorrow's run inherits today. The full history stays searchable behind the retrieval layer rather than inside the prompt.

That is the shape Vilix AI is built for. It is cloud-hosted, so there is no memory database to operate, back up, or debug at 2am. The same memory follows the scheduled run, your interactive sessions, and every other tool over MCP: Claude, Codex, Cursor, OpenClaw, Hermes, and anything MCP-compatible. One correction lands anywhere and every run sees it. Retrieval blends semantic and keyword search, so exact identifiers match literally while concepts match by meaning. The plan side is simple: free forever, with a 7-day Pro trial and no credit card if you want the full tier. Your data exports or deletes anytime.

Picture the 7am run under a budget. It wakes up, pulls its standing rules, retrieves yesterday's outcomes and this week's corrections, does the work, and saves the run. Ten thousand tokens of memory, not forty thousand words. The run is cheaper, the relevant correction is near the top of context instead of buried at token 24,000, and nothing from March pollutes the decision unless the run explicitly asks for it.

The takeaway

Stop asking whether your agent remembers enough. Ask how much it loads, per run, and whether you can defend the number. Three layers, 5,000 to 10,000 tokens, retrieval you trust, and a store that gets pruned. That is the budget. Everything beyond it is either insurance you are overpaying for or amnesia you are pretending not to notice.

Get Started for Free (vilix.ai) Free forever, no credit card.