Target query: how to isolate ai agent memory per client in scheduled automations (companion rewrite) Slug: one-client-one-memory-isolation-scheduled-agents Title: One Client, One Memory: The Isolation Playbook for Multi-Tenant Scheduled Agents Surface: vilix.ai blog (full rewrite of the per-client isolation theme) Companion piece (dev.to): scheduled-agent-memory-leaking-between-clients

One Client, One Memory: The Isolation Playbook for Multi-Tenant Scheduled Agents

A scheduled automation that serves one customer is a tool. The same automation serving five customers is a fiduciary. Somewhere between client two and client five, the memory your agents share quietly becomes the most liability-heavy piece of your stack. Not the API keys. Not the webhooks. The memory, because it is the one system that can take something you learned about Customer A and confidently present it to Customer B.

This is not a hypothetical. Teams scaling a single automation across clients keep hitting the same wall: the agent works beautifully for one tenant, and then the memories blur. A status update references another client's deliverable. A preference learned on one account quietly reroutes another account's workflow. Each incident reads like an agent bug. It is actually a scoping decision you never made.

The moment memory becomes multi-tenant

Consider the standard memory design for a scheduled agent: at the end of a run, the agent saves what it learned; at the start of the next run, it retrieves what it saved. Everything flows through one memory store. For a single-customer operation, that design is fine.

Add a second customer and two questions become urgent:

1. Can this agent ever retrieve what it learned about Customer A while serving Customer B?
2. Can something saved for Customer A ever influence a decision made for Customer B?

If the answer to either is "the agent shouldn't, because we pass the right id in the workflow," you have a promise, not an isolation model. Promises are what operator discipline keeps. Isolation models are what survive a tired operator at 2 AM, a cloned workflow with a hardcoded value, and a new team member who did not read the wiki.

Why filters fail where namespaces succeed

The most common half-measure is tagging: every memory gets a client_id field, and every query adds a filter. This is better than nothing, but it has the structural weakness of every convention-based security: the protection lives in the query, not in the data.

Three real failure modes, all common:

• The forgotten filter. A new workflow, a new developer, one retrieval function that queries the memory table without the client clause. The agent gets a merged memory of every customer. Nothing errors. The contamination is discovered when a client quotes their own digest back to you, puzzled.
• The consolidator that aggregates. Periodic summarization jobs that keep memory fast often run "across everything for efficiency." A nightly job that summarizes memories can merge Client A's facts into Client B's summary line. Once that happens, there is no audit trail that tells you which client's facts ended up where.
• The cloned workflow. Your standard pattern for onboarding a new client is duplicating an existing workflow. One day someone forgets to swap the tenant identifier in the copy. Two clients now write to and read from the same identity. The bug is invisible in every log you check, because from the system's perspective, everything is consistent. Only the clients notice.

The fix is structural: namespaces, not filters. Each client gets a separate memory space, and no operation crosses namespaces without an explicit, auditable action. A wrong query against the wrong namespace returns nothing, not the neighbor's data.

The three memory zones of a multi-client agent

Even with namespaces in place, one design question remains: what goes where? The useful mental model is three zones:

Zone 1: Client-scoped memory. Anything that would embarrass you if the wrong client saw it. Preferences, contacts, deployment quirks, correction history, past digests. This is per-client, namespaced, and the bulk of what the agent reads each run.

Zone 2: Shared operational knowledge. Runbook patterns, "how this API paginates," general skills. Genuinely client-agnostic. The test for admission to this zone is strict: no names, no numbers, no facts that differ per client. If in doubt, it goes in Zone 1.

Zone 3: Ephemeral run state. Checkpoints, cursors, "processed through page 20." Per-client by nature, because a cursor for Client A's API is meaningless for Client B. This zone is often the one people forget to scope, because it feels like plumbing rather than memory. It is plumbing that can leak too.

The zone model gives you a reviewable standard: any new memory gets classified before it is written, and the classification is enforced by where the write goes, not by documentation.

Two tests that prove your boundaries are real

You do not need a security audit to validate isolation. Two operational tests cover nearly everything:

The offboarding test. A client leaves. Can you delete every memory that belongs to them, in one operation, with proof that nothing belonging to another client was touched? If deleting one client's memories requires careful queries and crossed fingers, your boundaries are not boundaries.

The new-hire test. Hand a developer who has never seen your system the task of adding a scheduled agent for a new client, with only the existing code as reference. If the default path they fall into produces a properly isolated memory space, your architecture enforces isolation. If it produces a shared one unless they remember the convention, your architecture relies on luck.

Both tests are cheap to run and brutally honest about what you actually built.

Isolation as a feature of the memory layer

This is the part where building per-tenant isolation on top of a DIY vector database usually turns into a months-long background project: scoped namespaces, per-run tenant resolution, per-client consolidation, per-client deletion, and an audit view. All of it is undifferentiated plumbing, and all of it is load-bearing the day a client asks "exactly what do you remember about us."

A memory layer designed for agents treats scoping as native: separate memory spaces per tenant, the same memory reachable from every scheduled workflow and every chat client over MCP, full conversation history stored so client context is auditable from the actual exchanges rather than derived summaries. Individual memories or a whole client scope can be deleted instantly, and the data exports in a portable format whenever asked.

Vilix AI works exactly this way: a cloud-hosted memory layer with zero infrastructure to manage, the same memory everywhere over MCP, full conversation history rather than just extracted facts, data isolated per account, exportable and deletable anytime. There is a free plan that stays free, plus a 7-day Pro trial with no credit card, so the isolation behavior can be verified against real multi-client scheduled runs before it is trusted with real clients.

Your contracts already promise each client that their information stays theirs. The memory your agents share is the one place that promise can quietly break. Give every client their own memory, scope the shared knowledge ruthlessly, and run the two tests before a client does it for you.

Explore the Vilix AI memory layer: https://vilix.ai/?utm_source=devto&utm_medium=article&utm_campaign=one-client-one-memory-isolation-scheduled-agents