> ## Documentation Index
> Fetch the complete documentation index at: https://docs.automate.it.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Memory

> The worker learns from every correction — and remembers at the right level

**Memory** is how the worker gets better at your work over time. When you correct a draft or the worker learns something durable about your preferences, it records the learning as a memory entry — and every future run applies it automatically.

Memory is a list of short entries, one fact each: a preference, a correction, a topic already covered. There are three memory scopes, and each entry lives at exactly one of them:

| Scope          | What belongs there                                                             | Example entry                                                       |
| -------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------- |
| **Workspace**  | Facts true of *everything* you make — brand voice, house style, dos and don'ts | "Playful, never corporate. No emoji in headlines."                  |
| **Skill**      | How to perform one skill well, wherever it's used                              | "For golf-fitness programs, always lead with hip mobility screens." |
| **Automation** | Learnings specific to one recurring job                                        | "Client prefers kettlebell variations."                             |

The worker picks the narrowest scope where a learning is true. Skill memory travels with the skill — attach the same skill to five automations and they all benefit. Workspace memory applies to every run, so the worker reserves it for things that are genuinely universal.

## How memory gets written

* **The worker adds entries** at the end of a run, when something durable was learned. Rejecting a draft with a correction is the strongest signal: the next run fixes the draft *and* records the corrected preference so it never needs saying twice. When a correction contradicts an existing entry, the worker retires the old entry in the same step, so memory never holds two answers to one question.
* **You add entries directly**: workspace memory lives in workspace settings, skill memory in the skill editor, automation memory on the automation's detail screen. Add a learning yourself, or retire one that no longer holds.

Memory is for content and style decisions only — the worker doesn't record claims about how tools or platforms behave.

## Keeping it tidy

Each scope holds a bounded number of entries, and each entry is a few sentences at most. As a scope fills up, the worker folds related entries into one before adding more, and retires entries that a correction has made stale. You can do the same from any memory panel.

## History and restore

Retiring an entry never deletes it. Each memory panel has a **Show removed** toggle listing retired entries, who retired them and when, and whether a newer entry replaced them; one tap restores any of them. Every entry shows who added it — a team member, or the worker with a link to the task that learned it — and every change lands in the workspace activity feed under the Memory chip. The task page shows a **What it learned** section listing the entries that run added.

Workspace and automation memory are edited by administrators; skill memory by any member.

## Modeling clients: one automation per client

Running work for multiple clients (an agency, a coaching business, a studio)? The pattern that works:

1. **One workspace** for your whole operation — your house style and conventions live in workspace memory.
2. **One automation per client** — "Jane's weekly program", "Acme's newsletter". Each automation's memory accumulates that client's preferences and history, and its schedule drives the recurring work.
3. **Skills for shared domains** — a "TPI golf fitness" or "B2B case studies" skill carries the domain knowledge (and its accumulated corrections) across every client that needs it.

Corrections then land exactly where they belong: client quirks in that client's automation memory, domain learnings in the skill, house rules in the workspace.

<Note>
  Connected agents (via MCP or the API) read all three scopes. `get_task`, `claim_task`, and `claim_next_task` return a `memory` block with the workspace, automation, and per-skill entries a task should apply, and `get_automation`, `get_skill`, and `list_workspaces` each carry their own `memory` list. Writing memory is reserved for the built-in worker and for people editing in the app: API keys can't add or retire entries anywhere.
</Note>
