Should Your Scheduled AI Agent Share One Memory or Isolate Every Run?

Every operator who gives a scheduled agent a memory eventually hits the same fork in the road. Share one memory across all runs and the agent starts mixing things up: Monday's context leaks into Tuesday's run, a correction made for one customer shows up in another's, and stale facts contaminate fresh work. Isolate each run and the opposite failure arrives: the agent redoes work it already finished, relearns the same lessons, and asks questions it was already answered.

Both designs are defensible. Both fail in production when applied blindly. The right answer is a deliberate scope, and this is the playbook for choosing it.

What "shared" and "isolated" actually mean for a scheduled agent

A scheduled agent is a loop: wake up on a timer, read context, do the work, write back, go quiet. The memory scope decides what the next run is allowed to see.

Shared memory means every run reads and writes the same store. Tuesday's run sees what Monday's run learned. Corrections stick. The agent accumulates knowledge: which leads were already contacted, which alert pattern turned out to be a false alarm, how the boss wants the report formatted. This is the continuity that makes a scheduled agent feel like it is getting smarter.

Isolated memory means each run gets a fresh, private workspace. Nothing from a previous run is visible unless you explicitly hand it in. This is the safety that makes a scheduled agent feel trustworthy: no contamination, no stale leftovers, no cross-customer bleed.

Notice the tension. The memory that learns the most is also the memory most likely to poison a future run. The memory that can never poison anything also never learns.

The two failure modes, in the wild

Failure mode one: the shared bucket. An operator runs one scheduled workflow that triages support tickets for several customers. The memory is one shared table. On Monday the agent learns that "billing tickets from Customer A go straight to the priority queue." On Wednesday it reads that memory and routes Customer B's billing tickets to the priority queue too. Nobody wrote that rule for Customer B. The agent inferred it from a shared context it should never have seen. The same pattern shows up in multi-tenant setups, in agents that handle several regions, and in any workflow where the identity of the subject changes between runs.

Failure mode two: the isolated sandbox. An operator runs a daily lead-scoring agent with no persistent memory, each run starting from a blank prompt. Every morning it re-fetches the same leads, re-scores the same batch, and re-flags the same three duplicates that were already flagged yesterday and manually dismissed. The waste is not just tokens; it is a team re-reading the same false positives daily. And when the operator finally corrects it, "stop flagging ACME, they are a partner, not a prospect," the correction lives in Tuesday's run and dies there. Wednesday's run has never heard of it.

If your agent keeps redoing work it already finished, isolation is the cause. If it keeps mixing up contexts that should have stayed separate, sharing is the cause. Most operators are dealing with one of these two pains right now.

The honest answer: scope by identity and purpose

Neither "everything shared" nor "everything isolated" is the design. The design that survives production has two layers:

A shared durable layer holds what should outlive any single run: rules, corrections, preferences, learned facts about the domain. "Billing tickets from Customer A go to the priority queue." "ACME is a partner, flag them never." "The 9 AM report uses the archived Slack channel, not the active one." These are stable, they were expensive to learn, and every future run should see them.

A run-scoped working layer holds what belongs to exactly one run: the input batch, the intermediate plan, the working notes, the partial results. Tuesday's list of tickets. This morning's alert batch. When the run ends, the working layer is summarized into the durable layer and retired.

The split is the answer to the fork. Share the knowledge. Isolate the work.

The two-namespace pattern, in practice

However you store memory, Postgres, SQLite, a hosted layer, the implementation is the same shape:

1. One namespace for durable knowledge, keyed to the agent or workflow identity: (agent, memory_type). Corrections, rules, preferences, facts. Every run reads it first.
2. One namespace per run, keyed to the execution: (agent, run_id, memory_type). Inputs, intermediate state, raw notes. Only that run reads it.
3. A promotion step at the end of each run. When the run finishes, anything in the run-scoped layer that would matter tomorrow gets promoted to the durable layer. Corrections always get promoted. One-off working details get summarized and retired.
4. Scope the durable layer by subject, not just by agent. If one workflow serves several customers, the durable namespace is (agent, customer_id), not (agent). This is the single change that kills the cross-contamination failure mode.

How far back an agent should remember is a related question, and it has the same layered answer: keep summaries hot for days, keep rules until they are explicitly replaced, and expire volatile facts aggressively.

Where a hosted memory layer fits

Doing this by hand is a real option. A Postgres table with a namespace column, a read at run start, a write at run end, and a promotion step you enforce in the workflow. It works, and for one or two workflows it is the right call.

It starts to strain when you run many workflows, or when the same agent's context has to follow it across tools. The scoping rules are simple to describe and easy to get subtly wrong at 3 AM: a miskeyed namespace, a promotion step that silently fails, a shared bucket that two workflows were told to share "just this once."

Vilix AI is built for this shape: cloud-hosted with zero infrastructure, so there is no database to provision or namespace schema to maintain. One memory follows the agent across every tool over MCP, on the laptop, the phone, and every AI app. It keeps full conversation history, not just extracted facts, so the promotion step is a real record, not 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. The vision is the default memory brain every device plugs into: agents that wake up already knowing what their siblings and their past runs learned, scoped correctly, instead of starting blank every morning.

The 30-second checklist

Before the next run: one durable namespace keyed to the agent and the subject, one working namespace keyed to the run, a promotion step at the end of every run, and a stale-memory review on the calendar. Shared where knowledge should compound. Isolated where contamination should not. That is the whole playbook.