# 500 Skills, Zero Fine-Tuning: LinkedIn's Playbook for AI Agents — Ajay Prakash, LinkedIn AI Engineer · 2026-09-09 Ajay Prakash, senior staff software engineer at LinkedIn, explains how Contextual Agent Playbooks make coding agents reliable at enterprise scale, turning an on-call alert into a mitigated incident in minutes. Early vibe coding failed: agents trained on open source hallucinated across LinkedIn's 1,000 internal repos. An internal MCP server with code search, docs, and Jira fell short: tribal knowledge sat in stale wikis, context overloaded, and sessions started from scratch. Playbooks, instructions published as tools, work when self-contained and split into small referenced pieces, and agents open PRs to refresh stale ones. Since MCP degrades past 30 or 40 tools, everything surfaces behind three meta tools: search, get schema, execute, now 1,300 tools, 600 playbooks, 8,000 daily users. ## Questions this episode answers ### How does LinkedIn scale MCP beyond the 30-40 tool limit? Ajay Prakash explains that MCP degrades past 30 or 40 tools, so instead of surfacing all tools and playbooks directly, LinkedIn replaces them with three meta tools: search, get schema, and execute. The agent searches for relevant tools using keywords and tags, retrieves details via get schema, then executes. This let them scale to over 1,300 tools and over 600 playbooks. [17:56](https://aiengineer.podhood.com/4aa4c9d5-4b7c-4305-899c-66b43705fe8b?t=1076000) ### What are Playbooks and how do they work with coding agents? Ajay Prakash describes Playbooks as instructions and prompts exposed via MCP that appear just like regular tools, with names and descriptions. When invoked, the instructions are returned as tool output, so agents get both tools and guidance on using them. Playbooks must be self-contained for one specific task, and big ones are split into smaller referenced playbooks for reusability and progressive discovery of context. [10:38](https://aiengineer.podhood.com/4aa4c9d5-4b7c-4305-899c-66b43705fe8b?t=638000) ### How does LinkedIn keep Playbooks from going stale? Ajay Prakash says agents are encouraged, at the end of any session using a Playbook, to identify outdated information, discrepancies, or missing details, then check out the repository, update the Playbook, and open a PR. Once merged, the Playbook is updated, creating a seamless flywheel of self-learning that keeps the knowledge base fresh. [14:46](https://aiengineer.podhood.com/4aa4c9d5-4b7c-4305-899c-66b43705fe8b?t=886000) ### Why did coding agents fail when LinkedIn first rolled them out? Ajay Prakash says LLMs are trained on open source repos, so they lacked context on LinkedIn's over 1,000 repos, internal frameworks, custom databases, and configuration management system—knowledge engineers learn in a week-long boot camp. Agents hallucinated and got stuck, and engineers spent more time prompting them manually than coding themselves, so many went back to manual coding. [3:44](https://aiengineer.podhood.com/4aa4c9d5-4b7c-4305-899c-66b43705fe8b?t=224000) ## Key moments - **[0:00] On-call incident demo** - [0:40] Ajay Prakash opens with an on-call alert handed to a coding agent that debugs a LinkedIn service end to end - [2:40] A coding agent finds the root cause, mitigates the incident, updates the ticket, and opens a fix PR in minutes instead of hours - **[3:05] Why agents failed** - [3:43] "This is not fiction": LinkedIn engineers use coding agents as coworkers with deep knowledge of internal systems - [3:43] Why vibe coding failed at LinkedIn: agents trained on open source hallucinated on internal frameworks, sending engineers back to manual coding - **[4:57] LinkedIn's stack** - [4:57] LinkedIn runs over 1,000 repos on custom databases and config systems that new hires need a week-long boot camp to learn - **[6:30] Internal MCP** - [6:30] LinkedIn's first internal MCP tool was code search, letting agents find real examples of how things are done instead of guessing - **[8:30] Tools fall short** - [8:38] Tools alone weren't enough: tribal knowledge scattered across stale wikis and Slack, context overload, and no durable memory broke agent workflows - **[10:38] Playbooks** - [10:38] LinkedIn's Playbooks publish instructions as MCP tools, so agents invoke know-how like any other tool - [12:28] Playbook rule: keep each one self-contained and split big ones into small referenced pieces for progressive discovery of context - [14:23] Agents are told to open PRs fixing stale Playbooks, creating a self-improving flywheel that keeps the knowledge base fresh - **[15:34] Architecture** - **[17:16] Three meta tools** - [17:16] MCP degrades past 30–40 tools, so LinkedIn replaced its whole surface with three meta tools: search, get schema, and execute - [18:25] The system now serves 8,000 daily users with 1,300 tools and 600 Playbooks across engineers, PMs, and designers - **[19:05] Takeaways** - [19:25] Ajay Prakash's takeaway: latest models aren't enough — enterprises must build the right infrastructure for agents to operate ## Speakers - **Ajay Prakash** (guest) ## Topics Agent Skill Design, Model Context Protocol (MCP), Coding Agents ## Mentioned Anthropic (company), LinkedIn (company), Airflow (product), Claude Code (product), Cursor (product), GitHub Copilot (product), Jira (product), MCP (product), Slack (product) ## Transcript ### On-call incident demo **Ajay Prakash** [0:13] Hey everyone, good morning. Uh, thanks for being here. I see people are still coming, but yeah. My name is Ajay, and I'm a software engineer at LinkedIn. Today I'm going to be talking about how we're doing context engineering to improve the performance of coding agents at LinkedIn. Okay, uh, imagine you're a software engineer in a big tech company, and your products are being used by millions of users on a daily basis. And you happen to be on a team which owns a set of very critical services, and you're on call,right? And you get an alert saying that there is an error spike in one of your services. And, uh, by the time you're trying to figure out how to deal with this issue, you take the link to the alert, give it to a coding agent like Claude Code or GitHub Copilot. While you're trying to figure out, um, how to deal with the issue, the coding agent is working in the background. It will fetch the instructions on how to debug such issues in your company and identifies that based on that instruction, it identifies that this alert is happening in a specific service. Then it fetches instruction and context on how to debug that particular service, and it will fetch the based on those instructions, it will take actions like fetching logs, metrics, and then it uses those logs to identify the root cause of the issue,right? So it identifies, based on the error logs, where the issue is happening. And it doesn't just find the root cause, it also figures out the steps to mitigate the issue. And once it finds all the details, it summarizes and gives it to you, saying, this is the error, and this is the issue, and this is the actions that you need to take to mitigate. And once you confirm, it also goes ahead and takes those actions on your behalf to mitigate the issue. And it doesn't just stop there. It updates your incident management system with all the details, error metrics, and dashboards, etc. And also, it checks out the code and creates a PR for you to fix the root cause of the issue. All of this happens in a matter of a few minutes, which would have easily taken a few hours if you were to do it manually. This is not fiction. So this is how teams at LinkedIn are using coding agents as effective coworkers, with deep understanding of LinkedIn's internal systems and code to help the teams be really productive. ### Why agents failed **Ajay Prakash** [3:05] And this is possible because of a system that we built called Contextual Agent Playbooks and Tools at LinkedIn. And today I'm going to talk about why we built the system, how we built it, and what are our learnings from the success. To understand why we built the system, we have to go back to the early days of coding agents,right? So just like any other company, even at LinkedIn, we wanted to use the coding agents to be for our engineers and everyone to be really productive with the AI. So we started using started giving these coding agents to all of the engineers. And the problem was, the coding agents doesn't really or the vibe coding doesn't really work in a large enterprise at Link, um, like LinkedIn. So the biggest problem is the coding agent, or the LLMs, are trained on open source repos,right? So they don't have the context of how we'd our mature code bases at LinkedIn, or our internal frameworks, our internal systems. So what used to happen was, the engineers used to do vibe code or try the agentic coding, but because the agents lacked context, they used to hallucinate and, like, get stuck in between. Or even more dangerous, they used to make up things, which is not correct. So the engineers had to prompt these agents manually, um, to do theright thing, which used to take more time than the manual coding itself. So a lot of people, a lot of engineers went back to manual coding. So coding agents was not effective. To understand the problem, uh, to get more perspective, so if you look at the LinkedIn stack, we have over 1,000 repos, which make up thousands of microservices and apps. And we have a lot of all of these apps and services are built on a lot of internal frameworks and libraries. ### LinkedIn's stack **Ajay Prakash** [5:18] And we also have a lot of custom-built infra. For example, we have our own databases, we have our own experimentation and tracking platform, we have our own configuration management system, which is purely internal to LinkedIn, and coding agents doesn't have any idea about them. And engineers go through a week-long boot camp whenever a new engineer joins, so just to get familiar with these systems. So we looked at this problem, and we asked ourselves the question, how can we make any coding agent like Cursor or Claude Code or GitHub Copilot understand our LinkedIn's internal system so well that they can ship the code that our engineers can trust? By trust, I mean the code should be correct, and also the quality of the code should be as good as it is written by an actual engineer. So that is the bar we set out and wanted to figure out how do we get there. ### Internal MCP **Ajay Prakash** [6:30] So in early 2025, uh, last year or so, Anthropic released MCP, and it quickly became the standard for industry standard for building tools to the agents. We leveraged that, and pretty early on, we built our own internal MCP. And the first tool that we built was code search. So we have a pretty sophisticated code search system at LinkedIn, where you, um, engineers can go and search for code. It will ingest all of search for any code across thousands of repos using keywords and custom filters and rejects, etc. So we made that available to the coding agents via MCP. This was a really powerful unlock, because now you don't have to manually figure out how to do better search. The agent, you ask a question, hey, how do I set up a particular thing? And the agent can use the code search tools to figure out theright examples of how we do things at LinkedIn, and use that to give you answer and also implement it based on its findings. This was really powerful. So we added more tools. We added Docs, Jira, Slack, even connected to all of our data platforms, and even feature flags. So every tool that we added to our internal MCP, it created more value by comp it's almost like a compounding effect, because now an engineer can bring in the PRDs, product requirement documents, and design docs, and also their Jira tasks, which has different context, and use all this to give to the coding agent to automate their or help with their coding. But there was a problem. So you connect all these tools, but it's not enough,right? So even with a slightly complex workflow, the agents used to not do really well. The problem, uh, for example, if you give a context, it is with the tools, the agent was able to answer questions, answer basic questions, and find code examples, but it cannot do a, like, complete job reliably end to end. ### Tools fall short **Ajay Prakash** [8:59] The main problem was, to do a specific job end to end, it needs to have a lot of tribal knowledge,right? So all of, for example, how to fix a particular error, or how to configure a how do you debug a particular error log,right? So all of this knowledge, even though you have access to the tools, it is scattered across a lot of different surfaces. For example, docs, wikis, and Slack conversations, etc. And most of the times, you may have experienced that docs and wikis might be outdated, written, and there might be, like, duplicate docs,right? So the problem is, the agents, even though they have access to the tools, they used to get lost. The second problem was context overload. As agents use more and more tools, their context gets overloaded, which means every tool output, it takes up space in the context, which will eventually cause the agent to compact its while it is working, compacts its context, which causes it to lose some of the information. Then it has to do all over again. And the third problem was, even though even if the agent was able to figure out all these details, it can it doesn't have a way to retain this information. It doesn't have a durable memory. So every time an engineer asks the agent to do a certain task, they have to start from scratch. ### Playbooks **Ajay Prakash** [10:38] So how do we solve this problem? So we give these instructionsright away,right? So we built a system, we invented a system in early 2025 called Playbooks, where we not only provide the tools to the agents via MCP, we also allow the agents to access these instructions and prompts via MCP. We call it Playbooks. And Playbook, it just appears just like any other regular tool, and they have names and description on what it does. And the agent can decide to invoke that Playbook, just like any other regular tool. And when the Playbook is invoked, the instructions and the context within that Playbook are returned as the tool output to the coding agent. So that way, the agents have both tools as well as instructions on how to use tools to set up a or perform a task,right? For example, if the engineer goes and asks, like, how do I set up an Airflow DAG at LinkedIn, the agent will first decide, okay, so I have a Playbook for creating that specific task, and it will use that first uses that Playbook to get the information, and then it calls the necessary follows that instructions and calls the relevant tools to get the job done. This was really powerful, mainly because now anyone at LinkedIn can go ahead and create a set up a Playbook and check it into a repository and make it available for everyone else at LinkedIn. So as people started creating more Playbooks, so we wanted so this is one of two foundational principles we want everyone to follow when creating a Playbook. The first one is, a Playbook should be self-contained, which means it should do a very specific task only. For example, if it is for setting up an Airflow DAG, it should be about the instruction and the construct should be about one specific task. This helps the agents pick theright Playbook for theright task. And the second most important one is to break a big Playbook into multiple smaller Playbooks. So this has and reference those smaller Playbooks from a bigger Playbook. This is a really powerful principle, because just like so it has two main advantages,right? So the first one is reusability. So if you have a small self-contained Playbooks, it can be used from multiple reference from multiple Playbooks. And if you the another big advantage is progressive discovery of context, which means the agent only when it needs to read a smaller Playbook, instead of reading the entire all of the Playbooks at once, it can progressively go and read the Playbooks as it wants. So this is the same concept as skills as well. So Playbooks are very similar to skills, but we developed this entire system around Playbooks even before skills was a thing. And Playbooks are a little bit more nuanced, because it helps us it helps us seamlessly capture all of the organizational context and service via MCP without much of a setup. And another cool thing about this Playbooks is the self-improving loop. So you have engineers creating these Playbooks and check it into the repository. And one of the main problem with any knowledge base is, it gets outdated. How do you the biggest problem is, how do you keep the context fresh,right? So great thing about agents is, they can improvise. So we have we encourage the agents to whenever they use a particular Playbook, at the end of the session, to identify the learnings. So any outdated information, or any discrepancy, or any missing information. And we also encourage the agents to figure out how to improve the Playbook and use that context to check it to update the Playbooks, check out the repository and update the Playbooks, and create a PR. And that once it gets uploaded, it gets the Playbooks gets updated,right? This creates a really seamless flywheel of self-learning loop. ### Architecture **Ajay Prakash** [15:34] So what does the architecture of MCP server looks like? So this particular system, we have one local MCP server, and it is automatically installed on all of the LinkedIn laptops by default. So if you join LinkedIn and you get a laptop, it is pre-installed. And any updates to the MCP server or the Playbooks or the tools, it automatically gets updated every one hour on all the laptops. And we have a concept of two local Playbooks and central Playbooks, which means so central Playbooks are the Playbooks which are cross-cutting in nature,right? So you have these Playbooks apply for multiple repositories, not just one code repository. And then you have local Playbooks, where it these are the Playbooks which are very specific to your code repository, and you can just have them checked in with your repo with your repo. And when only when the coding agents are working in your repo, those Playbooks will be automatically picked up. So this helps us scale the local Playbooks which are very specific to repo without having to worry about changing the central repository. And also, this is one MCP server which is serving all of the Playbooks and tools. So this helps us do a lot of central things, like seamless authentication, telemetry, and that we can use for learning to make the whole ecosystem better. ### Three meta tools **Ajay Prakash** [17:16] You may be wondering, like, how many tools and Playbooks it can support,right? So this is a common problem with MCP. We cannot scale it beyond 30 or 40 tools without degrading the context or degrading the performance of the system. So what we do is, instead of surfacing all of these Playbooks and tools through MCP, we replace them with three meta tools. So the first one is search. The agent first uses this tool to search for the relevant tools and Playbooks using keywords and tags. So we also control the system instructions. So every coding agent is pre-configured with system instruction on how to use these tools and how to use the search really efficiently. And once it finds theright set of tool or Playbook, it can then get the more details about that particular tool using get schema, and then execute that tool or Playbook. So this has allowed us to scale to thousands of tools and Playbook. So this is the growth chart. So now we have over 8,000 users daily using the system daily, using tools and Playbooks. So we have over 1,300 tools and over 600 Playbooks. And it's not just engineering,right? So it is not just engineers, but also product managers, designers, TPMs. So across different functions, they are using the tools and bringing their Playbooks to automate their workflows. ### Takeaways **Ajay Prakash** [19:05] So I'll leave you with this takeaway key takeaways that can based on our learning. The first one is, the system was successful because we thought about quality and reliability from day one,right? So even before creating an MCP server, we thought, okay, our fundamental principle should be, how do we ensure not just productivity, but how do we ensure the quality and also reliability of the system so that it doesn't degrade as we move fast? And the second one was, build theright infrastructure for agents. In a large enterprise like LinkedIn, it's not just enough to give all of the engineers the all the latest and greatest tools and models. They are not very effective if you don't build theright infrastructure for the agents to operate within your enterprise. Yeah, that's my time. Thank you for attending, and feel free to connect with me on LinkedIn. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.