Skip to content

Commit 4f73acc

Browse files
docs(agent-platform): add Agent Memory research-preview pages (#86)
* docs(agent-platform): add Agent Memory research-preview pages Add overview, memory-stores, self-hosted-memory, and api pages under agent-platform/capabilities/agent-memory/. List the feature on the capabilities index and add a Suggested Skills from Agent Memory note to the skills page. The new pages are scoped to the agent-platform topic but are not yet wired into src/sidebar.ts; the cross-cutting sidebar PR will add the entries so the build resolves the topic association. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): scrub internals, downsize API page, tighten tone Address reviewer feedback and Slack-thread guidance on the Agent Memory research-preview pages. - Overview: narrow the API capability bullet to user-owned store creation (team-owned creation is in the Warp app only), drop the 'harness-support endpoint' internal reference, drop the service-account-granted-stores phrasing, trim the data flywheel section, and tighten the frontmatter description to fit the 50-160 char SEO range. - Memory stores: tighter description, generalize API references away from raw HTTP method/path callouts, drop schema field name leaks ('memory_stores' as wire field) in favor of conceptual prose, polish tone. - Self-hosted memory: present as forward-looking direction for the research preview, drop the specific Postgres/Turbopuffer/ Voyage AI vendor stack from the reference adapter section in favor of abstract relational + vector + embedding language. - API: downsize to a research-preview stub. Drop endpoint paths, request/response schemas, and HTTP method signatures. Keep authentication, capability surface at category level, attachment behavior rules, validation error patterns, and the design-partner contact path. - Skills: tighten Suggested Skills from Agent Memory section to honest, forward-looking direction-of-travel wording. - Capabilities overview: tighten the Agent Memory entry copy. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): drop remaining internal-implementation details Second pass of trimming on the Agent Memory research-preview pages, following the same direction as 1564a8d. - index.mdx: collapse the two-stage extraction/planning description of consolidation into a single user-facing paragraph; drop the internal facts/learnings/outcomes taxonomy; drop the reranker mention from the retrieval bullet; tighten the matching key-features and research-preview bullets for consistency. - memory-stores.mdx: remove the wire-format Update semantics section (omit / empty / non-empty) and link out to the API page instead; replace the dependency-order permanent-deletion sentence with a single user-facing line; drop the 409 Conflict HTTP status code while keeping the rule and remediation. - self-hosted-memory.mdx: replace the named interface-method list with a one-paragraph capability summary; drop the embedding-pipeline phrasing on both the in-scope and reference-adapter sections; drop the extraction/planning two-stage framing. - api.mdx: rename 'Validation errors' to 'Common rejection reasons' and drop the 400 invalid_request / 409 Conflict codes while keeping the rejection reasons; soften the wire-format mention for the identity-attachment endpoint. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): use canonical "agent identity" terminology Replace "named agent identity/identities" (and shorthand "named identity" forms) with "agent identity/identities" throughout the Agent Memory pages to align with the docs-wide canonical term. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): consolidate research-preview docs into a single page Replace the four-page Agent Memory subsection with a single research-preview overview page. The deleted pages (memory-stores, self-hosted-memory, api) were never published and overcommitted on behavior that's still in design. - Rewrite agent-memory/index.mdx as a tight overview: research-preview callout with waitlist CTA, what's available today, what's not yet available, how to get involved, related pages. - Tighten the "Suggested Skills from Agent Memory" subsection on skills.mdx to a single forward-looking paragraph without procedural claims. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): audit polish pass on the consolidated research-preview page Editorial copy pass on top of 2ea77ff. No structural or scope changes; no new claims, no new links. agent-memory/index.mdx: - Drop slight anthropomorphism in opener ("no recollection" -> "without context"). - Replace "verbose transcript dump" with neutral "the full conversation transcript." - Reorder the personal-memory bullet so the actor (Oz) leads and the harness clause doesn't bury the punchline. - Fix awkward SVO order on self-hosted bullet. - Replace vague "focused on the personal store" with precise "only reads from the personal store." - Tighten the two related-pages descriptions. skills.mdx: - Tighten the Suggested Skills from Agent Memory paragraph: drop the doubled "Agent Memory" reference, replace "is being explored" with "is in design," and remove the awkward "no concrete behavior" hedge. Validation: - style_lint --changed: one known false positive on the Suggested Skills header (Skills and Agent Memory are proper feature names per AGENTS.md). - check_links --internal-only: 0 broken links across 318 files and 2391 links. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): rewrite as unified SEO/waitlist page Drops the "What's available today" / "What's not yet available" split in favor of a single capability narrative. The page is now a marketing-pitched, SEO-oriented overview that walks a prospective user through the value of Agent Memory and pushes toward the waitlist three times (top caution, hero closer, dedicated Get early access section). Structural changes: - Tightened frontmatter description (132 chars, in SEO range) leading with the primary keyword "agent memory" and the value proposition. - Hero is now two short paragraphs that motivate the problem (cold runs) and introduce the product, ending with a request-early-access link. - Five keyword-rich H2 sections describe the capability surface in one unified narrative: Persistent memory across runs, Cross-harness retrieval, Automatic consolidation, Personal and team memory stores, Self-hosted memory backends. No shipped-vs-roadmap hedging in the body; the research-preview caution at the top covers "behavior may change." - New "What Agent Memory unlocks" section with three use-case vignettes (debugging that resumes; repeated maintenance agents that learn the codebase; team-shared knowledge) that give prospects concrete reasons to want it and add SEO surface area. - New "Get early access" section replaces the old "How to get involved." - Switched the Agent identities related-pages link from the absolute docs.warp.dev URL to a relative path, now that PR #88 has merged into the gating branch and been forward-merged into this branch. Validation: - style_lint --changed: 0 new issues on the rewritten page (the existing known false positive on skills.mdx:414 Suggested Skills header is untouched). - check_links --internal-only: 0 broken links across 319 files and 2,421 internal links. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): polish hero opener for clarity Drop the self-referential "by default" qualifier (the non-default mode it implied is Agent Memory itself, making the phrase quietly circular). Make the cold-start problem more concrete by spelling out that prior runs' learnings are lost \u2014 strengthens the value framing the page is trying to build for the waitlist CTA. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): consolidate PR #95 content, move to top-level Memory section Major restructure of the Agent Memory docs to address user feedback: 1. Promote Agent Memory to its own top-level section in the sidebar. New 'Memory (Research Preview)' group sits inside the Agents topic between Getting started and Warp Agents for top-of-list visibility. 2. Move the page from agent-platform/capabilities/agent-memory/ to agent-platform/agent-memory/ to match the new section's IA. The '/agent-platform/capabilities/agent-memory' URL now redirects to '/agent-platform/agent-memory/' via vercel.json. 3. Add '(Research Preview)' marker to the sidebar label, matching the page title and the existing Settings Sync (Beta) precedent. 4. Replace 'workspace' with 'team' in user-facing copy. The implementation-layer WORKSPACE enum is internal and unaffected. 5. Consolidate PR #95 (hyc/memory-waitlist) content into the page. PR #95 had been opened separately as a marketing/waitlist rewrite from another conversation. Taking its richer body (8 capability bullets, dedicated sections for Personal/team stores, Automatic memory from conversations with Sparse/Reasoned/Reversible sub-bullets, How agents retrieve memories with the Vector+BM25+Reranking pipeline, Attaching memory to agents covering identity-level and run-level attachments, and Built for teams), stronger CTAs (bold-link waitlist CTA after hero + 'Ready to give your agents memory?' closer), and richer 5-link related pages. Restores the research-preview caution callout that PR #95 had dropped, keeps the (Research Preview) title, and uses 'team' throughout. PR #95 will be closed in a follow-up. 6. Use generic 'agents' / 'your agents' / 'Warp agents' framing throughout. Memory is gated to cloud agents today but will work for local agents going forward, so the docs don't specify cloud vs local. The research-preview caution carries any 'behavior may change before GA' hedge. 7. Capability claims (deletion safety, per-store instructions, versioned history, hybrid semantic+keyword search) all match the QUALITY-585 and QUALITY-536 specs. Files touched: - src/content/docs/agent-platform/agent-memory/index.mdx (new) - src/content/docs/agent-platform/capabilities/agent-memory/index.mdx (deleted) - src/content/docs/agent-platform/capabilities/index.mdx (Agent Memory bullet removed) - src/content/docs/agent-platform/capabilities/skills.mdx (link URL updated) - src/sidebar.ts (new Memory group) - vercel.json (old URL redirect) Validation: - style_lint --changed: only the known pre-existing false positive on skills.mdx:414 Suggested Skills from Agent Memory header (both 'Skills' and 'Agent Memory' are proper feature names per AGENTS.md). - check_links --internal-only: 0 broken across 319 files and 2,422 internal links. New URL resolves cleanly. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): address Suraj's review feedback - Drop vector/keyword search and versioned history bullets; remove the 'recorded reason for every change' / 'Reasoned' bullet so the page stays high level for waitlist-phase customers (Slack feedback + pending inline comment). - Replace 'Warp agents' wording and explicitly call out cross-harness support (Warp Agent, Claude Code, Codex, Gemini) in the description and intro paragraph (pending inline comments on multi-harness and 'Warp agents'). - Reframe automatic-memory and bullets section around 'learning over time' instead of one-shot extraction (pending inline comment). - Rename 'Personal and team memory stores' to 'Memory stores', explain per-agent scoping with cross-agent sharing, and add the code-review + Sentry triage repo-store example (pending inline comment). - Replace 'runs a memory synthesis pass that extracts' with 'extracts' (pending inline comment). - Slim 'How agents retrieve memories' to 'How agents use memory' and note that agents can retrieve memories on demand throughout a conversation when they decide it's the right thing to do (pending inline comment + Slack 'how' removal). - Collapse 'Attaching memory to your agents' to one paragraph and remove the redundant 'Built for teams' section to keep the page scannable and 'what/why'-focused. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): lead with async + Oz-as-the-layer framing Follow-up to Suraj's feedback on PR #86. Verbiage inspiration from the Claude Managed Agents memory post. - Frontmatter description and hero paragraph now lead with the value prop ('Your agents should learn across every conversation, every harness, every run') instead of a descriptive opener, and explicitly position Warp as the platform the customer already uses to run their agents. - Hero paragraph + a new 'Async by design' bullet + a new sentence in each of 'Automatic memory from conversations' and 'How agents use memory' make it clear that memory creation and retrieval happen in the background. Agents never burn tokens or attention on memory work during a run. - 'Cross-harness persistence' is promoted to the first 'What you get' bullet and reframed as 'One memory layer for every agent in Warp'. Dropped the now-redundant 'Durable knowledge across conversations' bullet (the intro already says it). - New 'Built on the layer your agents already live on' subsection drives the Oz-as-the-layer pitch home: Warp Agent locally, Oz cloud agents in the background, and Claude Code/Codex/Gemini all go through the same platform, so memory is a free byproduct rather than new infrastructure. - Final CTA sharpened to 'Your agents already live on Warp. Give them a memory that lives there too.' Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): polish pass - Trimmed frontmatter description so it fits the ~50-160 char target and reads as a standalone summary. - Split the long hero paragraph into shorter sentences so each beat (value prop, harness list, no infra, async, each run) lands on its own. Fixed the 'memory ... memory' repetition by referring to creation and retrieval with 'they'. - Reworded the 'Built on the layer your agents already live on' paragraph: opens with 'Warp is already the platform where your agents run', drops the dangling 'through the same platform' clause, and avoids the 'layer ... layer too' echo by saying 'Agent Memory turns that same platform into a memory layer'. - Used 'Memory creation' (instead of 'Synthesis') in the 'Automatic memory from conversations' paragraph so the async terminology matches the 'Async by design' bullet. - Switched the 'Sparse by design' / 'Learns over time' mini-headlines to the bold-term + em-dash + explanation pattern used by the rest of the page. - Tightened the 'Per-agent access control and instructions' bullet. - Replaced the awkward 'watch what they learn today make them sharper tomorrow' construction in the final CTA with 'so what they learn today makes them sharper tomorrow'. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): de-marketing pass, dev-doc tone Strip marketing-style phrasing and rewrite the page in the descriptive, factual tone used by the rest of the agent-platform capability pages (skills.mdx, codebase-context.mdx, cloud-agents/overview.mdx). - Description and intro now lead with what Agent Memory is, not a rule-of-three pitch. Dropped 'Your agents should learn across every conversation, every harness, every run' and 'Agent Memory makes that real.' Replaced with: 'Agent Memory is a persistent memory layer that lives on Warp and is shared across every supported agent harness...' - Renamed 'What you get with Agent Memory' to 'Key features' (matches skills.mdx). - Renamed 'Built on the layer your agents already live on' to 'Where Agent Memory runs' and rewrote it as factual coverage info: storage + creation + retrieval are all hosted on Warp infrastructure, with an explicit bulleted list of the agent types covered (local Warp Agent, Oz cloud agents, third-party harnesses). - Tightened bullets to bold-term + em-dash + plain explanation pattern. Dropped 'draws from the same well of knowledge', 'any harness you reach for next', 'leaves your team a little smarter than the last', and 'Instructions matter: they're the difference between an agent that has memory and an agent that knows what to remember and when.' - Tightened the 'How agents use memory' paragraph and changed 'whenever they decide it's the right thing to do' to 'when they determine it's relevant' (preserves the intent of Suraj's earlier feedback without the colloquial phrasing). - Replaced the 'Ready to give your agents memory?' CTA with a plain 'Join the waitlist' section, and switched the in-body waitlist link from bold + arrow to a plain markdown link. All seven of Suraj's earlier pending comments are still addressed (multi-harness, harness-agnostic wording, learning over time, no 'reason' mentions, Memory stores rename + use case, 'Warp extracts', and on-demand mid-conversation retrieval). Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): address all of Suraj's review comments Addresses every inline comment from szgupta on PR #86: - Comment 3263750377 (lines 5-6, description, 'cross-harness covers it'): dropped the trailing 'that learns over time' clause from the description. - Comment 3263750945 (line 14, 's/Warp/Oz'): the platform that hosts Agent Memory is Oz. Replaced Warp -> Oz in the intro and anywhere else the page used Warp as the platform noun ('Where Agent Memory runs', the Oz API bullet, 'Oz extracts...', 'Oz searches...'). Kept Warp where it means the product (Warp Agent harness name, Warp client, warp.dev URLs). - Comment 3263752096 (line 14 reply, 'Gemini isn't officially supported in Oz yet'): removed every Gemini mention from the page (description, intro, Cross-harness bullet, 'Where Agent Memory runs' bullet). - Comment 3263755700 (line 25, 'focus more on sharing'): replaced the 'Personal and team stores' Key features bullet with 'Agent-scoped, shareable stores' that leads with default agent-scoping and cross-agent sharing. The Memory stores section now also notes that stores can be shared 'across teammates when knowledge should travel with the team'. - Comment 3263756525 (line 27, 'seems irrelevant?'): dropped the Deletion safety Key features bullet entirely. - Comment 3263761292 (line 20, suggested 5 new bullets): added Both local and cloud agents, Fully accessible via API, Traceability, Auditability, and Self-hostable to Key features. - Comment 3263763038 (line 31, 'we should mention self-hosted'): the 'Where Agent Memory runs' section now says memory runs on the same Oz instance that hosts your agents - Warp-hosted Oz by default, or a customer-hosted Oz instance for teams that need to keep memory inside their own perimeter. Paired with the new Self-hostable bullet in Key features. - Comment 3263765714 (line 35, '3P harnesses are Oz-cloud-only for now'): scoped the third-party harnesses bullet to 'Third-party harnesses running as Oz cloud agents' and added an explicit '(Running third-party harnesses locally isn't supported during the research preview.)' qualifier. Same scope is mirrored in the Cross-harness Key features bullet. - Comment 3263767235 (lines 52-53, replace Sparse/Learns with 'evolves+resolves contradictions'): replaced the two bullets with a single 'Memories evolve over time' bullet that says agents update and supersede their own memories as new information arrives, including to resolve contradictions with prior memories. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): polish pass after review-comment rewrite - Intro: separated the 'regardless of which harness' clause with an em-dash so the second sentence parses more cleanly. - 'Both local and cloud agents' bullet: 'Works for' -> 'Supports' for a slightly more formal verb. - Memory stores intro: replaced the em-dash construction with a comma so the two sharing scopes (across agents, across teammates) read as a single list, and tightened 'named container of memories' to 'named collection of memories'. - Attaching memory paragraph: 'free-form instruction string' -> 'per-store instructions', matching the terminology already used in the Key features bullet. No factual changes. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): make self-hosted explicit + small polish - 'Where Agent Memory runs' now calls out self-hosting by name: 'either Warp-hosted Oz (the default) or a self-hosted Oz instance that your team operates inside its own perimeter', replacing the previous 'customer-hosted Oz instance' phrasing. - 'Automatic memory from conversations': 'from what happened' -> 'from the transcript'; 'during the run that produced it' -> 'during that run'. - 'Attaching memory to your agents': 'Each attachment carries per-store instructions' -> 'Each attachment includes per-store instructions'; cleaned up the 'Without instructions' sentence to 'the agent can access the store but won't know when to read from or write to it'. Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): cross-link self-hosting + Oz API, tighten store bullet The page mentions self-hosting and the Oz API prominently in Key features and 'Where Agent Memory runs', but those concepts weren't linked to the dedicated reference pages. Add the links so readers can follow up: - Inline-link 'Oz API' in the 'Fully accessible via API' bullet to /reference/api-and-sdk/. - Inline-link 'self-hosted Oz' in both the 'Self-hostable' bullet and the 'Where Agent Memory runs' paragraph to /agent-platform/cloud-agents/self-hosting/. - Inline-link 'Rules' and 'Codebase Context' in 'How agents use memory' (and capitalize 'rules' to match the feature name). - Add 'Self-hosting overview' and 'Oz API and SDK' to Related pages. Also tightened the 'Agent-scoped, shareable stores' bullet so its sharing phrasing varies slightly from the near-identical sentence in the Memory stores section ('shared across multiple agents, or across an entire team, when the same knowledge should travel with the work'). Co-Authored-By: Oz <oz-agent@warp.dev> * docs(agent-memory): final scan nits - 'Attaching memory': 'Each attachment includes per-store instructions' -> 'Each attachment can include per-store instructions'. Removes a small logical contradiction with the very next sentence, which treats instructions as optional ('Without instructions, the agent can access the store but won't know when to read from or write to it.'). - 'Team stores' bullet: replaced the coined adjective 'any team-authorized agent' with 'any agent the team authorizes', matching the active-voice phrasing used elsewhere on the page. Co-Authored-By: Oz <oz-agent@warp.dev> --------- Co-authored-by: Oz <oz-agent@warp.dev>
1 parent 726f592 commit 4f73acc

