AI Agent Memory Lessons From LinkedIn's Hiring Assistant

A recruiter spends a week teaching a hiring assistant her preferences: skip phone screens for senior roles, three-bullet candidate summaries, tight fintech searches. Then she opens a fresh session and none of it survives. The agent greets her like a stranger because, from the model's point of view, she is one. Products that feel intelligent across sessions are not running the biggest context windows; they run real storage hierarchies underneath, because AI agent memory is a storage hierarchy problem, not a context window problem. LinkedIn's hiring assistant is the clearest public example of that hierarchy built deliberately: four separately governed layers (working, episodic, semantic, and user-profile), each with its own write trigger, decay policy, and privacy class.

Principal AI Researcher Praveen Bodigutula described the four-layer system in a Stack Overflow podcast interview. This teardown reconstructs what the team built, traces the research lineage it comes from, and converts it into rules you can apply to your own agent, flagging confirmed details versus my reconstruction as we go.

Why a big context window is not memory

A bigger window fails as a memory system for two separate reasons, and conflating them is why memory design gets skipped entirely.

The first is lifecycle. A context window is working space, not a store. It exists for the duration of a request, and unless something outside the model persists state between sessions, every new conversation starts blind and relearns the user from zero. The failure that opened this article is not the model forgetting; it is the absence of anywhere to remember into.

The second is attention. Even inside a single session, a full window does not behave like a database. As tokens pile up, effective attention degrades, and details buried mid-context get lost or misweighted. Anthropic's context engineering guidance frames the window as an attention budget to be spent deliberately, which is the right mental model: every stale transcript token carried forward competes with the current task for that budget. Reinjecting full history on every call also means paying for the same tokens again and again, forever.

So durable state belongs outside the model, in stores with their own lifecycles, and the design question changes shape. Ask which writes earn their keep, which store each write belongs in, and how long each record stays true. Those three questions organize everything below.

What LinkedIn's hiring assistant actually remembers

Per the interview and LinkedIn's engineering writeup, the team describes the assistant's memory as four layers, with persistence and personalization as first-class goals:

Layer	What it holds	Hiring example
Working	Current-session state: the in-flight task, intermediate results, tool outputs	The scratchpad of an active candidate search, filters applied so far
Episodic	Records of specific past interactions	A March chat where a candidate asked to be revisited after her visa transfer
Semantic	Distilled facts and domain knowledge	The hard requirements of a req, generalized across many conversations
User-profile	Stable preferences of the person using the agent	This recruiter wants bullet summaries and skips phone screens for senior roles

An honesty note on sourcing: the layer names, their intent, and the persistence goal are confirmed from the team's own descriptions. The specific write triggers, retention windows, and retrieval mechanics in the rest of this article are a reconstruction from the taxonomy and comparable production systems, not LinkedIn's disclosed spec. The architecture is the transferable part; the implementation details are one sound instantiation.

One detail stands out by omission: nothing described publicly suggests a separate procedural layer for learned skills. Skills stay in prompts and tools, keeping the memory stores about facts and people, which is a simpler surface to govern.

The four layers of AI agent memory

LinkedIn did not invent this shape. The four-store design converged from three directions that largely ignored each other. MemGPT-style systems page data between the context window and external storage, treating working memory the way an OS treats RAM. ChatGPT ships a visible, editable profile store, and other agent products are moving toward self-updating instructions. Simulation research arrived at the same place with memory streams. When independent lineages land on one architecture, the architecture is doing real work.

The most under-copied piece sits in the simulation lineage. The Generative Agents paper paired a memory stream with a reflection step: agents periodically reread their own episodic records and wrote distilled insights back. That reflection step is the episodic-to-semantic promotion mechanism, and it is the piece most production stacks skip. Skip it and your memory store becomes a write-only log: episodes pile up, nothing gets distilled, similarity search starts returning near-duplicates of the same old chat, and the store you built to save tokens starts costing attention.

