El cuello de botella de tus agentes no es el modelo: es la memoria que nunca les construiste
McKinsey acaba de prometerte entrega de software las 24 horas.
En "Rewiring software delivery for the agentic era" describen un mundo donde el sprint de dos semanas se comprime a uno diario, los agentes ejecutan de noche mientras duermes, y los equipos de ocho a doce personas dan paso a pods pequeños que supervisan. Una promesa bonita, y el diagnóstico de fondo es correcto casi siempre. Pero, como casi todas las promesas bonitas de consultora, se salta la parte aburrida: el motivo por el que tus agentes todavía no hacen el turno de noche no es el modelo que usan. Es que nunca les construiste una memoria.
No escribo esto desde la silla del consultor que dibuja el operating model, sino desde la de quien opera la plataforma donde aterrizan esos agentes. Llevo suficientes años de DevOps y de guardias a las tres de la madrugada como para saber una cosa: un agente autónomo de noche es exactamente lo mismo que un ingeniero de guardia recién incorporado. Brillante, incansable y completamente inútil si nadie le ha dejado por escrito cómo funciona de verdad el sistema. El modelo le da el cerebro. Lo que le falta no es cerebro.
El modelo no es el cuello de botella; el contexto que falta, sí
Piensa en lo que necesita de verdad un agente para enviar un cambio contra tus sistemas sin romper nada. No necesita ser más listo. Necesita saber qué significa «cliente de riesgo» en tu sector. Necesita saber cuál de los seis pasos de aquel proceso de devolución no se salta nunca. Necesita saber por qué aquel servicio se construyó de esa manera tan rara, y que fue por un incidente del trimestre pasado que terminó con la decisión de no reintentar nunca de forma automática contra ese endpoint.
Nada de eso vive en los pesos del modelo. Vive en la cabeza de tres personas, en un hilo de Slack que nadie va a encontrar, en un Confluence que no se actualiza desde hace un año, en un ticket de Jira cerrado y en un post-mortem que nadie releyó. El modelo más potente del planeta, sin ese contexto, es un fichaje en su primer día sin onboarding. Ponle el mejor cerebro del mercado: si no sabe cómo funciona tu empresa, va a adivinar. Y un agente que adivina en producción no es productividad: es deuda.
Las cuatro condiciones de McKinsey son, en realidad, una sola
El artículo enumera cuatro condiciones para que los agentes funcionen: una visión de negocio clara de lo que hay que construir, un entorno técnico estándar con frameworks comunes y arquitectura modular, una estructura estándar de requisito a código para que los inputs sean predecibles, y stakeholders enganchados a todo el value stream.
Cuatro casillas. Pero si las miras de cerca, todas apuntan al mismo sitio. No son cuatro requisitos independientes: son cuatro caras de un único sustrato. Las cuatro tratan de hacer el contexto de tu organización legible y fiable para que una máquina pueda razonar sobre él. La visión clara es contexto sobre el qué. El entorno estándar es contexto sobre el cómo. La estructura de requisito a código es contexto en un formato que el agente puede consumir sin interpretar. Y los stakeholders enganchados son la garantía de que ese contexto no se desincroniza de la realidad a media semana. McKinsey lo vende como una lista; en la trinchera es una sola cosa, y tiene nombre.
El knowledge graph es la capa de memoria de la IA
Aquí es donde el artículo dice lo de verdad interesante, y es lo que deberías llevarte a casa. Las empresas que van por delante están construyendo knowledge graphs que funcionan como una capa de memoria de IA a lo largo de todo el ciclo de vida del software, uno por dominio: conectan el feedback de cliente, los registros de decisiones de arquitectura, los documentos de diseño, los tickets, la actividad de GitHub, los informes de incidentes y las reglas de compliance.
La palabra clave es conectar. Un sistema de RAG sobre un wiki —del que ya hablé para quien integra LLMs— te recupera el párrafo que casa con las palabras de la pregunta. Útil, pero plano. Una capa de memoria de verdad sabe otra cosa: sabe que este incidente provocó aquel registro de decisión, que restringe este servicio, cuyo dueño escribió aquella regla de compliance. El valor no está en los nodos, está en las aristas. La diferencia entre las dos cosas es la diferencia entre un agente que te cita el wiki y uno que respeta tus cicatrices.
Y esta es exactamente la capa que defendí que era el foso: el modelo convierte en mercancía el 80% fácil, y la diferenciación se traslada al sistema que lo rodea. La memoria de cómo funciona de verdad tu empresa es la parte de ese sistema que ningún proveedor de modelos puede venderte, porque no la tiene.
Ya hemos codificado conocimiento tribal antes, y lo llamamos infraestructura como código
Si esto te suena, es porque los que venimos de operaciones ya hemos hecho este movimiento unas cuantas veces. Cada salto hacia la autonomía, sin excepción, ha sido el mismo gesto: coger conocimiento que vivía en la cabeza de un ingeniero sénior y codificarlo para que una máquina pudiera actuar sobre él.
Los runbooks a mano pasaron a remediación automática. Los pasos de despliegue que sabía el de siempre pasaron a un pipeline de CI/CD. El «pregúntale a María, que ella sabe cómo está cableada producción» pasó a infraestructura como código. Y el detalle que todo el mundo olvida: el pipeline no se puso a correr solo porque las herramientas se volvieran listas. Se puso a correr solo cuando escribimos lo que sabía María. Los agentes enviando software de noche son exactamente esa lección un piso más arriba. El agente ejecuta sin supervisión hasta justo donde el contexto que tiene se lo permite, y ni un paso más. El sustrato no es ninguna magia nueva; es conocimiento tribal, por fin escrito en un formato que una máquina puede recorrer.
La entrega 24 horas es el premio, no el objetivo
Por eso la cadencia diaria que vende McKinsey es real, pero va detrás del sustrato, no delante. La ejecución nocturna funciona hasta donde la memoria del agente le deja llegar solo; pasada esa línea, se detiene y espera a un humano. Así que la métrica que importa no es «los agentes pueden correr de noche», sino hasta dónde llega el agente antes de toparse con una pregunta que solo una persona puede responder, y cada una de esas paradas es un bug de contexto en tu capa de memoria, no un fallo del modelo.
Aquí tienes que dejarme conceder el contraargumento fuerte, porque es bueno: «los modelos mejoran cada trimestre, las ventanas de contexto crecen, ¿no se lo va a comer todo el próximo modelo?». En parte, sí. Parte del andamiaje de hoy quedará absorbido: modelos mejores necesitan menos que los lleves de la mano, y ventanas más grandes se tragan más documentos de una sola vez. Pero una ventana de contexto no es una memoria. Pegar todo el wiki en el prompt no hace que el modelo sepa qué paso no se salta nunca; hace que lea un montón de texto quizá contradictorio y adivine. Saber exige curación, verificación, frescura y resolución de conflictos: decidir cuál de dos fuentes que se contradicen es la verdad vigente hoy. Eso es criterio, lo hace un humano, y es trabajo de ingeniería permanente. El modelo es de alquiler e idéntico para el de enfrente. La memoria curada de cómo funciona tu empresa es la parte que nadie puede alquilar.
Qué haría yo este trimestre si fuera tu CTO
Cinco apuestas concretas, porque el diagnóstico sin acción es solo una opinión bonita:
- Localiza dónde vive de verdad tu contexto. Antes de comprar ninguna «fábrica de agentes», haz el inventario incómodo: ¿cuánto del conocimiento que un agente necesitaría para enviar código vive solo en cabezas, en hilos de Slack y en un wiki caducado? Esa respuesta es tu cuello de botella. No el modelo.
- Construye la memoria de UN dominio, no de toda la empresa. El knowledge graph de todo el SDLC de una vez es un proyecto que muere en comité. Elige un dominio con dolor real, conecta sus registros de decisión, sus tickets, sus incidentes y sus reglas de compliance, y haz que un agente razone sobre ello. Aprende ahí antes de escalar.
- Estandariza el camino de requisito a código. Es la condición de McKinsey que de verdad mueve la aguja. Si cada feature entra en un formato distinto, el agente adivina; si entra en una estructura predecible, ejecuta. Inputs reproducibles antes que outputs autónomos.
- Hornea el compliance dentro de la memoria, no al final. Las reglas de riesgo, legal y seguridad tienen que ser nodos que el agente lee mientras construye, no una puerta que alguien abre cuando ya está todo hecho. Un control que vive en el grafo mejora la trazabilidad y la completitud; un control que vive en un PDF es un cuello de botella con cara de persona.
- Mide la autonomía por lo lejos que llega el agente solo. Olvídate del «porcentaje de código escrito por IA». La métrica honesta es cuántos pasos encadena un agente antes de necesitar a un humano, y tratar cada parada como un bug de contexto que se arregla en el sustrato, no como un techo del modelo.
La línea que defiendo es la de siempre, y aquí la IA la ilustra de la forma más literal que he visto nunca: no sustituye al ingeniero, lo apalanca. Alguien tiene que decidir cuál de dos fuentes contradictorias es la verdad, qué paso no se salta nunca, cuándo un conocimiento ha caducado. Ese trabajo —construir y mantener la memoria de cómo funciona de verdad tu empresa— no lo hace el modelo. Lo hace un ingeniero con criterio. Y cuanto más autónomos quieras tus agentes, más necesitas, no menos.
McKinsey vende el destino: agentes que envían software mientras duermes. Tiene razón en que es posible. Lo que la diapositiva te ahorra es que el motor barato e intercambiable nunca fue el problema. El problema, como siempre, es todo el coche que lo rodea, y esta vez la pieza más difícil de construir se llama memoria.
¿Estás intentando que tus agentes pasen de la demo a producción y lo que se te desincroniza es el contexto, no el modelo? Habla con un CTO sobre montar el squad nearshore que te construya la capa de memoria, no solo que conecte el agente.
