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

Ajay Prakash, LinkedIn20:25 · Sept 2026 · 5,707 views
Thumbnail for 500 Skills, Zero Fine-Tuning: LinkedIn's Playbook for AI Agents Watch on YouTube
TL;DR
  1. 1

    LinkedIn gives coding agents access to internal knowledge through playbooks, which package instructions and tool-use guidance as callable tools.

  2. 2

    Playbooks are kept self-contained and split into smaller referenced pieces so agents can discover context as they need it.

  3. 3

    LinkedIn replaced a large MCP surface with three meta tools, search, get schema, and execute, allowing the system to support thousands of tools and playbooks.

Summary

Ajay Prakash describes how LinkedIn moved coding agents from unreliable code assistants to agents that can work with internal systems. Publicly trained models lacked knowledge of LinkedIn's repositories, frameworks, databases, configuration systems, and operating procedures. An internal MCP server added access to code search, documents, Jira, Slack, data platforms, and feature flags, but tools alone did not provide the scattered operational knowledge needed for complete tasks. LinkedIn added playbooks, which expose instructions and prompts through MCP alongside ordinary tools. Playbooks guide agents through tasks such as debugging a service or creating an Airflow DAG. The system encourages small, self-contained playbooks and lets agents propose updates when they find stale or missing information. A local MCP server distributes central and repository-specific playbooks. Because MCP performance degrades with many tools, LinkedIn exposes search, get schema, and execute instead of listing everything directly.

Key ideas
00:42

Coding agents can handle an incident when they have LinkedIn-specific instructions

Prakash opens with an error spike in a critical service. An engineer gives the alert link to a coding agent, which fetches general debugging instructions and then service-specific context. It collects logs and metrics, identifies the root cause, proposes mitigation steps, and summarizes the findings for the engineer. After confirmation, it applies the mitigation, updates the incident management system with error metrics and dashboards, and creates a pull request for the underlying code fix. Prakash says this takes a few minutes instead of the few hours the work could take manually.

03:29

Publicly trained coding agents lack the context needed for LinkedIn's internal systems

LinkedIn's early coding-agent rollout exposed a gap between public training data and its internal environment. The agents did not understand LinkedIn's mature codebases, internal frameworks, custom infrastructure, databases, experimentation and tracking platform, or configuration management system. Engineers had to correct hallucinations and supply prompts manually. Prakash says that this could take longer than writing the code by hand, so many engineers returned to manual coding. LinkedIn has more than a thousand repositories, and new engineers spend a week-long boot camp learning these internal systems.

06:37

Code search was the first useful bridge between agents and internal code

After Anthropic released MCP in early 2025, LinkedIn built an internal MCP server. Its first tool exposed LinkedIn's code search system, which searches across thousands of repositories using keywords, custom filters, and regular expressions. An engineer can ask how to implement something, and the agent can find examples of how LinkedIn already does it. LinkedIn then added access to documents, Jira, Slack, data platforms, and feature flags. These sources let an agent combine product requirements, design documents, and task context with code examples.

08:18

Tools alone do not contain the operational knowledge needed for end-to-end work

The growing tool collection helped agents answer questions and find examples, but it did not make complete workflows reliable. Instructions for fixing a particular error or debugging a service were scattered across documents, wikis, and Slack conversations. Some material was outdated or duplicated. More tools also filled the context with outputs, causing agents to compact their context and lose information. Agents had no durable memory, so each new task began from scratch. LinkedIn needed to give agents both the tools and the instructions for using them.

10:29

Playbooks package instructions as callable tools

LinkedIn's playbooks expose instructions and prompts through MCP. A playbook has a name and description, so an agent can choose it like any other tool. When invoked, it returns the instructions and context needed for a task. For example, when asked how to set up an Airflow DAG at LinkedIn, the agent can invoke the relevant playbook first and then call the tools required by its instructions. Engineers can create playbooks, check them into a repository, and make them available to other people at LinkedIn.

12:42

Small self-contained playbooks support reuse and progressive discovery

Prakash gives two design rules for playbooks. Each playbook should cover one specific task and contain the context needed for that task, which helps an agent select the right one. Large playbooks should be split into smaller playbooks and reference those pieces. Small playbooks can be reused by multiple larger playbooks. They also let the agent fetch context progressively instead of loading every instruction at once. Prakash says the approach resembles skills, although LinkedIn developed its playbook system before skills became a common concept.

14:19

Agents help keep the playbook corpus current

LinkedIn asks agents to inspect the playbooks they used at the end of a session. The agent can identify outdated information, discrepancies, or missing instructions, then update the playbook repository and create a pull request. Once the change is approved, the playbook becomes more useful for later sessions. This gives the knowledge base a maintenance loop tied to real work rather than leaving updates entirely to a central documentation process.

15:37

A local MCP server separates shared and repository-specific knowledge

LinkedIn automatically installs one local MCP server on its laptops and updates the server, tools, and playbooks every hour. Central playbooks contain cross-cutting instructions that apply across repositories. Local playbooks live with a specific code repository and are picked up when an agent works there. This lets teams scale repository-specific knowledge without changing the central repository. The shared server also handles authentication and telemetry, which LinkedIn uses to improve the ecosystem.

17:23

Three meta tools let LinkedIn expose thousands of tools without filling agent context

Prakash says MCP performance degrades when the system exposes more than roughly thirty or forty tools directly. LinkedIn instead gives agents three meta tools. Search finds relevant tools and playbooks using keywords and tags. Get schema retrieves the details for a selected item. Execute runs the chosen tool or playbook. System instructions teach each coding agent how to search effectively. This design lets LinkedIn support more than 1,300 tools and more than 600 playbooks while serving over 8,000 daily users.

"In a large enterprise like LinkedIn, it's not enough just enough to give all of the engineers the all the latest and greatest tools and models."19:46
Who should watch
  • You are building coding agents for a company with private repositories, internal frameworks, or custom infrastructure that public models do not understand.
  • Your MCP server is approaching a large tool count and agents are losing context or choosing tools unreliably.
  • Your team has useful operational knowledge in documents and Slack, but needs a way to turn it into reusable instructions that agents can maintain.