Agent Memory Architectures With External Web Data

Agent memory fails in production because teams treat memory as one undifferentiated pile instead of four distinct types, each with its own rules for staleness, retrieval speed, and persistence. The CoALA framework draws a sharp line between memory type (what gets stored) and memory architecture (how storage, retrieval, and control logic fit together), and commentators point to the conflation of those two layers as a common source of practitioner confusion, even though CoALA's own paper never frames it that way. Get that distinction right, and the question of where live web data belongs in an agent's memory stack stops being a guessing game.

The shift underway is bigger than a tooling upgrade. A review from Shanghai Jiao Tong University and collaborators describes agent infrastructure as reorganizing the cognitive system itself: capabilities once left for the model to recover internally, from memory to skills to interaction protocols, are now externalized into structures the agent can read, write, and update. The ICLR 2026 MemAgents workshop makes the same point from the research side, defining agent memory as online, interaction-driven, and under the agent's own control, separate from whatever got baked into the weights during training. That distinction, between memory the agent actively manages and memory that's just frozen model knowledge, is the foundation for everything that follows.

The four memory types and what each one holds

Working memory is whatever the agent is holding right now, in the current session: system instructions, conversation history, and any chunks pulled in at inference time. Atlan's description of this as the baseline pattern is blunt about its limits: once the session ends, so does the memory. Nothing here persists on its own.

Episodic memory holds the record of what already happened: past task runs, interactions, and observations, usually kept in a vector database or a structured table and pulled back later by similarity search or a fixed rule. FutureAGI's 2025 architecture guide groups episodic memory with working and procedural as the three layers that dedicated memory systems like Mem0, Letta, and Zep package into a single API.

Semantic memory is general world knowledge, the facts, concepts, and entity relationships an agent treats as settled reference material. The MemAgents workshop names semantic memory alongside episodic and working as one of the field's foundational architecture types, and it flags the interface between these stores and external data sources as a genuinely open research question. That openness matters, because semantic memory is where staleness does the most damage: anything that changes faster than a model's training cycle, prices, library versions, regulations, security vulnerabilities, starts decaying the moment there's no external refresh mechanism in place.

Procedural memory is how-to knowledge: tool-use habits, task decomposition patterns, the behavioral rules an agent follows without having to reason them out fresh each time. FutureAGI describes it as often baked directly into the system prompt or a small fine-tune, making it the most static of the four types. The externalization review frames this same content as "externalized procedural expertise," skills that used to live only inside the model's weights and now live as structures outside it.

Four types, four different jobs. The rest of this piece works through what live web data means for each one.

Working memory and live web retrieval: why fetch-time matters more than index-time

Working memory is where live web data has the fastest, most visible payoff, because it's the layer closest to the question being asked right now. A pre-crawled vector index can only hand back documents it already has on file, so any topic that moves faster than the crawl schedule, prices, scores, breaking news, security CVEs, gets answered with information that was already out of date the moment it was generated. A live-web RAG pipeline goes out to the open web at query time, fetching data when someone actually asks rather than weeks earlier during a scheduled crawl.

Speed is the constraint that decides what's even eligible to sit in working memory. Khan and Lipizzi's "Memory in the Loop" research puts a number on it: a networked vector store typically answers in tens to hundreds of milliseconds, while an in-process store answers in roughly 100 microseconds. At that in-process speed, retrieval becomes fast enough to sit inside every reasoning step without slowing the agent down, and a loop built to consult it at that frequency meets what Khan and Lipizzi call the extended-mind parity criteria for working memory. Below that speed, the store is useful for other things, but it can't function as working memory, because working memory has to be fast enough to touch on every single step.

That latency requirement is a practical design constraint for web fetches. A live web call that takes a few hundred milliseconds is fine for a single retrieval at the start of a task. It's not fine for something the agent needs to check five times inside one reasoning loop. Two options follow from that: make the fetch fast enough to sit inside the loop, or pull the data in before the session starts so it's already resident when reasoning begins.

Most production systems split the difference. Time-sensitive queries get a live fetch; stable reference content gets served from cache under a freshness TTL, so the pipeline doesn't re-fetch things that haven't changed. The TTL itself should track the topic, not a single global default: prices, scores, and breaking news need freshness windows measured in seconds or minutes, while stable reference material can hold for hours or even weeks. Working memory built this way doesn't need to persist past the session. It gets used once and dropped, which keeps storage simple but puts real pressure on getting the retrieval right the first time, since there's no later pass to catch an error once the session closes.

Episodic memory and web data: recording what the agent observed, not what the web said

Episodic memory has a narrower job than working memory, and it's easy to get wrong in a specific way: storing the web content itself instead of the record of having looked. The right pattern is to log the agent's retrieval actions and their outcomes, the query, the URL, a summary or structured extract of what was found, and the timestamp, not the raw page. Store the full page content instead, and the episodic layer turns into a second copy of the web, one that's slower to query and goes stale just as fast as the original.

