LinkedIn builds a context layer for code agents with MCP

The problem: vibe coding doesn't survive LinkedIn's scale

When "agent mode" arrived in coding tools in 2025 and Andrej Karpathy coined the practice vibe coding, entire teams started prompting in natural language, without looking at the code, trusting that agents would do the right thing. At LinkedIn it didn't work that way, said Ajay Prakash, a software engineer at the company, in a presentation at QCon AI reproduced by InfoQ (https://www.infoq.com/presentations/linkedin-context-engineering/). The reason: LinkedIn's codebase is too large and too mature to fit within any LLM's pre-trained knowledge.

The company has thousands of interdependent repositories and microservices, built on internal frameworks at every layer, with proprietary databases, its own tracking and experimentation system, and observability and configuration management custom-built for LinkedIn's scale. A new engineer spends a week in bootcamp and still takes weeks to become productive just by understanding these systems. Coding agents faced the same obstacle, only without a bootcamp: they made mistakes, hallucinated, or required the engineer to guide them line by line, which cancels out the promised productivity gain.

MCP enters the picture, but solves only part of the problem

The turning point came when Anthropic open-sourced the Model Context Protocol (MCP) and it became the de facto standard for connecting tools to agents; every relevant coding tool started supporting it. LinkedIn's first use was to wrap its internal code search engine in MCP, which already indexed the code of a thousand repositories with keyword search, regex, and language and file-type filters. With that, the agent stopped depending only on what it had learned from open source code and started consulting real examples from LinkedIn itself, including reading entire files when needed.

Then came tools to search documentation and wikis, read feature flags, task management systems, and the data platform. Each new tool expanded the available context, but the team noticed that even with access to all of it, agents still got stuck on slightly more complex tasks.

The three gaps that kept tripping up agents

Prakash summarizes three problems that survived the arrival of MCP:

• Tribal knowledge: instructions on how to install dependencies, compile, or test a specific service are scattered across docs, wikis, and Slack threads, when they aren't just in a senior engineer's head. Even with dozens of tools, the agent couldn't find this information; it was like looking for a needle in a haystack.
• Context overload: each tool call consumes space in the model's context window. When the agent needs to chain many calls to build the full picture, the system ends up compacting the history and losing information, which causes the agent to loop, repeating tool calls it had already made.
• Lack of long-term memory: without durable memory, the agent starts from scratch every time it runs the same task, which wastes time and burns a lot of tokens repeating the same discovery work.

Playbooks: the procedural memory that closed the loop

LinkedIn's answer was to give agents procedural memory, that is, persistent context about how to execute a task. The company called this playbooks, served by the same MCP used for the search tools. A playbook has a name, description, and instructions; the agent discovers and invokes it the way it would any other tool, and gets back the already-validated step-by-step for that type of task.

Prakash cites as an example a playbook for setting up pipelines with Airflow: when an engineer asks "set up an Airflow pipeline for me," the agent identifies that this playbook is available via MCP, invokes it, receives the internal instructions on how LinkedIn structures this type of pipeline, and completes the task with the right context, without needing anyone to explain everything again. Any LinkedIn engineer can create a playbook, which turns context curation into collective work instead of depending on a central team.

This mechanism resembles the concept of "agent skills," which Anthropic itself would later release; according to Prakash, LinkedIn arrived at an equivalent implementation on its own, before this feature existed as a product.

The result the company is showing

In the case described at the opening of the presentation, an agent connected to this set of playbooks and tools is able to identify the cause of a latency alert, trace the problem back to a downstream service, find the PR that introduced the bug, summarize the root cause, propose a mitigation, update the incident management system, and even generate a PR fixing the affected service, all in a few minutes, work that without the agent would take hours. Today the structure supports more than 600 workflows of this kind and thousands of tools registered in the internal MCP. According to Prakash, the aggregate result is a 20% productivity gain without loss of reliability.

What changes for those building agents here

The pattern LinkedIn describes isn't exclusive to American big tech: it's the problem any Brazilian company with a legacy codebase and large teams will run into when trying to put Copilot, Claude Code, Cursor, or any agent to work for real in production. Connecting an agent to a generic LLM solves autocomplete; making the agent reliable on top of your proprietary system requires treating organizational context as infrastructure, with its own layer, versioning, and MCP as the transport protocol, not as an accessory.

In practice, this suggests a roadmap: first expose code and documentation search via MCP before anything else; then catalog repetitive tasks, such as setting up a pipeline, debugging a service, or reviewing a deploy, and turn them into playbooks versioned by whoever actually does that work day to day, not by an isolated platform team. The point the presentation leaves open, at least in the available material, is how LinkedIn ensures the quality and safety of the playbooks themselves: who reviews what an engineer writes as instructions for an agent, and how the company prevents an outdated playbook from spreading errors at scale. That's the next question any team looking to copy this architecture will need to answer before trusting an agent with a production merge.