500 Skills, Zero Fine-Tuning: LinkedIn's Playbook for AI Agents — Ajay Prakash, LinkedIn

An error spike arrives while an engineer is on call. The engineer gives the alert link to Claude Code or GitHub Copilot, and the agent starts investigating in the background. Ajay Prakash, a software engineer at LinkedIn, opens with this workflow to explain what his team's Contextual Agent Playbooks and Tools system makes possible: an agent can follow the company's debugging procedures rather than ask the engineer to reconstruct them in a prompt.

The investigation narrows in stages. Company-level instructions help identify the affected service. Service-specific instructions then tell the agent how to investigate that service, including fetching logs and metrics. Those observations support a diagnosis and a proposed mitigation. The alert has become something the engineer can act on: a summary of the error, its cause, and the steps needed to reduce its immediate impact.

Human confirmation separates the proposed mitigation from execution. Once the engineer confirms, the agent takes the mitigation actions, updates the incident management system with details, metrics, and dashboards, and checks out the code to create a PR addressing the underlying cause. Mitigation handles the immediate incident; the repair PR handles the defect that produced it. Prakash describes teams using this workflow in a few minutes instead of the hours manual work could take, an operational account rather than a measured speedup across incidents.

Where does the agent acquire enough knowledge to move from an alert to a useful proposal? The flow below makes the narrowing visible: general procedures lead to service procedures, which lead to observations and a diagnosis. Confirmation comes before mitigation, while incident documentation and a repair PR extend the work beyond the immediate response.

The early rollout of coding agents produced a less encouraging result. Agents lacked context about LinkedIn's mature codebases, internal frameworks, and internal systems. They hallucinated, stalled, or invented incorrect details. Engineers then had to prompt them toward the right implementation, sometimes spending longer on corrections than manual coding would have taken. Some returned to writing the code themselves.

The missing context was substantial. LinkedIn had over a thousand repositories supporting thousands of microservices and apps, built on internal frameworks and libraries. Its custom infrastructure included databases, experimentation and tracking, and configuration management. New engineers spent a week-long boot camp becoming familiar with these systems. General coding ability offered no reason to expect an agent to know those local practices.

The target became specific: make coding agents understand the internal system well enough to ship code engineers could trust. Trust meant both correctness and code quality comparable to an engineer's work. That requirement shaped the infrastructure that followed; generating code quickly would be of little use if people still had to repair its assumptions.

The first internal MCP tool exposed LinkedIn's existing code search to agents. Engineers could already search across thousands of repositories with keywords, custom filters, and regular expressions. Connecting that capability through MCP let an agent investigate how LinkedIn actually implemented something before answering a setup question or writing an implementation.

This changed where implementation guidance came from. A request to set up a particular component could trigger a search for internal examples, and the agent could use those findings in its answer and code. The engineer no longer had to locate every useful example and paste it into the conversation.

More connections followed: documents, Jira, Slack, data platforms, and feature flags. Their value compounded because a task could draw on several kinds of context at once. Product requirements and design documents explained the intended change, Jira supplied task context, and internal code supplied implementation examples.

Tools helped agents answer basic questions and find examples, but slightly more complex jobs still failed to finish reliably. Knowing where information could be found did not supply the procedure for using it. Debugging a particular error, for example, required practical knowledge scattered across documents, wikis, and old conversations.

• Scattered and stale procedures: Duplicate or outdated documents made it difficult to choose the right instructions, even when the agent could reach every source.
• Context overload: Each tool output consumed context space. As the session grew, compaction could lose information the agent needed, forcing it to repeat earlier investigation.
• Repeated discovery: A successful session had no way to retain its procedural findings for the next request. Another engineer asking for the same task could send the agent back to the beginning.

Playbooks made instructions available through MCP alongside operational tools. A playbook had a name and description, and the agent could select and invoke it like another tool. Its output was the instructions and context for performing a task. This reused the agent's tool-selection mechanism to fetch procedural knowledge.

