Skip to content
VIREX
Log inGet started
// Virex Memory capability

One memory, whichever agent you run.

Virex Memory speaks the Model Context Protocol. Any MCP-compatible client discovers the memory tools and uses them directly, which means the layer under your tools stays put even when the tools change.

// Support follows the protocol, not a per-tool integration list.

// Why it exists

Captive memory does not compound.

Memory that lives inside one tool is only ever worth what that one tool is worth to you this quarter.

01

Teams do not run one agent

A developer picks one tool for planning and another for tight edits, and their teammate picks differently again. Memory held inside any one of them is invisible to the rest.

02

Tool choice changes faster than knowledge

What your team learned about its own codebase stays true for years. The agent you preferred when you learned it may not last the year.

03

Per-tool integrations age badly

A memory layer that needs a bespoke integration per client is always missing the one somebody just adopted.

// How it works

One server, discovered by the protocol.

MCP is how an agent finds and calls external tools. Virex ships the server; compatible clients do the rest.

A first-party MCP server

Built and maintained by Virex, so integration quality is a product decision rather than a community dependency.

Tools the agent can use unprompted

The client discovers memory reading and writing through the protocol, so agents record and retrieve without a human staging it.

Same memory, same scope

Every client resolves to your organization memory, with isolation enforced at the database layer rather than per client.

  • Claude Code
  • Cursor
  • Codex
  • Gemini CLI
  • opencode
  • Cowork
// In practice

What portability buys you.

The practical consequences of the memory living outside the tool.

Cross-toolA memory written from one MCP-compatible client is retrievable from any other, so mixed toolchains stop fragmenting what the team knows.
Cross-machineMemory follows the organization rather than a laptop, so the same context is there on a desktop, a laptop, or a fresh machine.
Cross-teammateWhat one member agent worked out is available to the next member agent, inside the same organization scope.
Forward-compatibleA client that speaks MCP works with the same memory on the day it ships, without waiting for a bespoke integration.
Non-MCP agentsFirst-party SDKs and a CLI cover agents you built yourself, with REST and gRPC on one host under the same rules.
Access controlTools resolve for members holding a Virex Memory seat. Removing the seat removes the access.
// FAQ

MCP-native memory questions

Which tools can use Virex Memory over MCP?

Any MCP-compatible client, including Claude Code, Cursor, Codex, Gemini CLI, opencode, and Cowork. Because support follows the protocol, a compatible client that ships later works with the same memory.

Do different tools see the same memories?

Yes. Memory is scoped to your organization rather than to a tool or a machine, so a memory written from one client is retrievable from another.

What happens when my team switches tools?

Nothing happens to your memory. It belongs to the organization, so changing which agent you run does not reset what your agents know.

Is there a separate integration to maintain per tool?

No. There is one first-party MCP server built by Virex, and MCP-compatible clients discover its tools through the protocol.

What if my agent does not speak MCP?

First-party SDKs and a CLI cover that case, with REST and gRPC available on one host under the same tenancy and access rules.

Point your agents at one memory.

Subscribe, assign a seat, and connect whichever MCP-compatible clients your team already runs.

Get startedSee pricing