Agent memory usually goes one of two ways. Either the agent forgets everything that falls out of the context window, so you find yourself repeating your name, your stack and your preferences every few days. Or the project bolts on a vector database, an embeddings pipeline and a retrieval layer, and now you run three more services to remember that you prefer short answers.

HydraOps takes a smaller route. Memory is two plain tools, remember and recall, and the whole thing runs on the SQLite file and the Markdown files you already have. Nothing new to install, nothing new to keep alive. This post is about why there are two tools instead of one, and what each of them actually does.

Two different problems

The comment at the top of recall's source says it in one line: remember keeps curated durable facts, recall digs up what actually happened. Those are different needs, and mixing them is how memory systems get confusing.

Curated facts are the things worth keeping on purpose: how you like answers, the name of the project you are on, a standing instruction. They are few, they are short, and they should be in front of the agent every single time. What actually happened is the opposite: thousands of exchanges, most of them irrelevant most of the time, until the day you ask "what did we decide about the backup plan last month?". You do not want all of that in the prompt. You want to search it.

So one tool writes, and the other one searches.

remember: a dated bullet in a file you can read

Every agent in HydraOps is six Markdown files, and one of them is <agent>.memory.md. Until version 0.1.19 that file could only be edited by hand, from the Agents view. Nothing in the system wrote to it.

remember changes that. When you tell an agent "remember that I deploy on Fridays", it appends a dated bullet to its own memory file:

- [2026-09-21] The user deploys on Fridays; avoid proposing risky changes late in the week.

Because the memory file is re-read into the system prompt on every task, the note applies immediately and to every future conversation. No restart, no reindexing.

Two limits keep it honest. A note can be at most 600 characters, and the file at most 64 KB. The tool tells the model to condense rather than dump, and when the file is full it asks you to prune old notes instead of silently overwriting. The tool description is explicit about what not to store: one-off task details, or things already in the conversation. One short, self-contained fact per call.

The file stays yours. Open it in the Agents view, edit a line, delete a line. It is plain text, not a black box.

recall: full-text search, no embeddings

recall is episodic memory: the agent searches its own past completed tasks by keywords, reaching beyond the ten most recent tasks that are already injected into its context.

The implementation is the part I like most, because of what it does not include. There is no embeddings model, no vector index, no separate service. It is SQLite FTS5, which ships inside the better-sqlite3 package HydraOps already depends on. A virtual table, tasks_fts, shadows the tasks table through triggers: every completed task's prompt and result (the first 4,000 characters) becomes searchable, and the index follows updates and deletes on its own. It is created lazily and backfilled from existing tasks the first time it is used, and since the triggers live in the database file itself, tasks completed by any process stay indexed.

Queries are reduced to bare word tokens, ranked with BM25, and the agent gets back the five best matches as dated excerpts: what you asked, what it answered. The tokenizer is configured to ignore diacritics, so a search for busqueda finds búsqueda. That matters more than it sounds for a project whose users write in Spanish, Portuguese, French and Italian.

An agent only sees its own memory

Both tools share one design decision, and for a project built around keeping credentials away from agents it is the one I would call out. The agent whose memory gets written, or searched, is never taken from the model's input. It comes from the worker: each worker binds the calling agent's identity into the tools it hands the model, innermost, inside the security guard and the usage tracking. remember can only append to its own agent's file. recall only ever receives keywords; the search closure already has the agent id applied. There is no parameter an agent could set to read another agent's notes or conversations.

On by default, and from the keyboard

Since 0.1.20, a new agent is born with four tools granted: web_search, fetch_url, remember and recall. Everything else stays off until you allow it in tools.md, under the same strict per-agent gate as every other tool. Existing agents were left untouched; it only changed the template for new ones.

And since 0.1.27 you do not need the model for the routine cases. Type / in the chat box and the palette lists /remember <note>, which saves a note with no model involved and no tokens spent, /recall <keywords>, which searches, and /memory, which shows the agent's memory file. The same commands work in the Telegram bot.

What this does not do

The honesty section, as usual:

It is keyword search, not semantic search. A query for "car" will not find a conversation about "the vehicle". In exchange it is exact, instant, cheap, and it needs nothing you do not already run. If you ever need semantic recall, that is a different tool, not a change to this one.
recall only searches completed tasks. A conversation that is still running is not in the index yet.
The model decides when to call remember. It is instructed to do so when you ask, or when it learns a stable preference, but if it does not, /remember puts the note in yourself.
The 600-character cap is a feature. Memory is for facts that stay true, not for transcripts.

remember landed in 0.1.19, recall in 0.1.20 together with the new defaults, and the slash commands in 0.1.27. The code is short enough to read over coffee: remember, recall and the FTS5 index. The manual covers it under Agents and Commands.

HydraOps is a self-hosted multi-agent AI system: one chat, several agents with their own personality, model and tools working on tasks in parallel. Try it here.