4 files changed

Lines changed: 94 additions & 0 deletions

File tree

Lines changed: 79 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
---
2+
title: Agent Memory (Research Preview)
3+
description: >-
4+
Agent Memory is a persistent, cross-harness memory layer for agents in
5+
Oz, including the Warp Agent, Claude Code, and Codex.
6+
sidebar:
7+
label: "Agent Memory (Research Preview)"
8+
---
9+
:::caution
10+
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.
11+
:::
12+
13+
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.
14+
15+
Memory creation and retrieval are asynchronous and run in the background, so they don't consume tokens or add latency to the active task.
16+
17+
[Join the Agent Memory waitlist](https://warp.dev/oz/agent-memory#waitlist)
18+
19+
## Key features
20+
21+
* **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 Oz cloud agents.
22+
* **Both local and cloud agents** — Supports interactive local agents in Warp and background Oz cloud agents.
23+
* **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.
24+
* **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.
25+
* **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.
26+
* **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.
27+
* **Fully accessible via API** — Memories and stores can be read, created, updated, and deleted through the [Oz API](/reference/api-and-sdk/).
28+
* **Traceability** — For any agent run, you can see which memories influenced it.
29+
* **Auditability** — Every change to a memory is recorded, so the full history of any memory can be inspected.
30+
* **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.
31+
32+
## Where Agent Memory runs
33+
34+
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:
35+
36+
* The local Warp Agent.
37+
* Oz cloud agents triggered from the CLI, web app, schedules, or integrations.
38+
* Third-party harnesses running as Oz cloud agents — Claude Code, Codex, and others as they're added. (Running third-party harnesses locally isn't supported during the research preview.)
39+
40+
Memory stays bound to its owner (a user or a team), independent of which harness reads or writes.
41+
42+
## Memory stores
43+
44+
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.
45+
46+
* **Personal stores** — Owned by a user. Hold preferences, working notes, and individual patterns.
47+
* **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.
48+
49+
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.
50+
51+
## Automatic memory from conversations
52+
53+
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.
54+
55+
* **Memories evolve over time** — Agents update and supersede their own memories as new information arrives, including to resolve contradictions with prior memories.
56+
57+
You can also explicitly ask an agent to remember something during a conversation, and it lands in the appropriate store.
58+
59+
## How agents use memory
60+
61+
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.
62+
63+
## Attaching memory to your agents
64+
65+
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.
66+
67+
## Join the waitlist
68+
69+
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.
70+
71+
## Related pages
72+
73+
* [Codebase Context](/agent-platform/capabilities/codebase-context/) — Let agents understand your codebase through semantic indexing.
74+
* [Rules](/agent-platform/capabilities/rules/) — Define global and project-level guidelines that shape agent behavior.
75+
* [Skills](/agent-platform/capabilities/skills/) — Reusable, scoped instructions that teach agents how to perform specific tasks.
76+
* [Agent profiles and permissions](/agent-platform/capabilities/agent-profiles-permissions/) — Control what permissions and autonomy agents have.
77+
* [Cloud agents overview](/agent-platform/cloud-agents/overview/) — Run background agents with team-wide observability.
78+
* [Self-hosting overview](/agent-platform/cloud-agents/self-hosting/) — Run Oz, and Agent Memory along with it, on your own infrastructure.
79+
* [Oz API and SDK](/reference/api-and-sdk/) — Read, create, update, and delete memories and stores programmatically.

