docs: align Agent Memory page with current research preview capabilities#227
Conversation
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 <oz-agent@warp.dev>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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 <oz-agent@warp.dev>
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This PR narrows the Agent Memory research preview page to avoid unsupported claims around default per-agent stores, public API CRUD access, retrieval traceability, and self-hosting. I reviewed the attached diff against the documentation review guidance and found no commentable correctness, structure, link, or security issues.
Concerns
- No blocking concerns found. The PR removes links rather than adding new ones, and no approved spec context was available for implementation drift checks.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
szgupta
left a comment
There was a problem hiding this comment.
@coolcom200 mind also doing a pass here? especially since auto-memory is gonna be enabled soon
| * **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. |
There was a problem hiding this comment.
The stores are agent-scoped but shareable across agents. There isn't a concept of sharing a store across a team. That's done by giving it to an agent that the whole team can use.
| * **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. |
Read through the docs they seem pretty clear! I did just merge in Auto-memory which will have a memory store created by default for newly create Agents, however, on the create page we have a toggle so any customer can choose if they wish to create a new agent owned memory store or to attach existing memory stores. Not sure what the best way to phrase this in the docs might be but we should call that out and maybe define what Auto-memory is. |
…ry 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 <oz-agent@warp.dev>
… 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 <oz-agent@warp.dev>
coolcom200
left a comment
There was a problem hiding this comment.
Thank you for drafting these docs!
|
|
||
| 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. |
There was a problem hiding this comment.
Should we rename this if it will cause confusion?
|
|
||
| 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. |
There was a problem hiding this comment.
Thoughts on: "automatic memory creation from conversions"
Summary
Aligns the Agent Memory (Research Preview) page with what customers can actually use today, per feedback from Trevor Nederlof. Some future-state features had made it into the docs from marketing materials; this removes or softens those claims so research preview customers aren't set up with wrong expectations. They can be re-added once they're actually supported / publicly documented.
A follow-up review pass verified the remaining claims on the page against the warp-server implementation (memory models, public API handlers, synthesis pipeline) and fixed three more inaccuracies.
Changes
src/content/docs/agent-platform/agent-memory/index.mdx
Original feedback items:
memory_storesattachment refs on agents/runs are).Memory.Source/SourceID). The Auditability bullet (memory change history) is unchanged and matches the immutableMemoryVersionmodel.Review-pass fixes (verified against warp-server):
Additional context
style_lint --changedclean, internal link checker clean,npm run buildpasses.Conversation: https://staging.warp.dev/conversation/9ddbc8fc-0afd-47fb-b784-71e34ae08845
Run: https://oz.staging.warp.dev/runs/019ebdd2-c6bf-7dd8-ad27-7537cfbfef4a
This PR was generated with Oz.
Co-Authored-By: Oz oz-agent@warp.dev