Memories

The Memories page is the management surface for Auto Memory - the durable, long-term facts an AI agent decides are worth keeping and reuses in every future conversation. Where the Auto Memory tool lets an agent write memories at runtime, this page lets you read, correct, and prune them.

Agents create memory entries on their own; there is no manual "new memory" button on this page. You come here to audit what an agent has learned, fix a fact that drifted, retype a mis-classified entry, or delete something the agent should no longer act on.

Auto Memory vs. this page

Auto Memory complements chat memory: chat memory replays the current conversation, while Auto Memory persists facts across all future conversations of the same scope. See Chat memory vs Auto Memory for the distinction.

The name of each entry is set by the agent when it first stores the memory and is immutable on this page - everything else (title, description, type, and content) is editable. To rename an entry, ask an agent that uses the Auto Memory tool to rename it (its MemoryRename tool).

Accessing Memories

Memories live under Settings → AI → Memories, alongside Providers and Skills in the AI group of the settings navigation. The page opens at /automation/settings/ai/memories; the older /automation/ai/memories address redirects there.

The page has no left sidebar of its own. Its header shows the title AI Memories with the description "Facts the agent has stored while working in this workspace.", and on the right:

• A Search by title or description... box (see Searching).
• A Filter Memories button that opens a dropdown with two filter groups, Owner and Type (see Filtering).

When a filter other than All is active, its selection is shown as a badge above the table.

Selecting an environment

Memories are environment-scoped so that facts learned in one environment do not bleed into another (for example, DEVELOPMENT preferences do not surface in PRODUCTION). The page has no environment control of its own: it follows the environment chosen in the environment selector at the top of the main navigation sidebar, next to the ByteChef logo (shown in the Enterprise Edition). Switching environments there reloads the table and the Owner filter with the memories stored for that environment.

Memory types

Every memory carries a type that classifies the kind of fact it holds. The type is shown next to each entry in the agent's memory index and lets you filter this page; it does not limit which memories the agent sees - the agent's index lists entries of every type.

Viewing the memories table

With the Owner filter on All, the table lists the memories you can address in the current workspace and environment: your own memories plus the memories of the workspace's project deployments (deployments of embedded connected-user projects are excluded). Memories are ordered by most recently updated, and the list can be narrowed with the filters and search. Each row shows:

Who can edit and delete

Your own memories can always be edited and deleted. Memories owned by a project deployment change how a live agent behaves on its next run, so Edit and Delete are offered on those rows only to users with the administrator role (ROLE_ADMIN). Other users see only View in the row's menu.

Empty states

• When no memories exist for the current workspace and environment and no filter is active, the page shows No memories yet: "AI Agents that use the Auto Memory tool write memories here when their workflows run - user preferences, project decisions, corrections, and external reference pointers. Once an agent stores something worth keeping, it shows up on this page and you can inspect, edit, or delete it."
• When a filter is active and nothing matches, the page shows "No memories match the selected filters."
• If the memories cannot be loaded, the page shows Could not load memories with a Retry button. If only the owner list fails to load, a notice reads "Could not load memory owners, so the Owner filter is unavailable." with its own Retry button.

Filtering

Open the Filter Memories dropdown in the header. Owner and Type are independent, so you can pick one value in each group at the same time. Both filters are applied on the server, so changing either one reloads the table.

Owner

1. All (default) - your own memories plus the memories of the workspace's project deployments.
2. My memories - only your own memories.
3. One entry per project deployment that holds memories in this environment, labelled with the deployment's name (or Deployment <id> if the deployment was deleted while its memories remain).

Only owners that actually hold memories in the current environment are listed. The Owner group is not shown at all when no owner holds any memories.

Type

1. All (default) - show every memory type.
2. User
3. Feedback
4. Project
5. Reference

Searching

Type into the Search by title or description... box in the header to filter the visible rows. Search matches against both the title and the description of each memory and runs on top of the active filters. Clearing the box restores the full (filtered) list. If the search matches nothing, the table shows "No memories match your search."

Viewing a memory

1. Click the ⋮ button on a memory's row and choose View.
2. The detail dialog opens, showing:
   • The memory title and its type badge in the header.
   • The name and the last-updated timestamp beneath the title.
   • The description (if set).
   • The full content, rendered from Markdown.
3. Click Close to dismiss the dialog.

Editing a memory

1. Click the ⋮ button on a memory's row and choose Edit. (Edit is not offered on deployment-owned memories unless you are an administrator - see Who can edit and delete.)

2. The Edit memory dialog opens, pre-filled with the memory's current values.

3. Change any of the editable fields:

   Field	Editable	Notes
   Name	No	Immutable here. To rename a memory, ask an agent that uses the Auto Memory tool to rename it (MemoryRename). Shown disabled for reference.
   Title	Yes	Required - Save stays disabled while the title is empty. Single line, up to 255 characters.
   Description	Yes	Optional one-line summary. Up to 1024 characters.
   Type	Yes	Choose User, Feedback, Project, or Reference.
   Content (Markdown)	Yes	The full memory body, edited as Markdown in a monospace text area. Up to 65,536 characters.

4. Click Save to persist your changes, or Cancel to discard them. If you make no changes, the dialog simply closes without a write.

On success a "Memory updated" confirmation appears and the table refreshes.

If an agent changes the memory while the dialog is open, the dialog says so, holds back Save, and offers a Reload button that loads the newer version (discarding your unsaved changes). If the memory is deleted while the dialog is open, the dialog stays open and says your changes cannot be saved.

Deleting a memory

1. Click the ⋮ button on a memory's row and choose Delete. (Delete is not offered on deployment-owned memories unless you are an administrator - see Who can edit and delete.)
2. The Delete this memory permanently? confirmation dialog opens, warning that the entry will be removed from the agent's long-term memory.
3. Click Delete permanently to remove the memory, or Cancel to keep it.

On success a "Memory ... deleted" confirmation appears and the row disappears from the table.

Storage providers

By default, memories are stored in ByteChef's relational database. Self-hosted operators can select where they live with the BYTECHEF_AI_AUTO_MEMORY_PROVIDER environment variable (bytechef.ai.auto-memory.provider):

Selecting a provider whose file-storage backend is not configured fails fast at startup rather than falling back - a silent fallback would write memories to storage the operator did not choose. On every provider an edit based on an outdated copy of a memory is rejected rather than overwriting the newer one. File backends check this before writing rather than atomically, so two writes racing at the same moment can both land, and two agents creating a memory with the same name at the same moment can both succeed. There is no migration path between providers - switching does not move existing memories.

Memory is stored only by the ByteChef server application. In a microservices (Enterprise Edition) deployment the Auto Memory tool is still offered to agents, but every call returns an error explaining that the installation runs as microservices, which do not store memory, and that memory requires the ByteChef server application.

Frequently Asked Questions (FAQs)