src/content/docs/agent-platform/capabilities/skills.mdx

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -411,6 +411,10 @@ Warp maintains a public collection of ready-to-use skills in the [warpdotdev/oz-
411411

412412
These same skills also appear as suggested agents in the [Oz web app](/agent-platform/cloud-agents/oz-web-app/), where you can run them directly in the cloud.
413413

414+
## Suggested Skills from Agent Memory
415+
416+
Promoting recurring patterns from [Agent Memory](/agent-platform/agent-memory/) into reviewable skill drafts is in design as part of the research preview. See the Agent Memory page for current status.
417+
414418
## Invoking skills with a prompt
415419

416420
You can pass additional context or instructions to a skill when invoking it with a slash command.

src/sidebar.ts

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -246,6 +246,12 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [
246246
'agent-platform/getting-started/faqs',
247247
],
248248
},
249+
{
250+
label: 'Memory (Research Preview)',
251+
items: [
252+
{ slug: 'agent-platform/agent-memory', label: 'Agent Memory' },
253+
],
254+
},
249255
{
250256
label: 'Warp Agents',
251257
items: [

vercel.json

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9572,6 +9572,11 @@
95729572
"source": "/oz",
95739573
"destination": "/agent-platform/cloud-agents/overview/",
95749574
"statusCode": 308
9575+
},
9576+
{
9577+
"source": "/agent-platform/capabilities/agent-memory",
9578+
"destination": "/agent-platform/agent-memory/",
9579+
"statusCode": 308
95759580
}
95769581
]
95779582
}

0 commit comments

Comments
 (0)