Building LinkedIn's First Production Agent: Hiring Assistant Platform and Architecture

linkedin · HR · 2025 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.0 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: HR & recruiting software (enterprise SaaS)

LinkedIn wanted to move recruiters from a manual, filter-driven search workflow (40+ facets, human-driven query refinement) to task automation with an agent, targeting the most time-consuming cognitive task: reviewing hundreds of candidates against role qualifications. Two prior product generations showed that translating natural language into constrained structured queries loses information, and that a monolithic LLM block cannot be quality-engineered by a team. Hiring Assistant is LinkedIn's first production agent, built together with a reusable agent platform.

Constraints:

• professional daily-use quality bar: recruiters must not have to wonder whether the AI will do the right thing
• online latency and capacity limits, with some paths (candidate evaluation) at orders-of-magnitude higher scale than conversational paths
• multi-region operation with traffic shifts a few times a day, host outages, and ephemeral failures
• trust, privacy, security, and responsible AI requirements including guardrails and runtime moderation
• fast-moving ecosystem: framework and model choices must remain swappable

Architecture

A supervisor agent treats specialized sub-agents (intake, sourcing, candidate evaluation) as invocable tools; the intake agent converts free-text hiring intent into human-readable qualifications instead of lossy structured queries, and the sourcing agent runs many parallel searches against the existing Recruiter Search index. All of it sits on a shared agent platform: a prompt source-of-truth service (namespacing, versioning, backward-compatibility checks), an OpenAI-compatible LLM inference proxy (config-based model switching, quota enforcement, runtime moderation), LangChain/LangGraph behind LinkedIn-owned adapters, messaging-based agent-to-agent orchestration reusing LinkedIn's production messaging platform (FIFO threads, nearline retries, retargeting across regions), scoped and layered memory (working, episodic, procedural, collective) with retrieval via recency, summarization and vector search, a central skill registry with runtime skill selection and service-principal authorization, and OTel-fed aggregated observability built for non-deterministic flows.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  messaging-orchestration[Messaging platform + agent orchestrator] --> supervisor-agent[Supervisor agent]
  supervisor-agent --> intake-agent[Intake agent]
  supervisor-agent --> sourcing-agent[Sourcing agent]
  intake-agent --> skill-registry[Skill registry]
  sourcing-agent --> skill-registry
  sourcing-agent --> recruiter-search-index[Recruiter Search index]
  recruiter-search-index --> candidate-evaluation[Candidate evaluation]
  candidate-evaluation --> llm-inference-proxy[LLM inference proxy]

Components

Data flow

A recruiter submits hiring intent (optionally attaching a job posting or notes). The supervisor agent classifies the intent and routes the request to the intake agent, which looks up recruiter preferences via skills and generates a set of textual qualifications. The sourcing agent reads those qualifications, uses skills to generate multiple search queries in parallel, and feeds them through the Recruiter Search index. Returned candidates flow to the candidate-evaluation task, where a fine-tuned model checks each qualification against the profile and resume and emits citations. When the agent cannot proceed, it escalates to a human. All user-agent and agent-agent hops travel as messages (structured payload + free-text instructions) through the messaging platform, with FIFO ordering inside a thread and nearline retry/retargeting on failure; sub-agents are reached via RPC endpoints behind the agent orchestrator.

Why this architecture

