---
title: "October 2026's Agent Memory Launches: Who Owns the Memory?"
slug: "agent-memory-launches-october-2026-lock-in"
author: "ibl.ai Engineering"
date: "2026-11-08 15:00:00"
category: "Premium"
topics: "agent memory, AI agent memory, vendor lock-in, data ownership, enterprise AI, AI agents, Databricks Agent Memory, Couchbase Agent Memory, Cohere North 2, GitHub Copilot Memory"
summary: "Cohere, Meta, Couchbase, Databricks and GitHub all shipped memory for AI agents between October 5 and October 28, 2026. What an agent remembers becomes the cost of leaving its vendor, so where that memory is stored, and who can read, export and delete it, is now a procurement question."
banner: ""
thumbnail: ""
linkedin: |
  Five companies shipped memory for AI agents in a single month.

  Between October 5 and October 28, 2026: Cohere North 2, Meta's Muse Wonder with Active Memory, Couchbase's managed Agent Memory on AWS, Agent Memory on Databricks, and GitHub Copilot Memory at general availability.

  Memory is what makes an agent better the longer you use it. It is also what makes it harder to leave. A year of corrected preferences and learned context is a switching cost that grows every week.

  The launches answer the ownership question very differently. Databricks says memories live in your Lakebase project and can be read, exported and deleted. GitHub lets you view or delete saved preferences. Cohere's launch post does not say where memory is stored, how long it is kept or how it is removed.

  And exporting rows is not the same as moving memory. The extraction rules, categories and embeddings that make those rows useful are code.

  On ibl.ai you own all the code and the data, including the memory: rows in your own PostgreSQL, governed by organization, agent and user switches, readable and deletable through documented APIs.

  #iblai #AgenticAI #EnterpriseAI #AgentMemory #DataOwnership #VendorLockIn
---

## 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.

<table style="width:100%; border-collapse:collapse; margin:1.5rem 0; font-size:0.95rem;">
  <thead>
    <tr style="background:#f5f5f0; border-bottom:2px solid #2175C5;">
      <th style="text-align:left; padding:0.75rem; color:#5f6368;">Date (2026)</th>
      <th style="text-align:left; padding:0.75rem; color:#5f6368;">Company and product</th>
      <th style="text-align:left; padding:0.75rem; color:#5f6368;">What shipped</th>
    </tr>
  </thead>
  <tbody>
    <tr style="border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem; font-variant-numeric:tabular-nums;">Oct 5</td>
      <td style="padding:0.75rem;"><strong><a href="https://cohere.com/blog/introducing-north-2">Cohere North 2</a></strong></td>
      <td style="padding:0.75rem;">Memory listed as a core feature: "Agents that keep context across sessions, instead of starting cold every time."</td>
    </tr>
    <tr style="border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem; font-variant-numeric:tabular-nums;">Oct 12</td>
      <td style="padding:0.75rem;"><strong><a href="https://about.fb.com/news/2026/10/introducing-muse-wonder-models/">Meta Muse Wonder</a></strong></td>
      <td style="padding:0.75rem;">Active Memory, "the ability to carry what matters to you across conversations."</td>
    </tr>
    <tr style="border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem; font-variant-numeric:tabular-nums;">Oct 20</td>
      <td style="padding:0.75rem;"><strong><a href="https://www.prnewswire.com/news-releases/couchbase-ai-data-plane-cuts-the-cost-of-running-production-ai-agents-at-enterprise-scale-302913871.html">Couchbase Agent Memory</a></strong></td>
      <td style="padding:0.75rem;">Fully managed on AWS, one quarter after the June self-managed launch; claims 33–45% fewer tokens on the LoCoMo benchmark.</td>
    </tr>
    <tr style="border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem; font-variant-numeric:tabular-nums;">Oct 20</td>
      <td style="padding:0.75rem;"><strong><a href="https://www.databricks.com/blog/introducing-agent-memory-databricks">Agent Memory on Databricks</a></strong></td>
      <td style="padding:0.75rem;">Beta on Agent Bricks, stored in Lakebase; claims a tripled pass rate on internal enterprise tasks with 31% fewer tokens.</td>
    </tr>
    <tr style="border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem; font-variant-numeric:tabular-nums;">Oct 28</td>
      <td style="padding:0.75rem;"><strong><a href="https://github.blog/changelog/2026-10-28-github-intelligence-puts-your-code-context-and-history-to-work/">GitHub Copilot Memory</a></strong></td>
      <td style="padding:0.75rem;">Generally available on paid Copilot plans; 93% of reviewed preview CLI sessions that used memory showed better adherence to developer preferences.</td>
    </tr>
  </tbody>
