I Tried to Add Memory to WebMCP. The Experiment Told Me Not To.

I had a problem that looked like memory.

I could work for hours with an agent on my laptop, move into the browser, and discover that the objective had survived—but the decisions, constraints, evidence, and next action had not. The new surface knew what I wanted in general. It did not always know what had already been ruled out, what was still unproven, or what should happen next.

My first idea was straightforward: perhaps WebMCP needed a compact continuity package.

I called it CCP—the Context Continuity Package. It would be small, origin-scoped, read-only, rejectable, and designed to carry only the state needed to resume a task. I imagined it as a bridge between Codex, ChatGPT in Chrome, Antigravity, and Edge.

Then I did the thing that changed the entire project: before proposing a new primitive, I read WebMCP as if I were preparing for surgery.

The result was not the victory I expected. It was more useful.

I learned that the continuity problem is real, that a CCP can reduce part of its visible cost, and that WebMCP is probably not the layer that should own agent memory.

This is the story of the experiment, the code, the failures, and the architectural boundary I found.

Why I chose WebMCP

I have followed WebMCP since its early development. For a long time, I watched the repository and its discussions more than I participated. I did not yet trust my understanding enough to enter a specification conversation with Chrome engineers.

Meanwhile, my own work kept returning to the same question: what makes an agentic system genuinely useful?

Swarm size is not enough. A hundred agents with poor tools can still fail in the same place. RAG, human-in-the-loop workflows, memory systems, and orchestration matter, but eventually an agent must act through the interfaces it is given. The quality of those interfaces determines what it can discover, what it must absorb, and what it can safely do.

That made WebMCP the right place to learn. It exposes structured page capabilities to agents. It sits close to the moment where intention becomes action.

But being close to a problem does not mean owning it.

The audit changed the question

I started with the question:

Where should CCP be placed inside WebMCP?

After auditing the repository, WebIDL, Bikeshed algorithms, lifecycle rules, origin boundaries, security notes, contribution history, and 247 GitHub objects, the question became:

Can the existing imperative WebMCP tool carry a rejectable continuity packet, and what defect—if any—would still belong to the platform?

That reformulation was decisive.

WebMCP exposes capabilities from a page. The browser mediates those capabilities. The agentic harness decides what the model sees, retains, compacts, or forgets. The product decides how conversations, sessions, telemetry, and model selection are presented.

CCP could travel through WebMCP without becoming WebMCP memory.

This boundary also corrected several security assumptions.

• readOnlyHint and untrustedContentHint are annotations, not enforcement.
• Same-origin limits scope, but it does not make content truthful or harmless.
• A digest proves that canonical bytes did not change; it does not prove that provenance is authentic.
• A tool visible in a browser is not necessarily discovered or invoked by the agentic product.
• CDP automation, DOM reading, and native WebMCP invocation are different evidence chains.

That last distinction became central to every test.

Building a packet the agent could refuse

The laboratory remained outside the upstream WebMCP checkout. I did not modify the specification repository.

The experimental contract, ccp.webmcp.experiment.v1, contained:

• an origin and task scope;
• declared producer, revision, creation time, and digest;
• objective, constraints, decisions, evidence references, completed work, blockers, and next actions;
• freshness and expiration state.

The initial limits were intentionally experimental: 8 KiB maximum, bounded arrays, and a 24-hour expiration window. The packet excluded transcripts, secrets, cookies, account identifiers, personal data, and cross-origin authority.

The validator parsed before building the business object, rejected duplicate keys, canonicalized JSON independently, checked RFC 8785 vectors, measured exact UTF-8 bytes, and returned stable error codes. The tests included hostile but correctly hashed content, false provenance, foreign origins, altered digests, expired packets, oversized payloads, Unicode edge cases, and forbidden data.

The most important finding was not that validation worked. It was understanding what validation could not establish.

A valid packet can still lie.

Five conditions designed to contradict me

I did not want a demonstration that made CCP look good. I wanted an experiment capable of showing that it was unnecessary.

Every condition came from the same controlled snapshot:

1. no context;
2. full history;
3. a free summary matched to the CCP byte budget;
4. CCP copied manually;
5. CCP retrieved through WebMCP.

The scorer checked required facts, the correct next action, stale-state contamination, hallucinated claims, unsupported certainty, clarification requests, and task completion. The order was counterbalanced across repetitions.

The protocol created 100 trial slots across four surfaces, five conditions, and five repetitions. Eighty manual trials were recorded, while the twenty WebMCP or relayed positions were classified separately so that a browser response could not masquerade as a native invocation.

