Agents > Memory (Research Preview)

Agent Memory (Research Preview)

Agent Memory is a persistent, cross-harness memory layer for agents in Warp — Warp Agent, Claude Code, Codex, Gemini, and others — that learns over time.

Agent Memory is a persistent memory layer that lives on Warp and is shared across every supported agent harness — the built-in Warp Agent, Claude Code, Codex, Gemini, and others. Agents read from and write to it as they run, so durable facts, decisions, and outcomes from one conversation are available to the next, regardless of which harness, machine, or teammate triggers it.

Memory creation and retrieval are asynchronous and run in the background, so they don’t consume tokens or add latency to the active task.

Join the Agent Memory waitlist

Key features

Cross-harness memory — Memory is shared across every supported harness (Warp Agent, Claude Code, Codex, Gemini, and others). No per-harness setup, and no separate memory service to maintain.
Asynchronous by design — Memory creation runs after a conversation ends. Retrieval runs in the background during a run. Neither consumes tokens or adds latency to the active task.
Automatic memory from conversations — When a conversation ends, Warp extracts durable facts, learnings, and outcomes and writes them as memories. New knowledge merges with existing memories or supersedes them on conflict.
Personal and team stores — Stores are owned by a user or a team. Personal stores are private; team stores are shared across the team and any agents the team authorizes.
Per-agent access and instructions — Attach stores to specific agents with read-only or read-write access. Per-store instructions tell each agent how and when to use the store.
Deletion safety — A store can’t be deleted while it’s attached to a live agent.

Where Agent Memory runs

Agent Memory runs entirely on Warp’s infrastructure. Storage, memory creation, and retrieval are all hosted services — there’s no separate memory backend for you to operate. Because the layer lives on Warp, the same memory is accessible from any agent you run through Warp:

The local Warp Agent.
Oz cloud agents triggered from the CLI, web app, schedules, or integrations.
Third-party harnesses on Warp: Claude Code, Codex, Gemini, and others as they’re added.

Memory stays bound to its owner (a user or a team), independent of which harness reads or writes.

Memory stores

A memory store is a named container of memories. By default, each agent has its own store and writes to it as it runs. Stores can also be shared across multiple agents when they need the same knowledge.

Personal stores — Owned by a user. Hold preferences, working notes, and individual patterns.
Team stores — Owned by a team. Hold shared knowledge like deployment runbooks, code review conventions, or on-call procedures. Every team member and any team-authorized agent can read from the same store.

Use multiple stores to keep contexts separate, and share stores across agents when needed. For example, a code review agent can have its own store of review patterns, while a repo-specific store of architectural decisions is shared between the code review agent and a Sentry triage agent so both reason about the same codebase.

Automatic memory from conversations

When a conversation finishes, Warp extracts durable facts, learnings, and outcomes from what happened and writes them as memories. Memory creation runs in the background after the conversation ends, so it doesn’t consume tokens or add latency during the run that produced it.

Sparse by design — Routine work produces nothing. Only meaningful, reusable knowledge becomes a memory.
Learns over time — New knowledge merges into existing memories or supersedes them on conflict.

You can also explicitly tell Warp to remember something during a conversation, and it lands in the appropriate store.

How agents use memory

When an agent starts a task, Warp searches the stores the agent can access for relevant memories and injects them as context. The search runs in the background, so the agent only sees the memories returned. Agents can also retrieve additional memories on demand mid-conversation when they determine it’s relevant, similar to how they consult rules or Codebase Context. You don’t need to write retrieval queries or pre-load memory.

Attaching memory to your agents

Attach stores to agents with read-only or read-write access. Each attachment includes a free-form instruction string that tells the agent how and when to use the store — for example, “Reference this store for team naming conventions” or “Write a new memory after each successful deployment.” Without instructions, the agent has access to the store but no guidance on when to read or write.

Join the waitlist

Agent Memory is rolling out to design partner teams during research preview. Join the waitlist to request access.

Codebase Context — Let agents understand your codebase through semantic indexing.
Rules — Define global and project-level guidelines that shape agent behavior.
Skills — Reusable, scoped instructions that teach agents how to perform specific tasks.
Agent profiles and permissions — Control what permissions and autonomy agents have.
Cloud agents overview — Run background agents with team-wide observability.