Agents operating over long-horizon, partially observable tasks have to maintain state about objects that can change outside their view, and when an agent stores a past observation as though it were still the current state of the world, planning breaks downstream. The web version of this problem is exact. A price fetched three days ago is not today's price, and the episodic record should reflect that directly: "fetched $49 on date X," not simply "$49". One phrasing is a fact about a past observation. The other is a claim about the present that will eventually be false.

Framed as a retrieval event, episodic memory gives an agent something genuinely useful on repeat encounters: a record of what it looked up before, when, and what it found, which lets it decide whether to re-fetch (because the source moves fast) or reuse what's already on hand (because the source is stable). Website monitoring and change detection slot neatly into this picture. A structured JSON diff of a page, captured over time, is itself an episodic record of what changed and when, and an agent can check that record against its own last fetch before deciding whether a re-crawl is worth the cost. That pattern resurfaces later in any pipeline built around continuous monitoring, and the core design choice stays the same here: dedicated memory systems like Mem0, Letta, and Zep package episodic storage into a single API, and the unit to write into that API is the retrieval event itself rather than the content retrieved.

Semantic memory and the staleness ceiling every RAG system hits

Semantic memory is where the gap between a model's training cutoff and the live state of the world causes the most damage, and it's also the layer where disciplined live-web grounding pays off the most. The category covers what an agent treats as settled: entity facts, product specifications, regulatory requirements, library APIs. None of it is actually fixed at the timescale production systems run on.

The staleness ceiling follows directly from how embedding-based RAG works. A vector index captures documents as they existed at crawl time, so any fact that changes between crawl runs gets served as though it were still current, and the system has no built-in way to detect that drift or flag it to the agent. It's a structural property of the architecture rather than a sign that the retriever is doing a poor job. Even a retriever that returns a perfect match is only returning the best match available in an index that might be months old.

One of the most dependable fixes is also one of the simplest to parse: Schema.org structured data published in JSON-LD format. It can be read without crawling or parsing the surrounding HTML, and JSON-LD holds a large majority of the market among structured data formats, so a page that publishes it hands an agent clean, machine-readable entity claims without the ongoing cost of maintaining CSS selectors. LlamaIndex has formalized this into a workflow: reliable extraction needs a defined schema with field types, constraints, and extraction rules spelled out in advance, and its MCP tooling now supports generating that schema (generateExtractionConfig) and running the extraction (extractFile) to return structured JSON no matter how chaotic the source HTML is. That schema-first approach is the right way to think about semantic memory updates generally: define what needs to be known, fetch the current page, and overwrite the existing record. Treat the web crawl as a write to semantic memory rather than as another document to pile into an index.

Brand and entity identity is a clean example of this same problem, not a side issue. An agent reasoning about a company's products, positioning, or tone needs the current version of that information, not whatever was true as of training cutoff. A growing stack of machine-readable formats, llms.txt, Agent Cards published at /.well-known/agent-card.json, and brand.json, gives agents structured entity facts they can write straight into semantic memory without an interpretive pass. Markolé's MCP server shows the pattern in practice: it exposes structured brand data, covering narratives, traits, visual identity, and presentations, under semantic labels, crawling as many as 75 URLs at a depth of 3 and running each chunk through trait and topic extraction prompts. What comes out the other end is a semantic memory record built for an agent to read, not a PDF built for a person to skim.

Procedural memory and web data: when the web teaches the agent how, not what

Procedural memory has the most indirect connection to live web data of the four types, and that's by design, not by oversight. Where working memory wants data fetched this second and semantic memory wants facts kept current, procedural memory holds the how, the decision rules, workflow patterns, and tool-use habits an agent falls back on by default. Content like that is meant to be stable across sessions, so it usually lives in a system prompt or gets folded into a small fine-tune rather than pulled fresh from a live source.

That stability is a feature rather than a gap to be fixed with more frequent crawling. An agent that re-derives its basic workflow logic from a live web fetch every session trades consistency for freshness it doesn't actually need, since the underlying skill, how to decompose a multi-step task, how to decide when to retry a failed tool call, rarely needs to change week to week. The cases where web data legitimately updates procedural memory are narrower and more deliberate: a new API version changes the correct call pattern, a tool's documentation changes its required parameters, or a published workflow pattern gets adopted wholesale because it solves a problem the agent's current skill set doesn't cover. In each of those cases, the web is teaching the agent a new how, not refreshing a what, and the update belongs in procedural memory precisely because it changes behavior going forward rather than correcting a single fact in the moment.

Treating procedural memory this way keeps the architecture honest. Working memory answers what's happening right now. Episodic memory answers what the agent already tried and found. Semantic memory answers what's currently true about the world. Procedural memory answers how the agent should act, and it changes only when there's a real reason to revise the playbook, not every time a crawler runs. Building an agent's memory stack around that separation, type by type, makes the staleness problems that plague undifferentiated memory designs mostly disappear on their own.