--- title: "Inside LinkedIn's cognitive memory agent for agentic personalization" url: https://daily.dev/posts/inside-linkedin-s-cognitive-memory-agent-for-agentic-personalization-l3bfixx0e source_url: https://stackoverflow.blog/2026/08/25/inside-linkedin-s-cognitive-memory-agent type: article source: "Stack Overflow Blog" published: 2026-08-25T04:02:27.373Z updated: 2026-08-25T04:03:03.020Z tags: ["career", "llm", "rag", "linkedin"] reading_time: 32 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Inside LinkedIn's cognitive memory agent for agentic personalization **[Stack Overflow Blog](https://daily.dev/sources/stackov)** · 32 min read · 0 upvotes · 0 comments ## Summary LinkedIn's principal AI researcher Praveen Bodigutla discusses the cognitive memory agent built to power personalization for LinkedIn's hiring assistant. The system uses four memory layers - conversational, semantic, episodic, and procedural - to persist recruiter preferences across sessions. The team moved away from GraphRAG to a tree-structured memory because GraphRAG was too slow and costly, requiring many LLM calls to rebuild indexes; the tree structure enables incremental updates by percolating changes along specific branches instead of reindexing everything. The conversation covers ingestion, retrieval, freshness/consistency, multi-tenant access control, latency budgets (memory gets 10-20% of total response latency), and inference optimizations like prefix caching and chunked prefills at the vLLM serving layer. Future work includes exploring virtual file systems for memory storage and improving attribution/evaluation. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### why did LinkedIn move away from GraphRAG for their AI memory system LinkedIn's team found GraphRAG too slow and not cost efficient because it required many LLM calls to identify linkages between nodes and had to rebuild the entire index every time memory was updated. They switched to a tree-structured hierarchical memory organization that supports incremental updates, percolating a preference change along the specific branch of the tree without recomputing or reindexing the whole memory store. _daily.dev surfaces engineering tradeoffs like this for teams weighing graph versus tree based retrieval architectures._ ### what are the different types of memory layers used in an AI agent's memory system A cognitive memory agent can use four distinct layers: conversational memory for the current session's most recent exchanges, semantic memory that aggregates a user's preferences across sessions and product surfaces, episodic memory that provides temporal querying and traceability back to specific past activities, and procedural memory that captures how a user approaches tasks and makes trade-offs, distinct from what they prefer. _engineers designing personalization layers track architecture patterns like layered memory systems on daily.dev._ ### how much latency budget should a memory retrieval layer take up in an AI agent's total response time A memory agent's retrieval and reasoning should consume roughly 10 to 20 percent of an application's total response latency budget, since memory is only one part of the context an application agent must fetch and synthesize before responding to a user. Optimizations like prefix caching, chunked prefills at the serving engine level, and structured, token-limited outputs help stay within that budget. _teams tuning agent latency budgets keep up with real world numbers like this on daily.dev._ --- Tags: [#career](https://daily.dev/tags/career), [#llm](https://daily.dev/tags/llm), [#rag](https://daily.dev/tags/rag), [#linkedin](https://daily.dev/tags/linkedin) [View this post on daily.dev](https://daily.dev/posts/inside-linkedin-s-cognitive-memory-agent-for-agentic-personalization-l3bfixx0e)