Modularity is the load-bearing decision: sub-agents (like the earlier copilot's specialist modules) can be developed and quality-iterated in parallel and in isolation, which is how a team of engineers scales work on a non-deterministic system — accepting compounded per-stage error in exchange for engineerable sub-components. Messaging was chosen as the orchestration substrate because agentic workloads face exactly the distributed-systems problems (state consistency, traffic shifts, host outages, ephemeral failures) that LinkedIn's messaging platform already solves. Platform abstractions (prompt service, inference proxy, framework adapters, skill registry) exist to standardize boilerplate, keep models and frameworks swappable in a fast-moving ecosystem, and give central enforcement points for quota and trust.

Models used: GPT-4o (development iteration on agent chains) · Azure OpenAI models · EON (LinkedIn multitask instruction-tuned open-source LLMs on economic graph data) · on-prem hosted fine-tuned open-source models

Scale

• The candidate-evaluation path scales with candidates, not recruiters: thousands of applicants per job and hundreds of results per sourcing search — orders of magnitude beyond the conversational intake path.
  “for a given job, you might have thousands of applicants, or for if you're sourcing, you might run a search and come back with hundreds of results. If we're going to evaluate all of those, that's going to scale with the number of candidates.”article, stated
• The platform operates multi-region with routine traffic shifts several times a day, so agent execution must survive region moves and host loss.
  “You have to handle traffic shifts, if you shift traffic out of a region, go to another region. At LinkedIn we do this a few times a day.”article, stated
• The recruiter product surface is mature and complex: over 40 search filters and facets, in production since 2008.
  “As of today, there's over 40 search filters and facets you can put on there.”article, stated
• General-purpose LLMs already know the jobs domain because 4M+ job descriptions exist in Common Crawl, which shaped the choice to start from general models and adapt.
  “you'll find over 4 million job descriptions that can be identified based on metadata associated with them”article, stated

Alternatives considered (roads not taken)

A single monolithic LLM block (prompt template + RAG few-shot examples) for query understanding, as prototyped

Rejected because: Any few-shot example added to fix one behavior can change unrelated behavior; the whole context influences the output, which bottlenecks a team trying to engineer quality in parallel.

Keeping the coach-era interface: translating natural language into the existing structured search facets

Rejected because: Rendering open-ended natural language into a constrained logical structure loses information; the agent instead preserves intent as human-readable textual qualifications used for search and evaluation.

Hand-implementing tool integrations inside every LLM application

Rejected because: It does not scale across teams; LinkedIn inverted the dependency into a central skill registry where every service/agent owner exposes skills that are retrieved and selected at runtime.

Sending prompts inside inter-agent messages

Rejected because: Messages carry structured data plus free-text instructions instead; already-structured data should not round-trip through natural language and risk information loss.

Relying on huge context windows instead of scoped memory with precise retrieval

Rejected because: Long context is slower, more expensive (token-bound), and increases hallucinations, so memory retrieval uses recency, summarization, and semantic vector search.

Patterns

multi-agent-orchestration (orchestration)

A supervisor agent invokes specialized sub-agents (intake, sourcing) as tools, passing information down and acting on returned results; the prior copilot's entire flow became one skill under one agent, applied hierarchically.

tool-use-orchestration (orchestration)

Skills (richer than tools: RPCs, database queries, prompts, even other agents) live in a central registry; at runtime the agent selects the most appropriate skill dynamically and fills its arguments, rather than having tools hardcoded per application.

async-message-orchestration (orchestration)

All user-agent and agent-agent communication is modeled as messages on LinkedIn's production messaging platform, inheriting its delivery, retry, retargeting, and thread semantics: FIFO within a thread for sequential context, multiple threads for parallelism.

agent-memory (context)

Memory is scoped and layered — working memory for task context, long-term episodic and procedural memory, experiential memory learned from human interactions, and collective memory at recruiter/company/role granularities — with retrieval via most-recent-N, summarization, and semantic vector search.

model-routing (model-operations)

Model choice is split by path economics: state-of-the-art general models (e.g. GPT-4o) where iteration agility matters, fine-tuned smaller models on the orders-of-magnitude-larger candidate-evaluation path; a config-driven inference proxy lets teams switch models on the fly.

human-in-the-loop-gate (governance)

Escalation to a human is an explicit agent-era concept: when the agent cannot do something it hands off, and the human's response feeds back into the loop.

eval-driven-development (evaluation)

Each sub-agent has a defined input/output surface evaluated in isolation via a common quality playbook: human rubrics first, transitioning quickly to LLM-driven, reference-free automated evaluation to unblock iteration speed; candidate evaluation itself emits per-qualification citations.

observability-tracing (operations)

Because agentic flows are non-deterministic, classic observability fails; LinkedIn built sophisticated aggregation feeding OTel traces and analytics dashboards, used both for single-invocation debugging and production-scale aggregates.

Tradeoffs

System decomposition: modular sub-agents versus one monolithic LLM block.

Chose supervisor plus specialist sub-agents developed and evaluated in isolation over a single prompt-template-plus-RAG block.

Rationale: Parallel team development and per-component quality engineering outweigh the compounding per-stage error that modularity introduces.

Model selection split by path scale characteristics.

Chose state-of-the-art general models for fast-iterating, recruiter-scaled paths; fine-tuned smaller models for candidate-scaled paths over one model class everywhere.

Rationale: Iteration agility needs best instruction-following; the evaluation path is orders of magnitude larger and needs cheap, specialized inference.

Orchestration substrate for distributed agent execution.

Chose message-based orchestration on the existing LinkedIn messaging platform over building new distributed state/retry machinery for agents.

Rationale: Agentic workloads share messaging's failure modes (state consistency, traffic shifts, outages), so reusing its resilience machinery avoids re-solving them.

Framework adoption posture.

Chose LangChain/LangGraph behind LinkedIn-owned adapters and platform layers over coupling application code directly to the framework.

Rationale: The space moves fast; layering keeps the framework swappable relatively cheaply.

Build-versus-buy default for agent infrastructure.

Chose buy/adopt existing components wherever available over investing in a fully custom stack.

Rationale: A fast-moving ecosystem punishes heavy in-house investment by making new capabilities hard to adopt.

When to use an LLM at all inside an agent.

Chose procedural code for simple workflow automation; LLMs only where reasoning is required over LLM calls as the default mechanism.

Rationale: Procedural code is more stable and faster; reasoning is the only thing that justifies the LLM's cost and nondeterminism.

Degree of model customization.

Chose prompt engineering and RAG first; fine-tuning and pre-training only when required by quality, scale, or latency over reaching for custom models early.

Rationale: Techniques at the top of the customization pyramid are expensive and hard to maintain while models evolve quickly.

Execution concurrency model for agent communication.

Chose FIFO ordering within a thread, parallelism by creating multiple threads over fully linear or fully parallel execution.

Rationale: Context and reference require sequential delivery within a task, while independent work should fan out.

Gotchas (what bit them)

Errors compound multiplicatively across modular LLM stages.

Root cause: Each stage is statistical; chaining two 90%-accurate stages yields 81% end-to-end.

Resolution: Accepted deliberately: engineer each sub-component to very high quality in isolation so the overall system still wins versus one unengineerable block.

In a single LLM block, fixing one behavior with a few-shot example silently changes other behaviors.

Root cause: The whole context influences non-deterministic output; examples are not isolated patches.

Resolution: Modular architecture with an interpreter/coordinator and specialist chains (later, sub-agents) so instructions for one concern cannot leak into another.

Classic observability tooling fails on agentic systems.

Root cause: Flows are inherently non-deterministic, so per-request traces do not yield insight on their own.

Resolution: Purpose-built aggregation over traces/events/logs feeding OTel and analytics dashboards, for local debugging and production aggregates.

Fine-tuning fights product iteration while the problem statement is still moving.

Root cause: Fine-tuning optimizes aggressively within a well-defined problem; an evolving product keeps redefining it.

Resolution: Multitask instruction tuning (EON): fine-tune open-source LLMs on LinkedIn economic graph data while preserving instruction-following, outperforming same-size open-source models yet staying steerable.

A bare text box is bad agent UX despite seeming ideal.

Root cause: Users carry the overhead of guessing what to type and whether it will work.

Resolution: Finer-grained controls (e.g. clickable personalization filters next to the editable AI message) instead of free text everywhere.

Spinners and static UIs fail for long-running agent work.

Root cause: Agents do heavy asynchronous work; users waiting on a spinner get irritated.

Resolution: Show progress indicators only for reasonably fast responses; otherwise use an explicit async flow with an ETA and notification when done.

A central skill registry can silently grant every agent dangerous capabilities.

Root cause: Any developer can register a skill wrapping a destructive service endpoint, and dynamic skill selection would expose it broadly.

Resolution: Service-principal authorization applied transitively to agents: an agent must hold the registered principals to call a skill.

Evaluation

A common quality playbook per sub-agent: define the input/output surface, write human rubrics, then transition quickly to LLM-driven, reference-free automated evaluation so quality iteration is not bottlenecked on human annotation; components are measured in isolation and then stitched together for overall-agent evaluation. The candidate-evaluation output itself is evidence-based, citing where each qualification is supported on the profile or resume.

Metrics: per-component quality rubrics (human, then LLM-automated) · reference-free evaluation scores · per-qualification evidence citations on candidate evaluations

Outcomes

• Hiring Assistant announced by LinkedIn's CEO at Talent Connect (October) and running in a limited charter with select enterprise customers.
• The shared agent platform enabled a parallel SMB-targeted variant of Hiring Assistant built from the same components.
• Skill registry integrates with MCP, which did not exist when the platform was built — evidence the adaptability bet paid off.

First production agent at LinkedIn, built on a platform intended for all subsequent agents; candidate-evaluation path designed for thousands of evaluations per job.