Why MCP tools still left LinkedIn’s coding agents lost

The on-call coworker LinkedIn is trying to build

The practical question for anyone who has already pointed Claude Code at company search, docs, and tickets is why that still stalls on internal workflows. Ajay Prakash, a LinkedIn software engineer who goes by AJ, answers from inside that stall. MCP tools could retrieve LinkedIn’s surfaces, and agents still got lost on the procedure. His talk, uploaded by the AI Engineer channel, is a failure analysis of that gap, then a walk through the internal system LinkedIn built on top of those tools.

He frames the work as context engineering: shaping what a coding agent can see and call so it can operate inside LinkedIn rather than as generic autocomplete. The hook is an on-call walkthrough he presents as a production story teams already run.

An engineer on a team that owns critical services gets an error-spike alert while still figuring out the incident. The engineer pastes the alert link into a coding agent such as Claude Code or GitHub Copilot. While the human is still oriented, the agent fetches company debug instructions, identifies the affected service, loads service-specific context, and pulls logs and metrics. From those, it proposes a root cause and mitigation steps, then waits for confirmation. After the engineer confirms, Prakash describes the agent taking mitigation actions, updating the incident-management system with details, error metrics, and dashboards, checking out code, and opening a pull request aimed at the root cause.

He says that loop happens in a few minutes of work that would have taken a few hours by hand, labels the walkthrough “not fiction,” and says teams at LinkedIn already use coding agents this way as coworkers with a deep understanding of internal systems and code. The enabling system, in his words, is contextual agent playbooks and tools. The rest of the talk covers why they built it, how they built it, and what they learned.

• Ajay Prakash, LinkedIn — AI Engineer talk (YouTube)

Why handing engineers generic coding agents was not enough

LinkedIn rolled coding agents out to engineers the way many companies did, and Prakash says they did not work well in a large enterprise. His diagnosis is a training-data gap: the models were trained on open-source repositories and lacked LinkedIn’s mature internal codebases, frameworks, and systems.

Without that context, he says, agents hallucinated, stalled mid-task, or invented incorrect details. Engineers then prompted them by hand to do the right thing, which often took longer than writing the code. Many engineers went back to manual coding.

The stack those agents had to learn, as he sketched it, is large and mostly private. New LinkedIn engineers, he says, sit through a week-long boot camp just to get familiar with those systems. He uses that onboarding as the analogy for why agents need the same organizational context.

• Over a thousand repositories feeding thousands of microservices and apps
• Internal frameworks and libraries under those services
• Custom infrastructure such as in-house databases, an experimentation and tracking platform, and an internal configuration-management system

The bar: any agent, trusted internal code

The design question they set was how any coding agent—Cursor, Claude Code, or GitHub Copilot—could understand LinkedIn internals well enough to ship code engineers would trust. Prakash defines that trust in two properties: the code should be correct, and its quality should match code written by an actual engineer.

That is the bar he says the team set.

Internal MCP tools were the first unlock

Prakash dates the first unlock to early 2025. He says Anthropic released MCP, the Model Context Protocol for connecting agents to external tools; that it quickly became an industry standard for building agent tools; and that LinkedIn built an internal MCP server whose first tool was company-wide code search. Automatic captions slip to “MCB” and “Cloud Code”; in the talk this is Anthropic’s MCP protocol and Claude Code.

LinkedIn already had a sophisticated code-search system that could query across thousands of repositories with keywords and custom filters. Exposing that system over MCP let agents find in-house examples of how LinkedIn does a given setup and implement from those findings. Prakash calls that a major unlock: an engineer could ask how to set something up, and the agent could search LinkedIn code rather than guess.

They then added more MCP surfaces: docs, Jira, Slack, data platforms, and feature flags. He describes compounding value as engineers fed product requirements documents (PRDs), design docs, and Jira tickets into coding agents.

Three reasons tools still could not finish the job

Connecting those tools still failed on slightly complex workflows. With tools, Prakash says, an agent could answer basic questions and find code examples. Completing a job reliably end to end was a different bar.

The first failure was tribal knowledge. Finishing a specific job required knowing how to fix a given error, configure a system, or debug a particular log. That knowledge lived across docs, wikis, and Slack conversations, and was often outdated or duplicated. Tools retrieve those surfaces. Assembling a procedure from them is a separate step. Agents with access still “got lost.”

