System Prompt vs Agent Memory: What Goes Where for Scheduled Agents
System Prompt vs Agent Memory: What Goes Where for Scheduled Agents Your 6 AM digest agent has a problem, and it is not the model. Open its system prompt and you will find the entire reporting playbook in there: which metrics matter, how each department likes its summary, the client's formatting quirks, the exception for the EMEA numbers, the note about the dashboard that lies on Mondays. Somebody wrote "the definitive guide to how we do reporting" and pasted it into the one place the agent can
System Prompt vs Agent Memory: What Goes Where for Scheduled Agents
Your 6 AM digest agent has a problem, and it is not the model. Open its system prompt and you will find the entire reporting playbook in there: which metrics matter, how each department likes its summary, the client's formatting quirks, the exception for the EMEA numbers, the note about the dashboard that lies on Mondays. Somebody wrote "the definitive guide to how we do reporting" and pasted it into the one place the agent can never escape.
Six months later that guide is wrong in a dozen small ways, the prompt is enormous, and every run pays for all of it. This is the standard failure mode of scheduled agents, and the fix is a clean split most operators never make: the system prompt holds what is static, memory holds what is alive.
Static knowledge vs living knowledge
Think of the two stores as answering different questions.
The system prompt answers: what is this agent, what can it touch, what must it never do. A new team member reading it should understand the job. None of it depends on what happened yesterday.
Memory answers: what has happened since. Client preferences that evolved, corrections from real incidents, judgments the agent formed over hundreds of runs, the outcome of the last run. All of it has a timestamp, implicitly or explicitly, because all of it can expire.
When living knowledge gets frozen into the prompt, two bad things happen at once. The knowledge starts rotting, because updating a prompt means a code change and nobody makes code changes for "the EMEA exception moved to Tuesdays." And the prompt starts bloating, because nothing ever gets removed. Prompts only grow. Nobody audits them the way they audit a database.
The three costs of a bloated prompt
Money. A scheduled agent re-sends its full system prompt on every run. That multiplication is what turns a 25,000-token prompt from a mild annoyance into the dominant cost of the automation. A prompt that runs every ten minutes sends its full contents 144 times a day. Context that was added "just in case" during one debugging session keeps billing you long after the incident is forgotten.
Rot. Prompts are deployed artifacts. They change on deploy cadence, which for most teams means rarely and nervously. Business facts change on business cadence, which means constantly. The wider that gap, the more confidently your agent applies outdated rules. The reporting agent still formats everything the way the client asked before the rebrand. The triage agent still escalates to someone who left in March.
Attention. Even the largest context windows are not fully usable. Analysis of long-context performance shows models reliably use roughly 60 to 70 percent of their advertised window before accuracy on buried details degrades, the "lost in the middle" effect (Startup Fortune). Every low-value paragraph in the prompt pushes something valuable toward the middle where the model stops seeing it. Prompt bloat does not just cost tokens. It costs comprehension.
The deploy test
Here is the heuristic for deciding where something lives. Ask: would this fact survive a code deploy unchanged for six months?
- "You are the nightly reconciliation agent. Flag discrepancies over $500 and post them to #finance." Survives. Prompt.
- "The staging database lags production by up to 20 minutes on weekends." Might change with infrastructure work, but it changes rarely and deliberately. Prompt, or a config the prompt references.
- "Brightline Logistics changed their invoice format; the total is now on page 2." This changed because the world changed. Memory.
- "Last run found duplicate charges in the March export; check for the same pattern." This is run history. Memory.
The pattern: instructions and guardrails go in the prompt. Facts, corrections, preferences, and history go in memory. If you need a deploy to change it, it is configuration. If a conversation should be able to change it, it is memory.
Memory only works if the run reads it
Splitting the stores is half the job. The other half is retrieval: the run must pull the memories that matter for this run, not the whole archive.
The working pattern is simple. At the start of a run, the agent queries memory for what is relevant: this client, this workflow, recent corrections. A handful of targeted memories, not a dump. At the end of the run, it writes back what it learned: the new exception, the corrected assumption, the outcome. Over time the store becomes the agent's accumulated experience, and the prompt stays lean because it never has to carry any of it.
This is also where the DIY approach usually breaks down for automation operators. A Postgres table or a folder of markdown files works when one workflow in one tool needs memory. It falls apart when the knowledge has to follow the operator across tools: the n8n workflow that runs on schedule, the Make scenario that handles the overflow, the Claude Code session where the automation gets debugged at midnight, the phone where the results get reviewed over coffee. Four tools, four memory silos, or one shared one.
Vilix AI is the shared one. It is cloud-hosted, so there is zero infrastructure to manage, and every agent connects to the same memory over MCP: scheduled runs, coding assistants, and phone apps all reading and writing one store. It keeps full conversation history rather than just extracted facts, so an agent can look back at what actually happened in a previous run instead of trusting a summary. The free plan is free forever, the 7-day Pro trial needs no credit card, and everything is portable: export it all or delete it anytime at vilix.ai.
Start with the highlighter
You do not need to redesign the agent to fix this. Open the system prompt, highlight every sentence that describes the world rather than the job, and move those sentences into a memory store the agent can read and write. Give the agent one standing instruction: check memory when a run starts, update it when a run ends.
Do that, and the prompt shrinks back to what it was always supposed to be: a short, stable description of the job. Everything the agent has learned since gets to live somewhere it can actually change. Your scheduled runs get cheaper, your facts stop rotting, and the next 6 AM digest runs on what the business looks like today, not what it looked like the day somebody wrote the prompt.