Skip to main content
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: 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.
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.