From 4a4cb392cfb82c50592e94889a9575a13df57835 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Fri, 12 Jun 2026 21:55:59 +0000 Subject: [PATCH 1/4] docs: align Agent Memory page with current research preview capabilities Remove or soften claims that aren't true today, per design partner feedback: - Remove "by default, each agent has its own memory store"; describe stores as attachable/shareable instead - Remove "Fully accessible via API" bullet and API related-page link until the memory API is publicly documented - Soften Traceability to memory provenance (where a memory came from) rather than run-context retrieval tracing - Remove self-hosting support claims throughout the page Co-Authored-By: Oz --- .../docs/agent-platform/agent-memory/index.mdx | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/src/content/docs/agent-platform/agent-memory/index.mdx b/src/content/docs/agent-platform/agent-memory/index.mdx index 6f07336f..b5fa40d5 100644 --- a/src/content/docs/agent-platform/agent-memory/index.mdx +++ b/src/content/docs/agent-platform/agent-memory/index.mdx @@ -28,16 +28,14 @@ Watch this short preview to see Agent Memory in context. * **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. +* **Shareable stores** - Memory is organized into stores that can be attached to specific agents, shared across multiple agents, or shared 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** - Memory retrievals are recorded so teams can inspect which memories contributed to a run's context. +* **Traceability** - Each memory records where it came from, so teams can trace a memory back to its source. * **Auditability** - Every change to a memory is recorded so teams can inspect how a memory has changed over time. -* **Self-hosting support** - 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. That instance can be 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: +Agent Memory is part of Oz. Storage, memory creation, and retrieval all run on Oz alongside your agents. 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. @@ -47,7 +45,7 @@ Memory stays bound to its owner (a user or a team), independent of which harness ## Memory stores -A memory store is a named collection of memories. 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. +A memory store is a named collection of memories. Stores can be attached to individual agents, shared across multiple agents when they need the same knowledge, and shared across teammates when knowledge should travel with the team. * **Personal stores** - Owned by a user. Store memories about preferences, working notes, and individual patterns. * **Team stores** - Owned by a team. Store 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. @@ -81,5 +79,3 @@ Agent Memory is rolling out to design partner teams during research preview. [Jo * [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. From 9fd273b0ffd8065c18e4a34b342e8748accdfa88 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Fri, 12 Jun 2026 22:03:24 +0000 Subject: [PATCH 2/4] docs: fix remaining Agent Memory accuracy issues from review pass Verified against the warp-server implementation: - Stores have a UID and optional description, not a name; drop "named" - Only team-owned stores can be attached to agents, so avoid "its own store" phrasing for agents; scope multi-store usage to teams (users have one live store) - Attachment instructions are required by the API, not optional Co-Authored-By: Oz --- src/content/docs/agent-platform/agent-memory/index.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/content/docs/agent-platform/agent-memory/index.mdx b/src/content/docs/agent-platform/agent-memory/index.mdx index b5fa40d5..28b80df2 100644 --- a/src/content/docs/agent-platform/agent-memory/index.mdx +++ b/src/content/docs/agent-platform/agent-memory/index.mdx @@ -45,12 +45,12 @@ Memory stays bound to its owner (a user or a team), independent of which harness ## Memory stores -A memory store is a named collection of memories. Stores can be attached to individual agents, shared across multiple agents when they need the same knowledge, and shared across teammates when knowledge should travel with the team. +A memory store is a collection of memories. Stores can be attached to individual agents, shared across multiple agents when they need the same knowledge, and shared across teammates when knowledge should travel with the team. * **Personal stores** - Owned by a user. Store memories about preferences, working notes, and individual patterns. * **Team stores** - Owned by a team. Store 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. +Teams can use multiple stores to keep contexts separate, and share stores across agents when needed. For example, a code review agent can use a dedicated 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 @@ -66,7 +66,7 @@ When an agent starts a task, Oz searches the stores the agent can access for rel ## 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, use instructions like "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. +Attach stores to agents with read-only or read-write access. Each attachment includes per-store instructions that tell the agent how and when to use the store. For example, use instructions like "Reference this store for team naming conventions" or "Write a new memory after each successful deployment." Instructions are required on every attachment so the agent knows the purpose of each store. ## Join the waitlist From c827fa6647998b45e34e654efd8c9eebf9acf9a6 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Tue, 16 Jun 2026 19:54:02 +0000 Subject: [PATCH 3/4] docs: define Auto-memory and fix store-sharing language on Agent Memory page Addresses review feedback on PR #227: - Define Auto-memory: new agents get a dedicated, agent-owned default store, controlled by an on-by-default toggle at agent creation. Added a Key features bullet and an "Auto-memory for new agents" subsection, explicitly distinguished from "Automatic memory from conversations". - Correct store-sharing model: stores attach to agents (no direct team-level sharing); team reach comes from attaching a store to an agent the whole team uses. Reworded the Key features bullet, the Memory stores intro, and the Team stores bullet, and added an Agent stores owner type. - Include agents in the memory owner list under "Where Agent Memory runs". Co-Authored-By: Oz --- .../agent-platform/agent-memory/index.mdx | 24 ++++++++++++++----- 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/src/content/docs/agent-platform/agent-memory/index.mdx b/src/content/docs/agent-platform/agent-memory/index.mdx index 28b80df2..d4457ce6 100644 --- a/src/content/docs/agent-platform/agent-memory/index.mdx +++ b/src/content/docs/agent-platform/agent-memory/index.mdx @@ -28,7 +28,8 @@ Watch this short preview to see Agent Memory in context. * **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. -* **Shareable stores** - Memory is organized into stores that can be attached to specific agents, shared across multiple agents, or shared across an entire team when the same knowledge should travel with the work. +* **Shareable stores** - Memory is organized into stores. A store can be attached to one or more agents, so the same knowledge is available wherever those agents run. To share knowledge across a team, attach a store to an agent the whole team uses. +* **Auto-memory for new agents** - New agents get a dedicated, agent-owned memory store by default, so they start building long-term memory from their first run. You can turn this off when you create the agent. * **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. * **Traceability** - Each memory records where it came from, so teams can trace a memory back to its source. * **Auditability** - Every change to a memory is recorded so teams can inspect how a memory has changed over time. @@ -41,16 +42,27 @@ Agent Memory is part of Oz. Storage, memory creation, and retrieval all run on O * 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 stays bound to its owner (a user, an agent, or a team), independent of which harness reads or writes. ## Memory stores -A memory store is a collection of memories. Stores can be attached to individual agents, shared across multiple agents when they need the same knowledge, and shared across teammates when knowledge should travel with the team. +A memory store is a collection of memories. Stores are used by attaching them to agents: a store can be attached to a single agent or to several agents that need the same knowledge. To make knowledge available across a team, attach a store to an agent the whole team uses; there's no separate step for sharing a store with individual teammates. -* **Personal stores** - Owned by a user. Store memories about preferences, working notes, and individual patterns. -* **Team stores** - Owned by a team. Store 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. +Stores differ by who owns them: -Teams can use multiple stores to keep contexts separate, and share stores across agents when needed. For example, a code review agent can use a dedicated 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. +* **Personal stores** - Owned by a user. Hold memories about preferences, working notes, and individual patterns. +* **Agent stores** - Owned by an agent. A new agent gets one by default as its auto-memory store (see below). +* **Team stores** - Owned by a team. Hold shared knowledge like deployment runbooks, code review conventions, or on-call procedures. Attach a team store to any agent the team uses so everyone's work draws on the same knowledge. + +Teams can use multiple stores to keep contexts separate, and attach the same store to several agents when needed. For example, a code review agent can use a dedicated store of review patterns, while a repo-specific store of architectural decisions is attached to both the code review agent and a Sentry triage agent so both reason about the same codebase. + +### Auto-memory for new agents + +When you create an agent in the Oz web app, **Auto-memory** is on by default. With it enabled, Oz creates a dedicated memory store owned by that agent and uses it as the agent's default long-term memory: the agent reads relevant memories before it acts and writes durable facts, decisions, and preferences for future runs. Each agent has a single auto-memory store. + +Auto-memory is different from automatic memory from conversations, described below: auto-memory is the store an agent gets by default, while automatic memory from conversations is how memories are written to a store after a conversation ends. + +You can turn Auto-memory off when you create the agent, and you can attach existing team stores at the same time, each with its own access level and instructions. ## Automatic memory from conversations From 7c1ab3f4f3b12836091f2590ce21adc259bc123a Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Tue, 16 Jun 2026 22:25:04 +0000 Subject: [PATCH 4/4] docs: note API access and self-hosting as coming soon on Agent Memory page Per review feedback (Suraj's two "coming soon?" comments), surface the two not-yet-available capabilities on the page instead of omitting them: added a "Coming soon" section listing programmatic API access and self-hosting support, clearly marked as not part of the research preview yet. Co-Authored-By: Oz --- src/content/docs/agent-platform/agent-memory/index.mdx | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/content/docs/agent-platform/agent-memory/index.mdx b/src/content/docs/agent-platform/agent-memory/index.mdx index d4457ce6..74d32ad2 100644 --- a/src/content/docs/agent-platform/agent-memory/index.mdx +++ b/src/content/docs/agent-platform/agent-memory/index.mdx @@ -80,6 +80,13 @@ When an agent starts a task, Oz searches the stores the agent can access for rel Attach stores to agents with read-only or read-write access. Each attachment includes per-store instructions that tell the agent how and when to use the store. For example, use instructions like "Reference this store for team naming conventions" or "Write a new memory after each successful deployment." Instructions are required on every attachment so the agent knows the purpose of each store. +## Coming soon + +These capabilities aren't part of the research preview yet, but they're on the way: + +* **Programmatic API access** - Read and manage memories and stores through the [Oz API](/reference/api-and-sdk/), in addition to managing them in the Oz web app. +* **Self-hosting support** - Run Agent Memory on a [self-hosted Oz](/agent-platform/cloud-agents/self-hosting/) instance to meet security, privacy, and compliance requirements. + ## Join the waitlist Agent Memory is rolling out to design partner teams during research preview. [Join the waitlist](https://www.warp.dev/oz/agent-memory#waitlist) to request access.