Compounding Memory

Ask your agent about a place it’s been helping you think about for months. In most systems, it answers by pulling twenty different memory snippets and summarizing them on the fly — new summary every time, never the same twice.

With Compounding Memory, the agent maintains a real page about that place. You mention Austin over a hundred chats and trips; the agent writes it all into one page titled “Austin, Texas” — with sections like an overview, your visits, and related activities. The page grows as you do. Over time, your agent builds a small encyclopedia about the things it knows you care about. Compounding memory is what turns the harness’s context-management layer from “raw recall” into a durable knowledge asset — the Reliability operating guarantee at memory scale (the answer to “what does this agent know about X” is a stable page, not a different summary each turn) and the Traceability guarantee in product form (every page is sourced; every fact in it traces back to the conversations and tool calls that wrote it).

What it feels like

Three things change when memory compounds into pages.

Your agent stops starting from scratch. The tenth conversation about a restaurant doesn’t retrace the first nine. The agent opens the page and reads what’s already there.

You can actually see what your agent knows. Pages are markdown. They have titles, sections, and links to each other. You can browse them. You can export them.

Context gets precise. When the agent needs to answer “what restaurants do I like in Lisbon?”, it reads one page instead of re-reading fifty memories.

The three kinds of pages

Every page is one of three types. The type shapes what kind of page it is.

Entity pages are about a specific thing — a person, a place, a company, a product, a project. “Austin, Texas.” “Taberna dos Mercadores.” “Marco’s Portugal Trip, 2026.”

Topic pages are collections under a theme. “Austin kids activities, April 2026.” “Portuguese restaurants I’ve tried.” “Open questions about the backend migration.”

Decision pages record choices — what was decided, why, and what followed. “Decision: use Hindsight as the primary memory engine.” “Decision: book the hotel in Bairro Alto instead of Chiado.”

What’s inside a page

Pages have four moving parts.

Sections are the body — markdown blocks with headings. Your agent patches one section at a time instead of rewriting the whole page. Add a new memory about a visit, only the “Visits” section updates.

Aliases are alternate names that all point to the same page. “Austin”, “Austin TX”, and “ATX” all resolve to “Austin, Texas.” When you mention any of them, the agent knows which page to open.

Links connect pages. If your “Taberna dos Mercadores” page keeps mentioning Lisbon, there’s a link between the two pages — so when you ask about Lisbon, Taberna shows up too.

Sources track where every section’s content came from. Each line in the “Visits” section was written from specific memories. You can always trace a claim back to the raw memory that produced it.

How a memory becomes a page

Compounding happens in the background. Here’s the shape of it without the plumbing:

You have a conversation. Something memorable happens.
Your agent saves a raw memory — a short text note.
A compile job notices new memories exist.
The leaf planner reads the new memories alongside the pages you already have, and decides: update an existing page? create a new one? hold this mention until you see it a few more times?
The section writer patches the markdown.
The aggregation pass then looks across your recently-changed pages and decides which hub topics should get rollup sections (your new Toronto restaurants joining the Toronto page’s Restaurants section) and which sections have become dense enough to promote into their own page (the Activities section on Austin earning its own Austin Activities page).
You can now read the page, search for it, or ask the agent about it.

Step 4 is deliberately conservative. Your agent won’t create a page the first time it sees a new name. It holds that name as an unresolved mention and waits until it sees the same thing a few more times before giving it a real page. This keeps the wiki from filling up with noise.

Step 6 is what makes memory compound instead of just piling up. As you mention Austin restaurants over and over, the Austin page’s rollup section grows. When it’s dense enough, it becomes its own page — and that page can then grow its own sections which eventually promote again. Recursive, grounded, self-organizing.

What your agent does vs. what you see

From the agent’s side, nothing changes about how it learns. It still captures memories the same way.

From your side, two new surfaces appear in the mobile app:

Search for a page — type “austin” and you get the Austin, Texas page back, with a note telling you which memory matched. The search is smart: it runs the same ranking your agent uses for recall, then shows you the pages those memories feed into.
Jump from a memory to its page — tap any memory in your timeline and see which pages that memory helped build.

Scope: one agent, one wiki

Right now, every page belongs to one agent. If you have two agents in the same workspace, they have independent wikis. Nothing bleeds across.

This is deliberate. Shared wikis across a team raise real questions — who sees what, what gets merged, what stays private — and we’d rather answer those questions explicitly than smuggle them in through a default. Team and company wikis will come later, with their own rules.

Compounding Memory: Pipeline — how a memory actually becomes a page
Compounding Memory: Pages — the full data model
Operating Compounding Memory — turning it on, troubleshooting
Compounding Memory (API) — GraphQL reference
Long-term Memory — the raw memory the wiki sits on top of

Under the hood

What’s really happening

Raw long-term memory (Hindsight or AgentCore) stays the canonical record. The wiki is a derived, rebuildable view — every page can be reconstructed by replaying the compile pipeline over the same memory records.

Where scope lives

Every wiki_* table row carries both tenant_id and owner_id, both NOT NULL. The owner_id is the agent id. There’s no tenant-wide read path and no owner_id IS NULL escape hatch. Team and company scope are deferred to a future scope_type model.

Which adapter drives compiles

Only Hindsight implements the listRecordsUpdatedSince cursor method. Tenants on AgentCore Memory won’t run compiles in v1 — the enqueue path short-circuits with skipped_adapter.

Design intent references

.prds/compounding-memory-scoping.md — v1 scope authority
.prds/compounding-memory-implementation-plan.md — phased delivery plan
.prds/thinkwork-memory-compounding-pipeline-deep-dive.md — pipeline philosophy
.prds/compiled-memory-layer-engineering-prd.md — engineering architecture
.prds/compounding-memory-company-second-brain-prd.md — product framing