> For the complete documentation index, see [llms.txt](/llms.txt).
> Markdown versions of each page are available by appending .md to any URL.

# Agent Memory (Research Preview)

Agent Memory is a persistent, cross-harness memory layer for agents in Oz, including the Warp Agent, Claude Code, and Codex.

Caution

Agent Memory is in **research preview** and is enabled per team for design partners. [Join the waitlist](https://warp.dev/oz/agent-memory#waitlist) to request access for your team.

Agent Memory is a persistent memory layer that lives on Oz and is shared across every supported agent harness — the built-in Warp Agent, Claude Code, Codex, and others as they’re added. 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](https://warp.dev/oz/agent-memory#waitlist)

## Key features

-   **Cross-harness memory** — One memory layer shared across the Warp Agent, Claude Code, Codex, and other harnesses as they’re added. Third-party harnesses are covered when they run as cloud agents.
-   **Both local and cloud agents** — Supports interactive local agents in Warp and background cloud agents.
-   **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, Oz extracts durable facts, learnings, and outcomes and writes them as memories. New knowledge merges with existing memories or supersedes them on conflict.
-   **Agent-scoped, shareable stores** — By default, each agent has its own memory store. Stores can also be shared across multiple agents, or across an entire team, when the same knowledge should travel with the work.
-   **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.
-   **Fully accessible via API** — Memories and stores can be read, created, updated, and deleted through the [Oz API](/reference/api-and-sdk/).
-   **Traceability** — For any agent run, you can see which memories influenced it.
-   **Auditability** — Every change to a memory is recorded, so the full history of any memory can be inspected.
-   **Self-hostable** — Enterprises can run Agent Memory on a [self-hosted Oz](/agent-platform/cloud-agents/self-hosting/) instance to meet security, privacy, and compliance requirements.

## Where Agent Memory runs

Agent Memory is part of Oz. Storage, memory creation, and retrieval all run on the same Oz instance that hosts your agents — either Warp-hosted Oz (the default) or a [self-hosted Oz](/agent-platform/cloud-agents/self-hosting/) instance that your team operates inside its own perimeter. The same memory is accessible from any agent you run on Oz:

-   The local Warp Agent.
-   Cloud agents triggered from the CLI, web app, schedules, or integrations.
-   Third-party harnesses running as cloud agents — Claude Code, Codex, and others as they’re added. (Running third-party harnesses locally isn’t supported during the research preview.)

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 collection 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, and across teammates when knowledge should travel with the team.

-   **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 agent the team authorizes, 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, Oz extracts durable facts, learnings, and outcomes from the transcript 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 that run.

-   **Memories evolve over time** — Agents update and supersede their own memories as new information arrives, including to resolve contradictions with prior memories.

You can also explicitly ask an agent to remember something during a conversation, and it lands in the appropriate store.

## How agents use memory

When an agent starts a task, Oz 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](/agent-platform/capabilities/rules/) or [Codebase Context](/agent-platform/capabilities/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 can include per-store instructions that tell 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 can access the store but won’t know when to read from or write to it.

## Join the waitlist

Agent Memory is rolling out to design partner teams during research preview. [Join the waitlist](https://warp.dev/oz/agent-memory#waitlist) to request access.

## Related pages

-   [Codebase Context](/agent-platform/capabilities/codebase-context/) — Let agents understand your codebase through semantic indexing.
-   [Rules](/agent-platform/capabilities/rules/) — Define global and project-level guidelines that shape agent behavior.
-   [Skills](/agent-platform/capabilities/skills/) — Reusable, scoped instructions that teach agents how to perform specific tasks.
-   [Agent profiles and permissions](/agent-platform/capabilities/agent-profiles-permissions/) — Control what permissions and autonomy agents have.
-   [Cloud agents overview](/agent-platform/cloud-agents/overview/) — Run background agents with team-wide observability.
-   [Self-hosting overview](/agent-platform/cloud-agents/self-hosting/) — Run Oz, and Agent Memory along with it, on your own infrastructure.
-   [Oz API and SDK](/reference/api-and-sdk/) — Read, create, update, and delete memories and stores programmatically.
