Context Engineering at LinkedIn: How 8,000 Engineers Use MCP to Give Procedural Memory to Their Agents
# Context Engineering at LinkedIn: How 8,000 Engineers Use MCP to Give Procedural Memory to Their Agents
In September 2026, Ajay Prakash, senior engineer at LinkedIn with 14 years building distributed systems and the last four completely focused on AI, took the stage at QCon AI Boston to tell a story the industry had been waiting months for. LinkedIn had solved the hardest problem facing modern coding agents: **how to make an LLM work productively inside a proprietary codebase it never saw during pre-training**. The solution was not a bigger model, nor more context, nor better fine-tuning. It was an **organizational context layer** built on Model Context Protocol (MCP), with over 600 reusable playbooks, 8,000 daily users, and a 20% productivity boost measured in production.
This matters beyond LinkedIn. Because the problem they solved is exactly what any medium or large organization faces when trying to deploy coding agents in its internal codebase: generic agents know how to program, but they do not know **how your organization programs**. They do not know your conventions, your internal frameworks, your past architectural decisions, or the runbooks your senior team has accumulated over ten years of production. Without that layer, the agent produces code that compiles but that a senior reviewer rejects in fifteen minutes because "that is not how we do it here".
The problem: brilliant agents on code they do not understand
LinkedIn has thousands of repositories, microservices, internal frameworks, proprietary libraries, and an engineering culture with decades of accumulated decisions. When they deployed the first commercial coding agents — Copilot, Cursor, Claude Code — the result was what any team can predict: the agent produced code that looked correct but broke the house conventions.
Three typical symptoms:
- **Inconsistent patterns.** The agent solved a cache problem with a standard Python library. The team uses an internal library called `li-cache` with different semantics. The code "worked" but introduced a strange pattern in the codebase. - **Incorrect configurations.** The agent generated a valid Kubernetes manifest. The organization uses Helm charts with specific values per region. The manifest did not deploy. - **Tests that passed locally but failed in CI.** The agent wrote tests assuming a local database. CI uses ephemeral containers with different seeds. The test failed because assumptions were different.
The pattern repeated in thousands of interactions. Senior engineers spent more time correcting the agent than they would have programmed themselves. The productivity boost vendors promised evaporated against the reality of a complex codebase and internal conventions the model never learned.
The solution: three layers in one architecture
LinkedIn tackled the problem in three layers, each attacking a different aspect of the gap between the generic model and the proprietary code.
**Layer 1: agent-friendly tools via MCP.** The first step was exposing LinkedIn's internal systems as tools accessible to agents through a local MCP server. The catalog includes:
- Internal code search with capabilities to understand the syntax and semantics of LinkedIn's proprietary code. - Internal documentation and wikis, indexed for fast retrieval. - Feature flag system with its rollout percentage and target value. - Task management system (internal Jira). - Internal data platforms with their documented APIs. - Production logs and metrics, accessible with scoped permissions. - Deploy history per service, with authors, reviewers, and documented reasons.
The MCP server lives locally on the engineer's machine. The agent — whether Claude Code, Cursor, GitHub Copilot, or any other that supports MCP — can call these tools just as it calls built-in ones. To the model, they are just functions; it does not know or care that they are backed by an internal API instead of an open-source library.
Critical to the design: **the tools were designed thinking about agents from day one**, not adapted afterwards. That means:
- Structured documentation the model can understand without ambiguity. - Typed errors with actionable messages, not generic Java stack traces. - Granular permissions per engineer and project scope. - Rate limiting that prevents an agent in loop from blocking the system.
**Layer 2: procedural memory with playbooks.** Tools solved "access". "Knowledge" was still missing. LinkedIn addressed that second dimension with **playbooks**: reusable units of procedural memory that encode how things are done at LinkedIn.
A playbook has three minimum components:
- **Name** that identifies the task it solves. - **Description** in natural language, readable by humans and models. - **Step-by-step instructions** that an agent can execute, with conventions, commands, validations, and related context.
Simplified example of a playbook for creating an Airflow pipeline:
```yaml name: create-airflow-pipeline description: | Creates a new pipeline in Airflow following LinkedIn conventions. Use this playbook when you need to orchestrate a batch or recurring job that requires scheduling, retries, or external dependencies. instructions: | 1. Identify the team owning the pipeline in /oncall/<team>. 2. Create the DAG file at airflow/dags/<pipeline-name>.py. 3. Always use the LinkedInAirflowOperator; never the standard operator. 4. Configure retries=3 with exponential backoff starting at 60s. 5. Add SLA of 2x the historical p99 of the closest similar job. 6. Document the pipeline in /docs/airflow/<pipeline-name>.md with: purpose, owner, upstream/downstream dependencies, incident runbook. 7. Add the pipeline to the team observability dashboard. 8. Request review from a senior team member before merging. validation: - airflow dags test <pipeline-name> 2024-01-01 - python -m pytest tests/airflow/test_<pipeline-name>.py related_context: - slack://li-eng-airflow - wiki://data-platform/airflow-conventions ```
When an engineer asks the agent "create an Airflow pipeline to process login events every 15 minutes", the orchestrator invokes this playbook via MCP. The agent combines the playbook instructions with the user's parameters, writes the code, executes the validations, and produces a PR ready for review.
Playbooks live in a **central repository** accessible by any employee. Repository-specific playbooks live next to the code they serve. Global playbooks live in a dedicated repo with versioning, ownership, and review process.
**Layer 3: integration in the daily flow.** The last component is making all of this natural in the engineer's day-to-day. LinkedIn reports:
- **8,000 daily users** of the internal MCP server. - **600+ playbooks** active in the catalog. - **20% productivity increase** measured in commit throughput and PR cycle time. - **Zero reliability loss** in the system during adoption.
The reliability metric is important. When you put LLMs in production at that scale, the risk is that agents in loop, poorly designed prompts, or model errors degrade system stability. LinkedIn reports that was not the case: reliability stayed constant while adoption grew. That implies solid guardrails, dedicated monitoring, and probably a rate limiting layer that prevents a zealous agent from making 10,000 calls to a downstream system in five minutes.
Technical anatomy of a playbook in production
The playbook structure LinkedIn documented in their presentation has more nuances than the simplified example above. The real sections include:
```yaml metadata: name: create-airflow-pipeline version: "2.3.1" owner: data-platform-team last_updated: "2026-08-15" review_cadence: quarterly tags: [airflow, batch, data-pipeline]
description: | Full narrative context about when to use this playbook, what problems it solves, what alternatives exist.
prerequisites: | - Write access to the airflow-config repo - Permissions in the observability system - Oncall rotation confirmed with the owning team
steps: - step: 1 action: identify_owning_team details: | Search in /oncall/<domain> for the responsible team. If not found, escalate to data-platform-leads. validation: owner_email_is_set
- step: 2 action: create_dag_file details: | Create airflow/dags/<pipeline-name>.py using LinkedInAirflowOperator as base class. validation: file_exists_and_is_valid_python
- step: 3 action: configure_retries details: | retries=3, retry_delay=timedelta(minutes=1), retry_exponential_backoff=True validation: config_matches_template
- step: 4 action: add_sla details: | SLA based on historical p99 of similar job. Calculate with scripts/analyze_sla.py --similar <name>. validation: sla_documented_in_dag
- step: 5 action: write_documentation template_path: /templates/airflow-doc-template.md validation: doc_has_all_required_sections
- step: 6 action: request_review details: | Assign PR to a senior from the owning team. Do not merge without explicit approval. validation: senior_approval_recorded
post_conditions: - pipeline_appears_in_airflow_ui - dashboard_panel_created - runbook_documented
metrics: - name: time_to_first_run target: "< 24 hours" - name: incidents_per_month target: "< 0.5"
rollback_plan: | Pause the DAG via Airflow UI. Communicate to owning team in #data-platform. Document incident in /postmortems/<date>-<pipeline-name>. ```
This level of structure is not decoration. It is what allows the playbook to work for both humans (who can read and understand it) and agents (who can execute it step by step, validate each step, and detect when an assumption fails).
Why MCP was the catalyst and not something else
LinkedIn chose MCP over internal alternatives for a strategic reason: **open industry standard**. Anthropic released MCP as an open protocol in 2024 and by 2026 it was the de facto standard for connecting tools to agents. This means three concrete things:
**First, avoidable vendor lock-in.** If LinkedIn had built a proprietary protocol, they would have had to maintain adapters for every agent in the market. With MCP, any agent that supports MCP can consume the internal playbooks and tools. Today LinkedIn uses Claude Code, Copilot, Cursor, and others; they all work with the same context layer.
**Second, a community that contributes protocols.** MCP evolves with contributions from across the industry. LinkedIn does not need to invent primitives like "resource sampling" or "elicitation"; they receive them from the standard and focus on the organization's specific value: the playbook content, the tool curation, the integration with internal systems.
**Third, easier recruiting.** A new engineer arriving at LinkedIn who already knows MCP can be productive in hours, not weeks. If the protocol were proprietary, every new hire would have to learn the internal tool before being able to use agents effectively.
The lesson for your organization: if you are considering building a context layer for your agents, **build on MCP** unless you have very specific reasons not to. The opportunity cost of a proprietary protocol at this point in the market is prohibitive.
Lessons any team can apply
The LinkedIn case has five practical takeaways you can start applying this week:
**1. Identify your undocumented conventions.** The first step before building playbooks is to know what conventions you have. Talk to your senior engineers. Read rejected PRs. Look for recurring comments in code review. The knowledge an agent needs to be productive in your codebase probably already exists — it is just in five people's heads and not in any file.
**2. Start with a high-value, low-risk playbook.** Do not try to build 600 playbooks on day one. Pick a repetitive workflow your team does poorly (with bugs, with excessive time) and create a playbook for that. Measure before and after. When you have data, scale.
**3. Version playbooks with the same rigor as code.** An outdated playbook is worse than no playbook: the agent follows it blindly, produces broken code, and the senior engineer assumes the agent is useless when in reality the playbook was wrong. Version, review, update quarterly.
**4. Measure productivity with metrics that matter.** "20% productivity increase" is an impressive number, but meaningless without definition. LinkedIn measured PR cycle time and commit throughput. Choose metrics your team already tracks and compare before/after the playbook. Without that, you cannot defend the program to leadership or iterate effectively.
**5. The playbook is living documentation.** A living playbook gets updated when the team discovers a better way to do something. A dead playbook is a PDF nobody reads. Design the system so updating a playbook is as easy as opening a PR in the central repo.
The architecture of the future: agents as coworkers
What LinkedIn has built is the harbinger of what engineering work will look like in five years. Coding agents are no longer "assistants that suggest code". They are **coworkers that execute complex tasks with guardrails**. The human decides what to do and reviews the result; the agent does the mechanical work following the organization's conventions.
This shift has deep implications:
**First, the senior engineer role evolves.** The senior no longer writes all the code; they review code the agent writes following the playbooks the senior helped define. Seniority is measured by the quality of playbooks they contributed, not by the amount of code they produce directly.
**Second, onboarding accelerates.** A new engineer with access to playbooks can be productive in days instead of months. Conventions, internal frameworks, incident runbooks — all codified in playbooks the agent can consult and apply.
**Third, culture code becomes explicit.** The "things everyone knows but nobody writes" become maintained, versioned playbooks. Culture stops being tribal and becomes executable code.
**Fourth, LLM inference cost becomes predictable FinOps.** 8,000 daily users with a reasonable average cost per session add up to a significant monthly figure. You have to budget, alert, and optimize like any other infrastructure piece.
Final reflection: context is the new code
The industry has been saying for years "prompts are the new code". The LinkedIn case suggests a more accurate version: **context is the new code**. Models are commodities; what differentiates an organization that uses agents effectively from one that struggles with them is the quality of context it provides.
If your team is deploying coding agents and the results are inconsistent, the answer is not "we need a bigger model". The answer is "we need better context": tools accessible via MCP, playbooks that encode our conventions, and a culture that maintains that context layer as a first-class asset.
LinkedIn demonstrated it can be done at scale, with measured results, without sacrificing reliability. The question for your organization is not whether the pattern works — it is proven. The question is when you start building your own context layer.
**CTA:** This week, identify the three most repetitive tasks of your engineering team. For each, write a one-page playbook with the exact steps, conventions, and validations. Publish them in a central repo accessible by your engineers. The following week, set up a minimal MCP server that exposes those playbooks to your coding agent. Measure before and after. In a month you will have data to decide whether to scale the program. The pattern works; what is missing is starting it.