Set up and manage memory

Long-term memory retains selected facts and preferences across conversations. It is optional and disabled by default because those records may contain personal information. You can use normal conversations and tools without enabling it.

Memory is not the same as a conversation’s transcript. It is a separate pool of selected records, not a promise that every earlier message or file will be available in every future request.

Choose an embedding model

Configure a generation provider first, then open Memory → Setup:

1. Select a configured Embedding provider.
2. Select Discover models if your provider supports discovery, or enter the exact ID in Embedding model yourself.
3. Decide whether to enable Show bounded memory lifecycle events to clients. These events show lifecycle status and counts, not the contents of memories.
4. Select Probe and enable. This sends a real embedding request to the selected provider.
5. Wait for confirmation that the probe passed, then restart ABot as instructed so the saved setting takes effect.

An embedding model converts text into representations used for retrieval. It is separate from the model that writes replies. ABot does not choose, install or download one for you. For Ollama, the embedding model must already be available to the Ollama server; for a hosted provider, use a model and credentials that support its embedding endpoint.

A failed probe is a configuration or connectivity issue to resolve, not successful enablement. Return to this screen and select Disable when you want to turn off passive memory; restart after that change too. Disabling the feature should not be confused with deleting the stored records.

For an npm installation, the equivalent commands are:

npx abot memory status
npx abot memory models --provider <provider-id>
npx abot memory enable --provider <provider-id> --model <embedding-model-id>

Replace the angle-bracket placeholders with IDs from your configuration. These are commands to run in your ABot installation folder, not in the library’s source repository.

Understand what gets saved

During ordinary conversations, the model can propose durable facts or preferences. Proposals enter a candidate pool before automatic admission to stored memory. A high first score is not enough: automatic admission requires independent supporting evidence. Candidates do not participate in recall until promoted.

The score is model judgment, not a measured probability. Temporary task notes, unsupported personal inferences and repeated copies of the same evidence should not become durable knowledge. This policy reduces accidental retention, but you should still inspect what has been saved.

A direct request to remember a fact can use a protected immediate-write path rather than waiting for automatic candidate maturation. Persistence happens in the background: a queued save or a model’s wording alone does not prove that storage completed. Check the record in Memory.

You can inspect, edit and delete saved records from that screen. Manual edits take precedence over pending automatic replacements. SPARK’s Knowledge tab shows candidates; it is not a second store of established memories.

How memory affects a response

The Runtime retrieves a bounded set of relevant records for the terminal response. The root Supervisor or Execution Agent may also request a focused recall during its loop. Retrieved facts are reference material, not new instructions, task authorization or proof of completed work.

Automatic terminal retrieval is not injected into every Planner, Worker or tool context. If a task requires a specific file or fact, include it in the current request rather than assuming every role will have remembered it.

If the embedding provider is unavailable, memory retrieval or persistence can fail while the ordinary reply still completes. A reply without a remembered detail does not, by itself, mean the record was deleted.

Keep the two memory systems distinct

The bundled explicit memory plugin exposes memory_add, memory_get, memory_search and memory_delete. It has its own deterministic store and does not require an embedding model.

Those plugin records are separate from core long-term memory and its candidate pool. Disabling the explicit plugin does not disable passive memory. Deleting a record in one store does not imply deletion from the other. Choose the mechanism deliberately when testing or managing retained information.

Know where the data goes

Core records and the derived vector index are stored under the environment’s Runtime directory:

<runtimeDir>/long-term-memory/memory.json

Local storage does not mean all processing is local. Text used for embeddings is sent to your configured embedding provider, and recalled content can be included in generation requests to your generation provider. Hosted providers therefore process the relevant data under their own terms.

ABot rejects recognizable secret formats, but filtering is not a guarantee against retaining sensitive content. Avoid asking it to remember passwords or API keys. Keep Runtime state out of source control, and use a separate environment for memory experiments. For activity-derived learning and its separate controls, continue with SPARK.