MMW

Managed memory and MCP gateway for AI agents

Visit Website
August 21, 2026 I built MMW because agent memory became impossible to audit

I started working on MMW after running into a simple problem: an AI agent could remember a fact, but I could not reliably answer where that fact came from, which workspace owned it,

whether the source had changed, or whether deletion had actually removed it.

That is manageable in a demo. It becomes a serious problem when an agent runs for weeks, works across projects, or shares knowledge with other agents.

MMW stands for Managed Memory Workspace. It gives AI agents a separate memory control layer through the Model Context Protocol (MCP).

The basic loop is intentionally small:

remember -> search -> validate -> forget

A stored record can include its source ID, hash and revision, confidence, and a state such as verified, unverified, stale, or conflict. Records are scoped by tenant, project, and

workspace. The goal is to make memory inspectable and portable instead of leaving it as anonymous text in a vector store.

I have also added an MCP Gateway to the pilot. An MCP client connects to one project endpoint and receives native MMW memory tools plus approved downstream tools. The first real connector

is GitHub read-only. Its token stays server-side, while the client sees three namespaced tools with a fixed allowlist.

The Free pilot currently supports one project and one active downstream MCP connection. It applies server-side limits and records audit metadata such as tool identity, status, timing, and

response size. It does not copy downstream arguments or response bodies into the audit log.

The current staging release has passed a disposable public lifecycle covering signup, Free activation without a card, one-time credential reveal, project scope, MCP tool discovery, a

namespaced downstream call, audit, disconnect, and cleanup. A separate staging check completed a real read-only call through the hosted GitHub MCP connector.

MMW is a working staging pilot, not a production SaaS. It has no production SLA, confirmed revenue, or claimed customers. The repository is private for now, and the pilot should only use

synthetic or non-sensitive data.

I am looking for a small number of design partners who already build AI agents or MCP integrations. The useful test is one concrete workflow where memory currently becomes stale, loses its

source, crosses the wrong boundary, or cannot be exported and deleted cleanly.

The pilot is free and onboarding is manual. I am looking for direct technical feedback, not signup numbers.

Product: https://mmw-staging.grifun.ru/

Design-partner preview: https://mmw-staging.grifun.ru/design-partners/

If you are building an agent today, what is the most painful memory failure in your workflow?

1 Comment

  1. 1

    The strongest part is making agent memory auditable rather than simply persistent. Source, ownership, revision, state, and deletion are much more consequential once memory crosses projects or survives for weeks.

About

AI agents can remember information, but teams often cannot see where that memory came from, which workspace owns it, whether it is still current, or whether it was actually deleted. I started MMW to make agent memory