Context Engineering en LinkedIn: cómo 8.000 ingenieros usan MCP para dar memoria procedural a sus agentes
# Context Engineering en LinkedIn: cómo 8.000 ingenieros usan MCP para dar memoria procedural a sus agentes
En septiembre de 2026, Ajay Prakash, ingeniero senior de LinkedIn con 14 años construyendo sistemas distribuidos y los últimos cuatro completamente enfocados en IA, subió al escenario de QCon AI Boston para contar una historia que la industria llevaba meses esperando. LinkedIn había resuelto el problema más difícil de los coding agents modernos: **cómo hacer que un LLM trabaje productivamente dentro de un codebase propietario que nunca vio durante el pre-entrenamiento**. La solución no fue un modelo más grande, ni más contexto, ni mejor fine-tuning. Fue una **capa de contexto organizacional** construida sobre Model Context Protocol (MCP), con más de 600 playbooks reutilizables, 8.000 usuarios diarios, y un boost de productividad del 20% medido en producción.
Esto importa más allá de LinkedIn. Porque el problema que resolvieron es exactamente el que cualquier organización mediana o grande enfrenta cuando intenta desplegar coding agents en su codebase interno: los agentes genéricos saben programar, pero no saben **cómo programa tu organización**. No conocen tus convenciones, tus frameworks internos, tus decisiones arquitectónicas pasadas, ni los runbooks que tu equipo senior ha acumulado en diez años de producción. Sin esa capa, el agente produce código que compila pero que un reviewer senior rechaza en quince minutos porque "no es la forma en que lo hacemos aquí".
El problema: agentes brillantes en código que no entienden
LinkedIn tiene miles de repositorios, microservicios, frameworks internos, librerías propietarias, y una cultura de ingeniería con décadas de decisiones acumuladas. Cuando desplegaron los primeros coding agents comerciales — Copilot, Cursor, Claude Code — el resultado fue el que cualquier equipo puede predecir: el agente producía código que parecía correcto pero que rompía las convenciones de la casa.
Tres síntomas típicos:
- **Patrones inconsistentes.** El agente resolvía un problema de cache con una librería estándar de Python. El equipo usa una librería interna llamada `li-cache` con semánticas distintas. El código "funcionaba" pero introducía un patrón extraño en el codebase. - **Configuraciones incorrectas.** El agente generaba un Kubernetes manifest válido. La organización usa Helm charts con values específicas para cada región. El manifest no deployaba. - **Tests que pasaban localmente pero fallaban en CI.** El agente escribía tests asumiendo una base de datos local. CI usa contenedores efímeros con seeds distintos. El test fallaba porque las asunciones eran diferentes.
El patrón se repetía en miles de interacciones. Los ingenieros senior pasaban más tiempo corrigiendo al agente que programaban ellos directamente. La productivity boost que los vendors prometían se evaporaba contra la realidad de un codebase complejo y unas convenciones internas que el modelo nunca aprendió.
La solución: tres capas en una arquitectura
LinkedIn abordó el problema en tres capas, cada una atacando un aspecto distinto del gap entre el modelo genérico y el código propietario.
**Capa 1: herramientas agent-friendly vía MCP.** El primer paso fue exponer los sistemas internos de LinkedIn como herramientas accesibles para los agentes a través de un servidor MCP local. El catálogo incluye:
- Búsqueda de código interna con capacidades de entender la sintaxis y semántica del código propietario de LinkedIn. - Documentación y wikis internas, indexadas para retrieval rápido. - Sistema de feature flags con su rollout percentage y su target value. - Sistema de gestión de tareas (Jira interno). - Plataformas de datos internas con sus APIs documentadas. - Logs y métricas de producción, accesibles con permisos scoped. - Historial de deploys por servicio, con sus autores, reviewers, y motivos documentados.
El MCP server vive localmente en la máquina del ingeniero. El agente — sea Claude Code, Cursor, GitHub Copilot o cualquier otro que soporte MCP — puede llamar a estas herramientas igual que llama a las built-in. Para el modelo, son solo funciones; no sabe ni le importa que estén backed por una API interna en lugar de una librería open-source.
Lo crítico del diseño: **las herramientas se diseñaron pensando en los agentes desde el primer día**, no fueron adaptadas a posteriori. Eso significa:
- Documentación estructurada que el modelo puede entender sin ambigüedad. - Errores tipados con mensajes accionables, no stack traces de Java genéricos. - Permisos granulares por ingeniero y por scope de proyecto. - Rate limiting que previene que un agente en loop bloquee el sistema.
**Capa 2: memoria procedural con playbooks.** Las herramientas resolvieron el "acceso". Faltaba el "conocimiento". LinkedIn abordó esa segunda dimensión con **playbooks**: unidades reutilizables de memoria procedural que codifican cómo se hacen las cosas en LinkedIn.
Un playbook tiene tres componentes mínimos:
- **Nombre** que identifica la tarea que resuelve. - **Descripción** en lenguaje natural, legible por humanos y por modelos. - **Instrucciones** paso a paso que un agente puede ejecutar, con convenciones, comandos, validaciones, y contexto relacionado.
Ejemplo simplificado de un playbook para crear un Airflow pipeline:
```yaml name: create-airflow-pipeline description: | Crea un nuevo pipeline en Airflow siguiendo las convenciones de LinkedIn. Usa este playbook cuando necesites orquestar un job batch o recurrente que requiere scheduling, retries, o dependencias externas. instructions: | 1. Identifica el equipo dueño del pipeline en /oncall/<team>. 2. Crea el archivo DAG en airflow/dags/<pipeline-name>.py. 3. Usa siempre el operador LinkedInAirflowOperator; nunca el operador estándar. 4. Configura retries=3 con backoff exponencial starting en 60s. 5. Añade SLA de 2x el p99 histórico del job similar más cercano. 6. Documenta el pipeline en /docs/airflow/<pipeline-name>.md con: propósito, owner, dependencias upstream/downstream, runbook de incidentes. 7. Añade el pipeline al dashboard de observabilidad del equipo. 8. Pide review de un senior del equipo antes de mergear. validation: - airflow dags test <pipeline-name> 2024-01-01 - python -m pytest tests/airflow/test_<pipeline-name>.py related_context: - slack://li-eng-airflow - wiki://data-platform/airflow-conventions ```
Cuando un ingeniero pide al agente "crea un pipeline de Airflow para procesar eventos de login cada 15 minutos", el orquestador invoca este playbook vía MCP. El agente combina las instrucciones del playbook con los parámetros del usuario, escribe el código, ejecuta las validaciones, y produce un PR listo para review.
Los playbooks viven en un **repositorio central** accesible por cualquier empleado. Los playbooks específicos de un repositorio viven junto al código que sirven. Los playbooks globales viven en un repo dedicado con versionado, ownership, y review process.
**Capa 3: integración en el flujo diario.** El último componente es hacer que todo esto sea natural en el día a día del ingeniero. LinkedIn reporta:
- **8.000 usuarios diarios** del MCP server interno. - **600+ playbooks** activos en el catálogo. - **20% de aumento de productividad** medido en commit throughput y PR cycle time. - **Cero pérdida de reliability** del sistema durante la adoption.
La métrica de reliability es importante. Cuando metes LLMs en producción a esa escala, el riesgo es que los agentes en loop, los prompts mal diseñados, o los errores del modelo degraden la estabilidad del sistema. LinkedIn reporta que no fue el caso: la reliability se mantuvo constante mientras la adoption crecía. Eso implica guardrails sólidos, monitorización dedicada, y probablemente una capa de rate limiting que evite que un agente狂热 haga 10.000 llamadas a un sistema downstream en cinco minutos.
Anatomía técnica de un playbook en producción
La estructura de playbook que LinkedIn documentó en su presentación tiene más matices que el ejemplo simplificado de arriba. Las secciones reales incluyen:
```yaml metadata: name: create-airflow-pipeline version: "2.3.1" owner: data-platform-team last_updated: "2026-08-15" review_cadence: quarterly tags: [airflow, batch, data-pipeline]
description: | Contexto narrativo completo sobre cuándo usar este playbook, qué problemas resuelve, qué alternativas existen.
prerequisites: | - Acceso de escritura al repo airflow-config - Permisos en el sistema de observabilidad - Oncall rotation confirmada con el equipo dueño
steps: - step: 1 action: identify_owning_team details: | Buscar en /oncall/<domain> el equipo responsable. Si no existe, escalar a data-platform-leads. validation: owner_email_is_set
- step: 2 action: create_dag_file details: | Crear airflow/dags/<pipeline-name>.py usando LinkedInAirflowOperator como base class. validation: file_exists_and_is_valid_python
- step: 3 action: configure_retries details: | retries=3, retry_delay=timedelta(minutes=1), retry_exponential_backoff=True validation: config_matches_template
- step: 4 action: add_sla details: | SLA basado en p99 histórico del job similar. Calcular con scripts/analyze_sla.py --similar <name>. validation: sla_documented_in_dag
- step: 5 action: write_documentation template_path: /templates/airflow-doc-template.md validation: doc_has_all_required_sections
- step: 6 action: request_review details: | Asignar PR a un senior del equipo dueño. No mergear sin approval explícito. validation: senior_approval_recorded
post_conditions: - pipeline_appears_in_airflow_ui - dashboard_panel_created - runbook_documented
metrics: - name: time_to_first_run target: "< 24 hours" - name: incidents_per_month target: "< 0.5"
rollback_plan: | Pausar el DAG via Airflow UI. Comunicar al equipo dueño en #data-platform. Documentar incidente en /postmortems/<date>-<pipeline-name>. ```
Este nivel de estructura no es decoration. Es lo que permite que el playbook funcione tanto para humanos (que pueden leerlo y entenderlo) como para agentes (que pueden ejecutarlo paso a paso, validar cada paso, y detectar cuándo una asunción falla).
Por qué MCP fue el catalizador y no otra cosa
LinkedIn eligió MCP sobre alternativas internas por una razón estratégica: **estándar abierto de la industria**. Anthropic liberó MCP como protocolo abierto en 2024 y para 2026 ya era el estándar de facto para conectar herramientas a agentes. Esto significa tres cosas concretas:
**Primero, vendor lock-in evitable.** Si LinkedIn hubiera construido un protocolo propietario, habría tenido que mantener adapters para cada agente del mercado. Con MCP, cualquier agente que soporte MCP puede consumir los playbooks y herramientas internas. Hoy LinkedIn usa Claude Code, Copilot, Cursor, y otros; todos funcionan con la misma capa de contexto.
**Segundo, comunidad que贡献 protocolos.** MCP evoluciona con contribuciones de toda la industria. LinkedIn no necesita inventar primitivas como "resource sampling" o "elicitation"; las recibe del estándar y se enfoca en el valor específico de su organización: el contenido de los playbooks, la curaduría de las herramientas, la integración con sus sistemas internos.
**Tercero, recruiting más fácil.** Un nuevo ingeniero que llega a LinkedIn y ya conoce MCP puede ser productivo en horas, no en semanas. Si el protocolo fuera propietario, cada nuevo hire tendría que aprender la herramienta interna antes de poder usar agentes efectivamente.
La lección para tu organización: si estás considerando construir una capa de contexto para tus agentes, **construye sobre MCP** a menos que tengas razones muy específicas para no hacerlo. El coste de oportunidad de un protocolo propietario en este momento del mercado es prohibitivo.
Lecciones que cualquier equipo puede aplicar
El caso de LinkedIn tiene cinco takeaways prácticos que puedes empezar a aplicar esta semana:
**1. Identifica tus convenciones no documentadas.** El primer paso antes de construir playbooks es saber qué conventions tienes. Habla con tus ingenieros senior. Lee las PRs rechazadas. Busca los comentarios recurrentes en code review. El conocimiento que necesita un agente para ser productivo en tu codebase probablemente ya existe — solo está en la cabeza de cinco personas y no en ningún archivo.
**2. Empieza con un playbook de alto valor y bajo riesgo.** No intentes construir 600 playbooks el primer día. Elige un workflow repetitivo que tu equipo hace mal (con bugs, con tiempo excesivo) y crea un playbook para ese. Mide el antes y el después. Cuando tengas datos, escala.
**3. Versiona los playbooks con el mismo rigor que el código.** Un playbook desactualizado es peor que ningún playbook: el agente lo sigue ciegamente, produce código roto, y el engineer senior asume que el agente es inútil cuando en realidad el playbook era incorrecto. Versiona, revisa, actualiza trimestralmente.
**4. Mide productividad con métricas que importan.** "20% de aumento de productividad" es una cifra impresionante, pero meaningless sin definición. LinkedIn midió PR cycle time y commit throughput. Elige métricas que tu equipo ya trackea y compara antes/después del playbook. Sin eso, no puedes defender el programa ante liderazgo ni iterar efectivamente.
**5. El playbook es living documentation.** Un playbook vivo se actualiza cuando el equipo descubre una mejor forma de hacer algo. Un playbook muerto es un PDF que nadie lee. Diseña el sistema para que actualizar un playbook sea tan fácil como abrir un PR en el repo central.
La arquitectura del futuro: agentes como coworkers
Lo que LinkedIn ha construido es el anticipo de cómo будет el trabajo de ingeniería en cinco años. Los coding agents ya no son "asistentes que sugieren código". Son **coworkers que ejecutan tareas complejas con guardrails**. El humano decide qué hacer y revisa el resultado; el agente hace el trabajo mecánico siguiendo las convenciones de la organización.
Este cambio tiene implicaciones profundas:
**Primero, el rol de senior engineer evoluciona.** El senior ya no escribe todo el código; revisa el código que el agente escribe siguiendo los playbooks que el senior ayudó a definir. El seniority se mide por la calidad de los playbooks que contributed, no por la cantidad de código que produce directamente.
**Segundo, la onboarding se acelera.** Un nuevo ingeniero con acceso a los playbooks puede ser productivo en días en lugar de meses. Las convenciones, los frameworks internos, los runbooks de incidentes — todo está codificado en playbooks que el agente puede consultar y aplicar.
**Tercero, la culture code se vuelve explícita.** Las "cosas que todos saben pero nadie escribe" se convierten en playbooks mantenidos y versionados. La culture deja de ser tribal y se vuelve código ejecutable.
**Cuarto, el coste de LLM inference se vuelve FinOps predecible.** 8.000 usuarios diarios con un coste medio razonable por sesión suman una cifra mensual significativa. Hay que presupuestar, alertar, y optimizar como cualquier otra pieza de infraestructura.
Reflexión final: el contexto es el nuevo código
La industria lleva años diciendo "los prompts son el nuevo código". El caso de LinkedIn sugiere una versión más precisa: **el contexto es el nuevo código**. Los modelos son commodities; lo que diferencia a una organización que usa agentes efectivamente de una que lucha con ellos es la calidad del contexto que provee.
Si tu equipo está desplegando coding agents y los resultados son inconsistentes, la respuesta no es "necesitamos un modelo más grande". La respuesta es "necesitamos mejor contexto": herramientas accesibles vía MCP, playbooks que codifican nuestras convenciones, y una cultura que mantiene esa capa de contexto como activo de primera clase.
LinkedIn demostró que se puede hacer a escala, con resultados medidos, sin sacrificar reliability. La pregunta para tu organización no es si el patrón funciona — está demostrado. La pregunta es cuándo empiezas a construir tu propia capa de contexto.
**CTA:** Esta semana, identifica las tres tareas más repetitivas de tu equipo de ingeniería. Para cada una, escribe un playbook de una página con los pasos exactos, las convenciones, y las validaciones. Publícalos en un repo central accesible por tus ingenieros. La semana siguiente, monta un MCP server mínimo que exponga esos playbooks a tu coding agent. Mide el antes y el después. En un mes tendrás datos para decidir si escalar el programa. El patrón funciona; lo que falta es empezarlo.