--- title: "Who Owns an AI Agent's Memory When You Switch Models?" slug: "who-owns-ai-agent-memory-when-you-switch-models" author: "ibl.ai Engineering" date: "2026-10-11 12:00:00" category: "Premium" topics: "agent memory, AI agent infrastructure, model gateway, model-agnostic AI, network governance, egress control, vendor lock-in, data ownership, enterprise AI" summary: "Agent memory belongs to whoever owns the database it is written to, not to the model that reads it — which is why memory, the model gateway and network egress are one ownership decision, not three features." banner: "" thumbnail: "" linkedin: | The model an AI agent runs on matters less than where the agent's memory lives. Here is the test. On March 2, 2026, Anthropic opened memory import to free Claude users. The documented path out of another assistant is a prompt: you ask the old model to list every memory it has stored about you, then paste its answer into Claude. That is a reasonable product. It is also a precise picture of what memory is when you don't hold it: a paraphrase a model writes on request. Anthropic's own support page calls imports experimental and says Claude may not always incorporate them. Agent infrastructure has three parts that only make sense together: → A memory store: per-user facts in a database, with a capture switch and a use switch → A model gateway: any agent can move between providers without touching that store → Network governance: an agent that remembers and acts can only reach the hosts you allow Own one of the three and rent the other two, and the rented part decides when you can leave. On ibl.ai you own all the code and the data. Memory is rows in your own PostgreSQL. Each agent picks its provider from the platform's list and can be switched at any time. A code sandbox starts with no network at all, and opens only as far as the egress profile you choose, down to an allowlist of exact host:port pairs. #iblai #AgenticAI #EnterpriseAI #AgentMemory #ModelAgnostic #AIGovernance --- ## The Short Answer **An AI agent's memory belongs to whoever owns the database it is written to, not to the model that reads it. Anthropic's documented way to bring memory over from another assistant is asking that model to recite what it remembers and pasting the prose into Claude. On ibl.ai you own all the code and the data, so memory is rows in your own PostgreSQL that stay put when you switch models.** That makes memory, the model gateway and network governance one decision about ownership. Each is only portable if the other two are. ## Are AI agents without memory really just stateless functions? Partly. An agent with no memory starts every conversation from zero, so a person has to re-explain their role, their preferences and their project each time. That is the cost the slogan is pointing at. But stateless is sometimes the correct design, not a defect. On ibl.ai, conversations in private mode never store memory regardless of the agent's setting, and the [9 October 2026 release](/updates/platform-update-2026-10-09) added incognito chat that can be switched off and on within one session. Memory on the platform is gated at three levels — the organization, the agent, and the user — per the [memory system documentation](/developer/platform/agents/memory). A user holds two independent switches: one governs whether anything new is captured, the other whether stored memories shape replies. So the better statement is narrower: an agent that should know you, and doesn't, is a function. An agent that remembers when you asked it not to is a liability. Both failures are about control, not capability. ## Who owns an AI agent's memory when you switch to a different model? The owner of the store, every time. The model only reads and writes it. The clearest public example of what happens without that ownership is a migration tool. On March 2, 2026, Anthropic made memory, and a [memory import tool](https://www.macrumors.com/2026/03/02/anthropic-memory-import-tool/), available to free Claude users. The mechanism is a prompt. You paste Anthropic's prepared prompt into the assistant you are leaving, it writes out the memories it holds about you, and you paste that text into Claude's memory settings. Anthropic's [support article](https://support.claude.com/en/articles/12123587-import-and-export-your-memory-from-claude) lists imports on the Free, Pro, Max and Team plans. It also says they are "experimental and still in active development," and that Claude may not always successfully incorporate them. That is honest, and it is the point. Memory you do not hold leaves as a paraphrase a model generates on request — not as records with dates, categories and provenance. Nothing about the old store comes with it except what the old model chose to say. The same article notes that Claude's memory prioritizes work-related content and may not retain imported personal details unrelated to work. The receiving model decides what survives the move. ## What does an AI agent's memory store actually contain? On ibl.ai, memory is a table, not a transcript. The [memory system documentation](/developer/platform/agents/memory) describes two scopes: global user memories that apply across all agents, and agent-specific memories scoped to a single agent. Each memory is stored in PostgreSQL with PGVector, alongside a 1,536-dimension embedding. When a new message arrives, the context service retrieves the top 5 global and top 5 agent memories by cosine distance and injects them into the system prompt. Agent memories carry categories — Knowledge Gaps, Learning Goals, Preferences, Progress Milestones and Personal Context by default — and administrators can add their own. Duplicates are caught by a SHA-256 hash and a semantic check at a cosine distance of 0.15. Since the [11 September 2026 release](/updates/platform-update-2026-09-11), graph agents on tool-calling models manage that store themselves through save, update, forget and search, and temporary facts carry an expiry purged nightly at 04:20 UTC. The model decides what is worth writing. You decide where it is written, who can read it, and when it is deleted. That division is the whole argument. ## What happens to agent memory when you change models, vendors or people? The useful question is not "does the agent have memory" but "what survives each kind of change." On infrastructure you own, the answers are mechanical rather than contractual.
Change What happens to the memory store on ibl.ai
Switch an agent's chat model Nothing moves. The memories live in your PostgreSQL, not in the provider's account, and retrieval injects them into the system prompt of whichever model the agent now uses.
Switch the embedding model Each memory's text is stored beside its 1,536-dimension vector. Vectors from different embedding models are not comparable, so a new embedding model means recomputing them from that text, which you hold.
A user turns capture off Nothing new is written. Existing memories stay until removed, and the separate use switch stops them shaping replies.
A person leaves the organization An administrator opens the organization's Memory tab, reviews every memory about that person across all agents, and edits or deletes them.
You change vendors entirely The database is already yours. There is no export prompt, because there is nothing to ask a model to recite.
The administrative row shipped in the [August 2026 memory administration update](/updates/memory-administration-and-conversation-exports): an organization-level tab with a Global view, user by user, and an Agent view, agent by agent. Memories captured automatically carry an `auto` badge, so a reviewer can tell an inference from something a person typed. ## What does a model gateway have to do with agent memory? A model gateway is the layer that lets any agent call any provider through one interface. It only delivers model independence if the state an agent depends on lives below it, not inside the provider. On ibl.ai, the [LLM configuration panel](/docs/os/agent-settings/llm-configuration) shows one card per provider; the documented screenshot lists 10 — Amazon, Anthropic, Microsoft, DeepSeek, Google, Groq, NVIDIA, OpenAI, Perplexity and xAI. Each agent picks its provider and model, and can be moved to another at any time. Because memory sits in the platform's own store rather than in any provider's account, that switch is a configuration change rather than a migration. Global memories are scoped to every agent, so two agents on two different providers draw on the same pool of global facts about the same person. The gateway also makes the switch measurable. The [rebuilt analytics](/updates/analytics-cost-by-model-and-transcripts) breaks spend down by provider, model, user and individual call, with median and 95th-percentile latency per model — the evidence you need before moving an agent. We made the broader case in [model-agnostic AI: the real risk is vendor lock-in](/blog/model-agnostic-ai-the-real-risk-is-vendor-lock-in). Memory is the part of that risk people notice last, because it accumulates quietly. ## Why does network governance belong in the same conversation as agent memory? Because an agent that remembers and can act is a data path. Memory gives it something worth sending; a tool or a code sandbox gives it a way to send it. Governing the network is what keeps the store you own from leaking through the agent you deployed. On ibl.ai, the [Virtual Machine Shell sandbox](/docs/os/agent-settings/sandbox) starts with no network at all. Four egress profiles set what it may reach: No Network, Package Registries, Public Internet with private ranges and cloud metadata addresses denied, or a Custom Allowlist that denies by default. An allowlist is a list of exact `host:port` pairs — no wildcards, at most 100 per policy — and loopback, link-local and cloud metadata addresses are refused outright. Policies are written once at the organization level and reused across agents. The wider shift of agent security into shipped infrastructure is in [enterprise agent security: what shipped in 2026](/blog/enterprise-agent-security-what-shipped-2026). Secrets follow the same logic. Up to 20 can be bound to an agent, and inside the VM each one is a placeholder; the real value is substituted only on encrypted requests to the hosts that secret is allowed to reach. The agent can use a key it can never read. VM time is metered at $1 per ten minutes by default, prorated per second, and each organization sets its own figure — including zero. Governance, here, is configuration you own, not a vendor default you inherit. ## Does the model matter less every month? Not exactly. Better models still reason better, and the analytics above exist because model choice changes both cost and latency. What is true is that the model has become the most replaceable part of an agent. The memory store, the gateway and the network policy are the parts that hold an organization's history and its rules. They are also the parts that decide whether replacing the model is a settings change or a project. That is the ownership argument in one line: own the three layers that accumulate, and treat the layer that improves fastest as a part you can swap. The same asymmetry applies to enterprise data integration, which we covered in [the model is the commodity, the context layer is the moat](/blog/context-layer-is-the-moat-not-the-model). We traced where memory itself goes wrong in [agent memory fails at state transitions, not retrieval](/blog/agent-memory-state-transitions-world-models-vs-rag), and what a school district should make it forget in [expiring agent memory under FERPA and COPPA](/blog/expiring-agent-memory-k12-ferpa-coppa-moderation). ## How does ibl.ai deploy agent memory, a model gateway and network governance together? With ibl.ai you own all the code and the data — the full platform, under a perpetual license, on your own infrastructure. It is model-agnostic across any LLM, usage-based with no per-seat pricing, and you can deploy anywhere: your own cloud, on-premise, GovCloud, or a fully air-gapped network. Memory, the provider list and the egress policies all run inside that perimeter on [Agentic OS](/product/agentic-os). 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. *Related reading: [memory and skills: what turns an agent loop into a real AI agent](/blog/memory-and-skills-what-turns-an-agent-loop-into-a-real-ai-agent); [agent memory fails at state transitions, not retrieval](/blog/agent-memory-state-transitions-world-models-vs-rag); [expiring agent memory under FERPA and COPPA](/blog/expiring-agent-memory-k12-ferpa-coppa-moderation).* *Sources: [Anthropic Adds Free Memory Feature and Import Tool](https://www.macrumors.com/2026/03/02/anthropic-memory-import-tool/) (MacRumors, 2 March 2026); [Import and export your memory from Claude](https://support.claude.com/en/articles/12123587-import-and-export-your-memory-from-claude) (Anthropic support); ibl.ai documentation for the [memory system](/developer/platform/agents/memory), [organization memory settings](/docs/os/organization-settings/memory), [LLM configuration](/docs/os/agent-settings/llm-configuration) and [sandbox network access](/docs/os/agent-settings/sandbox).* ## 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.