What is AI worker memory?

Worker memory is the facts and rules an AI worker carries between runs, so it does not start every run knowing nothing about your business.

A chat assistant forgets when you close the tab. That is fine, because you are there to re-explain. An AI worker runs unattended, so anything it needs to know has to survive between runs without you.

Memory vs context vs the instruction

The three get conflated constantly, and they are different things:

The instruction says what the job is. Context is today's material. Memory is what this worker has learned about your particular situation and is the only one of the three that accumulates.

What actually belongs in memory

The useful test: would a competent new hire need to be told this once, and then remember it?

• Your vocabulary. That "the Q3 deck" means a specific document, that "escalate" means a particular Slack channel.
• Standing exceptions. This customer is on a bespoke SLA. This sender is always urgent despite the tone.
• Decisions already made. We do not offer refunds past 60 days. Legal reviews anything mentioning a competitor.
• Corrections. The thing you told it last month when it got something wrong.

What does not belong: anything that changes every run. The day's calendar is context, not memory. Storing it as memory means a worker reasoning from a stale copy of something it could simply have read.

What each plan carries

Basic memory is the rules and facts you give a worker. Advanced adds long-term rules, facts and run history, which is the part that lets a worker refer back to what it did previously rather than only to what it was told.

That distinction matters most for jobs with continuity across runs. Follow-Up Tracker reaches email and tasks to track every thread you are waiting on and nudge when one goes quiet: knowing which threads it already nudged, and when, is the difference between a useful worker and one that sends a third reminder on Thursday.

Memory is scoped to the worker

Each worker has its own key and its own access, and its memory is its own too. That is a deliberate boundary rather than a limitation.

A support worker learning that a customer is difficult should not silently change how a sales worker writes to them. Keeping memory per worker keeps the blast radius of a wrong fact the same size as the blast radius of everything else about that worker, which is what makes a fleet reasonable to run: one worker, one job, one set of permissions, one set of beliefs.

The cost is that a fact relevant to three workers has to be told to three workers. That is the right trade for the same reason narrow access is.

The failure mode: a wrong fact, quietly

Memory's failure is not forgetting. It is **remembering something that stopped being true.**

A worker told in March that a particular contact handles billing will still believe it in September, after that person changed roles. Nothing errors. The worker confidently routes to the wrong person, and it looks exactly like correct behaviour, because from the worker's point of view it is.

This is the same plausible-failure shape that makes receipts matter elsewhere. A receipt showing what a run did is how a stale belief becomes visible, since the output looks fine and only the pattern across runs gives it away.

The practical mitigation is to treat memory as something with a review cadence rather than an append-only log. Facts about people and process rot faster than anyone expects.

The reasonable objection

"Persistent memory across runs sounds like a privacy problem waiting to happen."

Reasonable, and it is why memory sits inside the same boundary as everything else about the worker. It is scoped to one worker in your account, it is subject to the same app firewall that decides what the worker could read in the first place, and contact rules still filter what reaches it. Memory does not widen access; it retains what the worker was already permitted to see.

The sharper version of the objection stands though: anything a worker remembers is something you have chosen to keep. Reviewing memory is a real operational task, and a worker whose memory nobody reads is carrying assumptions nobody has checked.

When not to use memory

• The fact is available from an app. Read it. A CRM record is authoritative; a remembered copy is a fork that will drift.
• The fact changes weekly. That is context, and memory will be wrong more often than right.
• It is genuinely sensitive and not needed. The safest fact is the one not retained.
• You are still evaluating the worker. Add memory once the job is stable, or you will be debugging the instruction and the memory at once.

FAQ

What is memory in an AI worker?

The facts and rules a worker keeps between runs, so it does not start each run knowing nothing. It is distinct from the instruction, which is the standing brief for the job, and from context, which is what a single run reads from your apps.

What is the difference between basic and advanced memory?

Basic memory is the rules and facts you give a worker. Advanced adds long-term rules, facts and run history, so a worker can refer to what it did previously. Free carries basic; Pro, Team and Enterprise carry advanced. See /pricing.

Do workers share memory with each other?

No. Memory is scoped to one worker, like its key and its app permissions. A fact relevant to several workers has to be given to each, which keeps a wrong fact from spreading across a fleet.

Can a worker remember something it should not?

It can only retain what it was permitted to read, since the app firewall and contact rules apply before anything reaches it. Memory does not widen access, but it does retain, which is why reviewing it periodically is a real operational task.

What should I not put in worker memory?

Anything authoritative in one of your apps, and anything that changes every run. A CRM record should be read rather than remembered, because a remembered copy is a fork that drifts and fails silently when it goes stale.