LinkedIn developed the Cognitive Memory Agent (CMA), a horizontal memory platform designed to enable stateful and context-aware AI agents at scale, initially deployed within their Hiring Assistant product. The problem addressed was that delivering truly agentic experiences required more than capable models—agents needed domain intelligence, organizational context, and the ability to improve over time through personalized memory. CMA solves this by intelligently storing and retrieving contextually relevant information across multiple memory layers (conversational, episodic, semantic, and procedural), enabling agents to maintain continuity beyond context windows, learn from interactions, and provide deeply personalized experiences. The solution has been successfully integrated into Hiring Assistant, where it helps recruiters by suggesting roles based on past projects, auto-populating hiring requirements, and providing insights from historical activities, thereby reducing user friction and increasing productivity.
LinkedIn’s Cognitive Memory Agent (CMA) case study represents a sophisticated approach to building production-grade AI agents with memory capabilities. The platform was developed to support LinkedIn’s Hiring Assistant, their first AI agent for recruiters launched globally in 2025. The fundamental challenge LinkedIn identified was that while large language models provide powerful reasoning capabilities, they remain fundamentally stateless without proper infrastructure. To create agents that could genuinely assist users over time, LinkedIn needed to build systems that could remember, learn, and adapt based on ongoing interactions.
The business motivation stemmed from a recognition that truly useful agents require three capabilities beyond the base model: strong domain intelligence grounded in organizational context, the ability to improve over time, and memory to learn from interactions. Traditional memory systems required users to explicitly specify what should be remembered, creating friction and limiting utility. LinkedIn’s solution was to build an intelligent memory platform that could autonomously determine what to store and retrieve based on context.
The CMA platform is architected around three core components that work together to provide comprehensive memory capabilities. First is the memory layer itself, consisting of conversational, episodic, semantic, and procedural memory stores. Second is the ingestion layer that processes and extracts information from unstructured inputs. Third is the retrieval orchestration layer that handles query understanding and memory synthesis.
The memory architecture mirrors cognitive models from psychology, implementing multiple distinct memory types with different characteristics and purposes. Conversational memory captures compressed in-session state, storing indexed dialogue turns between users and agents. Messages are exchanged through LinkedIn’s highly scalable messaging platform, with both chronological logs and semantic indexes maintained via computed embeddings stored in vector databases. This dual representation allows the system to retrieve both recent interactions and semantically similar past conversations. Periodic summarization achieves context compression to manage growing conversation histories.
Long-term memory is subdivided into three categories. Episodic activity memory records specific timestamped events and interactions, capturing signals like “recruiter archived candidate due to lacking machine learning skills.” This contextual memory allows agents to reference similar activities within specific time ranges, building situational awareness. The challenge in episodic extraction involves correctly identifying episode boundaries, managing staleness, and resolving conflicts when events overlap or interleave.
Aggregated semantic memory stores generalized knowledge and preferences derived from repeated interactions. This operates at different granularity levels, analyzing longer time arcs to capture signals such as company visa sponsorship policies or remote work preferences. Unlike episodic memory which recalls specific events, semantic memory abstracts into general preferences that persist across contexts.
Procedural memory captures execution patterns and workflow preferences, influencing how tasks are performed rather than what is known. For example, one recruiter might filter candidates by seniority before selecting specific skills, while another accepts suggested candidates but applies particular communication templates. These patterns translate to specific memory tool choices and reasoning strategies for the orchestrator. True procedural memory must capture invariant workflow structure while isolating task-specific parameters.
The underlying infrastructure leverages multiple storage systems. The original experiential memory layer was built atop Couchbase and Espresso, providing a hierarchical key-value store. However, this initial approach lacked intelligence, requiring each application to manually handle preference extraction, indexing, and storage/retrieval logic. CMA enhanced this by adding dynamic extraction and synthesis capabilities.
Data processing is split between streaming and batch pipelines to optimize for different latency and computational requirements. Streaming processing handles latency-sensitive tasks like conversational memory summarization, preventing conversations from exceeding context limits. It also processes episodic memory ingestion, extracting verbalized activity from raw conversations to ensure up-to-date storage. Batch processing tackles computation-intensive tasks like semantic memory extraction and aggregation.
The hierarchical semantic memory indexing approach uses LLM calls to convert user activity data into aggregated question-answer pairs, hierarchical natural language summaries, and facets. This tree-like structure offers advantages over approaches like GraphRAG and flattened RAG by leveraging natural data hierarchies, reducing the number of LLM calls needed to determine edges, and avoiding context size limitations by not feeding all leaf nodes to the LLM simultaneously. The hierarchical design enables full parallel processing at each layer, making it well-suited for batch workloads and incremental updates processed in time-windowed batches.
The retrieval layer represents a departure from traditional RAG approaches. Rather than treating memory as a static corpus with simple embed-query-retrieve-synthesize operations, CMA implements retrieval as a reasoning process. The system functions as a lightweight agentic orchestrator that plans how to access and combine different memory layers before producing answers.
The orchestrator receives natural language queries, relevant memory keys, and available memory tools, then generates retrieval plans. Simple queries may involve single semantic lookups, while complex questions trigger sequential invocation of multiple memory providers, intermediate query refinement, and cross-layer synthesis. For example, answering “Why does a recruiter like this candidate?” requires consulting aggregated semantic memory for recruiter preferences and hiring patterns, querying episodic memory for recent feedback on similar candidates, incorporating conversational memory if the interaction is ongoing, and correlating these signals to synthesize an explanation.
The orchestrator currently uses an open-source LLM hosted on LinkedIn’s internal infrastructure, handling planning, memory tool calls, and response generation within one unified reasoning loop. This tight integration simplifies system design and keeps retrieval reasoning coupled with answer synthesis. LinkedIn is working to improve orchestrator performance through supervised fine-tuning and reinforcement learning, with plans to leverage lessons from domain-adapted foundation models to build a foundational, multi-turn instruction-tuned retrieval layer.
Access control is implemented through multiple layers. Each application operates within isolated memory stores, preventing cross-application data exposure. Every memory record carries ownership metadata tags enabling precise tracking and controlled access. Memory access is strictly limited to logged-in users within their sessions, with no data sharing across tenants or users. In Hiring Assistant, this means memory is per-recruiter and per-customer tenant.
Privacy and responsible AI practices are embedded throughout the system. Data persistence and retrieval conform to standard privacy-preserving practices, with scope limited to individual users’ accessible memory. All processing applies appropriate privacy-preserving techniques during summarization, extraction, and compression.
LinkedIn implements a three-tiered quality evaluation framework to measure end-to-end multi-agent interaction quality. Tier-1 metrics quantify memory representation quality on a continuous 0-to-1 scale, measuring ingestion process correctness. This includes checking that facts claimed about entities are supported by underlying conversations and activity signals (correctness), and estimating how much anchored information from sources is actually captured in generated memory (coverage).
Tier-2 metrics measure CMA response quality using LLM-as-judge approaches, also on a 0-to-1 scale. These evaluate whether retrieved information is relevant to queries, whether responses are grounded in retrieved memories without hallucination, and whether answers completely address user queries. This tier evaluates the full loop from query through retrieval planning, memory selection, and response synthesis, enabling isolation of issues in retrieval/routing versus synthesis.
Tier-3 metrics evaluate end-to-end product performance through offline helpfulness metrics, user satisfaction studies, and online A/B tests. Focus areas include task success rate improvements and user friction reduction, measuring actual business impact rather than just technical quality.
Beyond quality metrics, the system tracks cost and latency constraints. Ingestion can require substantial LLM compute for extraction, summarization, and structuring of long-term signals. Query latency is closely monitored since orchestration must return responses within acceptable service level agreements. Specific tracked metrics include response latency, number of reasoning tokens and planning steps generated by the orchestrator, and token usage with LLM call counts during ingestion.
Applications integrate with CMA through a natural language interface. Onboarding requires provisioning dedicated storage for isolated memory access, providing injectable business context with tool descriptions and hooks (CMA tools are generic with application-specific customizations provided via business context and detailed memory tool descriptions), ingesting user activity data and conversations through the CMA ingestion API, and querying through the retrieval API with natural language queries and relevant metadata.
Optionally, application teams can provide custom embeddings or fine-tuned models to override defaults for embedding-based retrieval, improving domain-specific retrieval performance. This flexibility allows teams to optimize for their specific use cases while leveraging the shared memory infrastructure.
The Hiring Assistant demonstrates CMA’s practical value through several concrete use cases. When recruiters start hiring projects, CMA fetches past projects and preferences to suggest roles they might hire for, providing productivity boosts when recruiters repeatedly hire for similar positions. This reduces friction by eliminating redundant data entry.
CMA also auto-populates hiring requirements for new projects based on past preferences from similar roles, once recruiters create a new role. This accelerates project setup while maintaining consistency with established patterns.
Through the conversational interface, recruiters can query insights about past hiring projects and activities. The Hiring Assistant internally queries CMA to obtain facts and compile insights, making historical information accessible through natural language rather than manual search through past projects.
LinkedIn’s roadmap for CMA focuses on transparency, reasoning capabilities, and robustness. Planned improvements include making memory transparent and user-controlled by allowing users to inspect, edit, and delete agent memory, shifting from hidden optimization to shared human-agent collaboration.
Dynamic test-time compute (deep thinking) aims to improve latency through cost-aware compute, dynamically allocating reasoning depth based on query complexity. This would optimize the tradeoff between response quality and computational cost.
Conflict detection and resolution capabilities will identify stale or contradictory memory entries, apply time-based prioritization policies for memory sources, implement conflict resolution strategies during both ingestion and retrieval, and periodically purge and update memory to maintain relevance.
Long-horizon simulation and benchmarking will enhance evaluation coverage by simulating and replaying multi-session interactions to capture distribution shifts in user interactions, expanding online and offline metrics to measure personalization gains, product impact, graceful degradation, and end-to-end memory system performance.
Finally, LinkedIn is exploring a distributed filesystem abstraction that treats memory more like a filesystem with hierarchy, versioning, and lifecycle control. This memory-native substrate would support scalable, high-frequency, semantically aware agent workloads while improving retrieval accuracy and storage scalability.
While LinkedIn presents CMA as a significant advancement in agent memory systems, the blog post is promotional in nature and should be evaluated critically. The claimed benefits around personalization and productivity improvements in Hiring Assistant are not substantiated with quantitative metrics or A/B test results. While the three-tiered evaluation framework is described, no actual performance numbers are shared.
The architectural complexity introduced by multiple memory layers, streaming and batch processing pipelines, and orchestrated retrieval raises questions about operational overhead, debugging difficulty, and failure mode handling that aren’t addressed. The tradeoff between system complexity and incremental value over simpler approaches remains unclear.
The hierarchical semantic memory approach is positioned as superior to GraphRAG and flattened RAG, but no comparative benchmarks are provided. The actual retrieval quality improvements and cost reductions versus these alternatives are asserted rather than demonstrated.
Privacy and access control mechanisms are described at a high level, but critical details about how the system handles edge cases, prevents leakage across tenant boundaries, and manages consent for memory storage are not elaborated. The statement about conforming to “standard privacy-preserving practices” is vague and doesn’t specify what techniques are actually employed.
The reliance on LLM-as-judge for Tier-2 evaluation introduces potential biases and limitations that aren’t discussed. The blog doesn’t address how evaluation metrics correlate with actual user satisfaction or business outcomes.
Despite these limitations in the presentation, the core technical approach represents sophisticated LLMOps engineering. The multi-layered memory architecture, separation of ingestion and retrieval concerns, and treating retrieval as orchestrated reasoning rather than simple search demonstrate advanced thinking about production agent systems. The recognition that agent intelligence emerges from “thoughtful harnesses built around models” rather than models alone is an important perspective for the field.
DoorDash faced challenges in scaling personalization and maintaining product catalogs as they expanded beyond restaurants into new verticals like grocery, retail, and convenience stores, dealing with millions of SKUs and cold-start scenarios for new customers and products. They implemented a layered approach combining traditional machine learning with fine-tuned LLMs, RAG systems, and LLM agents to automate product knowledge graph construction, enable contextual personalization, and provide recommendations even without historical user interaction data. The solution resulted in faster, more cost-effective catalog processing, improved personalization for cold-start scenarios, and the foundation for future agentic shopping experiences that can adapt to real-time contexts like emergency situations.
Snorkel developed a specialized benchmark dataset for evaluating AI agents in insurance underwriting, leveraging their expert network of Chartered Property and Casualty Underwriters (CPCUs). The benchmark simulates an AI copilot that assists junior underwriters by reasoning over proprietary knowledge, using multiple tools including databases and underwriting guidelines, and engaging in multi-turn conversations. The evaluation revealed significant performance variations across frontier models (single digits to ~80% accuracy), with notable error modes including tool use failures (36% of conversations) and hallucinations from pretrained domain knowledge, particularly from OpenAI models which hallucinated non-existent insurance products 15-45% of the time.
This case study examines Cursor's implementation of reinforcement learning (RL) for training coding models and agents in production environments. The team discusses the unique challenges of applying RL to code generation compared to other domains like mathematics, including handling larger action spaces, multi-step tool calling processes, and developing reward signals that capture real-world usage patterns. They explore various technical approaches including test-based rewards, process reward models, and infrastructure optimizations for handling long context windows and high-throughput inference during RL training, while working toward more human-centric evaluation metrics beyond traditional test coverage.
