Memory
A semantic search index over the notes your agent writes. Three living markdown files plus a vector store, all local to your machine.
What it is
Memory in Froots is two things working together: three core markdown files that hold the working state of the agent, and a semantic vector index over every other note the agent writes. Both live on your machine.
The three files are context.md (what you’re working on right now), decisions.md (choices made and the reasoning behind them), and learnings.md (mistakes worth remembering). The agent reads and edits them like any other file. They’re plain markdown — you can open them in any editor.
Everything else the agent writes into workspace/memory/ or workspace/kb/ gets automatically chunked, embedded, and indexed so it can be retrieved by similarity later.
How retrieval works
When you send a prompt, Froots embeds your message and scores it against every chunk in the agent’s memory store by cosine similarity. The store is a local SQLite-compatible database with a 384-dim F32_BLOB column per chunk.
Froots takes a short list of the closest matches above the similarity threshold, reranks it with a small local cross-encoder that reads your message and each chunk together, and injects the top results into the prompt as a markdown context block before the model runs. The threshold and the result count live in Settings → Advanced.
| Layer | What it does | Where it lives |
|---|---|---|
| Core files | Hand-edited working state — context, decisions, learnings | workspace/memory/*.md |
| Indexed notes | Automatic semantic recall over everything else the agent writes | The agent’s local database |
| Active prompt | Top-K snippets injected per turn | System prompt |
How writes happen
Memory writes are file-driven, not turn-driven. The agent edits a markdown file in the workspace. A file-watcher notices the change and runs the indexer: it splits the file into chunks that never cross a heading, prefixes each with the document title and heading path so a retrieved fragment says what it’s about, embeds the chunks, and updates the memories table.
Each row stores the chunk text, its embedding, the source file path, a category, and bookkeeping timestamps (created_at, last_retrieved, retrieval_count). The Memories tab in each agent’s settings shows recent memories, filters by category, and searches the index.
What it isn’t (yet)
Memory is ranked by relevance alone — similarity, then the reranker. Recency, retrieval frequency, and supersession (where a new decision replaces an old one) are tracked in the schema but don’t yet affect ranking. There’s no memory shared between people.
What you can do with it
- Resume threads. Ask “what was I doing with the API rewrite last month?” — the index surfaces the decisions and notes that mention it.
- Hand-curate the core. Edit
context.mddirectly when you want the agent to know something without re-explaining it. The next turn picks it up. - Search on purpose. Besides the automatic recall on every turn, agents can search their memory explicitly when they need to dig.