Introduction

Prompt engineering used to be a big deal. Then context engineering. But even this is a subset of the broader topic of agent memory management. In enterprise settings, memory is the full system by which an agent acquires facts, receives task-scoped context, carries state through execution, exchanges state with other agents, records what happened, and improves future work. The quality of that memory system often determines whether the agent behaves like a useful worker or an unreliable demo.

A useful frame comes from operating system design. A CPU cannot hold all of a program’s data in registers at once, so the OS maintains a working set — the subset of memory pages currently needed for execution — resident in RAM, while the rest remains on disk and is paged in on demand. Agent memory works on the same principle. The active context window is the register file: fast, small, and ephemeral. The task-scoped context package is the working set: curated, bounded, and loaded before execution begins. Long-term enterprise data is the disk: persistent, authoritative, and accessed on demand. The engineering problem in both cases is the same — deciding what needs to be resident, when, and at what cost.

Figure 1, Virtual Memory (Computer) vs Agent Memory

This article defines eight distinct forms of enterprise agent memory, explains how each is used at runtime, and describes the write path, lifecycle, and governance requirements that make a memory architecture production-worthy. These forms are: static memory, long-term enterprise memory, semantic memory, working memory, short-term memory, shared memory, episodic memory, and procedural memory.

They should not be collapsed. An organization’s systems of record are not the same thing as distilled business meaning. A replayable event history is not the same thing as a reusable operating procedure. A context package assembled for one task is not the same thing as the active context window during execution. Keeping these layers separate makes agent behavior easier to govern, reconstruct, and audit.

Figure 2, Agent Memory Types

Static Memory — The LLM

Static memory is the general knowledge and reasoning capability embedded in the model through pretraining. It includes language understanding, broad world knowledge, basic task-execution patterns, and multi-step reasoning. It is static because it does not update during task execution. The model does not permanently learn from each invocation. Every call begins from the same parameter state unless the model itself is retrained.

This is why static memory provides broad competence but cannot supply current enterprise facts. The model will not know the customer’s contract, the organization’s latest control procedure, or the correct interpretation of a local business term unless those facts are delivered at runtime through other memory layers.

Example: A retail agent receives a customer complaint written in colloquial language with missing punctuation and several unrelated details. It identifies the product, the claimed defect, the desired resolution, and the level of urgency — entirely from static memory. That interpretation becomes useful only when combined with order history, return policy, and inventory data from the layers below.

Long-Term Enterprise Memory — Systems of Record

Long-term enterprise memory is the organization’s persistent operational data: relational databases, document repositories, contract stores, knowledge bases, policy documents, source code, regulatory filings, and support histories. This layer is external to the model. It is where the actual state of the business lives.

Agents access this layer through tool calls, retrieval pipelines, or APIs into systems of record. The process definition determines what subset of enterprise memory the agent may access — and that boundary matters. Enterprise data access is an authorization problem and a data minimization problem. In regulated industries it is also a compliance problem. The memory architecture needs explicit controls over scope, source, and permitted use.

Example: A healthcare prior authorization agent retrieves the patient’s coverage plan, the clinical guidelines for the requested procedure, the prescribing physician’s credentials, and the insurer’s medical necessity criteria. None of those facts are in the model. They are persistent records that must be fetched under strict access controls and used as the factual basis for the determination.

Semantic Memory — Distilled Business Meaning

Raw records often lack the semantic structure needed for reliable reasoning. A database column named “exposure” in one system may correspond to “approved commitment” in another, and neither name reveals how the concept is used in a current credit decision. Semantic memory is the layer that resolves this: it contains stable concepts, definitions, taxonomies, relationships, policy interpretations, domain rules, and institutional abstractions that translate raw data into business meaning.

The structure is similar in intent to a personal knowledge tool like Obsidian. In Obsidian, notes are linked bidirectionally, concepts are connected explicitly, and the graph view makes relationships between ideas navigable rather than buried. An enterprise semantic memory layer does the same thing at a different scale: linked concepts and domain terms, explicit relationships between business entities, and navigable context that tells the agent not just what a data field contains but what it means. The differences are access controls, provenance tracking, versioning, and formal approval.

