Context and memory

Memory is a dedicated architectural component, not conversation history in a prompt. Three types (episodic, semantic, procedural), four scopes (user, agent, session, organization), retrieved and ranked simultaneously every time the agent responds.

Memory at answer time: the query triggers retrieval across all four scopes at once, results are ranked (user first, then session, then org), governance is enforced at the retrieval layer, and a dedicated component persists new facts for the next session.

Three memories, four scopes

For an agent to operate efficiently, a system is required that will supply the right information at the right time. Context and memory realize that capability: what gets loaded into the context window, what gets persisted across sessions and how the agent retrieves knowledge it was not trained on. Memory represents a distinct and dedicated architectural component that extracts, indexes, and retrieves facts across sessions. There are three types: episodic, which reflects past interactions, outcomes and errors; semantic, which covers truth artifacts such as facts, domain knowledge and user preferences; and procedural, which holds learned workflows and operational patterns.

In enterprise environments memory is scoped into four tiers: user (facts that follow the person), agent (knowledge bound to the role), session (discarded when the conversation ends) and organization (shared by every agent and user). When an agent is about to respond, the memory system retrieves across all four scopes simultaneously and ranks them. Without scoping we get either an agent that forgets everything between sessions or one that drowns in irrelevant organizational context.

Retrieval is a process, not a lookup

Retrieval in production agents is an iterative, governed process over structured knowledge. Two dominant approaches work best in a complementary mode. Agentic RAG describes the behavior: the agent does not just retrieve once and generate, it plans, retrieves, checks, and loops until the answer is grounded. Context-graph-grounded RAG is about what the agent retrieves from: instead of a flat vector store, a knowledge graph that encodes actual entity relationships. In enterprise production environments they need to converge, so the agent retrieves iteratively from a structured, governed knowledge base.

The deceptive layer

Context and memory can be the most deceptive layer if not architected properly. What looks like a capable agent in a 10-minute demo may be functionally unreliable across a 2-hour enterprise workflow. Memory gets dramatically worse at scale: temporal abstraction degrades at high token volumes, and cross-session memory treats change as replacement rather than evolution because it cannot track how a fact changed over time. On the governance level, enterprise RAG fails without access controls, metadata and compliance mapping enforced at the retrieval layer. Document-level ACLs at query time, security trimming and audit trails are architectural requirements, not optional add-ons.