How LinkedIn made coding agents work on 1,000+ internal repos without fine-tuning

Step-by-Step Breakdown

1. Start with tools over MCP — then notice it is not enough

   The first move was an internal MCP server, with code search as the first tool: a sophisticated existing search over thousands of repos, now reachable by any agent. More followed — docs, Jira, Slack, data platforms, feature flags — and each addition compounded, because an engineer could now bring a PRD, a design doc and a ticket into one session. But even with every tool connected, slightly complex workflows still failed.

2. Name the three reasons tools alone fail

   (1) Tribal knowledge is scattered. How to debug a specific error lives across docs, wikis and Slack threads, often outdated and duplicated, so the agent gets lost even with access. (2) Context overload. Every tool output consumes context; enough of them force a compaction, the agent loses information and starts over. (3) No durable memory. Whatever the agent worked out, it works out again from scratch next time.

3. Serve instructions as tools — the playbook

   This is the whole idea. A playbook is a set of instructions and context, exposed over MCP with a name and a description exactly like a regular tool. The agent decides to invoke it the same way it decides to call any tool, and the instructions come back as the tool output. Ask "how do I set up an Airflow DAG at LinkedIn?" and the agent first pulls the relevant playbook, then follows it to call the right tools. Anyone at LinkedIn can write one and check it into a repository.

4. Rule one: a playbook must be self-contained

   One playbook, one specific task. If it is about setting up an Airflow DAG, that is all it covers. This is what lets the agent pick the right playbook — overlapping or sprawling playbooks make selection ambiguous, which is the failure that returns you to hallucination.

5. Rule two: break big playbooks into small ones and reference them

   Two payoffs, and the second is the important one. Reusability — a small self-contained playbook can be referenced from many larger ones. Progressive discovery of context — the agent reads a sub-playbook only when it actually needs it, instead of loading everything up front. That is the direct answer to context overload above, and it is the same mechanism that makes lazily-loaded skills affordable.

6. Close the loop so the knowledge does not rot

   Playbooks live in a repository and improve through a self-improving loop rather than depending on someone remembering to update a wiki — the failure mode that made the original docs unusable.

Gotchas & Caveats

• This is an enterprise-scale answer to an enterprise-scale problem. If you have three repos and no internal frameworks, the payoff is much smaller — the value comes from the gap between what a model knows and what your organisation does.
• It requires an internal MCP server and people willing to write playbooks. The self-improving loop reduces the maintenance burden but does not remove the initial authoring cost.
• Playbook quality becomes the new single point of failure: a wrong playbook is followed confidently, which is the same failure as a wrong wiki page but faster.
• Presented by a LinkedIn engineer about LinkedIn's own system; the numbers (1,000+ repos, week-long bootcamp) are context rather than measured results, and no adoption or accuracy figures are given.

Key Takeaways

• Playbooks are instructions delivered through the tool protocol. The agent discovers them, selects them and loads them exactly as it would a tool — no harness changes, which is why this works with Claude Code, Cursor or Copilot alike.
• This predates skills and arrives at the same design. LinkedIn built it in early 2025; the speaker notes playbooks are very similar to skills, developed independently. Two teams converging on "instructions should be discoverable and lazily loaded" is a strong signal that the pattern is right.
• Access to information is not understanding. Connecting every tool an agent could want still left it lost, because knowing where things are is not knowing how your organisation does them.
• Self-contained + composable are the two authoring rules, and both exist to protect agent decision-making rather than human readability.
• The bar was set as trust, not capability: code that is correct and of the quality an actual engineer would write. That framing is why tools-only was judged a failure rather than a partial success.
• The worked example is an on-call incident: agent fetches the debugging playbook for the alerting service, pulls logs and metrics, identifies root cause, proposes mitigation, acts on confirmation, updates the incident system and opens a PR — minutes instead of hours.