ibl.ai agents now carry a curated Shared Memory — facts, rules and background an administrator writes by hand, injected into every conversation with that agent as an ## Agent Knowledge block, separate from the per-person memories the platform captures automatically, gated by three switches, and stored inside your own perimeter because on ibl.ai you own all the code and the data.
The platform shipped agent shared memory across the backend and SDK in the week of October 9, 2026.
The Agentic Vibe toolkit documented the tab that drives it the same week, and released it in v2.15.0 — one of six releases, v2.14.0 through v2.16.0, all published on October 20, 2026.
What is Shared Memory on an ibl.ai agent?
Shared Memory is one agent's institutional knowledge, with no user attached to it. The sub-tab describes itself exactly: "Facts, rules, and background this agent should always keep in mind. Every person who chats with this agent gets these memories."
Behind it is what the API calls agent knowledge — the agent-memories collection, listed 20 entries per page and capped at a page_size of 100.
Each entry is a short fact of at least 10 characters, and the list renders one card per entry showing the text and "Added by {name} · {time ago}", so a reviewer can see who curated a line and when.
The distinction that matters to a compliance officer is that nothing here is inferred. Personal memories are extracted from conversations by a background job; shared memories are written only by hand.
That is enforced by the absence of a column rather than by a default. An agent-knowledge row carries no is_auto_generated field at all — the flag that marks an LLM-extracted memory elsewhere does not exist on this store, so there is no code path that could set it.
How does an administrator add something an agent must always know?
Through one dialog on the agent's own Memory tab. Add Shared Memory opens a single textarea — "Write what this agent should always keep in mind..." — under a counter that reads "0/10 characters minimum" until ten characters are typed, then switches to a plain character count.
Save stays disabled below the ten-character floor. Entries also deduplicate on a content hash, so saving a line that already exists returns a 409 and the field shows "This shared memory already exists."
You therefore cannot accumulate four slightly different versions of the refund policy by accident.
The content is the kind of thing an organization already writes down somewhere worse — the toolkit's own examples are "Our refund window is 30 days" and "Always cite the policy handbook".
What happens when a shared memory is wrong, and who may change it?
Every entry carries a kebab menu with Edit and Delete. Editing reopens the same dialog with the text loaded; deleting asks first, and the confirmation says plainly what the blast radius is.
"Everyone who chats with this agent will stop seeing it. This action cannot be undone." That sentence is the honest version of what deleting an entry does, and it is why the write path is permissioned rather than open.
There is no dedicated shared-memory permission, so the agent's own write action stands in. With RBAC on and the agent present in the permission tree, a Limited Editor can add and edit shared memories and a Limited Viewer cannot.
Where the tree carries no entry for that agent, the interface stays permissive and the server's 403 is the only authority — which is why the UI treats one as final: when a 403 arrives, the add button and the per-entry menus disappear for the rest of the session rather than offering an action that will fail.
How is shared memory different from what the agent remembers about each person?
They are different stores with different scopes, different authors and different governance. The Personal Memories sub-tab is the per-person side: a user search, a date range, category tabs, a Categories manager and an Add Memory button.
Five categories auto-seed the first time an agent extracts anything — knowledge_gaps, learning_goals, preferences, progress_milestones and personal_context — which is why a brand-new agent's category list can come back empty, and why the tab above shows only the four it has used so far.
An administrator can rename those categories, delete them, or write a new one with its own extraction prompt. Here is how the three stores divide:
| Store | Scope | Written by |
|---|---|---|
| Global memories | One person, every agent in the organization | Auto-captured from chat, or by hand |
| Agent memories (Personal Memories) | One person × one agent, filed by category | Auto-captured per the category's extraction prompt, or by hand |
| Agent knowledge (Shared Memory) | One agent, no person — everyone gets it | Only by hand, never auto-captured |
The operational rule follows from the table: never put something about one person into Shared Memory, because everyone who talks to the agent will read it. That belongs in Personal Memories, where it is scoped to its owner and deletable on request.
What does the model actually receive?
Memory is not pasted in wholesale.
On a new message the platform embeds what the person wrote, runs a cosine search over the memory stores, and prepends roughly the top five global and top five agent memories to the system prompt as markdown, alongside the agent's curated knowledge. The shape is plain:
## Agent Knowledge
- Our refund window is 30 days
## User Information
- The user is a software engineer with 5 years of experience
## Relevant Context from Previous Conversations
- [Knowledge Gaps] The user struggled with recursion
- [Preferences] Prefers Python examples over pseudocodeThe embeddings behind that search are 1536-dimensional, stored in PostgreSQL with PGVector — in your database, on your infrastructure, not in a vendor's index you cannot inspect.
That structure is also why the hand-curation rule is a security property and not a style preference.
## Agent Knowledge reaches every person's prompt, so a store that could be written automatically from one user's message would be a standing injection path into everyone else's conversation.
Which switches decide whether any of this reaches a conversation?
Three, and they cascade top-down: a level that is off stops everything beneath it, whatever the lower levels say.
| Level | Flag | Who sets it, and what off means |
|---|---|---|
| Organization | enable_memsearch |
Organization administrator. Off = no memory for anyone, however many agents are configured |
| Agent | enable_memory_component |
Whoever may edit the agent — the switch on this tab. Off = no memory for this agent |
| Person | auto_capture_enabled, use_memory_in_responses |
The individual. Either can be switched off for privacy even while the organization and the agent are both on |
The tab says as much in the interface rather than burying it in documentation — two of the three gates, at least, where an administrator will actually read them: "Shared memories reach chats only while Long-term Memory is on for this agent and the person chatting has memory turned on."
Turn the agent switch off and both sub-tabs stay visible but inert. The backend injects neither store, and the hint under the switch says so.
Can we build this into our own product instead of using the tab?
Yes, and it is the same four endpoints the tab calls. The REST surface for agent knowledge sits at mentors/{mentor_id}/agent-memories/ with a GET for the paged list, a POST to create, a PATCH to edit and a DELETE that returns 204.
In the SDK, useGetSharedMemoriesQuery, useCreateSharedMemoryMutation, useUpdateSharedMemoryMutation and useDeleteSharedMemoryMutation cover the same ground. AgentMemoryTab drops the whole tab into a route in one import if you would rather not rebuild it.
Both paths are documented in the mirrored toolkit skills: the memory guide explains the three stores and three gates, and the agent memory REST reference lists every endpoint, parameter and error code.
The tab's own skill, with the component props and label overrides, is iblai-vibe-agent-memory on GitHub.
Where does this run, and who holds the data?
Both memory stores are rows in your own database. On Agentic OS you run the whole platform inside your perimeter — your cloud, on-premise, or fully air-gapped — and you own all the code and the data.
That is what makes "delete this entry and prove it" an operation your own team performs rather than a ticket you file with a vendor.
The organization-wide surface for exactly that work — correcting or removing a person's memories on their behalf — shipped earlier in Memory Administration and Conversation Exports.
It is also the reason the neighbouring privacy controls, like incognito chat and PII filtering, are things you configure rather than things you request.
Want to see agent memory on your own data?
We will walk through both sub-tabs on a live agent, show where each store lands in the database, and map the three switches onto your own governance model.
Book a 30-minute demo or talk to the ibl.ai team — ibl.ai is family-owned and operated from New York, NY.