MCP agent memory

MCP agent memory your founder can actually see.

RAAV exposes product memory through MCP so agents read and update the same repository state. Founders see proposals, active lanes, and completed-run evidence in the console.

Join waitlist View install prompt

What RAAV gives agents

MCP agents read current product and work state through the same connection
The same context reads through CLI and MCP without re-explaining the product
Founders review proposals before they become shared truth
Swimlanes and audit make MCP-driven work watchable and supervisable

The problem

MCP lets an agent pull context from tools, but that context is invisible to the founder. Nobody can review what the agent believed, watch what it changed, or supervise whether it was verified.

The RAAV layer

MCP carries the request. RAAV supplies the record behind it: confirmed product facts, current work, ownership, proposals, and completed-run evidence. The CLI and the founder console read that same record.

MCP moves context. RAAV makes it reviewable.

The Model Context Protocol is a clean way for an agent to read and write structured context. But a protocol alone does not tell the founder what is confirmed, what changed, or what still needs sign-off. RAAV is the memory those MCP calls operate through.

A protocol is plumbing; memory is the product

MCP standardizes how an agent fetches context and calls tools. What it fetches still needs to be durable, reviewable product truth rather than an ephemeral blob assembled per session.

RAAV provides that durable memory. The agent reads the Product Handbook, task state, claims, and lanes over MCP, and writes proposals and submits back through the same interface.

Structured context packs available over MCP and CLI
Proposal-first writes so MCP tools cannot silently rewrite truth
Memory candidates queued for founder review

MCP writes should still pass through review

When an agent updates context over MCP, the founder should be able to see it as a proposal, not a fait accompli. RAAV separates confirmed facts from inferred assumptions.

The protocol can carry the proposal, but the founder still decides whether it becomes product truth.

Confirmed vs inferred memory is explicit
Proposals wait for founder confirmation
Durable memory candidates before facts become permanent

A tool call should leave a visible record

Claims make MCP-driven edits visible before they collide. Each submit adds its verification and risk to a history the founder can read.

The protocol carries the bytes; RAAV makes the collaboration legible.

Claims and lanes over the same MCP surface
Verification recorded on submit
Audit export for founder review and handoff

How the agent loop works

RAAV does not replace your coding agent. It gives the agent a durable operating system for product truth, task ownership, and proof.

Connect

Point your MCP client at RAAV so the agent reads repo-local product memory.

Read

The agent pulls a context pack, active tasks, claims, and lanes over MCP.

Write

The agent proposes changes and submits verification instead of rewriting truth.

Review

The founder confirms proposals and supervises via the audit trail.

Wire RAAV into your MCP client

Ask your coding agent to install RAAV and expose its memory over MCP. The agent then starts each session from the ledger instead of a cold prompt.

Paste this into your coding agent

Install RAAV in this repo and expose it over MCP. Read the Product Handbook and next task through MCP before editing, claim files, then submit verification and memory candidates when done.

The MCP tools expose recorded project state; they do not add a second model to the agent loop.

Why this is different

Most tools either write code or track human tickets. RAAV sits between the founder and the coding agents as shared product memory, coordination, and audit.

Works through both CLI and MCP-style workflows

The connected agent supplies the reasoning; RAAV stores structured state

Founder testing starts with the €10 weekly Trial before wider checkout opens

Raw MCP context vs MCP memory you can supervise

Durability

Context is assembled per session and disappears afterward.

Product truth persists in a repo-local ledger the agent reads over MCP.

Review

MCP writes can change context with no founder visibility.

Writes become proposals and memory candidates for review.

Supervise

No record of what was verified after an MCP-driven run.

Submits record verification and risk into an audit trail.

FAQ

MCP users usually ask how RAAV fits alongside the protocol and whether it adds another model.

Does RAAV replace MCP?

No. MCP is the transport; RAAV is the durable, reviewable memory the agent reads and writes over MCP. They are complementary.

Does RAAV run its own model?

No. Your connected agent supplies the reasoning. RAAV stores the product state and exposes it through the CLI, MCP tools, and founder console.

Is RAAV a coding agent?

No. The coding still happens in Codex, Claude Code, Cursor, or another connected agent. RAAV exposes project state and work records over CLI and MCP.

What does it cost?

The Trial is €10 per week. Solo adds project capacity and longer history; Team adds a shared workspace. For now, plans are assigned through the founder testing waitlist.

Related RAAV workflows

Product memory for coding agents Claude Code memory Codex project memory