-
Notifications
You must be signed in to change notification settings - Fork 10
docs(agent-platform): add Agent Memory research-preview pages #86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 14 commits
7b00e11
1564a8d
ef5d17f
9bce66c
2ea77ff
5648a5a
527a384
ed1415b
c8a6458
b740473
f13928c
479b0c6
6c93d6f
0c488a6
10c0d32
a93275e
ac96a45
1258076
0064236
7e50661
e147217
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,75 @@ | ||
| --- | ||
| title: Agent Memory (Research Preview) | ||
| description: >- | ||
| 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. | ||
| sidebar: | ||
| label: "Agent Memory (Research Preview)" | ||
| --- | ||
| :::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 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. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also Gemini isn't officially supported in Oz yet, right? |
||
|
|
||
| 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 | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
|
||
| * **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. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would focus more on the sharing here, less on personal - highlighting that memory is agent-scoped and can be shared across agents. |
||
| * **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. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. seems irrelevant? |
||
|
|
||
| ## 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: | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This feels pretty strong - we should mention somewhere that it can be self-hosted |
||
|
|
||
| * 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. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's only supported for third party harnesses running in Oz (not 3p harnesses running locally), at least for now |
||
|
|
||
| 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. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would remove this and instead mention that memories evolve over time and can be updated by agents to resolve contradicitons, etc. |
||
|
|
||
| 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](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. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think the cross-harness part covers it?