LinkedIn Benchmarked Nine Memory Systems For Its Hiring Agent, Seven Lost To Pasting Everything Into The Prompt

SnackOnAI Engineering | Senior AI Systems Researcher | Technical Deep Dive | August 11, 2026

This issue dissects Hierarchical Long-Term Semantic Memory for LinkedIn's Hiring Agent, accepted to the KDD 2026 Applied Data Science track, presented in Jeju this week. Ten authors from LinkedIn, fully deployed in production behind Hiring Assistant.

Covered: the schema-aligned tree topology and why it beats semantic clustering, the multi-view node representation, the retrieval scoring math and one normalization choice that decides whether the system works at all, the lossless incremental indexing, and a hard reading of the results tables.

Excluded: LinkedIn's broader agent orchestration stack, and the appendix evaluations on privacy isolation and incremental indexing, which I could not retrieve in full. Where I do arithmetic, the inputs are transcribed from the paper's tables and the computation is mine.

HLTM is the long-term memory behind LinkedIn's Hiring Assistant. It answers questions like "what kind of candidate does this recruiter usually hire" by reading everything that recruiter has ever done and returning a grounded answer with node-level citations.

The framing that matters: this is not a chatbot memory. It is a multi-tenant enterprise index where a wrong retrieval is a data leak, not a bad answer.

The architecture in one sentence. Build a tree whose shape is copied from your business ownership model, not from embedding clusters. Put three different representations of the same content at every node. Restrict every query to a subtree before you retrieve anything. Update only the ancestor path when a leaf changes.

Scale, from the paper: ~53M tokens of history across 1,341 human-labeled queries, ~40K tokens of history per query, millions of documents ingested daily in production, six months of live operation. Backbone for the published evaluation is GPT-4o mini with text-embedding-3-large.

Caption: Focus on Step One. The privacy filter runs before retrieval, not after ranking. That ordering is the difference between a compliance control and a suggestion.

Equation Three looks like a boring scoring detail. It is the load-bearing choice in the retrieval path.

Caption: Same inputs, same embeddings, same cosine. The only difference is what you divide by.

I ran both. Query: the paper's own example, "typical workplace for hiring software engineers in the San Francisco Bay Area," parsed into two micro-queries. Node: two matching facets and eight unrelated ones.

Caption: The top-k form is flat. The naive form decays toward the noise floor as a node learns more.

Here is why that matters and why it is not obvious. In a hierarchical memory, the nodes holding the most facets are the aggregated parent nodes. Those are precisely the nodes that broad summary queries need to retrieve. Under the naive normalization, every act of aggregation makes a parent node less retrievable. You would build the tree, watch summary quality get worse as the tree got richer, and spend a quarter blaming the summarizer.

Caption: Two design decisions in nine lines. Filter before ranking, and give every view its own guaranteed budget instead of one blended score.

Input: a recruiter edits one hiring project at 09:14.

Now the cost comparison at three deployment sizes, assuming fifty seats per account and twenty projects per seat:

Caption: Update cost is O(tree height), not O(number of nodes). At a million leaves the same edit still touches three nodes, which is what turns a nightly batch job into a nearline pipeline measured in minutes.

The word doing the work is lossless. Every parent is recomputed from its current children, so the incremental result is identical to a full rebuild over the latest snapshot. GraphRAG's incremental path is lossy and still needs periodic full re-indexing. That is a real operational difference: one system has a maintenance window and the other does not.

The paper's abstract claims correctness up more than five percent and retrieval F1 up more than ten percent. Those numbers are true and badly undersell the table.

Caption: The abstract quotes the weakest of its own three headline results. Correctness is the metric closest to saturation and therefore the least flattering.

Now the decomposition that reframes the architecture:

Caption: HLTM beats full-context on precision by 63.7 percent and on recall by 2.9 percent. The tree is not finding more. It is returning less garbage.

The usual way to win a correctness benchmark is to spend more time. Figure Two says HLTM did not.

Caption: HLTM sits in the upper left. RAG matches it on latency and gives up 0.122 correctness. HippoRAG is the closest baseline on quality and pays roughly double the query time to get there, because graph traversal happens online.

That gap is the payoff for moving work across the serving boundary. HippoRAG does its reasoning at query time. HLTM did it at indexing time, months earlier, and the online path is three embedding lookups and one generation call. Figure Five makes the same point on the other axis: HLTM lands on the Pareto frontier of indexing latency against query latency rather than trading one for the other.

That is the sentence I would put on the whiteboard. Everyone building agent memory talks about recall, about not losing information, about the needle in the haystack. LinkedIn's own numbers say the haystack was never the problem. Full-context already had 0.849 recall by brute force. What it could not do was stop shoveling irrelevant history into the context window.

Why it works. Enterprise data already has a hierarchy and it is not the one embeddings would discover. Accounts own seats, seats own projects. That ownership chain is stable, auditable, and already enforced everywhere else in the stack. Copying it into the memory index means the privacy boundary and the retrieval boundary are the same object.