The academic taxonomy agrees. CoALA (Cognitive Architectures for Language Agents, Sumers and colleagues, 2023) formalizes the same split, and LinkedIn's design maps almost cleanly onto it:

• Working memory is the scratchpad of the current turn or session.
• Long-term memory divides into episodic records, distilled semantic facts, and procedural skills.
• User-profile memory is CoALA's semantic store with governance boundaries drawn around it: facts about a person need editability, consent, and expiry in a way facts about a req never will.

The one divergence is procedural memory, the layer the hiring assistant leaves out, at least in what has been described publicly. The omission reads as deliberate. A learned skill is a behavior, not a fact, and you cannot show a behavior to a user in an edit table. Procedural memory is the hardest layer to audit and revoke, which is why production systems keep skills in prompts and tools, where code gets review, versioning, and rollback. LinkedIn's contribution is consolidation, not novelty: four known mechanisms under one governance model, each layer with its own write trigger and decay policy.

What to persist and what to recompute

Every piece of agent state belongs to one of two economies. State that recurs across sessions earns storage; state that perishes with the task earns deletion, because persisting it costs writes, adds retrieval noise, and eventually goes stale and poisons a future turn.

Persist what recurs. Recompute what perishes.

Three questions sort any candidate state:

1. Does it outlive this session? If not, it is working memory at most.
2. Would a future turn or another session benefit from knowing it? If yes, it earns a write.
3. Is it cheap to rederive? If rederiving costs less than storing, retrieving, and maintaining it, recompute.

Apply the test to a single hiring-assistant turn: find backend engineers in fintech who did well on past screens.

State in play	Outlives session?	Cheap to rederive?	Verdict
Search filters applied this turn	No	Yes	Recompute (working)
Reasoning over the candidate ranking	No	Yes	Recompute
Candidate asked to be revisited in Q3	Yes	No	Persist (episodic)
Req requires 5+ years and London on-site	Yes	Eventually	Distill into semantic
Recruiter wants three-bullet summaries	Yes	No	Persist (profile)

The asymmetry cuts both ways. Persisting perishable state produces the classic bug: store "three open reqs" as a fact and the agent will confidently cite it for weeks after the fourth opens. Persisting nothing produces the blind session from the opening. Good AI agent memory design sits between those two failure modes, and token economics tell you exactly where.

When a memory write pays for itself in tokens

The token cost of writing agent memory is real. The write path runs an extraction pass over a finished session, emits candidate memories, then pays curation work to dedupe, merge, and resolve conflicts. The read path saves tokens whenever a future request injects a compact memory block instead of the raw history it replaces.

A worked example, assumptions stated, because transcripts and prices vary:

• Finished session transcript of 6,000 tokens; the extraction call reads it and emits 300 tokens of memories. Write cost: about 6,300 tokens, paid once.
• Alternative pattern: inject a 20,000-token history block into each request versus a 1,000-token memory assembly.
• A typical future session makes 10 model calls: 200,000 tokens of history reads versus 10,000 with memory. Savings: 190,000 tokens per session.

One 6,300-token write pays for itself a few requests into the very next session. Generalized, the payback condition is: (tokens saved per read) × (expected future reads) exceeds (extraction cost + curation cost). Persistent AI agents earn their storage through recurrence; single-session state never crosses the threshold.

Published evaluations support the shape of the arithmetic, if not your exact numbers. Mem0's published evaluation reports roughly 90 percent token savings against feeding full conversation history, with tail-latency wins as well. Run your own numbers, but the ordering is robust: distilled memory beats raw history, and the margin widens the longer the relationship runs.

How personalization memory goes stale

Profile memory is the layer of AI agent memory most likely to rot, because it stores claims about people, and people change.

The quiet failures look like this: a recruiter who preferred phone screens for everything now skips them for senior roles, says so once, and the agent keeps scheduling screens because the old preference still sits in the store with equal weight. Or a candidate changes title, company, and city, and the agent keeps routing opportunities to a person who no longer exists.

