Agent memory

Agent memory is a capability native to Hilbana: agents save observations (decisions, bugs, conventions, discoveries) organized by scope (project/repo), so they survive across sessions and apply themselves from then on.

What it is

Each observation belongs to a scope, which is the name of the project or repo folder the agent works in. The same folder shares the same memory. Each memory has:

• A content (the text).
• A type: decision, bug, convention, discovery, preference, fact or note.
• Optionally, a topic that groups related memories.

Search is full-text in Spanish (there’s no semantic embedding search): it blends relevance with a recency boost, so the most recent and pertinent surfaces first.

What it’s for

So agents remember across sessions what they learned in each project without having to be re-told: an architecture decision, a bug’s root cause, a team convention. On startup they load context; during work they save what’s relevant; on close they leave a session summary.

How to use it

Agents operate memory with MCP tools:

• mem_context: loads the scope’s most recent memories on startup.
• mem_search: searches by text within the scope.
• mem_get: reads a specific memory by its id.
• mem_save: saves a typed observation (registers the scope the first time).
• mem_session_summary: saves an end-of-session summary.

In the app, the Memory page (admins only) lets you inspect and curate by hand what agents save: the list of scopes (projects) with their memory count, and each one’s memories with type, topic and date, with a search box. Deleting a memory is a soft delete: it stops appearing but the history is kept.

Details

• Memory is isolated per workspace, and when one key reaches several (see API & MCP) the destination follows the work: if the agent has an issue claimed, it saves into that issue’s workspace — so what it learns working for someone reaches their team — and otherwise into the key’s default workspace. mem_save always answers with where it ended up, and workspaceId forces it.
• Reading is explicit: mem_context, mem_search and mem_get use the default workspace unless you pass workspaceId. When picking up issues from another workspace, load its context too.
• Anything about you (how you work, your preferences) should go to your own workspace via workspaceId: saved while working for someone else, their team will see it.
• Project-scoped guests don’t reach the memory of the workspace they visit; theirs stays in the default one. Memory isn’t scoped by project, so it’s read whole or not at all.
• The valid types are the seven above; an unknown type is saved as note.
• It’s not real-time collaborative data: it’s operated over MCP/API, not synced to the interface like issues are.

Related: Agents · API & MCP · Working framework.