Local Agent Memory: Store Context on Your Own Machine

Local agent memory keeps context on the device running the agent: a SQLite file, a JSON store, or a locally running vector database. The advantage is simplicity: no external service, no credentials to manage, and fast read and write for a single user.

The constraint is that local memory does not follow the work across devices or team members. Tools like fenbs are the right layer when the context needs to be readable by another person, another assistant, or the same agent on a different machine. Local storage and a shared project record each solve a different problem.

SQLite: the practical default for local agent memory

SQLite stores data in a single file on disk. An agent can open the file, query and write rows using standard SQL, and close it without running a server process. It handles thousands of rows quickly and supports typed columns, indexes, and transactions. A SQLite file is easy to inspect, back up, and move to a new machine by copying it.

The main limit is concurrent writes. SQLite allows many concurrent readers but only one writer at a time. If you run multiple agent processes on the same machine that write to the same database simultaneously, one will wait while the other writes. For a single-user local setup, this is rarely a problem. For multiple agents running in parallel, consider a server-based database instead.

JSON files: simple storage for small memory sets

A JSON file or a newline-delimited JSON file (NDJSON) is a practical option when the total memory is small and you do not need to query by attribute. An agent can read the whole file, update a value in memory, and write it back. NDJSON is append-friendly: the agent writes a new JSON object per line without reading and rewriting the whole file.

JSON files become slow when the file grows large, because finding a specific entry requires reading all of it. They also have no built-in concurrency protection: two processes writing to the same file at the same moment may corrupt it. Use a JSON file for quick prototyping or for memory sets that stay small, and switch to SQLite when the file grows beyond a few hundred entries.

Local vector databases for semantic retrieval

A local vector database, such as Chroma or a local Qdrant instance, stores text as numerical vectors so the agent can retrieve entries by semantic similarity rather than by exact key match. The agent embeds a query and finds the closest stored entries. This suits memory that is dense in meaning and where the exact wording of a retrieval query is unlikely to match the wording used when the fact was stored.

The tradeoff is complexity: embedding requires an embedding model, either local or via an API call. The database adds a dependency that must be installed and maintained. Use a local vector database when semantic retrieval genuinely outperforms exact-key lookup for your use case. See agent memory vs RAG for a closer look at retrieval approaches.

Device and sharing limits of local storage

Local memory is tied to the device. If the agent runs on a laptop today and a different machine tomorrow, the memory does not transfer unless you copy the file. If a colleague runs the same agent on their machine, they start with empty local memory. These are deliberate tradeoffs, not bugs: local storage is private and offline-capable precisely because it does not connect to anything outside the machine.

If sharing is eventually needed, plan for migration from the start. Keep the local memory in a format that is easy to export (SQLite has a dump command; NDJSON can be streamed line by line). Build a periodic export step so the local record can be moved to a shared store when the work outgrows a single machine.

When local memory is the right fit

Local memory is the right choice when privacy is a priority and the data must not leave the device, when internet access is unreliable, when the agent is a personal tool that only one person uses, or when you are prototyping and do not want to configure external services yet.

It is not the right choice when the agent's work is part of a shared project, when multiple people need to see or continue the work, or when the agent runs on infrastructure rather than on a personal machine. For those cases, a shared record is needed alongside or instead of local storage. See what is agent memory and agent memory vs context for a look at broader storage options.

How to do this with fenbs

Use local storage for personal, private, or offline memory. Use fenbs for the project record that needs to be shared across sessions, devices, and team members.

1. Create a free account and add your project to fenbs with the current tasks and any standing rules.
2. Connect your assistant from /integrations. Ask it to read fenbs context at the start of each session.
3. Choose a local store for operational memory: SQLite for structured data, NDJSON for simple append-only logs, Chroma for semantic retrieval.
4. Build a load step at startup (read the local store) and a flush step at shutdown (write new memory back to the store).
5. Before the session ends, ask the assistant to save progress in fenbs, including what was done and what remains.