Semantic clustering cannot offer that. A cluster is a statistical artifact that can straddle two customers, and it moves when you add data. The paper names both failure modes: clustering can mix content across business scopes, and new data triggers re-clustering, which means topology drift and periodic full re-indexing.

What it trades away.

You must have a schema. This is the big one and the paper does not dwell on it. HLTM's central mechanism is unavailable to anyone whose data lacks a clean ownership tree. A consumer chat assistant has sessions and messages, which is a hierarchy but a shallow and semantically arbitrary one. The privacy scoping argument evaporates entirely in single-tenant consumer settings.

Offline cost is real, it is just moved. Three LLM agents run per node at ingestion, then aggregation runs an LLM per parent, recursively to the root. The token bill does not vanish. It converts from per-query variable cost into amortized indexing cost, which is a good trade only when the read-to-write ratio is high.

Rough arithmetic on the eval set: 1,341 queries at ~40K tokens of history each is 53.6M input tokens for one full-context pass. Retrieving a couple thousand tokens per query instead puts you near 2.7M, roughly twenty times fewer input tokens at serving time. Every one of those saved tokens was already paid for once, offline.

Three views means three embedding indexes. Facets, questions, and summaries each get embedded and indexed separately, and each aggregated parent regenerates all three. Storage and index maintenance scale with views times nodes.

And the ablation complicates the story I just told. Table Four reports single-representation variants, and the finding is that the summary view contributes most to overall performance, with facet and QA memories providing complementary gains. All three together is best, but the ranking is worth sitting with: the plainest retriever, one cosine against a one-sentence summary, carries the most weight. The facet retriever, the one with the carefully normalized per-micro-query top-k that I spent a section admiring, is a contributor rather than the engine.

Read that as a warning about where engineering effort goes. The sophisticated component was necessary to keep aggregated nodes retrievable at all, which is why the normalization matters, but it was not where the quality came from. The same ablation shows that restricting retrieval to leaf nodes only, which is to say keeping the tree but refusing to use the aggregated levels, causes a clear drop in summary-style correctness. The hierarchy earns its place. The elaborate scoring on one of its three views earns rather less.

The adaptation loop can chase its own tail. Mining historical query patterns to decide what to memorize means the system gets better at questions people already ask and no better at questions they gave up asking because it used to fail. The paper mitigates with minimum-support thresholds and optional human review, which is honest, but the feedback loop is structurally self-reinforcing.

Not the tree. Trees are free.

The schema is the moat, and LinkedIn owns it. Accounts, seats, projects, and the access-control policy that governs them are a decade of product surface. Anyone can implement subtree-scoped retrieval in a week. Almost nobody has an ownership hierarchy that is simultaneously the privacy model, the billing model, and the natural granularity of the user's mental model.

The labeled evaluation set. 1,341 queries with gold answers, each independently annotated by at least three domain experts with majority-vote resolution, split into 473 retrieval-style and 868 summarization-style. Plus a human alignment study on roughly 200 triples where inter-annotator agreement measured by quadratic weighted Cohen's kappa exceeded 0.8, with the LLM judge validated against consensus labels at the same threshold. That is expensive, unglamorous, and it is why their numbers mean something.

Provenance as a first-class return value. Every answer returns the node IDs used as grounding evidence. Not a bolt-on citation feature, an output of the retrieval contract. In a hiring product this is not a nice-to-have. It is what lets a recruiter, a compliance reviewer, and an engineer debugging a bad answer all look at the same object.

Set the bar at doing nothing. Full-context prompting has no index, no ingestion pipeline, no vector store, no operational burden. Paste the history in and ask.

On LinkedIn's dataset, full-context scores 0.791 correctness and 0.544 retrieval F1.

Seven of the nine competing memory systems score lower on correctness: RAG, Schema Filter, A-Mem, RAPTOR, GraphRAG, SimpleMem, and Mem0. Only HippoRAG (0.833) and ReadAgent (0.796) clear it. Four of nine also lose on retrieval F1.

GraphRAG is not close. Token-F1 0.114, correctness 0.381, retrieval F1 0.084. That is not underperformance, that is a system failing to engage with the data shape. Enterprise hiring history is ownership-structured, not entity-relationship-structured, and community summarization has nothing to grab onto.

The uncomfortable implication for anyone shipping an agent this quarter: if your history fits in the context window, the burden of proof is on the memory system, and on this benchmark most of them do not meet it. Memory earns its complexity through cost, freshness, multi-tenancy, and provenance. It does not automatically earn it through quality.

HLTM explicitly builds on RAPTOR's collapsed-tree retrieval. Same paradigm: flatten all levels into one candidate pool, retrieve across granularities. So RAPTOR is the cleanest possible ablation of everything except the tree's shape.

RAPTOR ranks second of eleven on summary-style Token-F1 at 0.539. It ranks tenth of eleven on retrieval-style F1 at 0.348, with precision 0.332.

HLTM's retrieval F1 is 2.25 times RAPTOR's. Its retrieval precision is 2.29 times RAPTOR's.

