500 Skills, Zero Fine-Tuning: LinkedIn's Playbook for AI Agents — Ajay Prakash, LinkedIn
https://www.youtube.com/watch?v=9wZpvF3QleU
AI Engineer · 20 min · 143 sentences · sentence-level transcript from YouTube's caption track; each line begins at the time shown

[00:01] [music]
[00:12] Hey everyone, good morning.
[00:14] Uh thanks for being here.
[00:17] Uh I see people are still coming.
[00:20] Uh but yeah, my name is uh AJ and uh I am a software engineer at uh LinkedIn.
[00:28] Today I'm going to be talking about how we are doing context engineering to improve the performance of coding agents at LinkedIn.
[00:40] Okay.
[00:40] Uh imagine you are a software engineer in a big tech company and your products are being used by millions of users on a daily basis and you are happen to be on a team which owns set of very critical services
[00:57] and you are 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,
[01:12] you take the link to the alert, give it to a coding agent like Cloud Code or GitHub Copilot.
[01:20] While you're trying to figure out um how to deal with the issue, uh the coding agent is working in the background, it will fetch the instructions on how to debug such issues in your company
[01:31] and identifies that based on that instruction, it identifies that this alert is happening in uh specific service.
[01:38] 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
[01:51] 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
[02:04] figures out the steps to mitigate the issue and once it finds all the det details.
[02:09] It summarizes and give it to you saying this is this is the error and this is the issue and this is the actions that you need to take to mitigate.
[02:17] And once you confirm, it also goes ahead and takes those actions on your behalf to mitigate the issue.
[02:25] And it doesn't just stop there.
[02:27] Uh 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 uh to fix the root cause of the issue.
[02:40] All of this happens in matter of few minutes which would have easily taken few hours if you were to do it manually.
[02:48] This is not fiction.
[02:49] So this is how teams at LinkedIn are using coding agents as effective co-workers with deep understanding of LinkedIn's internal systems and code to help the teams be really productive.
[03:05] And this is possible because of a system that we built called as contextual agent playbooks and tools at LinkedIn.
[03:13] 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.
[03:23] To understand why we built the this system, we have to go back to the early days of coding agents, right?
[03:30] 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.
[03:42] So we started using started giving this coding agents to all of the engineers and the problem was the coding agents doesn't really or the w coding doesn't really work in a large enterprise
[03:55] at link um like LinkedIn.
[03:59] So the biggest problem is the coding agent or the LLMs are trained on open-source repos right.
[04:06] So they don't have the context of how we our uh mature code bases at LinkedIn or our internal frameworks or internal systems.
[04:18] So what used to happen was the engineers used to do wipe code or try the agentic coding but because it the agents lacked context they used to hallucinate and
[04:29] like get stuck in between or uh even more dangerous they used to make up things which is not correct.
[04:37] So the engineers had to prompt these agents manually um to do the right thing which used to take more time than the manual coding itself.
[04:48] So a lot of people a lot of engineers went back to manual coding.
[04:52] So coding agents was not effective to understand the problem uh to get more perspective.
[05:00] So if you look at the LinkedIn stack, we have over thousand repos which make up thousands of uh microservices and apps and we have a lot of all of these apps and services are built on lot of internal frameworks and libraries
[05:18] and we also have a lot of custombuilt infra.
[05:22] For example, we have our own databases.
[05:24] We have our own experimentation and tracking platform.
[05:27] 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.
[05:43] So uh just to get familiar with these systems.
[05:49] So we looked at this problem and we asked ourselves the question how can we make any coding agent like cursor or cloud code or uh GitHub copilot understand our LinkedIn's internal system so well that they can ship the code that our engineers can trust.
[06:12] By trust I mean the code should be correct and also the quality of the code should be as good as uh it is written by an actual engineer.
[06:22] So that is the bar we set out and wanted to figure out how do we get there.
[06:30] So in early 2025 uh last year so uh Anthropic released MCB and it it quickly became the standard for industry standard for building tools to the agents.
[06:43] We leveraged that and pretty early on we built our own internal MCP and the first tool that we built was uh code search.
[06:55] So we have a pretty sophisticated code search system at LinkedIn where you um engineers can go and search for code.
[07:02] It will ingest all of uh 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.
[07:15] This was a really powerful unlock because now you don't have to manually figure out how to do better search the agent.
[07:23] You ask a question.
[07:24] Hey, how do I set up a particular thing?
[07:27] And the agent can use the code search tools to figure out the right examples of how we do things at LinkedIn and use that to give you answer and also
[07:38] uh implement it based on the its findings.
[07:41] This was really powerful.
[07:44] So we added more tools.
[07:46] We added docs, uh, Jiraa, Slack, um, even connected to all of our data platforms and even feature flags.
[07:56] So every core tool that we added to our internal MCP it created more value by comp it it's almost like a compounding effect because now a engineer can bring in the
[08:10] PRDS product requirement documents and design docs and also their Jira tasks which has mult uh different context and use all this to give to the coding agent to automate their
[08:22] um or help with their coding.
[08:27] But there was a problem.
[08:29] So you connect all these tools but it's not enough right?
[08:33] So even with a slightly complex workflow the agents used to not do really well.
[08:42] The problem for example if you give a context it is uh with the tools the agent was able to answer questions answer basic questions and find code examples but it cannot do a like a complete job reliably end to end.
[08:58] The main problem was to do a specific job end to end it needs to have a lot of tribal knowledge right.
[09:07] So all of for example how to fix a particular error or how to uh configure how do you debug a particular um error log right so all of this knowledge
[09:19] even though you have access to the tools it is scattered across lot of different surfaces for example docs wikis and slack conversations um etc and most of the times you may have experienced the docs and wikis might be outdated written and there might be like duplicate get docs, right?
[09:39] So, the problem is the agents even though they have access to the tools, they used to get lost.
[09:45] The second problem was context overload.
[09:49] As agents use more and more tools, their context gets overloaded which means every tool uh tool output it takes up space in the context which will eventually cause the agent to compact its
[10:04] um while it is working compacts it its context which causes it to lose some of the information.
[10:11] Then it has to do all over again.
[10:14] And the third problem was even though even if the agent was able to figure out all these uh details it can it doesn't have a way to retain this information it doesn't have a a durable memory.
[10:28] So every time a engineer asks the uh agent to do a certain task they have to start from scratch.
[10:38] So how do we solve this problem?
[10:40] So we give this instructions right away right?
[10:43] So we built a system, we invented a system in early 2025 called as uh 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.
[11:01] We call it playbooks.
[11:03] And playbook it just appears just like any other regular tool.
[11:10] uh and they have uh 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
[11:21] uh playbook is invoked the instructions and the context within that playbook are returned as the tool output to the coding agent.
[11:31] So that way the agents have both tools as well as instructions on how to use tools to set up a or uh uh perform a task.
[11:41] Right?
[11:41] For example, uh if the uh engineer goes and ask like how do I set up a airflow DAG uh at LinkedIn?
[11:48] The agent will first decide okay so I have a playbook for creating um that specific task and it will use that first fet uh uses that playbook to get the information
[12:01] and then it calls the necessary uh follows that instructions and calls the relevant tools to get the job done.
[12:10] This was really powerful um 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.
[12:27] So as people started creating more playbooks so we wanted so this is um one of two foundational principles we want everyone to follow when creating a playbook.
[12:41] The first one is a playbook should be self-contained which means it should do a very specific task only um for example um if it is for setting up a airflow
[12:53] DAG it should be about the instruction and the construct should be about uh one specific task.
[12:59] This helps the agents pick the right playbook for the right task.
[13:04] And the second uh most important one is to break a big playbook into multiple smaller playbooks.
[13:12] So this has um and reference those smaller playbooks from a bigger playbook.
[13:18] This is a really powerful um principle because just like um so it has two main advantages, right?
[13:25] So the first one is uh reusability.
[13:28] So if you have a small self-contained playbooks, it can be used from multiple uh reference from multiple playbooks and if you um the another big advantage is progressive discovery of um
[13:41] 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 uh progressively go and read the playbooks as it wants.
[13:53] So this is the same concept as skills as well.
[13:57] So playbooks are very similar to uh skills but we developed this entire system around playbooks even before skills was a thing.
[14:06] And uh playbooks are a little bit more nuanced because it helps us um it helps us seamlessly capture all of the organizational context and service via MCP without much of a setup.
[14:23] And another cool thing about this playbooks is this self-improving loop.
[14:29] So u you have uh engineers creating these playbooks and checking into the repository.
[14:35] And one of the main problem with any knowledge base is it gets outdated.
[14:40] How do you uh the biggest problem is how do you keep the context fresh right?
[14:46] So great thing about agents is they can improvise.
[14:49] So we have we encourage the agents to whenever they use a particular playbook at the end of the session to identify the learnings.
[15:00] 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
[15:13] check it uh to update the playbooks check out the uh repository and update the playbooks and create a PR and that once it gets upload it gets uh the playbooks gets updated
[15:26] right this creates a really seamless flywheel of a self-arning loop.
[15:34] So what does the architecture of a MCP server looks like?
[15:39] So this particular system we have one local MCP server and it is automatically installed on all of the LinkedIn laptops by default.
[15:49] So if you join LinkedIn and you get a laptop, it is pre-installed and any updates to the uh MCP server or the playbooks or the tools, it automatically gets updated every 1 hour on all the laptops.
[16:04] And we have a concept of two local playbooks and central playbooks which means so central playbooks are the playbooks which are crosscutting um in nature, right?
[16:15] So you have um these playbooks apply for multiple uh repositories not just one uh code repository and then you have local playbooks where it these are the playbooks which are very specific to your code repository
[16:30] and you can just have them checked in with your repo um uh with your repo and when only when the coding agents are working in your repo those playbooks will be automatically picked up.
[16:43] So this helps us scale the local playbooks which are very specific to repo without having to worry about um uh changing the uh central repository and also this is one MCP server which is serving all of the
[16:59] uh playbooks and tools.
[17:00] So this man helps us do a lot of uh central things like seamless authentication, telemetry and u that we can use for learning to make the whole uh ecosystem better.
[17:16] You may be wondering like how many tools and playbooks it can support, right?
[17:20] Uh so this is a common problem with MCP.
[17:23] we cannot scale it beyond 30 or 40 tools without degrading the uh context or degrading the performance of the system.
[17:34] So what we do is instead of uh surfacing all of these playbooks and tools through MCP we replace them with three meta tools.
[17:44] So the first one is search.
[17:46] The agent first uses this tool to search for the relevant tools and playbooks using keywords and tags.
[17:55] U so we also control the system instructions.
[17:58] Um so every coding agent is preconfigured with system instruction on how to use these tools and how to use the search really efficiently.
[18:07] And once it finds the uh right 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 uh playbook.
[18:19] So this has allowed us to scale uh to thousands of tools in playbook.
[18:27] Um so this is u the growth chart.
[18:30] So now we have over 8,000 users daily um using the system daily.
[18:36] using uh tools and playbooks.
[18:39] So we have over,300 uh tools and over 600 uh playbooks and it's not not just engineering right.
[18:48] So it is uh not just engineers but also product managers, designers, uh TPMS.
[18:54] So across different functions they are using the tools and bringing their playbooks uh to automate their uh workflows.
[19:05] uh so I'll leave you with this takeaway uh key takeaways that can based on our learning the first one is the system was successful because we thought about quality and reliability
[19:17] uh from day one right so even uh before creating a MCP server uh we thought okay the our fundamental principle should be how do we ensure not just productivity
[19:28] but how do we ensure the quality and also reliability of the system so that it doesn't degrade um as we move fast.
[19:37] Uh and the second one was u the build the right infrastructure for agents.
[19:42] Uh 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:51] Uh these are they are not very effective if you don't build the right infrastructure for the agents to operate within your enterprise.
[20:01] Um yeah that's my time.
[20:03] Thank you for attending and feel free to connect with me on
[20:06] [applause]
[20:06] LinkedIn.