Everyone tells you to give your scheduled agents memory. Almost nobody tells you what your agent should never be allowed to remember.
That matters more than it sounds. Every fact your agent stores persists across runs, gets retrieved into future context, and shapes decisions you never reviewed. One careless memory, an old API key from a log, a customer's salary figure from a spreadsheet, a policy that expired months ago, can echo through your automations for weeks before anyone notices.
1. Secrets and credentials
This is the most dangerous thing an agent can remember, and the most common. Your agent reads server logs, CRM records, error payloads, and config dumps every run. Somewhere in that stream there is usually an API key, an OAuth token, a database password, or a private key fragment. If the agent saves it into long-term memory, it is now persisted in plain text, retrievable into context, and one confused prompt away from being pasted into a Slack message or a support ticket draft.
The rule is absolute: memory is never a credential store. Keep secrets in environment variables or a proper secrets vault, and keep the agent's memory far away from them. When you write your agent's memory instructions, make the ban explicit: "Never store API keys, tokens, passwords, or credentials in memory." It feels redundant until the day an agent helpfully memorizes a Stripe key from a stack trace.
2. Raw personal data it does not need
Agents touch a lot of personal data: names, email addresses, phone numbers, order histories, salary figures, health details in support conversations. Most of it is transient task context, useful for the current run and nothing else.
There is a simple data-minimization test, borrowed from privacy regulation: store only what a future run genuinely needs to do its job. "Customer prefers email over phone" is a fact worth keeping. The customer's full mailing address, copied verbatim into memory from a shipping label, is not, unless a future run will need it.
This also covers inference. If your agent starts forming opinions about people ("this customer is difficult," "this employee is sloppy"), that unverified characterization should never reach durable memory. Store the verifiable fact, like what was requested and what was decided. Leave the editorial out.
3. Full transcripts of everything
Memory is not a recording of your agent's life. Dumping entire conversation transcripts into long-term storage makes retrieval worse, not better: every future query drags in noise, token costs climb, and the agent has a harder time finding the one fact that matters.
Store distilled facts instead of raw history. "Billing questions route to #support-billing" beats a 400-line transcript of the morning someone figured that out. If your memory layer keeps full conversation history for your own review, keep that archive separate from the working memory the agent actually retrieves from.
4. Stale facts that used to be true
An agent that runs every morning for a year accumulates a lot of memories that were true when written and are wrong now. The pricing page changed. The policy was revised. The contact left the company. The workaround that saved you in March is a liability in September.
Stale memory is worse than no memory, because the agent acts on it with confidence. An agent that knows nothing asks or guesses visibly. An agent with a stale memory acts, and you discover the problem when a customer replies "this is not our policy anymore."
Two habits fix this. First, review memory periodically, especially for anything with a natural expiry date: prices, policies, contact details, vendor names. Second, when a fact changes, update or delete the old entry rather than adding a new one alongside it. Contradictory memories force the agent to guess which is current, and guessing is how stale facts survive.
5. Raw instructions pulled from untrusted content
Your agent scrapes webpages, reads emails, parses tool responses. Some of that content tells the agent what to do, and not all of it deserves to be trusted. OWASP flags "memory poisoning" as a real risk: malicious data persisted in agent memory that influences future sessions or even other users of a shared store.
If your agent reads external content, treat persistence as a decision, not a default. Facts from your own systems get stored. Instructions scraped from a random webpage do not, at least not without your review.
What to store instead
The short version of a healthy memory policy: preferences, patterns, procedures, and corrections. What the client prefers. How the workflow runs. What failed last time and what fixed it. Corrections you made that should stick. These are compact, stable, and get more valuable over time, which is exactly the opposite of the do-not-store list above.
It also helps to decide who can change memory. A scheduled agent writing its own memories is powerful but unsupervised; many operators keep the agent's write scope narrow and handle deletion and policy changes themselves. Whatever you choose, the audit should be yours: you should be able to list everything the agent remembers and delete any of it, any time.
A memory layer that makes the do-not-store list enforceable
This is where the tooling matters. A memory policy is only as good as your ability to see and manage what is stored. Vilix AI is a cloud-hosted memory layer for your agents and AI tools, so there is no infrastructure to run: connect your clients over MCP and they share the same memory, on your laptop, your phone, and every tool you use.
Because the memory lives in one place, the do-not-store list becomes manageable. You can open the dashboard at app.vilix.ai and see exactly what your agents remember, delete individual memories, or wipe the whole account instantly if a credential or a piece of personal data ever lands where it should not. Export everything in a portable format whenever you want, so you are never locked in. Vilix AI also keeps full conversation history behind each memory, so you can trace exactly which conversation a stale or sensitive fact came from.
It is free to start: a free plan that never expires and a 7-day Pro trial with no credit card. If your scheduled agents are accumulating memories faster than you can review them, that is exactly when a visible, manageable memory layer pays for itself: https://vilix.ai/?utm_source=devto&utm_medium=article&utm_campaign=scheduled-ai-agent-memory-do-not-store-list.
The checklist
Before your next scheduled run, open whatever stores your agent's memory and ask five questions:
- Are there any secrets or credentials in here?
- Is there personal data no future run actually needs?
- Are there full transcripts that could be distilled facts?
- Are there facts that were true months ago and never re-verified?
- Is anything in here copied from untrusted external content?
If the answer to any of them is yes, clean it up. A small, honest memory beats a large, careless one every time. Your agents forget everything between runs by default; when you finally give them memory, make sure it is only the good stuff.
Top comments (0)