</table>

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."

<table style="width:100%; border-collapse:collapse; margin:1.5rem 0; font-size:0.95rem;">
  <thead>
    <tr style="background:#f5f5f0; border-bottom:2px solid #2175C5;">
      <th style="text-align:left; padding:0.75rem; color:#5f6368;">Launch</th>
      <th style="text-align:left; padding:0.75rem; color:#5f6368;">Where memory is stored</th>
      <th style="text-align:left; padding:0.75rem; color:#5f6368;">Export stated?</th>
      <th style="text-align:left; padding:0.75rem; color:#5f6368;">Deletion stated?</th>
    </tr>
  </thead>
  <tbody>
    <tr style="border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem;"><strong>Databricks</strong></td>
      <td style="padding:0.75rem;">Your Lakebase project, "operated by Databricks"</td>
      <td style="padding:0.75rem;">Yes</td>
      <td style="padding:0.75rem;">Yes</td>
    </tr>
    <tr style="border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem;"><strong>GitHub Copilot</strong></td>
      <td style="padding:0.75rem;">Not stated (a GitHub-hosted service)</td>
      <td style="padding:0.75rem;">Not stated</td>
      <td style="padding:0.75rem;">Yes, view or delete saved preferences</td>
    </tr>
    <tr style="border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem;"><strong>Couchbase</strong></td>
      <td style="padding:0.75rem;">Managed on AWS, or self-managed since June</td>
      <td style="padding:0.75rem;">Not stated</td>
      <td style="padding:0.75rem;">Not stated</td>
    </tr>
    <tr style="border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem;"><strong>Cohere North 2</strong></td>
      <td style="padding:0.75rem;">Not stated (North deploys on-prem, in the cloud or air-gapped)</td>
      <td style="padding:0.75rem;">Not stated</td>
      <td style="padding:0.75rem;">Not stated</td>
    </tr>
    <tr style="border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem;"><strong>Meta Muse Wonder</strong></td>
      <td style="padding:0.75rem;">Not stated</td>
      <td style="padding:0.75rem;">Not stated</td>
      <td style="padding:0.75rem;">Not stated</td>
    </tr>
    <tr style="background:#f0f9ff; border-bottom:1px solid #e5e7eb;">
      <td style="padding:0.75rem;"><strong>ibl.ai</strong></td>
      <td style="padding:0.75rem;">PostgreSQL with PGVector, in the environment you deploy to</td>
      <td style="padding:0.75rem;">Readable through documented REST endpoints</td>
      <td style="padding:0.75rem;">Yes, per memory, per user, per agent</td>
    </tr>
  </tbody>
</table>

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](/developer/platform/agents/memory). 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](/blog/who-owns-ai-agent-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](/docs/os/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](/docs/os/organization-settings/memory); 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.

1. **Where is memory stored?** A named database in a named environment, not "in the platform." Databricks names Lakebase; Cohere's launch post names nothing.
2. **Can every memory be exported in a structured form?** Every record, per user and per agent, with dates and categories, not a summary.
3. **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.
4. **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.
5. **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](/product/agentic-os) hands over with the rest of the stack.

For a related case on the model side, see [Tencent's Hy-Memory-30B](/blog/tencent-hy-memory-30b-open-weight-memory-policy), an open-weight model whose only job is writing agent memory, and our note that [Meta's Muse Wonder Full](/blog/meta-muse-wonder-full-no-api-distribution-lock-in) puts its lock-in in distribution rather than in memory.

## Why does owning the AI stack matter?

**ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.**

- **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours.
- **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform.
- **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ.
- **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity.

1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.

ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.