Platform Engineering for AI: Scaling Multi-Agentic Systems with MCP

linkedin · Tech · 2026 · source Agentic: yes · promotional bias: low · summary-only (no fetched source) · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise platform engineering for AI agents

LinkedIn needed to move AI agents from siloed proof-of-concepts into production-scale engineering infrastructure serving thousands of developers, while avoiding repeated plumbing, inconsistent safety controls, fragmented tool integrations, and agent behavior that bypassed normal engineering review.

Constraints:

Architecture

LinkedIn built an agentic platform with two complementary execution modes. Foreground agents run inside developer tools such as IDEs and augmented GitHub Copilot, using MCP tools and instruction files to inject LinkedIn context while developers stay actively involved. Background agents run asynchronously in secure remote sandboxes, receive structured specs, use native and MCP tools, create branches and pull requests, and respond to review comments. Shared platform layers provide prompt and instruction management, MCP server abstractions, model-inference abstraction, RAG over code/docs/PR history, execution tracing, agent identities, permission enforcement, evaluation, and observability.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  Developer_task_spec["Developer task spec"] --> Background_agent_orchestrator["Background agent orchestrator"]
  Foreground_agent_layer["Foreground agent layer"] --> MCP_tool_layer["MCP tool layer"]
  Foreground_agent_layer --> Instruction_file_system["Instruction file system"]
  Background_agent_orchestrator --> Remote_sandbox["Remote sandbox"]
  Background_agent_orchestrator --> MCP_tool_layer
  Background_agent_orchestrator --> Model_inference_abstraction["Model inference abstraction"]
  Background_agent_orchestrator --> Pull_request_review_loop["Pull request review loop"]
  Remote_sandbox --> GitHub_integration["GitHub integration"]
  MCP_tool_layer --> Code_search_tools["Code search tools"]
  MCP_tool_layer --> Static_analysis_tools["Static analysis tools"]
  MCP_tool_layer --> Documentation_retrieval["Documentation retrieval"]
  MCP_tool_layer --> Observability_tools["Observability tools"]
  RAG_and_semantic_index["RAG and semantic index"] --> MCP_tool_layer
  RAG_and_semantic_index --> PR_history_knowledge_base["PR history knowledge base"]
  PR_history_knowledge_base --> Evaluation_system["Evaluation system"]
  GitHub_integration --> Pull_request_review_loop
  Pull_request_review_loop --> Evaluation_system
  Pull_request_review_loop --> Observability_and_audit["Observability and audit"]
  Evaluation_system --> Observability_and_audit
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
Developer task spec Structured expression of developer intent, scope, tools, acceptance criteria, and validation checks. Background agent orchestrator
Foreground agent layer IDE-integrated assistance where developers actively observe and steer work through augmented commercial tools. MCP tool layer, Instruction file system
Background agent orchestrator Runs autonomous tasks in secure sandboxes and manages execution from spec to pull request. Remote sandbox, MCP tool layer, Model inference abstraction, Pull request review loop
Remote sandbox Constrained environment where agents can manipulate files and run operations with restricted identities and permissions. Background agent orchestrator, GitHub integration
MCP tool layer Standardizes tool calling across agents, models, languages, and internal services. Code search tools, Static analysis tools, Documentation retrieval, Observability tools, Foreground agent layer, Background agent orchestrator
Instruction file system Maintains Copilot-style Markdown instructions containing enterprise, language, and repository-specific context. Foreground agent layer, Background agent orchestrator
Model inference abstraction Abstracts commercial and in-house model inference so teams do not couple use cases to one provider. Background agent orchestrator
RAG and semantic index Maintains semantic understanding of code, documentation, PR history, review comments, and internal knowledge. MCP tool layer, PR history knowledge base
PR history knowledge base Stores semantic descriptions of prior pull requests and review outcomes for similar-task retrieval and evaluation. RAG and semantic index, Evaluation system
GitHub integration Handles repository access, branch management, and pull request creation from sandboxed agents. Pull request review loop
Pull request review loop Lets developers review, comment on, approve, or reject agent-generated changes; agents can address review comments. Evaluation system, Observability and audit
Evaluation system Measures build/test/static-analysis success, PR acceptability, quality regressions, and qualitative model judgments. Observability and audit
Observability and audit Captures execution traces, reasoning chains, tool calls, agent identities, permissions, and what the agent observed. Pull request review loop

Data flow

A developer writes a task spec or uses an IDE assistant. For foreground work, custom instructions and MCP tools enrich commercial assistants with LinkedIn context. For background work, the platform instantiates an agent in a remote sandbox with the spec, context, identity, and allowed tools; the agent edits files, invokes GitHub and internal systems, opens a pull request, and then iterates on developer review comments. Execution traces, observations, reasoning, tool calls, and PR outcomes feed observability, evaluation, and future context/memory.

4 supporting quotes
“Foreground agents operate directly in the IDE, where developers remain actively involved and can observe what the agent is doing in real-time.”summary, stated
“Background agents represent a different paradigm where LinkedIn has built the orchestration system ground-up.”summary, stated
“The platform instantiates the agent within this sandbox along with the context from the developer's spec or prompt”summary, stated
“Every agent-generated change goes through the exact same code review process, testing pipelines, and ownership checks that human-generated code undergoes.”summary, stated

Why this architecture

LinkedIn treats AI agents as infrastructure because the hard production problems are shared: orchestration, sandboxing, tool contracts, context, security, evaluation, and observability. The foreground/background split lets developers choose active control or asynchronous toil reduction, while MCP and common platform abstractions prevent every team from rebuilding custom adapters and safety layers.

3 supporting quotes
“developed a unified platform engineering approach that treats AI agents as a first-class execution model, comparable to microservices infrastructure.”summary, stated
“This standardization enables LinkedIn to use the same MCP tools across both foreground and background agents, maximizing leverage and reducing duplication.”summary, stated
“The platform ensures developers aren't reinventing boilerplate infrastructure while maintaining autonomy over their specific use cases.”summary, stated

Models used: GitHub Copilot · commercial models · in-house models · MCP-compatible models · LLM judges

Scale

Alternatives considered (roads not taken)

Let teams continue building local scripts and siloed AI tools

Rejected because: That approach repeatedly reinvented orchestration, data access, safety evaluation, and deployment plumbing.

“developers were experimenting with AI in silos, creating one-off scripts and local tools”summary, stated
“teams repeatedly reinvented the same infrastructure plumbing around prompt orchestration, data access, safety evaluations, and deployment.”summary, stated

Build all foreground agents from scratch

Rejected because: LinkedIn instead augments commercial tools like GitHub Copilot with MCP tools and custom instructions when developers need active IDE assistance.

“LinkedIn doesn't build these from scratch but instead augments commercial products like GitHub Copilot with MCP tools and custom instructions”summary, stated

Give background agents direct authority to change code

Rejected because: LinkedIn requires agents to propose changes through pull requests, with standard review, testing, and ownership checks.

“agents cannot directly make code changes—they can only propose changes.”summary, stated
“Every agent-generated change goes through the exact same code review process, testing pipelines, and ownership checks”summary, stated

Wire tools separately for each model vendor

Rejected because: Vendor-specific function-calling formats created fragmentation and custom adapter work.

“Before MCP, AI teams had to wire tool calls differently for each model vendor's function-calling format”summary, stated
“MCP solves this by providing a common protocol that, once implemented, allows any language, agent, tool, or model to interact seamlessly.”summary, stated

Recreate general-purpose coding assistants

Rejected because: LinkedIn argues the unique value is solving company-specific, repetitive, high-friction tasks where proprietary context matters.

“solve for company-specific context rather than recreating general-purpose tools like GitHub Copilot or Cursor.”summary, stated
“Generic coding assistance is commoditized; domain-specific automation leveraging proprietary knowledge and patterns is where organizations can capture unique value.”summary, stated

Patterns

multi-agent-orchestration (agent-architecture)

LinkedIn operationalizes foreground agents, background agents, observability agents, UI QA agents, and analytics agents on a shared platform rather than as isolated tools.

“A key architectural distinction in LinkedIn's platform is the separation between "foreground agents" and "background agents," each serving different developer workflows and requirements.”summary, stated
“Beyond development, LinkedIn explores observability agents that monitor production metrics, analyze logs, respond to alerts, and even take safe remedial actions autonomously.”summary, stated

tool-use-orchestration (agent-architecture)

MCP standardizes how agents invoke code search, static analysis, internal CLI, impact analysis, documentation, and observability tools.

“The Model Context Protocol (MCP) plays a central role in LinkedIn's agentic platform by standardizing tool calling across different agents, models, and services.”summary, stated
“LinkedIn has developed a range of MCP tools covering common developer needs: code search capabilities, static analysis execution, internal command-line tool invocation”summary, stated

safety-policy-enforcement (safety)

LinkedIn constrains agents through sandboxes, agent identities, limited authorization, isolated systems, PR-only changes, and standard review gates.

“This sandbox provides the agent with freedom to manipulate the file system and execute necessary operations while maintaining strict security boundaries.”summary, stated
“Certain systems are simply isolated from agent access regardless of the task.”summary, stated

human-in-the-loop-gate (control)

Agents propose PRs, developers inspect traces and final changes, and standard review/approval remains the authority path.

“Developers can replay execution traces, inspect reasoning chains, verify what the agent observed, examine the final changes, and ultimately approve or reject the work.”summary, stated
“This human-in-the-loop pattern maintains engineering judgment and quality standards while leveraging agents to increase productivity.”summary, stated

context-engineering (context)

LinkedIn preserves enterprise-wide, language-specific, repository-specific, PR-history, documentation, telemetry, and semantic-code context for agents.

“The platform provides a standard library of MCP tools and preserves context at multiple levels—enterprise-wide, language-specific, and repository-specific”summary, stated
“One of the most challenging aspects of agentic systems is providing sufficient context for agents to make informed decisions”summary, stated

rag-retrieval (retrieval)

A semantic RAG index over evolving code, docs, PR history, and review knowledge gives agents examples and organization-specific facts.

“LinkedIn addresses this through a comprehensive RAG (Retrieval-Augmented Generation) architecture that maintains semantic understanding of the evolving codebase.”summary, stated
“the system generates a description of what actually changed. When agents need to perform similar tasks, they can query past PRs to find relevant examples”summary, stated

eval-driven-development (evaluation)

Evaluations are built into the platform from day one, combining verifiable code checks with PR-history-based qualitative assessment and regression tracking.

“LinkedIn emphasizes that evaluations are not optional or "phase two" work—they are core to the platform. The team learned this lesson the hard way and now prioritizes understanding whether agentic systems are improving or regressing over time.”summary, stated
“The platform incorporates both qualitative and quantitative evaluation approaches. On the quantitative side, verifiable checks include whether code builds successfully, whether tests pass, and whether changes meet static analysis requirements.”summary, stated

observability-tracing (operations)

Execution traces, reasoning chains, observed context, tool calls, decisions, identities, and permissions are captured so developers can trust and debug agents.

“Observability is built into the platform by default. Every step an agent takes, every tool call it makes, and every decision it reaches is audited and traceable.”summary, stated
“Every step an agent takes, every tool call it makes, and every decision it reaches is audited and traceable. Developers can replay execution traces, inspect reasoning chains, and verify exactly what the agent saw and thought during execution.”summary, stated

prompt-versioning (prompt-ops)

The platform manages prompt/instruction artifacts, including Copilot instruction Markdown files generated and maintained for enterprise, language, and repository contexts.

“These include mechanisms for prompt management, abstractions for defining tools and spinning up MCP servers, and standard infrastructure for abstracting model inference across commercial and in-house models.”summary, stated
“LinkedIn generates and maintains instruction files (like Copilot instructions for GitHub Copilot) that are essentially Markdown files encapsulating common context.”summary, stated

agent-memory (memory)

The platform mines PR history, human review comments, responses, semantic descriptions, and examples so agents learn reusable organizational patterns.

“An innovative approach LinkedIn developed involves using AI to describe individual pull requests at a semantic level.”summary, stated
“This prevents agents from having to figure everything out from scratch and leverages the organization's historical knowledge encoded in PR history.”summary, stated

Tradeoffs

Split agents into foreground and background modes.

Chose foreground IDE agents plus background sandbox agents over one interaction model for all developer tasks.

Rationale: Developers sometimes need high-fidelity active control, and sometimes need asynchronous toil reduction with reviewable PR outputs.

3 supporting quotes
“A key architectural distinction in LinkedIn's platform is the separation between "foreground agents" and "background agents,"”summary, stated
“Foreground agents are ideal when developers want to maintain active control, test ideas, validate approaches, and work through solutions iteratively.”summary, stated
“Background agents excel at reducing toil—handling repetitive but essential tasks that rarely get prioritized, such as dependency migrations, refactoring large codebases, improving test coverage, and cleaning up deprecated A/B tests.”summary, stated

Use PR review as the control boundary for autonomous work.

Chose agent-proposed pull requests with human review over agent-direct commits, merges, or production changes.

Rationale: Pull requests preserve standard engineering quality, ownership, compliance, and human judgment while agents handle execution.

“Critically, LinkedIn applies the principle that agents cannot directly make code changes—they can only propose changes. Every agent-generated change goes through the exact same code review process, testing pipelines, and ownership checks that human-generated code undergoes.”summary, stated
“This ensures that engineering judgment remains central, code quality standards are maintained, and compliance requirements are met.”summary, stated

Standardize tool access with MCP.

Chose MCP-based tools shared across agent types over custom vendor-function-calling adapters.

Rationale: A common protocol reduces duplication and lets the same enterprise tools work in IDE assistants and autonomous background agents.

“MCP solves this by providing a common protocol that, once implemented, allows any language, agent, tool, or model to interact seamlessly.”summary, stated
“A developer working in their IDE with an augmented GitHub Copilot can access the same enterprise tools that a background agent uses”summary, stated

Invest in semantic PR history as agent context.

Chose AI-described PR history and review comments over forcing each agent to infer organizational patterns from scratch.

Rationale: Past PRs encode migration patterns, review expectations, and mergeability signals that can guide future agent tasks.

“if a PR bumps a Gradle dependency version, the system generates a description of what actually changed.”summary, stated
“observe what other changes typically accompany such updates.”summary, stated

Fund an agentic platform team.

Chose dedicated platform operations and shared building blocks over unfunded grassroots agent adoption.

Rationale: Agents require ongoing process changes, technology evolution, operations, and infrastructure support like other platform layers.

“LinkedIn has established a fully funded agentic platform team responsible for process changes, technology evolution, common building block development”summary, stated
“This mirrors how organizations support microservices infrastructure, storage systems, or machine learning platforms—recognizing that agents represent a fundamental execution model requiring professional operations and continuous improvement.”summary, stated

Gotchas (what bit them)

Siloed agent experiments create infrastructure sprawl.

Root cause: Teams build local scripts and one-off tools that each solve prompt orchestration, data access, safety, evals, and deployment differently.

Resolution: Treat agents as a first-class platform execution model with shared infrastructure support comparable to microservices or Kubernetes.

“moving beyond the scattered proof-of-concept phase that many organizations experience.”summary, stated
“treats AI agents as a new execution model requiring the same level of infrastructure support as microservices or Kubernetes-based compute infrastructure.”summary, stated

Autonomous agents can overstep without security boundaries.

Root cause: Background agents need filesystem and tool access to do useful work, but unrestricted access would violate security and compliance expectations.

Resolution: Run agents in remote sandboxes with isolated systems, limited auth, restricted permissions, and specific agent identities.

“Certain systems are isolated from the sandbox, authentication and authorization are limited, and agents operate with restricted permissions assigned to specific agent identities.”summary, stated
“All agents operate with distinct identities within LinkedIn's systems, making their work auditable and subject to the same permissions and authorization checks that apply to human developers.”summary, stated

Vendor-specific tool calling slows platform adoption.

Root cause: Each model vendor's function-calling format required separate adapters and left subtle incompatibilities.

Resolution: Use MCP as a common protocol so tools work across foreground and background agents, models, and services.

“creating fragmentation and requiring custom adapters for every internal service.”summary, stated
“This standardization enables LinkedIn to use the same MCP tools across both foreground and background agents, maximizing leverage and reducing duplication.”summary, stated

Company-specific context is the durable value, not generic coding assistance.

Root cause: Generic tools are increasingly commoditized and lack the proprietary knowledge needed for high-value internal automation.

Resolution: Focus on repetitive, high-friction engineering tasks where LinkedIn's internal context, PR history, and platform knowledge are decisive.

“Generic coding assistance is commoditized; domain-specific automation leveraging proprietary knowledge and patterns is where organizations can capture unique value.”summary, stated
“The value lies in identifying repetitive, high-friction engineering tasks unique to the organization and applying agentic solutions where the company's specific context provides competitive advantage.”summary, stated

Evaluations deferred until later leave teams unable to tell if agents improve or regress.

Root cause: Agentic systems can look impressive without rigorous measurement over time.

Resolution: Make qualitative and quantitative evals core platform components from the beginning.

“The team learned this lesson the hard way and now prioritizes understanding whether agentic systems are improving or regressing over time.”summary, stated
“don't underestimate evaluations. They're critical for knowing whether systems improve or regress and should be core platform components from day one”summary, stated

Evaluation

LinkedIn evaluates agents with verifiable checks such as builds, tests, and static analysis; qualitative assessment from historical PR data; regression tracking over time; and full observability of traces, reasoning, tool calls, and what the agent saw.

Metrics: Build success · Test pass rate · Static analysis results · PR quality and acceptability · Predicted reviewer comments or required revisions · Regression detection over time · Execution trace completeness · Permission and authorization auditability

3 supporting quotes
“On the quantitative side, verifiable checks include whether code builds successfully, whether tests pass, and whether changes meet static analysis requirements.”summary, stated
“On the qualitative side, LinkedIn leverages its historical PR data to train models that can assess PR quality and predict whether changes will be accepted or require revision.”summary, stated
“Developers can replay execution traces, inspect reasoning chains, and verify exactly what the agent saw and thought during execution.”summary, stated

Outcomes

The summary describes thousands of daily developer users, thousands of daily PRs, tens or hundreds of thousands of historical PRs for evaluation, and background agents operating across thousands of repositories.

4 supporting quotes
“The platform serves thousands of developers daily, indicating substantial scale and adoption.”summary, stated
“Background agents handle toil reduction tasks like dependency migrations across thousands of repositories, improving test coverage systematically, cleaning up deprecated A/B tests, and executing large-scale refactoring efforts.”summary, stated
“Foreground agents accelerate active development by eliminating setup and teardown toil, providing context-aware code suggestions, and helping developers test and validate ideas more quickly. They assist with the thinking-heavy work where developers benefit from intelligent collaboration.”summary, stated
“Beyond development, LinkedIn explores observability agents that monitor production metrics, analyze logs, respond to alerts”summary, stated