{"slug": "presentation-context-engineering-at-linkedin-how-we-built-an-organizational-for", "title": "Presentation: Context Engineering at LinkedIn: How We Built an Organizational Context Layer for AI Agents with MCP", "summary": "LinkedIn software engineer Ajay Prakash detailed Contextual Agent Playbooks and Tools, an organizational context layer built on the Model Context Protocol (MCP) that powers over 600 coding-agent workflows and thousands of tools across the company. The system lets agents such as GitHub Copilot fetch company-specific debugging instructions, logs, metrics, and recent deployments to trace incidents to a buggy pull request, then summarize root cause, take mitigation action, file a report, and open a fix PR in minutes rather than hours. Prakash traced the work to the evolution from LLM autocomplete to agent mode, which Andrej Karpathy termed \"vibe coding\" in early 2025.", "body_md": "## Transcript\n\n**Ajay Prakash:** My name is Ajay Prakash. I'm a software engineer at LinkedIn. I'll be talking about context engineering at LinkedIn. Imagine you're an engineer in a software company, a big software company, and you happen to be on call for your team. Your team owns a set of very critical services, which is used by millions of users. All of a sudden, you get a pager alert about a latency spike in one of your services. It is causing disruption for a lot of your users. While you're trying to figure out how to deal with this issue, and how to mitigate it faster, you take the link to that alert and give it to a coding agent, like GitHub Copilot. The coding agent, it fetches the instructions on how to figure out how to debug this issue, or debug alerts in your company. It identifies that this issue is coming from one of your services.\n\nThen it also fetches instructions on how to debug that service. Based on those instructions, it fetches the logs, metrics, and recent changes, and deployments that went in. It identifies that the issue is coming because of a different service, which is a downstream service, which is throwing a lot of errors. Then the coding agent also goes and fetches the instruction on how to debug the issue in the downstream service. It does the same thing based on the instructions on how to fetch the logs, metrics, and it identifies that there was a recent PR code change that went in, which was buggy, and it got deployed, and it is causing all of the issues. The impressive thing is the agent was able to figure out all these things, while you were figuring out how to deal with that issue. Once it finds the information, it also creates a detailed summary for you on what it found and what was the root cause, and what are the steps, or actions needed to be taken to mitigate the issue.\n\nOnce you confirm that and verify, it will also go ahead and take the action to mitigate the issue. This happens in a matter of a few minutes. The coding agent doesn't stop there. It will also go and create a detailed report and updates the incident management system for you. Also, it goes beyond where it fetches instructions on how to make the coding on the affected service where the bug was happening, and it also creates a PR for you. As I said, it all happens in a matter of a few minutes. This would have easily taken, without coding agents, a few hours of time. This is not fiction. This is how teams at LinkedIn are using coding agents as very productive coworkers with a deep knowledge of LinkedIn systems to automate their workflows and be very productive. This is just one example. We have over 600 such workflows and thousands of tools helping teams automate their workflows. This is possible because of a system that we built, we are calling it Contextual Agent Playbooks and Tools. Today I'll be going over why we built it and how we built the system, and what did we learn by building the system, and from its success.\n\n## Coding Agents\n\nTo understand why we built this system, we have to go back in time of the early days of AI coding assistants. The early coding assistants were mainly LLM based smart autocomplete, where it will help you autocomplete a sentence, or a line, or a code block based on the context it has. Then the agent mode was introduced across different coding tools. The agent mode was really powerful because the agent now with AI powered agents now have access to tools to edit the files and also run terminal commands. Now they could figure out how to make the changes and not only suggest those changes, they can also go ahead and make those changes. They can edit multiple files within your workspace. This was really powerful. In early 2025, Andrej Karpathy famously termed this vibe coding. The idea is you don't have to look at the code. You can just keep prompting the agent on what you want and the agent will figure out what changes to make and it will make the changes.\n\nBecause it has access to the terminal, it will also run some commands to verify the changes it makes. You just have to watch the output. This idea was really powerful and it created a lot of hype around the industry. Just like any other company, even at LinkedIn, there was a lot of excitement to use these coding agents. We provided access to the coding tools early on to all the engineers. We also wanted everyone to use it and be really productive. A lot of us tried the coding agents to do vibe coding or to become automated coding in our LinkedIn codebase. It was not working. The vibe coding was not working. Can you guess why it was not working? The main issue was the LinkedIn's codebase is so mature and there is a lot of internal context. The agents didn't have the context of how to make the changes properly.\n\nEven though the idea is really powerful, but when you try it in your company, the agents miss a lot of the context and either produce subpar results or it will completely hallucinate and create wrong code. The engineers had to constantly give the right prompts and give the right context to the agents to guide them in the right direction. This was opposite to what you hope for, because you want to be productive, but now you're babysitting this agent to do the right thing and understand your company's codebase. A lot of the engineers just went back to regular manual coding because everyone has deadlines to it. It was not working as we expected.\n\n## LinkedIn's Massive Stack\n\nTo understand this problem more concretely. If you take a look at the LinkedIn stack, it's massive. We have thousands of repos, thousands of microservices and apps, which depend on each other. They're all built using a lot of internal frameworks at every layer. Also, we have a lot of custom infra built. For example, we have our custom databases built. We have a custom tracking and experimentation system, observability, and configuration management, which are really mature. These are built to handle the unique challenges of LinkedIn scale. Engineers, whoever joins LinkedIn, they spend over one week through a rigorous bootcamp, just to try to understand the internal systems, get familiar with them. It also takes a few weeks for them to be really productive because there is so much to learn and do things right. The same problem is with the coding agents as well. You just cannot throw a coding agent at such a massive system and expect them to be productive.\n\nWe asked this question to ourselves, how do we make these coding agents understand LinkedIn's internal systems so well that they can ship the code our engineers can trust? One of the problems with coding agents also was the engineers couldn't really trust the code that was getting produced because we have a really high quality bar for code and also the reliability of systems. Since the agents didn't have the right context, we cannot really trust the code that it was generating. We asked ourselves, how do we make the code that is generated by these agents really trustworthy?\n\n## Model Context Protocol\n\nAround the same time, Anthropic released and open-sourced Model Context Protocol, or MCP. It became really popular and also got adopted as an open standard. It became an open standard for connecting the tools to the agents. All of the coding agents started supporting MCP. This was a really good moment for us, because now we can connect the coding agents and extend their capability by adding the tools so that they can access our internal system and understand our internal system. The first set of tools that we added was code search. We had a very sophisticated code search system already existing, which engineers were using. This code search engine, it basically ingests all of the code within LinkedIn across 1,000 repos and allows the engineers to search for code using keywords or regex and advanced filters like file types and language. Now using MCP, we wrap this code search tool to query the code for relevant code snippets, and also get the file content of the file, and connected it to the coding agents.\n\nThis was a really huge unlock because now the coding agents not just have to rely on their pre-trained data. Because, remember, all of these LLMs are just trained on open-source code. They're really good at generating the code, but they don't know what the code in LinkedIn looks like. By adding code search capability, now the coding agents were able to use the tools to understand how the code looks like in LinkedIn by performing a query and getting the relevant examples. Also, if they need, they can also go and read the entire file. The LLMs, or the coding agents generally, they are really good at tool calling. The users, even if you give a natural language query like, show me how to do a LangChain example. Even if the query is really vague and in natural language, the coding agents can repeatedly use the code search tool to figure out what queries to use.\n\nThey can repeatedly call the code search with different kinds of things and improvise and find the relevant context, and then summarize that. This was really powerful and it unlocked a lot of possibilities. With that, we also started adding more and more tools. For example, we made it possible for the coding agents to search for the docs and wikis, and also, you can give any link to the doc or the wiki, they can read that and get that into the context. Similarly, we added tools to read the feature flags, task management, and data platform. Every tool that we added, what it unlocked was now the agents can get better and richer context to do their work. For example, using docs, you can now give product requirement documents and also architecture documents and some wiki pages, which were created by the team, which has a lot of internal context. Now the coding agents have access to it.\n\n## The Context Gaps\n\nThis is all good. Now the agents are able to get all the context, but still, it was not quite working. Especially if the task becomes even slightly complex, the agents were not able to do it end-to-end. You couldn't rely on agents to figure out everything and do a slightly complex task end-to-end. The main problems were, the first is the tribal knowledge. To do any coding task, it's not just about figuring out how to find the relevant code examples and just doing the coding. It also involves figuring out how to install the dependencies and write commands to compile the code or test the code. These are all the nuanced knowledge. These were scattered across a lot of docs and wikis and Slack threads. It's just tribal knowledge, which lives in some senior engineer's head. Even with all these tools, the coding agents were not able to find the relevant context.\n\nIt's like finding the needle in the haystack. This is one problem. The second problem is context overload. Whenever an agent uses a specific tool, the tool output also takes space in the LLMs context. All of the LLMs have a limited context window. They're getting bigger and bigger, but it is still limited. What happens when the coding agents try to look for the relevant context to do a certain task? The more tools they use, they get overloaded with the context. Finally, at a certain point, they summarize all of that information using compaction. Once the context window is compacted, it loses a lot of the information. Then it has to do all of the tool calls again to find that relevant context. This is one of the reasons sometimes coding agents get into a weird loop where they do a bunch of tool calls, figure out how to do things, but all of a sudden, they get summarized, and they will forget what they were doing, and they start to do that all over again.\n\nThat's the context overload problem. Another big problem is the agent doesn't have a long-term memory. The coding agents, now we are seeing some form of memory, but these were the early days, and there was no durable long-term memory. The issue with this is even if the agent figures out by all of the tool calls and all of the context you give by hand, the next time you want to do the same task, the agent has to figure out all of these things all over again. This is really time-consuming, because if you're an engineer and you are doing a task, you want to get it really fast. If the agent is always starting from scratch and trying to figure out all of these things over again, it is not really a good experience. Also, this is very expensive because it takes up a lot of tokens.\n\n## Procedural Memory - Playbooks\n\nWhat is the solution to all of this? Of course, as I said, the solution is to provide memory. How do we make the agents remember a context on how to do things? We have to understand procedural memory. Procedural memory is just the context on how to do things. If the agent, for example, whenever you give a task, it had figured out all of the context it needs to perform a job and it was able to get to the final state, you store that context, store all of the relevant context as a procedural memory. When the agent wants to do the same task next time, you serve that procedural memory on all the steps and all the background information and nuanced knowledge to the agents to do that same task again. By giving this procedural memory, if you're able to do this efficiently, then you can make the agents remember things and do the entire task without taking too much time and also without burning a lot of tokens.\n\nThat's the whole concept of procedural memory. This procedural memory is also the concept behind agent skills, which is open sourced by Anthropic. At LinkedIn, we had a similar implementation. We didn't use agent skills because it was not even a thing back then. We developed our own concept of procedural memory, we called it playbooks. What are playbooks? Remember, we built a MCP and connected the tools. We use the same MCP to serve the procedural memory. We call it playbooks. Whenever you want to do a certain task, we have a playbook for that, which consists of name, description, and instructions. The name and description give the hint to the coding agent on what that specific task is. Now the coding agents can invoke the playbooks as regular tools. When it invokes, all of the instructions are returned as a tool output back to the coding agent. For example, there is a playbook for writing offline pipelines using Airflow.\n\nIf an engineer asks, can you set up an Airflow pipeline for me? Then the coding agent realizes that it has access to the Airflow playbook via MCP and it invokes that to get the relevant context. It can also get the context from the user on what specific changes it needs to do. It uses all of this context to perform the task. Anyone at LinkedIn can create a playbook and check it into a central repository. Now it is available for everyone else at LinkedIn. This is a really powerful concept, and it made it possible to share the prompts and share the context.\n\nWhat does a good playbook look like? Also, whenever we are creating playbooks, we have to keep these two things in mind. These are the design philosophies we try to enforce. The first philosophy is the playbook should be self-contained, which means a playbook should do the exactly one specific thing. For example, if it is for creating the Airflow, it should have all of the concepts and instructions and everything. If there is a playbook which is doing multiple different things, it is better to break it up into multiple playbooks. The agent can always decide to choose which playbook to use. The second design philosophy is composability, which means if you have a very long playbook, and there are some tasks which can be extracted out, then it is better to create smaller playbooks, which can be referenced by the bigger playbooks. This is similar to how you do code reusability, where you break the code into multiple places.\n\nThere are two main advantages of this composability. The first one is reuse. As I said, just like code, the playbooks can also be reused, where multiple playbooks can reference the smaller playbooks to do a certain action. The second biggest advantage is the progressive disclosure of context. What I mean by that is, when the coding agents want to perform a task, want to get a context, if they load all of the context up in one go, it overloads the context. It's not also good for the performance of the agent. With progressive disclosure of context, when a big playbook references small playbooks, and so on, the agents can choose to read the smaller playbooks only if they need to. If they don't need to, then they can skip those. This is efficient management of context. With these two philosophies, we can now create an organizational context within LinkedIn, where you can almost capture all of the context within LinkedIn as a graph of playbooks, which the agent can now navigate to figure out how to do things at LinkedIn, and do longer and longer running tasks.\n\nAs we are creating more and more playbooks, there is one common problem. With any knowledge base, it gets outdated, because these playbooks are created at some point in time, at that time you captured certain instructions. As the systems evolve, the instructions in those playbooks get outdated. Great thing about coding agents is they can improvise, which means when they use a playbook, and if they detect that there is outdated information, they don't just stop there, they can improvise and figure out what is the right solution using the tools that we have. Once they find the right solution, and also, they can find that the information is outdated, and they can try to find what is the latest information, or they can always ask the user of the coding agent to provide the relevant information. This also works for any edge cases. The playbook doesn't have to be really perfect from day one.\n\nYou can start with a basic set of instructions, and there are always edge cases, and the agents, they are really good at finding some edge cases. We have in our system prompt, which encourages the coding agents to always capture these learnings, outdated information or any edge cases, and summarize that at the end of the session. Then we also encourage the coding agents to check out the code for the playbooks, and also capture all of their information to update the playbook, which can be now checked in. This creates a really good flywheel where more and more the playbooks are used, the agents, they can update it with the new learnings. The procedural memory, the more it is used, it becomes better and better.\n\n## Architecture\n\nHow does it all look like from an architecture point of view? We have one local MCP server. All of the tools and playbooks are served via this MCP server. We have two kinds of playbooks, central playbooks and local playbooks. This is just another context engineering aspect where certain playbooks are only used or only needed in a specific repository. Only when the user is working in that repository, you would need that playbook. Because we are using a local MCP server, we have access to the file system. The MCP server also has the awareness of which directory it is working in. When the MCP server starts, and it identifies which workspace it is working in, and if it has the playbooks directory, then it can load all of the playbooks in that directory. All of the team's playbooks and repository specific playbooks can go here. They also get checked in with the repository where they exist in, so that the teams can create all of their playbooks without having to worry about overloading the system.\n\nThen we have the central playbooks, these are the playbooks which are applicable across multiple repositories. We want to make sure that only playbooks which are applicable across the repositories or even without repositories, they go in here. Then we have tools. All of the tools, they require authentication. We have a seamless authentication library where every tool, they connect to either our internal system or our external system, and they would need some kind of authentication. This happens using a seamless auth where whenever the user is using the tool for the first time, and it identifies that it requires authentication, it launches the authentication flow, generally OAuth, and the user can authenticate. The auth layer, it captures the tokens and stores it in a secure keychain. Then the tool execution continues. The next time the tool is called, it can fetch the same tokens, refresh the tokens and perform the tool execution.\n\nThis MCP server, it is also pre-installed on all LinkedIn laptops. It is also auto-updated every hour whenever there is an update. This means that anyone can create a playbook or a tool, and once it gets deployed, it is available for everyone else within one hour. Every tool that we create has to go through our InfoSec review. Because the MCP is fairly new, and it can open up a can of worms for a lot of security issues, having everything in one place helps our team to make sure every tool is audited and also every tool is secure.\n\nHow many of you are wondering, how many tools can this MCP server possibly fit before it degrades the performance? Anyone wondering about how many tools? I think this is a general problem with MCP itself, where I'm talking about creating thousands of tools. If you are familiar with the MCP or in general tools, every tool takes up space in the context, and as more and more tools are given to the coding agent, it takes up a lot of space in their context window, and it degrades the performance of the agent itself. For example, if you add a lot of tools and even if you don't need them, it causes the agent to perform compactions more often. Generally, beyond 30 tools, it makes the agents slow down and also degrades their performance as I said. How do we scale this beyond 30 tools? Of course, we want to create a lot of playbooks and a lot of tools, and this is a central system.\n\nWhat we do is, instead of exposing all of these tools and playbooks directly to the MCP, we replace them with three tools. The first one is search for the tools and playbooks. The agent, whenever it needs to perform an action or find a playbook, it can use this tool to first do the search based on keywords and also tags like domain and what action the tool does. This search tool will surface relevant results of the tools and playbooks, and then the agent can decide based on the name and description, which tool to use, and then it can get the schema of the tool. This is to get the input arguments, how to construct the arguments for that tool, and then it can execute. This way we are able to scale the tools and playbook catalogs to thousands of tools and playbooks. Who maintains all these tools and playbooks and server, because everyone keeps adding the tools and everyone keeps adding the playbooks?\n\nIf everyone just keeps adding tools, there should be someone to maintain them. We follow this ownership model where there is a central team which is responsible for maintaining the MCP server itself, and they also maintain a set of core tools. This ensures that if there is any issue with the MCP server or any of the core tools, the central platform we have on call, they will help and fix any issues. Then we have an open contribution model where, as I said, anyone can go and contribute, of course with the InfoSec review, but whichever team adds the tools or playbooks and makes it available for everyone, they also should be maintaining those tools and playbooks. Any playbooks or tools which are not used or not maintained, we'll actively and aggressively deprecate them. The whole point is we want every tool and everything to be accounted for to maintain the health of the entire system.\n\nWe have over 8K users who use the MCP server and any of the tools on a daily basis. This is not just engineers. We gave access to coding tools or coding agents to other functions as well, like product managers, designers, TPMs. They use all or some of the tools for their workflows. Again, the coding agents are not just for coding anymore. You can do a lot more things, for example, debugging. A lot of people use the coding tools, because it has access to docs and wiki, they can go and create docs or write the docs using the tools from the MCP. We also looked at what are these playbooks primarily used for. We have over 600 playbooks, which are automating the workflows. We realized that these are the top five broad themes which the teams are creating for the playbooks and using them. The first one is, interestingly, debugging and investigation of issues.\n\nIt is related to coding, but this is not exactly coding. What we realized is all of the teams, now they are converting their runbooks into playbooks. The agents, when you give them a good set of instructions on where to look for the data and go and investigate, they are really good at ingesting all of this data and figuring that needle in the haystack. This is one of the areas where humans also hate doing this. This is a really interesting aspect of the coding agents. The second one, of course, which was the intended purpose of this whole playbooks was the coding. If you look at coding in big companies like LinkedIn, it is a lot of boilerplate code, because we have a lot of internal frameworks and setting up the databases. It takes up a lot of boilerplate code, which is very manual. Given the right set of instructions, the agents can do a really good job of creating those boilerplate code for you and also running the commands and verifying that it is set up properly.\n\nYou can do a longer running task when you have a lot of boilerplate to go set up. This makes it really easy for engineers to cut out all of the boring stuff and manual stuff of setting up the boilerplate code and focus instead on really interesting things, which is, what products to build and what changes to make and how to iterate faster. Then the third top most use case is also code cleanup and migrations. If anyone is working in a big company, they will know that this is one of the pains, which is, there is constant migrations, and these are not fun, but you have to pay the tax. This is where coding agents can really help where you have a lot of migration that you want the dependent teams to do. You can create a playbook and you can ask the coding agents to go and do the migrations and create a PR.\n\nBecause the migration playbooks are really good, we can actually rely on the coding agents to do the right job. All of the playbooks also need to have good verification steps where the agent can go and verify its own work. Then, as I said, there is a lot of custom infra and it requires a lot of management. Also, we have a lot of pipelines, for example, offline pipelines and AI training, and the playbooks really help the coding agents. These are the tasks which the coding agents can help with, where instead of an engineer going and managing these pipelines and fetching the logs and trying to debug them or trying to manage some of the long-running tasks, you can delegate that to coding agents and give them instructions via playbooks, and they can do that job. The fifth one is environment and repo setup. As I said, any new engineer joins, now they can use these playbooks to set up their local development environment and get productive sooner instead of figuring out all of the things in the README and going through this process.\n\n## What's Next?\n\nWhat next? We have a good system which is working. What are we working on next? So far, as I mentioned, the engineers were responsible for creating the playbooks. Of course, we have playbooks to write playbooks, which means the engineers are not manually writing the playbooks. They are using the coding agents to figure out the right context and capturing that as a playbook. We want to automate that, where we can have a background coding agent, which looks at all of the information from the PRs and also the agent sessions and the telemetry to understand what are the common workflows that can be automated, and they can write the playbooks themselves. This allows us to scale the entire organizational context at LinkedIn much faster. Another thing we are working on is also, we have a lot of playbooks. Now, of course, we have a way to update them and keep them up to date, but it is still a manual process where somebody has to remember or direct the agent to go and update the playbooks with the new learnings. We want to automate that where there is a background coding agent, again, like an offline job, which looks at all of the agent sessions and any new learnings from the telemetry, and takes a look at the playbooks themselves, and see if there is any gaps, and it can go and make updates to that playbook.\n\n## Key Takeaways\n\nI'll leave you all with two key takeaways. The first one is, it's not enough to give AI coding tools to the engineers in your team and in your company and expect them to be productive. The first one is, you need to think from day one, how to put enough guardrails around the quality, how to ensure that the coding agents are creating quality output. This is really important in your company. The second one, the downstream effect of it is you need to make sure whatever the code your coding agents are generating, it's not degrading the reliability of your systems. This is a very common issue where, as the code velocity goes up, it will cause some downstream effects. You need to think from day one on how to maintain the quality and the reliability. The second one is, the coding agents and the harnesses, models, everything keeps getting updated.\n\nOne thing that doesn't change is the coding agents still need access to your internal context, your tribal knowledge, that doesn't change. You need to have some infra where you make it easy for the coding agents to access your internal tribal knowledge via skills or playbooks like we did. You need to have some kind of infra for the agents to navigate your company, only then they will be successful. The third one is the developer experience. To get the adoption of the coding agents, you need to make the experience of using the coding agents really seamless. Then the productivity is really hard. The problem is these coding tools are really new and people may not right away like the code that the coding agents generate or they don't want to use that. You need to put constant effort as a company to make that experience better for them to generate the code.\n\n## Questions and Answers\n\n**Participant 1:** You got the data point for a lot of users using the playbook over the past few months, right now 8,000 people. Can you provide some insights about the productivity and quality over time?\n\n**Ajay Prakash:** They're not just using the playbooks, but a lot of people are using the tools by themselves. There are 8K users who are using the tools. Over the quality, as I mentioned, we put the guardrails on quality from day one. It has not decreased, which is a really good thing. Also, what we realized is we also maintain the productivity. The productivity has gone up, about a 20% increase in productivity. We also measure the productivity against the reliability of our system. The reliability has not gone down at all.\n\n**Participant 2:** When you're doing the searching for the tools, so you're doing the searching, and then returning the schema and then actually executing, what pieces of the tool call were relevant when you were doing the search? Was it just like the name and description, or did you include like pieces of the schema or pieces of something else in there?\n\n**Ajay Prakash:** How does the agent figure out the right tool to use based on what we present in the results? The first one is the name and the description of the tool itself. It is enough for the agent to decide which tool to use. Also, we have something called a short description. We have a long-form description and a short description. What we realized is just the short description itself is enough for the coding agent to figure out which tool to use.\n\n**Participant 3:** You mentioned that agents would be able to identify outdated playbooks. How exactly is the agent able to identify that anything has gotten outdated and automatically notify that the playbook needs to be updated based on any infrastructure or any other architectural changes? How would you do that?\n\n**Ajay Prakash:** How do the agents detect the outdated information in the playbooks and how do they improvise? The way it works is, so even without the playbook, also the agents can try to figure out what to do. With the playbooks, when it finds any outdated information, suppose the command that you gave is not working, it actually first tries the command and it fails. It takes the output and reasons about it that, ok, so this is the command given in the playbook, but it is not working. I need to try something else. Of course, based on their pre-training, they can try different things. Also, if they cannot find it, then they always have access to the tools. For example, let me go and search in the Google Docs on the right information, or they can use the code search to go and look for the right information and they can improvise.\n\nThe thing about these coding agents or the models like Claude, they don't give up that easily. They keep going and trying new things until they exhaust all of the options. They generally don't, they just keep going. We also have those instructions in the agent that if it finds a dead end and it has used up a lot of tokens, they can always go and ask the user to direct them, provide some missing information. Then the user can find the information and point it in the right direction. These are the mechanisms to make them updated.\n\n**Participant 4:** I wanted to know what is the process to control how many playbooks you can have in your company, but also how to remove or prevent duplication of playbooks that are created. What is the system then to control that?\n\n**Ajay Prakash:** The main mechanism is, of course, every playbook that we create has to go through code review. Generally, a human will review before it gets merged. If there is any duplicate, it gets flagged. Also, we have automated code reviews for the system, where we have instructions. For example, whenever someone creates a PR, we also ask the coding agent which is doing the reviews to figure out if it is a duplicate or if it is not needed, then they can surface that. Also, another thing is like the coding, as I mentioned, the people are not doing the playbooks manually, they are using coding agents to create the playbooks. We also have instructions on what is the best practice of writing a playbook and also telling the user, or the engineer that this might not be needed or irrelevant. I think another important aspect of this MCP server is also we are able to use metrics to measure the usage of all the tools and playbooks. We go and look at the metrics for each of the playbooks, and we can deprecate the things that are not used.\n\n**See more [presentations with transcripts](https://www.infoq.com/transcripts/presentations/)**", "url": "https://wpnews.pro/news/presentation-context-engineering-at-linkedin-how-we-built-an-organizational-for", "canonical_source": "https://www.infoq.com/presentations/linkedin-context-engineering/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global", "published_at": "2026-09-19 11:00:00+00:00", "updated_at": "2026-09-19 11:23:17.266410+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "developer-tools", "ai-products"], "entities": ["LinkedIn", "Ajay Prakash", "Contextual Agent Playbooks and Tools", "Model Context Protocol", "GitHub Copilot", "Andrej Karpathy"], "alternates": {"html": "https://wpnews.pro/news/presentation-context-engineering-at-linkedin-how-we-built-an-organizational-for", "markdown": "https://wpnews.pro/news/presentation-context-engineering-at-linkedin-how-we-built-an-organizational-for.md", "text": "https://wpnews.pro/news/presentation-context-engineering-at-linkedin-how-we-built-an-organizational-for.txt", "jsonld": "https://wpnews.pro/news/presentation-context-engineering-at-linkedin-how-we-built-an-organizational-for.jsonld"}}