Skip to main content
Build and run

Automation memory

Memory lets an automation keep durable notes between runs. With it off, every run starts from the same system prompt, knowledge sources, and trigger payload, and remembers nothing from the run before.…

Written By Christopher Scaminaci

Last updated 3 days ago

Memory lets an automation keep durable notes between runs. With it off, every run starts from the same system prompt, knowledge sources, and trigger payload, and remembers nothing from the run before. With it on, the automation can write notes during a run and read them back on the next one.

Memory is separate from Knowledge Sources. Knowledge is content you provide and StackJack injects into every run. Memory is content the model writes for itself. Removing a knowledge source does not touch memory, and clearing memory does not touch knowledge.

The notes live in a private memory store, one per automation. For an automation that runs on StackJack, the store is in Anthropic's platform: StackJack stores the mapping to that store and an audit record of every change made from the Portal, and the Portal reads the notes back for you on demand. For an automation that runs on your Azure Foundry on a Claude model, StackJack keeps the notes itself, in its own database; see Automation memory on Azure Foundry, which also covers moving memories when you switch where an automation runs.

Turning memory on and off

Remember across runs is in the builder's Knowledge section. Turn it on to let the automation write and read notes; leave it off to keep every run independent.

Two things about the switch are worth knowing before you use it:

  • Turning it on does not create anything yet. The private store is created the first time the automation runs with memory enabled. Until then the memory panel says memory is on but nothing is stored.
  • Turning it off stops future use; it does not delete anything. An automation whose memory you switch off stops reading and writing notes, but the store and its contents remain. Use Clear memory or Erase all memory below if removal is what you want.

Memory is also outside the version snapshot, so restoring an older version never turns the switch on or off. A staging copy starts with production's setting, but deploying that copy back over production does not carry the setting with it — production keeps whatever it has. Set it deliberately on each one.

Reviewing what an automation has remembered

The Memory card on the automation detail page is where you browse and manage the notes. What you see depends on the state:

StateWhat the card shows
Memory is off for this automationA note telling you to turn on Remember across runs in the builder.
Memory is on, no run has stored anything yetA note that the store is created on the first run with memory enabled.
A store existsThe full browser: entries, contents, version history, and the removal controls.

The browser works like a small file tree. Folders and individual memories are listed together; click a folder to open it, click a memory to read it. A breadcrumb above the list shows where you are, with root to jump back to the top and Up one level inside a folder.

  • Refresh re-reads the current location. Use it after a run finishes to see what that run wrote.
  • Load more appears when the location holds more entries than one page. A store can hold a large number of memories, and without loading the rest you have only seen the first page — which matters when you are checking whether anything sensitive was written.
  • Selecting a memory shows its content below the list, along with a content fingerprint and its Version history.

Removing memory

There are three removal actions, and they are not interchangeable. Read this table before you pick one.

ActionWhat it removesWhat survives
Clear memory (on a selected memory)That one memory from the store. The automation stops reading it on future runs.Every other memory in the store.
Redact (on one row of Version history)The content of that one retained earlier version.The version marker itself, so the history still shows that a change happened. The current content.
Erase all memoryThe automation's entire store and every retained version.Nothing in the store. It cannot be undone.

Details that decide which one you need:

  • Redact only works on an older version. The current version cannot be scrubbed — the Portal refuses it and tells you to redact an older version or use Clear memory instead. If the content you want gone is what the automation is reading today, Clear memory is the action.
  • Clear memory asks you to confirm. Erase all memory asks you to type ERASE, because it destroys the store and its whole history at once.
  • Clearing one memory is not the same as erasing its history. The clear removes that memory from the store, and StackJack does not make a claim about what happens to earlier retained versions of it on Anthropic's side. If specific content has to be gone, redact the versions that carry it as well, or use Erase all memory.
  • The Portal's version-history hint says retained versions live for about thirty days. Treat that as a display hint about Anthropic's retention, not a promise StackJack can make about how long anything is kept. If you need a durable record that specific content was removed, keep your own note of the action and its date.
  • Archiving or discarding an automation is not erasure. StackJack attempts to archive the memory store rather than hard-delete it. Use Erase all memory first if removal is what you need, and see the automation detail page for what else archiving retains.

Who can view and change memory

Every action on this card — reading included — needs the same permission that configuring automations needs. Owners and administrators have it. An ordinary member needs the Automation builder access grant, which owners and administrators manage from Team settings. A member who can open the automation's detail page but does not hold that grant cannot browse, clear, redact, erase, or move its memory. Each change is recorded against the person who made it.

Reading is not a neutral act here. Memory is written by the model from whatever it saw during a run, so it can contain customer data pulled from your connectors. Treat opening the memory browser as looking at run data, and treat exporting or pasting it elsewhere accordingly.

Memory and your own Anthropic key

A memory store belongs to the Anthropic workspace it was created in, and runs read it from that workspace. That has a consequence when you change key mode.

If an automation's store was created while your organization was on StackJack-managed credentials, it lives in StackJack's shared Anthropic workspace. After you enrol your own key, runs execute in your workspace — and the store in the shared workspace is not there. The Memory card offers Move memory to your Anthropic workspace for exactly this case: it copies every memory into a new store in your workspace and retires the old one. Large memories take a moment.

Before you use it:

  • You need a key on file first. Without one the move is refused, with the reason shown.
  • The offer only appears in one direction. It is shown only while the store is still in StackJack's shared workspace. Once the store is in your own workspace the card no longer offers it, and there is no self-service move back.
  • Removing your key later does not bring the store back. Reviewing, redacting, clearing, and moving memory all need the key while it is in your workspace, so they are refused while an Agent Runner plan lapse has paused the key. Erasing a store still works. See When an Agent Runner plan ends.