Living Memory Launcher

Ask the agent you already use to open a shared memory room — and the page does it. Living Memory exposes WebMCP tools in the browser, so a real room is minted for you. No signup, no server setup.

Comment

Inspiration

I kept running into the same problem while working with AI agents: the work lived longer than the session.

One agent would run out of context. Another would hit a quota. Sometimes I needed to move to a different agent simply because it had the right tools. Every time, I became the bridge — explaining what happened, what we had already tried, what we decided, and what still needed to be done.

Eventually I started asking a different question: why am I moving the project’s history between agents? Why can’t the agents come to a place where that history already lives?

That question became Living Memory.

The timing of this submission made the idea unusually literal. While preparing it, Codex ran out of quota. Claude arrived afterward, recalled the project history from our Living Memory world, and continued the work. The agent changed. The work did not restart.

WebMCP made the next step obvious: if agents can arrive at a website and discover what they can do there, then Living Memory should not only be a place agents can remember together. The front door itself should be agent-native.

What it does

Living Memory is a place, not a database. A Room is small, shared and temporary; a World is durable. Humans and AI agents both enter, act, and leave traces — decisions, promises, what was already tried and ruled out — and whoever arrives next can read them. Files and git show the current state of the code. They cannot show why.

The WebMCP part is the front door. The Living Memory page itself speaks WebMCP: it registers browser-side tools on document.modelContext, so the agent already sitting in the visitor's browser can call create_free_room and mint a real, working Living Memory room for that person, on the spot. No signup, no API key, no server-to-server integration, no copy-pasting a config file.

The moment the agent's tool call succeeds, the page hero updates live to show the room the agent just made — you watch your own agent open the door.

And what it mints is not a demo object. It is a real MCP endpoint (stateless streamable HTTP) with memory_add, memory_search, handoff_post and handoff_read, good for 21 days, reachable from ChatGPT, Claude, Codex, or anything else that speaks MCP. The agent that created it is not the only agent that can use it.

Why this has to be WebMCP, and not a server integration

  1. The visitor has no account yet. A server integration presupposes an identity, credentials and an OAuth dance. WebMCP lets the page hand a capability to whatever agent is standing in front of it, before any of that exists. Onboarding is the tool call.
  2. The grant belongs to the browser session. The room is minted for the person at the page, and the page's own UI reflects it immediately through the same event the tool fired. A server integration would mint into an account and leave the human watching a page that knows nothing about it.
  3. Discovery beats configuration. Adding an MCP server today means editing JSON in a client you already trust. WebMCP inverts it: you visit a URL, and your agent finds out what this place can do by asking the place.
  4. The handoff is the product. Living Memory exists so a different agent, later, can pick up where this one left off. A tool that only the site's own backend could call would defeat the point.

How we built it

  • The front desk (this repo, this URL) — SvelteKit 5 and Tailwind 4 on Cloudflare Workers through adapter-cloudflare, deployed as the worker living-memory-webmcp-demo on living-memory.app. The WebMCP tool is registered on document.modelContext and shares state with the page's own Room dialog — which is why a room the agent creates appears in the human's UI in the same instant, not after a refresh.
  • Rooms and worlds — a stateless streamable-HTTP MCP server on Workers. One unauthenticated POST mints a 21-day room; owned, persistent worlds sit behind OAuth with per-world membership. The browser tool calls the same public endpoint any other MCP client would: there is no privileged path for our own page.
  • Discovery — a Chrome origin-trial token served with the page, so a judge on stock Chrome 149+ gets the WebMCP API without touching chrome://flags.
  • The rest of the rail — Stytch for sign-in, PostHog for product analytics, Vitest and Playwright for unit and end-to-end tests, with typecheck and lint as merge gates.

Challenges we ran into

  • WebMCP is origin-bound and behind an origin trial. The token is registered per origin, so every additional hostname is another registration — a detail that quietly decides which URL a judge should open.
  • Silent success is the real enemy. An agent that never calls your tool still answers the question, and the demo looks like it worked. We had to instrument the tool-call path first, or spend midnight debugging the wrong layer.
  • Cloudflare Bot Fight Mode was 403-ing the MCP endpoint — and on the free plan you cannot skip it with a WAF rule, because it does not run on the Ruleset Engine. Any rule we wrote would have looked like a fix and done nothing.
  • Local DNS negative-cached the new domain, so a deploy that was live for the entire internet looked dead from our own laptop. Indistinguishable from a broken deploy if you only check from where you are standing.
  • Free rooms have honest limits (about five per IP per day) which is a real failure mode at a demo or a meetup, where everyone shares one NAT address.

Accomplishments that we are proud of

  • Verified end-to-end on a real browser, not on a mock: the tool visible in document.modelContext.getTools(), executeTool minting a real room, the page hero updating in the same second, and the minted room answering MCP initialize as living-memory.
  • It is a running product rather than a hackathon prop — live rooms, live checkout, real users' agents in real worlds.
  • This submission was written by an agent that recalled the project's own history — decisions, deadlines, past failures — out of a Living Memory world. The product wrote its own Devpost page from memory.

What we learned

  • Never let "I could not observe" render the same as "there was nothing to observe." It is the same failure in a browser tool call, a search result and a CI check.
  • Fail closed, loudly. Failing open is how a broken demo looks fine.
  • Every arrival is a first arrival. An agent entering a room knows nothing; the environment has to brief it, and that is a product requirement, not a nicety.

What is next for Living Memory Launcher

  • Multi-world primitives: world creation, human membership, grant and revoke, per-world ownership.
  • Explore as doors rather than documentation — prepared public rooms you enter to understand the thing, instead of reading about it.
  • More WebMCP surface than the front door: let a visiting agent enter, read and continue a room straight from the page.

Built With

  • chrome
  • cloudflare-workers
  • model-context-protocol
  • playwright
  • posthog
  • revenuecat
  • stripe
  • stytch
  • svelte
  • sveltekit
  • tailwindcss
  • typescript
  • vite
  • vitest
  • webmcp
  • wrangler
Share this project:

Updates

Submission history