The switching cost isn't the model anymore. It's everything the model remembered. That's a moat the vendor gets to build out of your data, and the better their memory works, the deeper it gets.
There's a workflow a lot of us have backed into. You explore a problem with a local coding agent, Cursor or Claude Code, right there in the repo. You poke at the failing test, read three files, and figure out that the bug is really a race in the retry path, not the thing the ticket says. Then you want to hand the actual work, "fix this bug," "finish this feature," off to another agent so it can grind on it standalone while you do something else.
Maybe that other agent runs in the cloud. Maybe it's a background agent, or a CI job. And increasingly, maybe it's a different model entirely, you did the exploring with Claude, but you want a GPT-based agent to write the fix, or the reverse, because one is cheaper for the long grind and the other is better at the reasoning.
The handoff is where it falls apart. The next agent boots into a clean slate with none of what you just learned. So you paste a paragraph of context into the task description and hope it's enough. It usually isn't. And if the two agents are from different providers, there's no shared memory feature to fall back on at all, Anthropic's memory doesn't talk to OpenAI's, and neither talks to your CI runner.
The fix isn't a better paste. It's giving every agent the same memory, independent of which model or vendor is behind it. This post shows how to wire that up with SenseLab, and why you'd want your context to live somewhere no single provider controls.
Model providers are racing to add memory. That sounds great until you notice where the memory lives: inside the provider. Your agent's accumulated understanding of your codebase, your incidents, your "we tried that and it regressed prod" knowledge, ends up as a proprietary blob in someone else's account.
Two things follow from that, and both should worry you:
You get locked in by your context, not by the model. Switching models is supposed to be easy, it's an API call. But if a year of hard-won operational knowledge lives in Provider A's memory, moving to Provider B means starting from zero. The switching cost isn't the model anymore. It's everything the model remembered. That's a moat the vendor gets to build out of your data, and the better their memory works, the deeper it gets.
You don't actually own the thing that makes your agents good. The model is a commodity, there are several good ones and more every quarter. The durable asset is the accumulated context: what worked, what failed, why. If that asset lives in a provider's memory system, the provider owns your compounding advantage, and you're renting it back. When you can't export it in a form another agent can use, you don't own it in any way that matters.
The way out is to keep memory in a layer you control and every agent can reach, whatever model is driving it. Providers compete on reasoning; your context stays yours.
Concretely, provider-neutral shared memory buys you:
The mechanism that makes this provider-neutral is MCP.
SenseLab is an MCP server that stores memory in a shared backend keyed by the thing the work is about (an entity path like myapp/checkout-service), not by machine, session, or vendor. Any MCP-capable client, Claude Code, Cursor on any model, an OpenAI-based agent, a custom one, connects to the same server and sees the same memory.
Locally, in your .cursor/mcp.json (or ~/.claude/claude_desktop_config.json for Claude Code):
{
"mcpServers": {
"senselab": {
"command": "uvx",
"args": ["amfs-mcp-server-pro"],
"env": {
"AMFS_HTTP_URL": "https://amfs-login.sense-lab.ai",
"AMFS_API_KEY": "${env:AMFS_API_KEY}"
}
}
}
}
Give every other agent the same server, with AMFS_HTTP_URL and AMFS_API_KEY supplied as environment secrets in that runtime, whether that's a Cursor cloud/background agent, a CI job, or an OpenAI-based agent in your own container. Same URL, same key, same tenant. For agents that aren't MCP clients, the same store is reachable through the Python and TypeScript SDKs, so an OpenAI Agents or LangGraph workflow reads and writes the identical memory.
That's the whole requirement. Once agents talk to the same backend, they share memory, and none of it depends on which model they run.
The point of the local session is to leave a trail a cold agent, on any model, can pick up. Three kinds of things are worth recording, and they map to three tools.
Decisions and observations go in as context, as they happen, the useful sentences from your chat, minus the noise.
amfs_set_identity("checkout-bugfix", "Tracing the intermittent 500s on checkout")
amfs_record_context(
"root-cause",
"The 500s aren't validation. It's a race in the retry path: two workers retry the same order when Redis is slow.",
source="local debugging"
)
Findings you're confident about go in as memory, typed so a reader knows what's solid and what's a hunch.
amfs_write("myapp/checkout-service", "bug-retry-race",
"Concurrent retries double-submit orders under Redis latency > 200ms. Repro in test_retry_storm.",
memory_type="belief", confidence=0.7)
amfs_write("myapp/checkout-service", "fix-approach",
"Add an idempotency key per order + a distributed lock around the retry. Do NOT just bump the retry ceiling, that made it worse in DEP-431.",
memory_type="fact", confidence=0.9)
The causal chain gets snapshotted when you close out the session. commit_outcome records everything this session read and wrote, plus the contexts above, as one decision trace tied to a reference you choose, use the ticket ID.
amfs_commit_outcome("BUG-742", "success")
That trace is the thing that makes the handoff work across providers. It's not a vendor-specific memory object, it's a structured record of what informed the decision, which any agent can replay.
You don't have to do this by hand every time. The MCP server ships with agent instructions that push agents to record context and commit outcomes, so a well-guided session does most of it on its own. But knowing the three tools is what lets you reason about what actually crosses over.
Now, the standalone task, and here's where the model can be completely different from the one that did the exploring. The receiving agent starts on BUG-742 in a clean checkout, but its first move isn't to read files, it's to load what the previous session left.
amfs_set_identity("cloud-fixer", "Standalone: fix BUG-742 on checkout-service")
# Compiled digest of everything known about this entity
amfs_briefing(entity_path="myapp/checkout-service")
# The specific decision trace from the earlier session
amfs_get_trace("BUG-742")
# Or pull a specific finding straight from the exploring agent's brain
amfs_read_from("checkout-bugfix", "myapp/checkout-service", "fix-approach")
By the time it reads a single source file, the agent already knows the root cause is a retry race, that the fix is idempotency plus a lock, and that bumping the retry ceiling is a known dead end, no matter which vendor's model is running it. That's the context that would otherwise have died in a chat window, or been stranded in another provider's memory, now delivered as portable memory instead of a prompt.
amfs_read_from also records that the receiving agent learned from the earlier session, so the knowledge transfer is on the record and shows up in the trace, across providers, not lost in a copy-paste.
The handoff isn't one-directional. When the agent finishes, it commits its own outcome. Because it read the earlier session's findings, that outcome back-propagates onto them: the fix approach that led to a clean deploy gains confidence, so next time any agent, any model, asks about this service, the thing that actually worked ranks higher.
amfs_commit_outcome("BUG-742", "success")
Ship a fix that quietly regresses instead, and the same mechanism marks the entries that led there, so the next agent is warned off. Over a few cycles the shared memory stops being a notebook and starts being a track record, one that belongs to you and follows you across whatever models you use.
It helps to be precise about what's being ported, because it's not "the conversation," and it's not tied to a vendor.
None of it is tied to your laptop or to a model provider. It's keyed to myapp/checkout-service and to the agent identities, so it's addressable from anywhere with the API key, by any agent, on any model.
The mechanism is simple; the discipline is in two naming choices.
Stable entity paths. Key memory to the thing the work is about, not to a session or a branch. myapp/checkout-service is good because every agent that ever touches checkout will use it. bugfix-tuesday is useless, no one reuses it. This is the address every agent agrees on without coordinating, regardless of model.
Stable, meaningful agent identities. amfs_set_identity("checkout-bugfix", ...) gives a session a name the next agent can read_from. Use role/domain names that persist (checkout-bugfix, deploy-agent), not session-42. If the receiving agent is continuing the same line of work, it can even reuse the same identity to build directly on that brain.
Get those two right, and cross-agent, cross-model handoff is just multiple clients reading one store. Get them wrong, and you're back to guessing which memory belongs to what.
Strip away the specifics, and the pattern is small:
Context stops living in a chat window that closes when you switch machines, or in a memory feature that's locked to one vendor. It lives in a layer you own, that any agent, local or cloud, Anthropic or OpenAI, can read. The prompt shrinks to "fix BUG-742," because everything else is already there, and it's yours.
If you want the reference implementation, SenseLab is free.
Free tier. No credit card. Connect in minutes.
