How to Structure Your AI Agent's Memory So Scheduled Runs Actually Find Things

Your scheduled agent has a memory store. Maybe it is a vector database, maybe a key-value table, maybe a growing pile of transcript files. And yet every morning it wakes up asking questions it already got answers to, re-discovering rules it already learned, and treating last week's resolved incident like breaking news.

The usual diagnosis is "the agent needs more memory." That is rarely the fix. What it needs is structure. A flat pile of stored text is not memory; it is a junk drawer. The difference between the two is organization: what kind of thing each memory is, how it is keyed, how long it lives, and how the agent finds it again.

Why one big bucket fails

Most DIY agent memory setups store everything in one place with one retrieval method. Transcripts, learned facts, user preferences, error logs, all embedded into the same index, all fetched by similarity.

This fails in three predictable ways.

First, retrieval dilutes. When the refund policy and a three-week-old resolved incident summary sit side by side in one index, they get equal weight. The agent retrieves what is semantically loudest, not what is most true or most current.

Second, stale facts look exactly like fresh ones. A pricing note from March carries the same authority as one from yesterday unless something marks the difference. An agent that confidently acts on outdated memory is worse than one that remembers nothing, because nothing at least forces a fresh lookup.

Third, context cost compounds. A daily agent loading a large undifferentiated history pays for every stale word, every run. Memory should make the agent cheaper to run, not more expensive.

The four-bucket structure

Scheduled agents work best with four kinds of memory, each with its own shape and lifespan.

Bucket 1: Subject profiles. Facts about who or what the agent works on: customer preferences, account details, contact context. Long-lived, corrected by events, keyed per subject: profile:<customer-id>. When a preference changes, the old value is replaced, not stacked on top.

Bucket 2: Durable rules. How the agent should behave: routing thresholds, formatting rules, corrections operators issued, decisions that stick. Keyed per workflow with a version: rules:<workflow>:v3. Rules are superseded, never appended. The moment two versions of the same rule exist, the agent has to guess which one wins, so keep exactly one live version.

Bucket 3: Run summaries. What happened recently: a short digest per run. Keyed by run: run:<date> with a short lifespan, around two weeks. This is the "catch me up" layer the agent reads at the start of every run. Old summaries age out automatically; anything still important gets promoted to a durable rule before it expires.

Bucket 4: Full archive. Complete transcripts and raw logs. Searchable on demand for audits, disputes, and "what exactly did we say in March." Almost never loaded into the prompt by default. The archive exists so nothing is lost, not so the agent reads it every morning.

The pattern: profiles and rules are small and always loaded. Run summaries are recent and cheap to load. The archive is big and loaded only when asked.

Name things so retrieval works

The naming scheme carries half the retrieval logic. A few rules that hold up in practice:

• One durable key per fact. The customer's shipping preference lives at exactly one key. Updates overwrite; they never create a second entry.
• Everything gets a timestamp. A stale fact without a date is indistinguishable from a live one.
• Namespaces separate concerns: profile:, rules:, run:, archive:. The agent can then load whole categories instead of searching the entire pile.
• Names say what and who. rules:support-triage:escalation-threshold beats memory_0042 because a human can audit it and the agent can request it by name instead of by semantic guess.

Structured, keyed storage also fixes the repeated-questions problem at the root: if the answer is stored at a known key, the agent does not need to hope retrieval finds it.

The promotion loop

Structure only works if new memories land in the right bucket. Build a short end-of-run step into the schedule: after each run, the agent distills what happened into three questions.

1. Did anything happen that should become a durable rule or a correction? Write it to bucket 2.
2. Did any subject fact change? Update bucket 1.
3. Is there anything the next few runs need to know? Summarize it into bucket 3.

Everything else stays in the archive. The promotion step is what keeps the hot layers trustworthy: small, current, and deliberate.

What the agent loads each morning

With the structure in place, the read pattern is simple and cheap. At the start of a run, the agent loads three things: the relevant subject profiles, the workflow's current rules, and the last few run summaries. That is usually a few hundred tokens, not a few thousand.

Archive lookups happen only when the agent hits something it does not recognize, the same way a person checks old files only when the current folder does not have the answer. Targeted reads, not bulk retrieval. The agent stops paying for memory it is not using.

Where a hosted memory layer fits

You can build all of this by hand: a table with a namespace column, a read at run start, a write at run end, a promotion step you enforce in the workflow, and TTLs you remember to apply. For one or two workflows, that is a reasonable weekend project.

It strains as the fleet grows. The schema rules are simple to describe and easy to get subtly wrong at 3 AM: a miskeyed namespace, a promotion step that silently stops running, two workflows quietly writing to each other's rules bucket. And the day the same agent's context has to follow it across tools, inside-the-tool storage turns into a migration project.

Vilix AI is built for this shape. It is cloud-hosted with zero infrastructure, so there is no database to provision and no namespace schema to maintain by hand. One memory follows the agent across every tool over MCP, on the laptop, the phone, and every AI app, so the structure survives a platform switch. It keeps full conversation history, not just extracted facts, so the archive layer is a real record rather than a lossy summary. The free plan is free forever, the Pro trial runs 7 days with no credit card, and everything can be exported or deleted anytime. Agents that wake up with their profiles, their rules, and their recent summaries already organized are agents that spend the run doing the work instead of re-learning it.

The 30-second checklist

Before the next run: four buckets with clear key patterns, one live version of every rule, timestamps on every fact, a promotion step at the end of each run, and TTLs on the volatile layers. Store deliberately, retrieve by name, promote what matters. That is the whole playbook.