Ask a team of six developers which coding agent they use and you will usually get three answers. One person has settled on something for planning work, another prefers a different tool for tight edits, and somebody switched last month because a release changed how a feature behaved.
This is normal and it is not going to stop. The tools are young, they are improving unevenly, and the switching cost is low enough that people switch on preference. Any architecture that assumes convergence on one client is planning for a world that has not arrived.
What that does to memory
Memory is the capability most damaged by this, because memory is the one thing whose value comes entirely from accumulation. A tool you used for a month and abandoned cost you a month of habit. A memory store you used for a month and abandoned cost you everything it had learned.
When memory lives inside a client, three things break at once.
- It fragments across tools, so the context depends on which client happened to be open when the work was done.
- It dies on switch, because migrating a proprietary memory store between vendors is not a feature anybody ships.
- It never reaches teammates, since a per-client store has no concept of the organization around it.
The protocol argument
The Model Context Protocol changes the shape of this problem, and it is worth being precise about how. MCP is a convention for describing tools so an agent can discover and call them. That is all it is. It is not a memory format, and it does not say anything about what a server does behind it.
What it provides is the one property that matters here: the capability stops belonging to the client. A memory server behind MCP is reachable by Claude Code, Cursor, Codex, Gemini CLI, opencode, and Cowork, not because we wrote six integrations but because all six speak the same protocol.
Support follows the protocol rather than a per-tool integration list, which means a compatible client that ships next year works with the memory you already have.
That last part is the durable version of the claim. A hand-written integration list is a promise you have to keep re-earning with every new client. A protocol is a property of the architecture.
Why the scope is the organization
There is a second decision underneath this one, and it is independent of the protocol. Memory could be scoped per machine, per user, or per organization, and MCP would work identically in all three cases.
We chose the organization because that is where the value compounds. A memory written by one developer agent on Monday is exactly what a teammate agent needs on Wednesday. Scoping to the machine or the individual throws that away for no security benefit, since isolation between organizations is enforced in storage either way.
What we are not claiming
Two honest limits. First, MCP compatibility is a property of the client, not something we can grant. If a tool does not speak the protocol, we are not going to pretend otherwise, and the SDKs exist for exactly that case.
Second, this argument applies to Virex Memory and not to Virex Remote. Remote is built specifically around how Claude Code sessions run and pause, and that specificity is what makes the oversight useful. We would rather have one product with broad portability and one with deliberate depth than blur both.