Agent Memory

The mechanism by which an AI agent retains and accesses information across tasks or sessions. Unlike a single-turn LLM interaction, agents often need to recall earlier steps in a workflow, user preferences, or prior outputs. Agent memory can be short-term, meaning it exists within a session only, long-term, meaning it is stored externally and retrieved as needed, or episodic, meaning it takes the form of a log of past actions. In CRE workflows, agent memory allows a deal-screening agent to remember a user’s investment criteria across multiple properties reviewed over time, without requiring the user to re-enter context at the start of each session.

Putting Agent Memory in Context

An acquisitions analyst at a value-add firm configures a deal-screening agent with long-term memory that stores their target return thresholds, preferred submarkets, and minimum clear height requirements for industrial assets, so that when a new offering memorandum is uploaded weeks later, the agent evaluates it against the same criteria without the analyst re-entering any parameters, and appends its findings to a running log of all properties reviewed that quarter.


Frequently Asked Questions about Agent Memory

Pasting context into a prompt is a manual, session-bound action that disappears when the conversation ends. Agent memory is a structured system where information is stored externally, tagged, and retrieved automatically when relevant, without the user doing anything. In a CRE workflow involving dozens of properties reviewed over weeks, manually re-supplying context each session is impractical, while a memory layer allows the agent to operate continuously with an accumulating knowledge of past decisions and preferences.

Short-term memory exists only within a single session and is typically held in the model’s active context window, making it useful for multi-step tasks like walking through a rent roll and producing a summary within one working session. Long-term memory is written to an external store such as a database or vector store and retrieved in future sessions, making it appropriate for maintaining investor profiles, deal screening criteria, or a history of properties underwritten over months. Most production CRE agents require both, using short-term memory to handle the current task and long-term memory to provide continuity across sessions.

The primary risk is memory staleness, where stored preferences or criteria no longer reflect the firm’s current strategy but continue to influence the agent’s outputs without anyone noticing. A fund that shifts its target from value-add multifamily to net lease industrial, for example, needs a process for updating or invalidating stored memory, or the agent will keep screening deals against outdated parameters. There are also data governance concerns, particularly around storing proprietary deal information or investor preferences in third-party infrastructure, which requires careful review of where and how memory is persisted.

Episodic memory stores a sequential log of the agent’s past actions and outputs, similar to an audit trail, rather than storing distilled facts or user preferences. In CRE asset management, this is useful when a portfolio manager needs to understand why an agent flagged a lease renewal for review three months ago, because the episodic log captures the reasoning and data state at the time of that decision. It is less about personalization and more about traceability, making it particularly valuable in compliance-sensitive workflows or when multiple team members interact with the same agent over time.

A vector database is the most common infrastructure choice for long-term memory because it allows the agent to retrieve semantically relevant information efficiently, even when the query does not match stored content word for word. However, simpler implementations using structured databases, key-value stores, or even a well-organized spreadsheet connected via API can serve as adequate long-term memory for narrowly scoped CRE agents with predictable retrieval patterns. The right choice depends on the volume of stored information, the variety of retrieval queries expected, and the technical resources available to the team building the system.


Click here to get this CRE Glossary in an eBook (PDF) format.