The manual CCP performed well on the controlled resumption task: it recovered the correct action in 19 of 20 completed manual trials, the same count as full history. The matched free summary recovered it in 14 of 20.

That was evidence that structured continuity could be useful.

It was not evidence that WebMCP needed a memory primitive.

Origin Trial activation was only the beginning

The Origin Trial was activated on the registered laboratory origin. The server delivered the token through the Origin-Trial header, Chrome accepted it with the experimental flag returned to its default state, document.modelContext became available, the tool registered, and the page-side hook executed.

Those observations proved activation.

They did not prove product discovery.

The test chain had to remain explicit:

token delivered → token accepted → API present → tool registered → tool discovered → tool invoked → result used

Antigravity produced two server-confirmed native invocations out of five attempts in the relevant series, and one produced a usable resumption report. In the observed ChatGPT/Chrome and Edge configurations, the server confirmed no native invocation. Codex produced useful external relays, but those relays were labeled as relays rather than native WebMCP discovery.

This was not one generic failure called “unsupported.” It was a map of where each chain stopped.

The token-efficiency experiment complicated the result

My daily concern was not only continuity. It was cost.

When an agent enters the browser, visible context can include the operator prompt, previous history or CCP, tool names, descriptions, schemas, call arguments, results, and the final answer. Shrinking only the memory component does not necessarily shrink the whole interaction.

I therefore added an appendix experiment in Antigravity with five configurations:

• eager_full: complete history, twelve full tool contracts, verbose results;
• eager_ccp: optimized CCP, twelve full contracts, verbose results;
• progressive_full: complete history with progressive capability discovery;
• bounded_full: complete history with bounded results;
• optimized_combined: CCP, progressive discovery, and bounded results.

I measured exact UTF-8 bytes and used a pinned local Hugging Face tokenizer as a reproducible proxy. I also recorded the visible Antigravity quota gauge, but never converted it into internal Gemini tokens.

In completed trials, eager_ccp reduced average visible context by approximately 27% in bytes and 25.1% in proxy tokens compared with eager_full. Bounded results reduced another independent component by about 21.2% in bytes and 19.6% in proxy tokens.

The theoretical optimized combination exceeded 50% before execution.

It did not pass the native pilot.

The progressive router was not reliably discovered, and the experiment ended PARTIAL. Only one of nine completed trials preserved all seven expected decision elements. The next action survived in eight of nine, but the complete micro-task succeeded only once.

So I cannot claim a 50% operational reduction. I can claim something more precise:

• CCP reduced one real component;
• bounded responses reduced another;
• tool selection behavior could still double visible cost;
• progressive discovery had the greatest theoretical potential and the weakest native evidence;
• compression without decision fidelity is not optimization.

What I will not propose

I will not propose an RFC that adds CCP memory to WebMCP.

The experiment gave CCP a better address: the harness or agentic product. There it can remain a versioned, rejectable handoff contract. A complete envelope can serve the system, while a smaller projection can serve the model. The model does not “learn” by changing its weights during these handoffs; the surrounding system improves what it preserves, selects, and presents.

The questions most directly related to WebMCP are different:

• How should a page expose many capabilities without front-loading every schema?
• How can agents discover tools progressively?
• How should results be bounded without hiding necessary evidence?
• How can invocation be observed clearly enough to distinguish native integration from browser automation?

These questions already connect with ongoing WebMCP discussions about length and context inflation, tool filtering, dynamic definitions, and batch or code-mode execution.

My experiment does not resolve those issues. It provides a concrete case where initial context reduction is measurable, native discovery is uneven, and decision quality remains the guardrail.

A negative architectural result can still be a successful contribution

I began this work hoping to find a place for CCP inside WebMCP.

Instead, I found a reason not to put it there.

That is not arriving empty-handed. The work produced a repository audit, an external laboratory, an Origin Trial activation chain, 108 passing local tests, a 100-slot cross-surface matrix, 50 ablation results, a context-cost experiment, and a hypothesis that was corrected by evidence.

For me, the deeper lesson is about open-source participation. A professional contribution is not measured by how much architecture I can add. Sometimes it is measured by recognizing that the architecture already has the right boundary—and by returning with a smaller, more useful question.

Before building more agents, examine their tools.

Before adding memory to a protocol, identify who already owns retention.

Before celebrating fewer tokens, verify that the right decision survived.

And before writing an RFC, let the experiment earn the question.

Read or listen

• Full trilingual monograph and evidence package on Zenodo
• Companion podcast
• WebMCP repository