Read those two rows together and the mechanism is unmistakable. Semantic clustering is good at synthesis and destroys entity identity. When you cluster leaf documents by embedding similarity and summarize the cluster, "which project was this" stops being recoverable. Summary queries do not care. Retrieval queries are nothing but that.

So the honest one-line summary of this paper is not "hierarchical memory works." RAPTOR was already hierarchical. It is "let the business schema pick your topology and you get entity identity, privacy scoping, and stable incremental updates for free, all three from the same decision."

Which is also the limit. That decision is only available if the schema exists.

Full-context prompting beats most memory systems overall, and scores 0.067 on the one query type LinkedIn's product is actually built on.

The LongMemEval-s breakdown, full-context by question type:

Everything is in a normal range except one number that falls off a cliff. On preference questions, plain RAG scores 0.528 and A-Mem scores 0.567. Those are 7.9x and 8.5x better than full-context on the same task by systems that full-context beats overall.

Now recall what Hiring Assistant does. It reads a recruiter's history and infers what kind of candidate they tend to hire. Typical titles, typical locations, typical qualifications. That is preference synthesis, top to bottom. It is the feature LinkedIn's product page leads with, and it is the exact capability where stuffing the context window returns essentially nothing.

The reason is structural, not about context length. Preference is not stated anywhere in the history. It is a pattern that only exists across many documents, and it has to be computed. A model reading 40K tokens of raw project logs is being asked to induce a distribution while also doing retrieval, and it does the retrieval. HLTM computes the preference offline, at aggregation time, when there is no latency budget and nothing else competing for attention, and stores the result as a first-class object.

That reframes the entire case for agent memory. The usual pitch is cost and context limits, and on those grounds the LinkedIn table says most memory systems lose. The real argument is that some questions cannot be answered by reading, only by having already computed the answer. Find the query types in your product that sit on that cliff. If you do not have any, your context window is probably enough. If you do, no amount of context length will save you.

Imagine a recruiter who has run two hundred hiring projects over three years. Somewhere in that history is an answer to "what kind of engineer does this person usually hire," but it is not written down anywhere. No document says it. It only exists as a pattern spread across hundreds of separate records.

An AI assistant has two ways to answer. It can read all two hundred projects every time someone asks, which is slow, expensive, and, it turns out, surprisingly bad at spotting patterns. Or it can work the answer out ahead of time and file it somewhere it can be looked up in a second.

The second approach is what people mean by giving an AI agent memory. The hard part is not storing things. It is deciding how to organize them.

Most systems organize by meaning: group similar things together, summarize each group. That works nicely for a library of articles. It works badly for a company, because groups formed by similarity can accidentally span two different customers, which is a privacy problem, and because adding new information reshuffles the groups.

LinkedIn's answer is to stop inventing an organization scheme and copy the one the business already has. Projects belong to recruiters, recruiters belong to companies. Build the memory in exactly that shape. Now restricting what a recruiter can see is the same operation as picking a branch of the tree, and adding new information only touches one path from a leaf up to the root.

The broader lesson reaches past hiring. As AI agents move into enterprises, the winning designs are likely the ones that inherit structure the organization already maintains, rather than inventing a parallel structure that has to be kept in sync and defended separately.

The interesting claim in this paper is not that hierarchical memory works. RAPTOR established that in 2024 and its summary-style numbers here are still second best of eleven.

The claim is that when your data already carries a structure someone else is obligated to maintain, inheriting that structure gives you three things at once: an entity identity that survives aggregation, a privacy boundary that is enforced by construction rather than by ranking, and an update path whose cost is the height of the tree. No amount of clustering sophistication produces any of the three.

The corollary is the part to sit with. Most teams reading this do not have that schema, and for them the honest reading of LinkedIn's table is bleaker than the abstract suggests. Full-context beat seven of nine memory systems.

So run the cheap experiment before you run the expensive one. Take fifty real queries from your product, bucket them by type, and answer each one twice: once by stuffing the whole history into the context window, once through whatever memory system you are considering. Then look for the bucket where full-context falls off a cliff the way it did at 0.067 on preference synthesis.

If that bucket exists and it is what your product sells, build the index. If it does not, the context window is already your answer, and the most valuable thing in this paper is permission to not build the thing.

LinkedIn's HLTM organizes agent memory into a tree whose shape is copied from enterprise ownership rather than discovered by embedding clustering, which delivers entity identity, privacy scoping by subtree, and updates costing tree height instead of node count. Its published tables show it beating the best baseline by 26.7 percent on retrieval F1, almost entirely through precision rather than recall. The same tables show seven of nine competing memory systems losing to plain full-context prompting, which is the most useful and least discussed result in the paper.

Tax season doesn't have to mean wondering if you have the right forms, second-guessing your deductions, or scrambling to pull everything together before the deadline.

With BELAY’s tax prep support, you can approach tax season with confidence. Stay organized with one centralized place to gather and check off your documents, keep track of valuable deductions like HSA contributions and education expenses while leaning on experienced professionals who make tax preparation accurate, efficient, and completely hands-off.

Download BELAY's free Personal Tax Checklist and start preparing with confidence, today.

Download the Free Checklist