Last-write-wins is not an invalidation policy. Durable personalization state needs at least three explicit mechanisms:

• Expiry by TTL. Every entry carries a lifetime; "open to offers until March" is not a permanent fact. Semantic and profile records get reviewed or decayed on a schedule rather than stored forever by default.
• Contradiction handling. When a new statement conflicts with a stored one, the system should detect it, prefer the recent, and log the conflict rather than silently keeping both or blindly overwriting. Recency-weighted merges with timestamp provenance are the standard shape.
• Human visibility. ChatGPT-style memory controls show users what is stored and let them edit or delete it. In a hiring product this is table stakes: recruiters will tolerate an agent that forgets; they will not tolerate one they cannot correct.

The failed state to remember: the store holds two contradictory preferences, the agent alternates behavior between sessions, and the user concludes the product is broken, because from the outside it is.

Where privacy boundaries belong

Hiring is the stress test for agent memory architecture, because the layers carry very different legal weight. The most common and most expensive mistake is consolidating them into one store with one retention policy and one access path.

Layer	Privacy class	Retention	Access
Working	Transient session data	Session-bound, aggressive cleanup	User in session
Episodic	Candidate personal data	Tied to application lifecycle, honoring deletion rights	Recruiter on the req, logged access
Semantic	Internal knowledge, often mixed with candidate facts	Versioned, reviewed on schedule	Team-scoped
User-profile	Personal data about your own user	Editable, visible, short default TTL	The recruiter, always

Two notes. Profile memory is still personal data, just about the recruiter rather than the candidate, which is why editability belongs at that layer specifically. And the regulatory floor is high: regimes like the EU AI Act classify employment and recruitment AI as high-risk, which triggers documentation, logging, and human-oversight obligations. A per-layer privacy model is not just hygiene; it is the shape a compliance review will force on you eventually, and building it late means migrating live stores of people's data.

A four-layer blueprint to copy

Everything above compresses into one table. Treat it as a starting point, not LinkedIn's spec.

Layer	Write trigger	Store	Retrieval	TTL	Privacy class
Working	Every turn	Session state object	Passed on each call	Session	Transient
Episodic	Session close	Append-only summaries keyed by entity	Similarity search on the task	Months, reviewable	Candidate data
Semantic	Distillation job over episodic store	Versioned fact records	Direct lookup	Long, scheduled review	Internal
User-profile	Explicit statement or repeated pattern	Small editable record	Always injected	Short default, user-controlled	Recruiter personal data

A minimal first implementation

1. Keep working memory as a state object your agent loop already owns; persist nothing from it past the session.
2. At session close, run one extraction prompt that emits a handful of memories, each with an entity key, timestamp, and source session id.
3. Store episodic records as plain rows and retrieve the top few by embedding similarity to the current task.
4. Run a nightly job that promotes repeated episodic facts into semantic records and flags near-duplicates.
5. Keep profile entries in their own table, expose them in the UI for editing, and timestamp every write.

One record schema covers all four layers:

{
  "layer": "episodic",
  "entity": "candidate:priya-s",
  "text": "Asked to be revisited after her visa transfer",
  "source_session": "sess_8812",
  "written_at": "2026-03-14",
  "confidence": 0.82,
  "ttl_days": 120
}

Pitfalls that sink memory systems

• One undifferentiated store for all four layers.
• Last-write-wins updates with no conflict detection.
• Persisted scratchpad that was cheap to recompute.
• No observability into which memory fired. When an agent asserts something odd, the first debugging question is which memory that came from; if you cannot answer it per layer, you cannot debug personalization at all.

Closing the loop on the blind session

Put the recruiter from the opening back in a fresh session. Working memory holds this turn's filters, episodic memory recalls the March conversation, semantic memory carries the req's hard requirements, and profile memory keeps the summaries to three bullets. Nothing was relearned, nothing stale fired, and four small governed stores did a job no context window can do on its own. That is the design, and it copies.