Repository navigation
Allow developers to manage Agent's memory #29
Description
nithanaroy shared this idea, filing an issue to see if there's interest. It does sound like something we can consider down the line.
MCP already has a concept of resources: Data sources that provide contextual information to AI applications (e.g., file contents, database records, API responses). These enable the application to manage context used by the Agent. Agents extracting context from a web page could use this capability as well to have more relevant context for a user. Currently they are limited to data within the current DOM but not other application memory which could be relevant. For example, maybe there's items in the user's cart (which aren't visible in the current UI) but are implicit context to the user's query.
nithan also tried to explain a concept of short term vs long term memory and whether a capability here should consider that difference.
Activity
domfarolino commentedon Jun 11, 2026
We discussed in today's WebML CG call, but decided not to come to any resolution yet, since (a) we got to it too late, and (b) we want to get more real-world feedback on Chrome's WebMCP Origin Trial to see if there any gaps that would need to be filled with a proposal like this. However, some notes if we decided to pursue this: this kind of sounds similar to the Prompt API's manual context management:
measureContextUsage()That could be something to draw from, although I'm not sure we want super programmatic/surgical interaction with the context/memory like that, or if we just want to do something "MCP-ish" where we have "resources" instead of "tools" that the agent can call to load its brain with useful context. You can imagine native versions of this like the "localStorage resource" that the agent can read, or developer-provided ones like "shopping cart context". It's not clear if this is any better than just having a readOnly tool though.
It's also not clear if any of this is necessary, since unlike the Prompt API and other "built-in AI" APIs, WebMCP has an expectation that built-in agents have much more knowledge about the site's context (DOM and local storage, perhaps) and access to browser internals on its own, compared to the relatively limited built-in/local models.
ferhimedamine commentedon Jun 11, 2026
Interesting discussion. @domfarolino raises a good point about whether this is better served by a "readOnly tool" or a resource abstraction. From building production agent memory systems, I'd argue the answer depends on access patterns, and you probably need both.
Agent memory management in practice needs at least four primitives: store (with importance scoring, tags, and memory type — episodic vs semantic vs procedural), recall (with filters for tags, importance range, time window, and memory type), forget (explicit deletion, which matters for compliance and right-to-be-forgotten), and consolidate (merge similar memories, extract patterns, deduplicate). The API should support both vector-based semantic search and filter-based retrieval because different use cases demand different access patterns. A "what did the user say about preferences?" query is semantic; a "get all memories from session X" query is filter-based.
The "localStorage resource" idea is promising but insufficient on its own. Raw localStorage is unstructured — an agent reading it gets a blob of key-value pairs with no relevance ranking. What agents actually need is a layer that handles importance weighting (not all memories matter equally), temporal decay (recent context should surface more easily), and scope isolation (memories from one site's agent shouldn't leak to another). The Prompt API's context window measurement is relevant here because memory injection into context is fundamentally a budget allocation problem — you're choosing which memories are worth the tokens. A memory system that can rank by importance and filter by relevance solves this more naturally than manual context management.
One thing to consider: the "much more knowledge about the site's context" assumption for built-in agents may not hold as agents become more stateful across sessions. An agent that remembers user preferences, past interactions, and learned behaviors across visits needs persistent, structured memory regardless of how much DOM/localStorage access it has. The DOM tells you what's on the page now; memory tells you what the user cared about last time.