The second failure was context overload. Each tool result consumed space in the agent’s context window—the working memory of the session. Eventually the session had to compact, summarizing or dropping earlier material, which lost information and forced the agent to redo work.

The third failure was the lack of durable memory. Even when an agent figured out a task, the next engineer request for the same work started from scratch. Playbooks later address that as instruction files in a repository.

• Tribal knowledge for a given error, config, or log was scattered across docs, wikis, and Slack
• Each tool result filled the context window until compaction dropped information
• A solved task had no durable memory, so the next session started over

Playbooks: instructions served the same way as tools

In early 2025, Prakash says, they invented playbooks so MCP would serve both tools and the instructions or prompts for using them. Each playbook appears as a named, described tool the agent can invoke. Invoking it returns its instructions and context as tool output, so the agent receives capabilities and guidance through the same channel.

His usage story is an engineer asking how to set up an Apache Airflow DAG—a directed acyclic graph of tasks—at LinkedIn. The agent selects a playbook for that task, reads the returned instructions, then calls the relevant tools to finish the job.

Anyone at LinkedIn can author a playbook, check it into a repository, and make it available to others.

Two authoring rules, and the skills comparison

As people created more playbooks, Prakash says they asked everyone to follow two foundational principles. First, a playbook should be self-contained around one specific task so agents can choose the right one. An Airflow DAG playbook stays about that DAG.

Second, a large playbook should split into smaller playbooks that a parent can reference. Splitting, he says, buys two things: reuse, because a small playbook can be referenced from multiple parents, and progressive discovery, because the agent loads a smaller playbook only when it needs that slice of context.

He also compares playbooks to skills, the industry pattern of packaging instructions that an agent can load on demand. Prakash says playbooks are the same idea, that LinkedIn built the playbook system before skills existed, and that playbooks are more tailored to capturing organizational context and serving it over MCP with little setup.

The encouraged loop that keeps playbooks from going stale

The knowledge-base problem he names is staleness: instructions go outdated. The encouraged agent workflow is to use a playbook, then at the end of the session identify learnings—outdated, discrepant, or missing information—update the playbook files in the repository, and open a pull request.

He says the playbook is updated after the pull request. He calls that a flywheel: agents both consume and refresh company instructions.

One laptop MCP, central playbooks, local playbooks

Distribution, as he describes it, is a local MCP server preinstalled on LinkedIn laptops. Join the company, get a laptop, and the server is already there. Prakash says updates to the server, playbooks, and tools arrive every hour.

Playbooks split into two kinds. Central playbooks cover cross-cutting work that applies across many repositories. Local playbooks live in a specific repo and are picked up only when the coding agent is working there, so repo-specific knowledge can scale without changing a central catalog.

A single MCP server fronts all playbooks and tools so authentication, telemetry, and learning can be handled centrally.

Why they stopped listing every tool

Listing every playbook and tool on the MCP surface ran into a scaling limit he treats as a common MCP problem: they could not go past about 30 or 40 tools without hurting context and system performance.

The indirection they used sits in front of the catalog as three meta-tools. The agent searches by keywords and tags, fetches the schema for a chosen tool or playbook, then executes that item. LinkedIn preconfigures each coding agent with system instructions on how to use search and the other meta-tools efficiently. Prakash says that design let them scale to thousands of tools and playbooks.

Who uses it, and the two enterprise takeaways

On a growth chart he showed on stage, Prakash cites more than 8,000 daily users of tools and playbooks and more than 600 playbooks. He also says product managers, designers, and technical program managers (TPMs) use the tools and bring playbooks alongside engineers, across functions. The uploaded video title packages the talk as “500 Skills, Zero Fine-Tuning”; the spoken talk contains neither a 500-skill count nor a no-fine-tuning policy.

His first takeaway is that the system worked because they treated quality and reliability as day-one constraints, including before they built an MCP server. He describes that principle as ensuring quality and reliability of the system, with productivity, so it would not degrade as they moved fast.

His second takeaway is the argument for working coders who have already wired MCP search and tickets. In a large enterprise, he says, the latest agents and models stay ineffective unless the company also builds infrastructure those agents can operate inside: the playbooks, the laptop MCP, and the meta-tools that keep the catalog from flooding the session.

• Watch the talk on YouTube