Skip to content

docs: align Agent Memory page with current research preview capabilities#227

Merged
hongyi-chen merged 8 commits into
mainfrom
agent-memory-docs-accuracy
Jun 17, 2026
Merged

docs: align Agent Memory page with current research preview capabilities#227
hongyi-chen merged 8 commits into
mainfrom
agent-memory-docs-accuracy

Conversation

@hongyi-chen

@hongyi-chen hongyi-chen commented Jun 12, 2026

Copy link
Copy Markdown
Collaborator

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:

  • Per-agent default stores: Removed "By default, each agent has its own memory store" from the Key features bullet and the Memory stores section. Stores are now described as attachable to agents and shareable, without claiming a per-agent default.
  • API accessibility: Removed the "Fully accessible via API" key feature bullet and the "Oz API and SDK" related-pages link. The store/memory CRUD endpoints aren't in the published OpenAPI spec (only memory_stores attachment refs on agents/runs are).
  • Traceability: Softened from "Memory retrievals are recorded so teams can inspect which memories contributed to a run's context" to memory provenance — teams can trace a memory back to its source, which matches the implementation (Memory.Source/SourceID). The Auditability bullet (memory change history) is unchanged and matches the immutable MemoryVersion model.
  • Self-hosting: Removed self-hosting claims throughout — the Key features bullet, the self-hosted Oz mention in "Where Agent Memory runs", and the self-hosting related-pages link. (Code comments confirm self-hosted memories are future work.)

Review-pass fixes (verified against warp-server):

  • "Named collection": Stores have a UID and optional description, not a name — dropped "named".
  • "Its own store" example: Only team-owned stores can be attached to agents via the public API, so the example now says a code review agent "can use a dedicated store" instead of "its own store", and multi-store usage is scoped to teams (users have one live store).
  • Instructions optionality: The API requires non-empty instructions on every attachment, so removed "Without instructions, the agent can access the store but won't know when to read from or write to it."

Additional context

  • Slack feedback thread from Trevor Nederlof (June 12).
  • Validation: style_lint --changed clean, internal link checker clean, npm run build passes.

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

hongyi-chen and others added 2 commits June 12, 2026 21:55
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>
@cla-bot cla-bot Bot added the cla-signed label Jun 12, 2026
@vercel

vercel Bot commented Jun 12, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
docs Ready Ready Preview, Comment Jun 16, 2026 10:28pm

Request Review

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>
@hongyi-chen hongyi-chen marked this pull request as ready for review June 12, 2026 22:59
@oz-for-oss

oz-for-oss Bot commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

@hongyi-chen

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 /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

@oz-for-oss oz-for-oss Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 szgupta left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

coming soon?

* **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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

coming soon?

@coolcom200

Copy link
Copy Markdown
Contributor

@coolcom200 mind also doing a pass here? especially since auto-memory is gonna be enabled soon

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 coolcom200 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts on: "automatic memory creation from conversions"

@hongyi-chen hongyi-chen merged commit aeb24e5 into main Jun 17, 2026
8 checks passed
@hongyi-chen hongyi-chen deleted the agent-memory-docs-accuracy branch June 17, 2026 02:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants