Overview
Coding agents become useful inside a large enterprise only when they understand its private systems, operating procedures, and quality standards. LinkedIn initially gave engineers general-purpose agents, but those agents lacked knowledge of its internal frameworks, infrastructure, and more than 1,000 repositories, producing incorrect or fabricated guidance that required extensive human correction. The company first exposed code search and other internal systems—including documentation, Jira, Slack, data platforms, and feature flags—through an internal MCP platform. Tool access improved basic assistance but did not reliably support complete workflows because procedural knowledge remained fragmented, context windows became crowded, and agents retained no durable learning between sessions. LinkedIn addressed this gap with runbooks: self-contained, task-specific instruction packages that agents discover and invoke like tools. Large procedures are decomposed into reusable sub-runbooks, enabling progressive context disclosure. A locally installed MCP server provides both central, organization-wide runbooks and repository-specific local runbooks, with hourly updates. Instead of exposing every asset directly, the server presents search, schema retrieval, and execution utilities, allowing the catalog to scale. The resulting system reportedly serves more than 8,000 daily users, 1,300 tools, and 600 runbooks, demonstrating that dependable enterprise agents require curated context infrastructure—not merely stronger models.
Sections
System Architecture and Implementation
Concrete architectural mechanisms used to deliver and scale contextual tools and instructions.
- One local MCP server is automatically installed on LinkedIn-issued laptops and provides the common interface for tools and runbooks.
- Updates to the MCP server, tools, and runbooks are automatically distributed to employee laptops every hour.
- Central runbooks apply across repositories, while local runbooks live with a specific repository and are automatically selected when an agent works there.
- The platform avoids exposing its entire catalog directly. Agents first search by keywords and tags, retrieve the chosen asset's schema, and then execute it.
- The reported operating scale is more than 8,000 daily users, over 1,300 tools, and more than 600 runbooks.
Strategic Implications
Higher-level conclusions derived from LinkedIn's implementation experience.
- Enterprise agent performance is primarily a systems-design problem: models need authoritative retrieval, procedural instructions, controlled execution, and maintenance workflows around them.
- Runbooks function as an organizational memory layer even though individual agent sessions remain stateless. Durable knowledge resides in version-controlled, discoverable instructions rather than in a model's conversational memory.
- The pull-request update loop balances adaptation with governance: agents help identify and draft improvements, but humans approve changes before shared operational knowledge is updated.
- Repository-local runbooks distribute ownership to domain teams while a central MCP interface preserves a consistent access and authentication model.
- Catalog scale becomes manageable when discovery is separated from execution; the agent sees a stable, minimal interface instead of every possible capability.
Key Design Comparisons
Important alternatives and boundaries described in the talk.
- Providing internal tools improved search and basic answers, but combining tools with runbooks enabled agents to approach complete workflows because runbooks supplied the missing procedural knowledge.
- Large monolithic runbooks contain broad context but are harder to reuse and load efficiently; smaller self-contained runbooks can be composed and retrieved progressively.
- Central runbooks serve practices shared across multiple repositories, whereas local runbooks capture repository-specific knowledge and can evolve without modifying the central repository.
- Exposing every tool and runbook directly risks context overload; a search-schema-execution interface keeps the visible tool surface small while supporting a much larger catalog.