The Context Gap in Enterprise AI

LinkedIn found that off-the-shelf coding agents failed in their environment because they lacked knowledge of internal frameworks, custom databases, and proprietary configuration systems. Engineers spent more time correcting AI hallucinations than writing code. While connecting tools via the Model Context Protocol (MCP) provided basic capabilities, it failed to solve for tribal knowledge scattered across stale wikis and Slack threads. Furthermore, exposing too many tools directly to an agent caused context overload, leading to performance degradation and memory loss.

Playbooks: Instructions as Tools

To bridge this gap, LinkedIn developed "Playbooks"—instructions and prompts served as tools via MCP. When an agent needs to perform a task (e.g., debugging an error spike), it invokes a playbook, which returns the necessary instructions and context as tool output. This ensures agents have both the capability to act and the procedural knowledge to act correctly.

Two core principles govern these playbooks:

  • Self-Containment: Each playbook focuses on a single, specific task to ensure the agent selects the correct one.
  • Modularization: Large workflows are broken into smaller, referenced playbooks. This enables reusability and allows for "progressive discovery," where the agent fetches context only as needed, preventing context bloat.

Scaling via Meta-Tools

To overcome the MCP limitation where performance degrades beyond 30–40 tools, LinkedIn implemented a three-meta-tool architecture: Search, Get Schema, and Execute. Instead of surfacing all 1,900+ tools and playbooks, the agent uses the 'Search' meta-tool to find relevant resources, 'Get Schema' to understand how to use them, and 'Execute' to perform the action. This allows the system to scale to thousands of tools while keeping the agent's context window clean.

The Self-Improving Flywheel

To prevent knowledge rot, LinkedIn treats playbooks as living code. Agents are encouraged to identify discrepancies or missing information after a session. They then propose updates to the playbook via a Pull Request. This creates a self-improving loop where the collective knowledge of the engineering organization is continuously refined by the agents themselves. The system is deployed via a local MCP server installed on all developer laptops, which syncs updates hourly, ensuring that central cross-cutting playbooks and repository-specific local playbooks remain current.