The Short Answer
Between October 5 and October 28, 2026, Cohere, Meta, Couchbase, Databricks and GitHub each shipped memory for AI agents, and what an agent remembers becomes the cost of leaving its vendor. On ibl.ai you own all the code and the data, so agent memory is rows in your own PostgreSQL, readable and deletable through documented APIs, wherever you deploy.
The launches are not equal on ownership. Databricks documents export and deletion; Cohere's launch post documents neither. The questions to ask a vendor are where memory is stored, who can read it, and what leaves with you.
Which companies shipped AI agent memory in October 2026?
Five companies shipped agent memory in one month. Each date below is from the company's own announcement, and the performance figures are vendor-reported, not independently tested.
| Date (2026) | Company and product | What shipped |
|---|---|---|
| Oct 5 | Cohere North 2 | Memory listed as a core feature: "Agents that keep context across sessions, instead of starting cold every time." |
| Oct 12 | Meta Muse Wonder | Active Memory, "the ability to carry what matters to you across conversations." |
| Oct 20 | Couchbase Agent Memory | Fully managed on AWS, one quarter after the June self-managed launch; claims 33–45% fewer tokens on the LoCoMo benchmark. |
| Oct 20 | Agent Memory on Databricks | Beta on Agent Bricks, stored in Lakebase; claims a tripled pass rate on internal enterprise tasks with 31% fewer tokens. |
| Oct 28 | GitHub Copilot Memory | Generally available on paid Copilot plans; 93% of reviewed preview CLI sessions that used memory showed better adherence to developer preferences. |
Google and Microsoft are often named in the same breath, but neither belongs on an October list. Google's Memory Bank reached general availability in December 2025, and Microsoft's Foundry memory refresh shipped in June.
Why does AI agent memory become a switching cost?
Agent memory is valuable for the same reason it is hard to leave: it compounds. GitHub's 93% figure is a measure of that value, since an agent that follows preferences it learned last month saves a correction this month.
Enterprise software has seen the pattern before. A CRM becomes hard to replace less because of its features than because years of deal notes and account history live inside it. Agent memory is the same mechanism, filled by observation rather than data entry.
A CRM holds what a team typed about its customers.
An agent's memory holds what the agent inferred about the team: preferences, gaps, recurring tasks, and the corrections people made. Couchbase describes its store as persisting "profiles, conversation history, and vectorized facts across sessions."
That makes the location of agent memory a governance question, not only a technical one. Whoever operates the store decides how long it is kept, who can read it, and what leaves when the contract ends.
What do the October 2026 agent memory launches say about export and deletion?
The five launches answer the ownership question very differently, and it is worth crediting the ones that answer it well. The table records only what each launch announcement states; a blank is "not stated in the launch," not "not possible."
| Launch | Where memory is stored | Export stated? | Deletion stated? |
|---|---|---|---|
| Databricks | Your Lakebase project, "operated by Databricks" | Yes | Yes |
| GitHub Copilot | Not stated (a GitHub-hosted service) | Not stated | Yes, view or delete saved preferences |
| Couchbase | Managed on AWS, or self-managed since June | Not stated | Not stated |
| Cohere North 2 | Not stated (North deploys on-prem, in the cloud or air-gapped) | Not stated | Not stated |
| Meta Muse Wonder | Not stated | Not stated | Not stated |
| ibl.ai | PostgreSQL with PGVector, in the environment you deploy to | Readable through documented REST endpoints | Yes, per memory, per user, per agent |
Databricks is the clearest of the five.
Its announcement lists "Memory you own and control" as a feature, says sessions and memories "live in your Lakebase project, independent of any single agent framework," and lets developers "read, export, and delete the entries an agent keeps about each user."
So the lock-in question is being asked, at least by one vendor.
The gap is elsewhere: Cohere's launch post names no storage location, retention period or deletion mechanism for memory, and Meta's names none either. For a regulated buyer, a launch that is silent on those three is a launch to question before enabling.
Is exporting AI agent memory the same as being able to move it?
No. An export gives you the rows; it does not give you what made the rows useful. Agent memory is a set of records plus the code that decides what to write, how to classify it, how to embed it, and which records to retrieve for a given message.
On ibl.ai, that code path is documented in the memory system reference. Each memory is stored with a 1,536-dimension embedding, and on each new message the platform retrieves the top 5 global and top 5 agent memories by cosine distance.
Those numbers are why rows alone do not travel.
Embeddings produced by one model are not comparable with another model's, so a receiving system has to re-embed everything. Categories and extraction prompts have to be rebuilt, or the new agent remembers differently from the old one.
We made the same argument from the model side in who owns an AI agent's memory when you switch models: memory belongs to whoever owns the database it is written to. Owning the code that writes and reads it is the other half.
How does ibl.ai keep AI agent memory under the customer's control?
On ibl.ai you own all the code and the data, and agent memory is part of that data. Memory is stored in PostgreSQL with PGVector, in whichever environment you deploy the platform to: your cloud, your data center, or an air-gapped network.
Three switches cascade from the top down, per the Agent Settings: Memory documentation: the organization, the agent, and the person. A level that is off stops everything beneath it, and conversations in Incognito mode never store memory regardless of the agent's setting.
Memories can be read and corrected from three places that reach the same store.
Administrators use the agent's Memory panel and the organization's Memory settings; each person uses their own Profile. Memories captured automatically carry an auto badge, so a reviewer can tell inference from a deliberate entry.
Personal memories and shared knowledge are kept apart. Personal memories belong to one user at a time.
Shared Memory holds "facts, rules, and background" every person who chats with the agent receives, and it is only ever written by hand, so nothing one person says in a chat can reach everyone else.
The same records are reachable through documented REST endpoints for global and agent-specific memories, with filters by content and date and a delete call per memory. If you leave, you take the rows and the code that produced them.
What should a buyer ask before turning on AI agent memory?
Five questions separate memory you own from memory you rent, and each maps to a column the October launches either answered or left blank.
- Where is memory stored? A named database in a named environment, not "in the platform." Databricks names Lakebase; Cohere's launch post names nothing.
- Can every memory be exported in a structured form? Every record, per user and per agent, with dates and categories, not a summary.
- Can a single memory be deleted, verifiably? Per memory, per user, per agent. GitHub documents view and delete for saved preferences; that is the minimum.
- Who can see what the agent remembers about a person? A person can ask what is held about them under GDPR's right of access (Article 15), so an administrator must be able to answer.
- What runs the memory, and do you get it? The extraction prompts, categories, embedding model and retrieval rules decide what the rows mean. Without them, an export is an archive.
None of the five October announcements says the customer receives the code that writes and reads memory, which is why the fifth question matters most. It is the part Agentic OS hands over with the rest of the stack.
For a related case on the model side, see Tencent's Hy-Memory-30B, an open-weight model whose only job is writing agent memory, and our note that Meta's Muse Wonder Full puts its lock-in in distribution rather than in memory.