El nuevo problema de los agentes de código: no trabajan juntos

El artículo es una columna de opinión firmada por Zach Lloyd, fundador y CEO de Warp (una plataforma de desarrollo nativa de IA) y ex Principal Engineer de Google, donde lideró la ingeniería de Google Docs y Google Sheets. Publicado el 7 de julio de 2026 en Forward Future, el texto aborda un problema que, según Lloyd, se ha vuelto central para los equipos de ingeniería de software: la gestión de "flotas mixtas" de agentes de codificación con IA.

El punto de partida es simple: durante el último año se ha producido una explosión de agentes de codificación capaces —Claude Code, Codex, Gemini y el propio Warp Agent, entre otros— que ya asumen tareas equivalentes a las de un ingeniero junior. Los desarrolladores han probado varias opciones y, como ocurre históricamente con editores de código o terminales, cada uno ha terminado inclinándose por una herramienta u otra más por preferencia personal que por diferencias objetivas de rendimiento. El resultado es que dentro de un mismo equipo conviven distintos agentes de distintos proveedores, algo que en sí mismo no es nuevo (los equipos nunca han impuesto un único editor o flujo de trabajo), pero que en el caso de los agentes de IA introduce fricciones logísticas inéditas, especialmente a medida que estos agentes dejan de operar solo en las máquinas locales de los desarrolladores y pasan a ejecutarse en la nube.

Lloyd identifica cuatro problemas concretos que surgen cuando los agentes de distintos proveedores conviven en un mismo flujo de trabajo, precisamente porque no fueron diseñados para interoperar entre sí. El primero es la visibilidad: cada agente registra su actividad con su propio formato de logs, su propia interfaz y su propio nivel de transparencia, de modo que no existe una vista unificada de qué se ejecutó, qué se tocó o dónde falló algo. Depurar un flujo de trabajo multiagente implica, según el autor, reconstruir el contexto a partir de tres paneles de control distintos que no comparten nada entre sí. El artículo menciona, a modo de ejemplo anecdótico y con tono humorístico, los reportes sobre modelos de OpenAI que hicieron que OpenClaw se "obsesionara con goblins", como ilustración de lo que ocurre cuando dos herramientas de proveedores distintos no hablan exactamente el mismo lenguaje.

El segundo problema son los permisos. Un agente que trabaja sobre infraestructura de despliegue no debería tener el mismo nivel de acceso que uno dedicado a resumir logs, pero gestionar secretos, claves de API y variables de entorno a través de diferentes entornos de agentes (harnesses) añade una sobrecarga operativa real. Según Lloyd, la mayoría de los equipos terminan optando por sobre-permisionar por comodidad, o gestionando los accesos manualmente de una forma que no escala.

El tercer problema es la memoria. La mayoría de los agentes olvidan todo entre sesiones —una limitación que ya existe incluso dentro de un mismo entorno—, pero entre proveedores distintos no hay, por defecto, ningún contexto compartido: cada nueva sesión arranca de cero. Esto obliga a que un equipo que trabajó la semana anterior en una refactorización compleja tenga que volver a explicar el enfoque, las restricciones y las decisiones ya tomadas, una ineficiencia que se multiplica por cada sesión y por cada ingeniero del equipo.

El cuarto factor, que según el autor agrava a los tres anteriores, es el coste. Cuando los desarrolladores eligen herramientas por preferencia y se mantienen fieles a ellas, no existe un mecanismo natural que empuje hacia la opción más eficiente en coste. Con las herramientas de desarrollo tradicionales esto no había sido un problema mayor porque las suscripciones SaaS son fáciles de prever, pero el gasto en tokens de IA puede dispararse rápidamente, y los responsables de ingeniería cada vez preguntan más por tener visibilidad real sobre el gasto de una flota de agentes que no controlan del todo. Por ahora, señala Lloyd, la mayoría de las organizaciones no tiene una buena respuesta a esa pregunta.

Pese a este diagnóstico de fricciones, el artículo defiende que las flotas mixtas de agentes no son un problema en sí, sino una fuente de ventajas cuando se gestionan bien. La primera ventaja es la independencia de proveedor: si un modelo determinado está caído, limitado por cuotas de uso o rinde mal en una tarea concreta, el equipo puede redirigir el trabajo hacia otro. Esa capacidad de maniobra, argumenta Lloyd, importa cada vez más a medida que los agentes se convierten en infraestructura crítica y dejan de ser meras herramientas de productividad.

La segunda ventaja es el coste: dirigir las tareas más exigentes hacia un modelo y las más simples hacia alternativas más baratas reduce el gasto de forma notable sin necesidad de rediseñar todo el flujo de trabajo. Como dato concreto, el artículo cita una simulación reciente del llamado "YC-Bench", en la que el modelo GLM-5 gestionó una empresa simulada con un resultado prácticamente equivalente al de Claude Opus —terminando con una cantidad de dinero similar— pero con un coste de inferencia aproximadamente diez veces menor. Lloyd subraya que las pilas tecnológicas de un solo proveedor no ofrecen esta palanca de ahorro, y que ningún proveedor grande tiene incentivos para permitirlo, ya que todos buscan retener al cliente dentro de su ecosistema completo.

La conclusión del artículo es que el agente que mejor funciona hoy para un caso de uso concreto puede no ser el más adecuado dentro de seis meses, y que un equipo que ya gestiona varios agentes en paralelo no tiene que "empezar de cero" al sustituir uno de ellos. Según Lloyd, sacar partido de una flota mixta de agentes exige ser deliberado en su gestión, y los equipos que él observa "sacando ventaja" son los que dedican menos tiempo a comparar benchmarks entre modelos y más tiempo a construir la capa que hace posible gestionar esas flotas: cómo comparten contexto los agentes, cómo se aplican los permisos de forma consistente entre proveedores y cómo se mantiene visibilidad real sobre lo que se está ejecutando en cada momento. Esa, concluye, es la verdadera línea de trabajo, y quienes se enfoquen en ella ahora tendrán una ventaja significativa frente al resto.

Conviene señalar que el autor es el CEO de Warp, una plataforma que se posiciona precisamente como capa de gestión para este tipo de flotas de agentes, por lo que el artículo, aunque plantea un diagnóstico razonable y verificable sobre fragmentación de logs, permisos y memoria entre agentes de distintos proveedores, tiene también un componente de interés comercial directo en la tesis que defiende.