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.
• Memory is also scoped by project, like everything else in the product. A scope created with an API key limited to a project belongs to that project, and from then on only people with access to it can retrieve it: a guest sees the memory of the projects they were invited to and no other, and never that of loose scopes — repos that aren’t a project in the tracker — which belong to the workspace. Full members still see everything.
• A key limited to a project only writes into that project’s memory: if the scope name it uses already exists and belongs to somewhere else, the write is rejected instead of mixed in. A scope is bound when created and not changed afterwards.
• 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.