Consider the request to set up an Airflow DAG at LinkedIn. The agent first selected the playbook for that task and fetched its instructions. It then followed those instructions and called the relevant tools. Internal setup knowledge entered the session before the agent attempted the work, instead of being rediscovered across unrelated sources. Anyone at LinkedIn could author a playbook, check it into a repository, and make it available to others.

Two authoring rules kept that growing library usable:

• Give each playbook one specific task. An Airflow DAG setup playbook should contain the instructions for that task. A narrow purpose makes it easier for the agent to match a request to the right procedure.
• Split large procedures into referenced pieces. A larger playbook can refer to smaller, self-contained playbooks. Those pieces can be reused by several procedures, and the agent can read them only when needed.

The second rule directly addressed context overload. A reference preserved access to a procedure without immediately loading all of its contents. The agent could progressively discover context as the task developed. Prakash connects this to Skills: both approaches make task expertise available on demand. LinkedIn's implementation served that expertise through its internal MCP system.

A repository of instructions could become as stale as the wikis it replaced. The maintenance loop therefore used the agents doing the work. At the end of a session, agents were encouraged to identify outdated information, discrepancies, or missing steps in the playbooks they had used.

The agent could check out the playbook repository, propose an improvement, and open a PR. Approval then updated the shared playbook. The learning persisted in an editable procedure that future sessions could retrieve. This is the concrete mechanism behind the self-improving loop: experience produces a proposed text change, and review determines whether that change becomes shared guidance.

The system ran through a local MCP server preinstalled on LinkedIn laptops. Updates to the server, tools, and playbooks arrived automatically every hour. That distribution mechanism made the shared infrastructure available without requiring each engineer to assemble a separate setup.

• Central playbooks: Cross-cutting procedures applied to multiple repositories and lived in the shared collection.
• Local playbooks: Repository-specific procedures were checked in with their code. They were automatically picked up only when the coding agent worked in that repository, allowing teams to maintain local knowledge without changing the central repository.

One MCP server served both the tools and playbooks. This provided a common place to handle authentication and collect telemetry that could inform improvements to the ecosystem. The knowledge could be authored locally while access and observation used shared infrastructure.

A growing library created another scaling problem: exposing every tool and playbook directly to the agent. Prakash reports degradation beyond roughly 30 or 40 tools in the team's experience; that is an observation about agent context and performance, not a hard limit imposed by MCP. LinkedIn replaced the directly exposed catalog with three meta tools.

• Search: Find relevant tools and playbooks using keywords and tags.
• Get Schema: Retrieve the details of a selected tool or playbook after discovery.
• Execute: Invoke the selected capability once its details are available.

How can thousands of capabilities remain accessible through three tools? The diagram shows the two outcomes of execution. An operational tool performs work; a playbook returns instructions that guide subsequent tool calls. Discovery and detailed loading happen before either outcome, so the agent does not need the complete catalog in context at the start. Preconfigured system instructions teach each coding agent how to use this search sequence efficiently.

This extended progressive discovery to the catalog itself. Small referenced playbooks controlled how much procedural text entered context; the meta tools controlled which capability details entered it. At the time of the talk, Prakash reported over 1,300 tools, over 600 playbooks, and over 8,000 daily users. Use extended beyond engineers to product managers, designers, and TPMs bringing playbooks for their own workflows.

The closing lesson returns to the original definition of trust. Quality and reliability were design goals before the MCP server existed. The system needed to remain useful as the team moved quickly and added capabilities. Productivity depended on agents producing work engineers could rely on, rather than shifting the effort into correction.

Giving an enterprise the latest tools and models did not by itself give agents a way to operate inside it. LinkedIn's response was to build that environment: access to internal examples and systems, retrievable task procedures, selective loading, automatic distribution, and reviewed improvements. The on-call workflow at the beginning depended on this accumulated infrastructure. Its useful unit of knowledge was a procedure another session could find and follow.