El compañero de guardia que LinkedIn intenta construir
La pregunta práctica, para quien ya apuntó Claude Code a la búsqueda, los documentos y los tickets de la empresa, es por qué eso sigue atascándose en los flujos internos. Ajay Prakash, ingeniero de software de LinkedIn al que llaman AJ, responde desde dentro de ese atasco. Las herramientas MCP podían recuperar lo que hay en LinkedIn, y los agentes seguían perdiéndose en el procedimiento. Su charla, subida por el canal AI Engineer, analiza ese hueco como un fallo y después recorre el sistema interno que LinkedIn construyó encima de esas herramientas.
Enmarca el trabajo como ingeniería de contexto: dar forma a lo que un agente de código puede ver y llamar para que opere dentro de LinkedIn, y no como autocompletado genérico. El gancho es un recorrido de guardia que presenta como una historia de producción que los equipos ya ejecutan.
Un ingeniero de un equipo que posee servicios críticos recibe una alerta de pico de errores mientras todavía está entendiendo el incidente. Pega el enlace de la alerta en un agente de código como Claude Code o GitHub Copilot. Mientras la persona sigue orientándose, el agente trae las instrucciones de depuración de la empresa, identifica el servicio afectado, carga el contexto de ese servicio y extrae registros y métricas. A partir de eso propone una causa raíz y pasos de mitigación, y espera la confirmación. Después de que el ingeniero confirma, Prakash describe al agente tomando acciones de mitigación, actualizando el sistema de gestión de incidentes con detalles, métricas de error y paneles, haciendo checkout del código y abriendo un pull request dirigido a la causa raíz.
Dice que ese ciclo ocurre en unos minutos de trabajo que a mano habrían llevado unas horas, etiqueta el recorrido como “no es ficción” y dice que los equipos de LinkedIn ya usan así los agentes de código, como compañeros con un conocimiento profundo de los sistemas internos y del código. El sistema que lo hace posible, en sus palabras, es contextual agent playbooks and tools. El resto de la charla cubre por qué lo construyeron, cómo lo construyeron y qué aprendieron.
Por qué no bastó con entregar a los ingenieros agentes de código genéricos
LinkedIn desplegó agentes de código entre los ingenieros como lo hicieron muchas empresas, y Prakash dice que no funcionaron bien en una gran organización. Su diagnóstico es un hueco en los datos de entrenamiento: los modelos se entrenaron con repositorios de código abierto y carecían de las bases de código, los marcos y los sistemas internos ya maduros de LinkedIn.
Sin ese contexto, dice, los agentes alucinaban, se paraban a mitad de la tarea o inventaban detalles incorrectos. Los ingenieros entonces los guiaban a mano para que hicieran lo correcto, y eso a menudo llevaba más tiempo que escribir el código. Muchos ingenieros volvieron a programar a mano.
La pila que esos agentes tenían que aprender, tal como él la bosquejó, es grande y en su mayor parte privada. Los ingenieros nuevos de LinkedIn, dice, pasan por un boot camp de una semana solo para familiarizarse con esos sistemas. Usa esa incorporación como analogía de por qué los agentes necesitan el mismo contexto de la organización.
- Más de mil repositorios que alimentan miles de microservicios y aplicaciones
- Marcos y bibliotecas internos bajo esos servicios
- Infraestructura propia, como bases de datos internas, una plataforma de experimentación y seguimiento, y un sistema interno de gestión de la configuración
La barra: cualquier agente, código interno de confianza
La pregunta de diseño que se plantearon fue cómo cualquier agente de código —Cursor, Claude Code o GitHub Copilot— podía entender lo interno de LinkedIn lo bastante bien como para entregar código en el que los ingenieros confiaran. Prakash define esa confianza con dos propiedades: el código debe ser correcto, y su calidad debe estar a la altura del código escrito por un ingeniero de verdad.
Esa es la barra que, según él, fijó el equipo.
Las herramientas MCP internas fueron el primer avance
Prakash sitúa el primer avance a principios de 2025. Dice que Anthropic publicó MCP, el Model Context Protocol para conectar agentes a herramientas externas; que en poco tiempo se convirtió en un estándar de la industria para construir herramientas de agentes; y que LinkedIn construyó un servidor MCP interno cuya primera herramienta fue la búsqueda de código de toda la empresa. Los subtítulos automáticos se deslizan hacia “MCB” y “Cloud Code”; en la charla se trata del protocolo MCP de Anthropic y de Claude Code.
LinkedIn ya tenía un sistema de búsqueda de código sofisticado, capaz de consultar miles de repositorios con palabras clave y filtros propios. Exponer ese sistema por MCP permitió a los agentes encontrar ejemplos internos de cómo LinkedIn hace una configuración dada e implementar a partir de esos hallazgos. Prakash lo llama un avance importante: un ingeniero podía preguntar cómo configurar algo, y el agente podía buscar en el código de LinkedIn en lugar de adivinar.
Después añadieron más superficies MCP: documentos, Jira, Slack, plataformas de datos y feature flags. Describe un valor que se acumulaba a medida que los ingenieros metían documentos de requisitos de producto (PRD), documentos de diseño y tickets de Jira en los agentes de código.
Tres razones por las que las herramientas seguían sin poder terminar el trabajo
Conectar esas herramientas seguía fallando en flujos un poco complejos. Con herramientas, dice Prakash, un agente podía responder preguntas básicas y encontrar ejemplos de código. Completar un trabajo de punta a punta con fiabilidad era otra barra.
El primer fallo fue el saber interno disperso. Terminar un trabajo concreto exigía saber cómo corregir un error dado, configurar un sistema o depurar un registro concreto. Ese saber vivía repartido entre documentos, wikis y conversaciones de Slack, y a menudo estaba desactualizado o duplicado. Las herramientas recuperan esas superficies. Armar un procedimiento a partir de ellas es un paso aparte. Los agentes con acceso igual “se perdían”.
El segundo fallo fue la sobrecarga de contexto. Cada resultado de una herramienta ocupaba espacio en la ventana de contexto del agente, la memoria de trabajo de la sesión. Al final la sesión tenía que compactar, resumiendo o descartando el material anterior, lo que perdía información y obligaba al agente a rehacer el trabajo.
El tercer fallo fue la falta de memoria duradera. Aunque un agente resolviera una tarea, la siguiente petición de un ingeniero para el mismo trabajo empezaba de cero. Los playbooks abordan eso más adelante como archivos de instrucciones en un repositorio.
- El saber interno sobre un error, una configuración o un registro estaba disperso entre documentos, wikis y Slack
- Cada resultado de una herramienta llenaba la ventana de contexto hasta que la compactación soltaba información
- Una tarea resuelta no tenía memoria duradera, así que la sesión siguiente empezaba de nuevo
Playbooks: instrucciones servidas del mismo modo que las herramientas
A principios de 2025, dice Prakash, inventaron los playbooks para que MCP sirviera tanto las herramientas como las instrucciones o los prompts para usarlas. Cada playbook aparece como una herramienta con nombre y descripción que el agente puede invocar. Invocarlo devuelve sus instrucciones y su contexto como salida de herramienta, de modo que el agente recibe capacidades y guía por el mismo canal.
La historia de uso que cuenta es la de un ingeniero que pregunta cómo montar un DAG de Apache Airflow —un grafo acíclico dirigido de tareas— en LinkedIn. El agente elige un playbook para esa tarea, lee las instrucciones devueltas y después llama a las herramientas pertinentes para terminar el trabajo.
Cualquier persona en LinkedIn puede escribir un playbook, subirlo a un repositorio y dejarlo disponible para los demás.
| Fallo en sesiones solo con herramientas | Qué dice que ocurrió | Qué debían cambiar los playbooks |
|---|---|---|
| Saber interno disperso | Cómo corregir un error, configurar un sistema o depurar un registro vivía entre documentos, wikis y Slack, a menudo desactualizado o duplicado; los agentes con recuperación igual se perdían | Un playbook con nombre devuelve un procedimiento autocontenido para una tarea |
| Sobrecarga de contexto | Cada resultado de una herramienta llenaba la ventana hasta que la compactación soltaba información y el agente rehacía el trabajo | Los playbooks más pequeños a los que se hace referencia se cargan solo cuando hacen falta (descubrimiento progresivo) |
| Sin memoria duradera | Una tarea resuelta empezaba de cero en la sesión siguiente | Archivos de playbook en un repositorio, refrescados mediante pull requests después de las sesiones |
Dos reglas para escribirlos, y la comparación con las skills
A medida que la gente creaba más playbooks, Prakash dice que pidieron a todo el mundo seguir dos principios de base. Primero, un playbook debe ser autocontenido en torno a una tarea concreta para que los agentes puedan elegir el correcto. Un playbook de un DAG de Airflow se queda en ese DAG.
Segundo, un playbook grande debe partirse en playbooks más pequeños que un padre pueda referenciar. Partirlos, dice, compra dos cosas: reutilización, porque un playbook pequeño puede referenciarse desde varios padres, y descubrimiento progresivo, porque el agente carga un playbook más pequeño solo cuando necesita esa tajada de contexto.
También compara los playbooks con las skills, el patrón de la industria de empaquetar instrucciones que un agente puede cargar cuando hacen falta. Prakash dice que los playbooks son la misma idea, que LinkedIn construyó el sistema de playbooks antes de que existieran las skills, y que los playbooks están más ajustados a capturar el contexto de la organización y servirlo por MCP con poco montaje.
El ciclo que se alienta para que los playbooks no se queden viejos
El problema de la base de conocimiento que él nombra es que envejece: las instrucciones se quedan desactualizadas. El flujo de trabajo del agente que se alienta es usar un playbook, identificar al final de la sesión lo aprendido —información desactualizada, discrepante o ausente—, actualizar los archivos del playbook en el repositorio y abrir un pull request.
Dice que el playbook se actualiza después del pull request. A eso lo llama un volante: los agentes consumen y refrescan las instrucciones de la empresa.
Un MCP en el portátil, playbooks centrales, playbooks locales
La distribución, tal como él la describe, es un servidor MCP local preinstalado en los portátiles de LinkedIn. Quien entra en la empresa y recibe un portátil ya tiene el servidor ahí. Prakash dice que las actualizaciones del servidor, de los playbooks y de las herramientas llegan cada hora.
Los playbooks se parten en dos clases. Los playbooks centrales cubren trabajo transversal que se aplica en muchos repositorios. Los playbooks locales viven en un repositorio concreto y solo se recogen cuando el agente de código está trabajando ahí, de modo que el saber propio de ese repositorio puede crecer sin cambiar un catálogo central.
Un solo servidor MCP se pone delante de todos los playbooks y herramientas para que la autenticación, la telemetría y el aprendizaje puedan manejarse de forma central.
Por qué dejaron de listar cada herramienta
Listar cada playbook y cada herramienta en la superficie MCP chocó con un límite de escala que él trata como un problema habitual de MCP: no podían pasar de unas 30 o 40 herramientas sin dañar el contexto y el rendimiento del sistema.
La indirección que usaron se sienta delante del catálogo en forma de tres metaherramientas. El agente busca por palabras clave y etiquetas, obtiene el esquema de la herramienta o el playbook elegido y después ejecuta ese elemento. LinkedIn preconfigura cada agente de código con instrucciones de sistema sobre cómo usar la búsqueda y las otras metaherramientas con eficiencia. Prakash dice que ese diseño les permitió escalar a miles de herramientas y playbooks.
- Preconfigurar el agente LinkedIn preconfigura cada agente de código con instrucciones de sistema sobre cómo usar la búsqueda y las otras metaherramientas con eficiencia.
- Buscar El agente consulta palabras clave y etiquetas para encontrar herramientas y playbooks pertinentes en el catálogo.
- Obtener el esquema Para un elemento elegido, el agente trae los detalles que necesita para llamarlo.
- Ejecutar El agente ejecuta esa herramienta o ese playbook y recibe el resultado de la herramienta o las instrucciones del playbook como salida de herramienta.
Quién lo usa, y las dos conclusiones para la empresa
En un gráfico de crecimiento que mostró en el escenario, Prakash cita más de 8.000 usuarios diarios de herramientas y playbooks y más de 600 playbooks. También dice que los product managers, los diseñadores y los technical program managers (TPM) usan las herramientas y traen playbooks junto a los ingenieros, entre funciones. El título del video subido empaqueta la charla como “500 Skills, Zero Fine-Tuning”; la charla hablada no contiene ni un recuento de 500 skills ni una política de no hacer fine-tuning.
Su primera conclusión es que el sistema funcionó porque trataron la calidad y la fiabilidad como restricciones desde el primer día, también antes de construir un servidor MCP. Describe ese principio como asegurar la calidad y la fiabilidad del sistema, junto con la productividad, para que no se degradara mientras avanzaban rápido.
Su segunda conclusión es el argumento para quienes ya programan con la búsqueda MCP y los tickets conectados. En una gran empresa, dice, los agentes y los modelos más recientes siguen sin ser eficaces salvo que la compañía construya también infraestructura dentro de la cual esos agentes puedan operar: los playbooks, el MCP del portátil y las metaherramientas que impiden que el catálogo inunde la sesión.
Fuente
También de
Fuentes y criterio editorial
Se leyeron los subtítulos completos en inglés de la charla de Ajay Prakash subida a YouTube por AI Engineer (URL canónica https://www.youtube.com/watch?v=9wZpvF3QleU, video fechado el 2026-09-09). No hubo un segundo ASR, ni documentación oficial de LinkedIn, ni una verificación independiente del producto o del rendimiento.