In a mature architecture, semantic memory is served through concept cards, policy cards, ontologies, data catalogs, and business glossaries. It reduces the probability that the agent retrieves technically relevant material but reasons over it incorrectly — a failure mode that is common and hard to diagnose from output alone.

Example: A credit adjudication agent pulls financial data from three systems. One labels a field “exposure,” a second uses “approved commitment,” and a third uses a legacy local term tied to an older workflow. Semantic memory tells the agent how these concepts relate, which one governs the current decision, and where the exceptions apply.

Working Memory — Task-Scoped Context

Working memory is the curated context package prepared for a specific task at a specific moment. It contains selected enterprise facts, semantic guidance, policy constraints, task instructions, and any supporting evidence the agent needs to begin. It is assembled before execution, not improvised by the agent during execution.

In enterprise architectures, this assembly should be handled by a governed pipeline — a context service or knowledge fabric — rather than by leaving retrieval strategy to each individual agent. The assembled package should be bounded, reconstructable, and auditable. If the agent makes a bad decision, the organization should be able to inspect exactly what information was delivered and in what form.

Working memory is distinct from short-term memory. Working memory is the input — the curated package. Short-term memory is the active context window once execution is underway.

Example: A pharmaceutical regulatory submission agent is tasked with reviewing a drug application against current FDA guidance. The context service assembles the applicable regulatory framework, the product’s clinical trial summaries, the relevant prior correspondence with the agency, and the internal review checklist. It excludes superseded guidance versions, unrelated product files, and internal marketing documents. The agent begins from a scoped packet rather than an open search against the full document repository.

Short-Term Memory — The Live Context Window

Short-term memory is the agent’s active context window during a single execution. It holds the system prompt, working-memory package, tool results, intermediate outputs, active notes, and any new human input received while the task is underway. It is ephemeral: it exists only for the duration of execution unless portions are summarized or persisted elsewhere.

The context window is constrained by token limits, latency costs, and competition between instructions, tool outputs, and retrieved data. As execution proceeds, tool results and intermediate reasoning accumulate. When the window fills, the system must trim, summarize, compress, or externalize state.

Example: A logistics agent resolving a shipment exception begins with the original order, retrieves customs documentation, pulls the carrier’s delay report, and receives an updated delivery window from the freight partner. All of that accumulates in the live context window while execution continues. When the task completes, that state disappears unless key outputs are written to the event stream or a case note.

Shared Memory — Inter-Agent Process State

In a multi-agent process, agents should not depend on direct pairwise handoffs. They should publish outputs into a controlled shared substrate — the communications fabric — where downstream tasks consume results according to process rules. This produces loose coupling and clearer observability. It also makes replay and audit straightforward because the state transitions are recorded in a single place rather than embedded in bilateral agent calls.

Shared memory is scoped to the process instance. One upstream output may fan out to multiple downstream agents. The process manager controls sequencing, dependencies, and access boundaries. Shared memory should not cross process-instance boundaries unless cross-instance access is explicitly designed and governed.

Example: In a manufacturing quality control flow, one agent inspects sensor readings from a production line and publishes a structured defect record to the shared fabric. A second agent classifies the defect against product specifications. A third determines whether the batch should be quarantined or released. Each reads from the shared process state rather than calling the others directly, and the full decision chain is reconstructable from the fabric’s event log.

Episodic Memory — Execution History

Episodic memory is the durable record of what happened across executions over time: task histories, decision sequences, tool calls, retries, failures, escalations, and outcomes. It supports audit, operational diagnosis, and compliance review. It also supports retrieval of prior similar cases to guide current execution.

These two uses have different quality requirements. For audit and diagnosis, completeness matters most — every step should be traceable. For experience retrieval, relevance and outcome quality matter most — a retrieved prior case that was handled incorrectly is worse than no retrieval at all. Retrieval from episodic memory needs filtering by outcome quality, not just task similarity.

Example: An IT operations agent handling infrastructure incidents finds that a specific class of memory leak in a containerized service recurs after deployments on Tuesday evenings. The episodic record surfaces the pattern across twelve prior incidents: same service, same deployment window, same remediation path. Future incidents in that window can be routed directly to the proven resolution sequence rather than treated as novel.

Procedural Memory — Reusable Execution Methods

