Warp's Agent Memory Lets Claude Code and Codex Share One Brain

Warp's new shared memory layer lets Claude Code, Codex, and Warp Agent learn from each other's sessions, with self-hosted or managed storage.

·
·
  • Warp launched Agent Memory in research preview, a shared memory layer for coding agents.
  • Works across Claude Code, Codex, and Warp Agent through the Oz orchestration platform.
  • Uses semantic search over indexed embeddings for fast org-wide retrieval without file traversal.
  • Memory writes and reads are asynchronous, so they don't burn tokens or add latency.
  • Personal and team stores let knowledge travel with users or stay scoped to a team.
  • Memory artifacts are portable and can be self-hosted on your own infrastructure.

Warp just opened a research preview for Agent Memory, a persistent memory layer that sits underneath multiple coding agents and lets them share what they've learned. The pitch is straightforward: stop making your agents relearn the same lessons every session, every repo, and every time a teammate kicks off a new task.

Agent Memory is a fully portable, cross-harness memory system that helps Claude Code, Codex, and the Warp agent remember what works across every session. It runs on Oz, Warp's cloud agent orchestration platform, and it's the first piece of memory infrastructure that explicitly spans more than one agent harness.

One brain, many agents

The core idea is decoupling memory from the agent runtime. Memory stays bound to its owner (a user or a team), independent of which harness reads or writes. So if Claude Code figures out the right way to run your migration scripts on Monday, Codex can pick up that same knowledge on Tuesday without anyone re-typing it into a prompt.

Memory is organized into named stores. By default, each agent has its own store that it writes to as it runs. Stores can also be shared across multiple agents when they need the same knowledge, and across teammates when knowledge should travel with the team. Personal stores hold individual preferences and working notes, while team stores carry shared artifacts like deployment runbooks, code review conventions, and on-call procedures.

How retrieval actually works

Under the hood, this is a retrieval system rather than a giant context window stuffing exercise. Semantic search on indexed embeddings delivers fast retrieval at an org-wide scale. No slow, agent-driven file traversal required. That matters because the alternative, having the agent grep around your repo to rediscover context, burns tokens and wall-clock time on every run.

Writes happen out of band too. Memory creation and retrieval are asynchronous and run in the background, so they don't consume tokens or add latency to the active task. Session transcripts are mined automatically for mistakes, feedback, and decisions, which get consolidated into the memory store for future retrieval.

Memories also carry temporal context and relationships, so the system can reason about how patterns evolved on your team rather than treating every fact as timeless.

Self-hosting and ownership

For teams that don't want their institutional knowledge living in someone else's database, Warp is offering both options. The memory store is owned by the organization deploying it, and Warp can either host it for you or you can build and maintain your own. Memory artifacts are described as auditable and portable, which is the kind of language enterprise buyers want to hear before they let an agent learn anything about their production topology.

Self-improving agents, in theory

The more ambitious claim is that this turns into a feedback loop. Warp is announcing cross-harness Agent Memory that allows agents to store and retrieve long-term memories, enabling self-improvement over time. Agent Memory is an index over all your organizational knowledge that lets Oz pull the right knowledge into context for any agent task.

It also supports pluggable data sources, so the index can pull from files, MCP servers, databases, or other enterprise applications, not just past chat transcripts. The end goal Warp describes: code review agents learn your team's coding style, production agents remember your system's deployment topology, data analysis agents learn and remember how your data is structured.

Where it fits

Agent Memory ships alongside a broader Oz update that adds multi-harness orchestration and automatic multi-agent coordination. Oz now runs Claude Code and Codex alongside Warp Agent through a single control plane, with consistent access controls, governance policies, and audit logs across all harnesses. Teams can compare harnesses directly and assign the right one for each task. Memory is the glue that makes that meaningful, since otherwise each harness would be a stranger to the others.

Availability and access

Agent Memory is in research preview and gated by a waitlist. According to Warp's pricing page, cross-harness agent memory is listed as a research preview feature within the Enterprise tier. The multi-harness orchestration layer it plugs into is in open beta and available to all users while in beta. Practical use cases Warp is positioning it for include code review agents that learn team style, bug investigation agents that remember past incidents, and migration agents that carry decisions forward across long-running projects.

Trending
  • No trending articles

Comments

avatar

Next Reads