Procedural memory is the remembered method for performing a class of tasks: playbooks, standard execution sequences, escalation rules, and reusable subtask patterns that persist across runs. An agent system that rediscovers the correct execution approach on every run is wasting resources and introducing variance.

Procedures should not form implicitly. A production architecture needs a defined path by which candidate procedures are observed, evaluated, approved, versioned, and promoted into durable use. An unreviewed habit promoted silently from a few successful runs is a hidden behavior change, not a governance mechanism.

Example: A procurement agent processing vendor onboarding learns that applications move fastest when sanctions screening is completed before legal review begins, and that incomplete tax documentation should trigger a structured information request rather than a hold. Once that sequence is verified across enough cases, it is promoted into procedural memory and applied consistently — rather than rediscovered on each new application.

The (Memory) Write Path

A complete architecture needs more than a read path. It needs a write path. Facts, corrections, case notes, summaries, and candidate procedures are produced during every execution. The write path determines what gets preserved, in what form, and in which store.

The write path should distinguish three stages: raw observation, candidate memory object, and approved durable memory. Not every tool result should become memory. Not every successful run should produce a procedure. Candidate memory should be extracted, typed, validated, deduplicated, attributed to a source, and only then promoted into the appropriate store. Some items belong in episodic history only. Some should become semantic annotations. Some should update a procedure. Some should be discarded.

The store that receives everything becomes unreliable faster than the store that receives nothing.

Lifecycle — Retention, Compression, and Expiry

Memory has a lifecycle, and that lifecycle must be engineered explicitly.

Short-term memory must be trimmed during execution. Working memory must be bounded before dispatch. Shared memory should expire with the process unless retained for a defined purpose. Episodic memory may require archival tiers as volume grows. Semantic memory needs periodic review and refresh. Procedural memory requires version control and retirement when it no longer matches current controls.

Figure 3, Agent Memory Types

Forgetting in this case is a design requirement. The system should define what is retained, for how long, at what fidelity, and under whose authority. Memory objects that are stale, superseded, or no longer permitted to persist should be deleted or archived on a defined schedule. A memory architecture without lifecycle controls becomes slower, more expensive to operate, and harder to audit.

Quality, Conflict, and Governance

Memory can be wrong. Enterprise systems routinely contain duplicate records, contradictory interpretations, stale notes, outdated procedures, and local conventions that were never formally approved. A production memory architecture must account for this.

Source precedence, freshness rules, provenance, confidence, approval status, and override logic should all be explicit. If a human annotation conflicts with formal policy, the system needs a defined resolution path — not an implicit one. If a stored procedure no longer matches current controls, it must be versioned out or revoked.

Governance applies separately to read access and write authority. Who may retrieve a memory object is one question. Who may create, approve, modify, or retire it is another. Durable memory objects should carry lineage, timestamps, ownership, and status. In regulated environments, that metadata is an operating requirement. Without it, an organization can show what the agent saw but cannot demonstrate whether the memory itself was valid, current, or authorized for use at that point in time.

Conclusion

Enterprise agent memory is a layered system, not a single store. Each layer has a distinct function, and collapsing them produces systems that are harder to govern, harder to audit, and harder to improve.

What distinguishes a production deployment from a demo is not the model. It is the memory architecture around it — whether facts are sourced and scoped correctly, whether context is assembled and bounded before dispatch, whether execution state is governed and auditable, and whether the system improves over time without silently accumulating bad habits. Those properties are determined by memory architecture, not model capability.

***

Feel free to reach out and connect with the author Eric Broda on LinkedIn. Questions and comments are welcome and encouraged!

***

This is part of larger article that addresses a broader suite of topics related to agents (see my full article list). If you like this article, you may wish to checkout my new book, “Agentic Mesh”, with O’Reilly, and on Amazon.

***

All images in this document except where otherwise noted have been created by Eric Broda. All icons used in the images are stock PowerPoint icons and/or are free from copyrights.

The opinions expressed in this article are that of the authors alone and do not necessarily reflect the views of our clients.

Looking for more?
👉 Discover the full O’Reilly Agentic Mesh book by Eric Broda and Davis Broda

🎧 Follow The Agentic Mesh Podcast on Youtube, Spotify and Apple Podcasts. A new video every week!