OpenAI y Cursor coinciden en la arquitectura de agentes: coordinador y trabajadores
La API de Agents de OpenAI y los Projects de Cursor llegan el mismo día con el mismo diseño: un coordinador que reparte y agentes especializados que ejecutan.
OpenAI abrió en beta pública su API de Agents este mes y deja a la vista la maquinaria que mueve Codex: sesiones gestionadas, coordinación de herramientas y orquestación de subagentes. Ese mismo día, el 10 de septiembre, Cursor lanzó Projects, pensado para coordinar varios agentes de programación sobre bloques grandes de trabajo. Son productos que viven en puntos distintos de la pila, pero los dos desembocan en el mismo dibujo: un coordinador que entiende el objetivo global y reparte, y agentes especializados que ejecutan cada pieza.
El patrón tampoco es nuevo. AWS Bedrock AgentCore llegó a disponibilidad general en octubre de 2025 y los Claude Managed Agents de Anthropic entraron en beta pública en abril de 2026. Lo llamativo es que dos actores centrales del desarrollo asistido por IA expongan la misma separación entre coordinador y trabajadores de forma independiente y casi a la vez.
Por qué el bucle de un solo agente se queda corto
Un agente de programación trabaja en lo que Anthropic describe como un bucle: observa el estado del repositorio, razona el siguiente paso, llama a una herramienta, mira el resultado y sigue. Para una tarea pequeña basta. Cuando el alcance crece —una migración grande, un esquema de base de datos que hay que tocar, servicios, pruebas y configuración de despliegue— mantener la fiabilidad dentro de un único contexto se complica.
Hilliary Lipsig, ingeniera principal de fiabilidad en Red Hat y responsable de equipos SRE de Azure Red Hat OpenShift, lo resume así: "Un contexto grande no solo incluye todo lo correcto o importante, también arrastra mucha información de usar y tirar. Con la compactación, esa información puede acabar clasificada como importante e influir de forma indebida en lo que hace tu agente. O la información correcta puede deformarse hasta volverse incorrecta". Tras un par de rondas de compactación, dice, los desarrolladores ven caer la precisión y vuelven a gestionar el contexto a mano.
Eso encaja con lo que los investigadores llaman context rot, y no se ha ido con los modelos nuevos. Un estudio de 2026 que probó modelos frontera, entre ellos Claude Opus 4.6, GPT-5.4 y Gemini 3.1 Pro, encontró que se les escapaba una acción peligrosa enterrada en una transcripción larga de agente entre dos y 30 veces más a menudo cuando aparecía después de 800.000 tokens de actividad benigna. Es el guardia de seguridad que deja de mirar carnés con atención después de doscientas personas, aunque nada de su entrenamiento haya cambiado.
Hay otro problema de fondo: las tareas no son secuenciales. Obligar a un solo agente a encadenar análisis de base de datos, documentación y descubrimiento de pruebas convierte en serie una carga que podía ir en paralelo.
El coordinador no es otro agente de programación
Cuando el trabajo se reparte, el coordinador pasa a ser un plano de control y no un agente más. No escribe código: entiende la tarea global, gestiona dependencias y decide cómo se ejecuta. A diferencia de un planificador convencional, emite juicios probabilísticos sobre la calidad de los resultados y el reparto de recursos. Manda a uno a mirar el esquema de la base de datos, a otro la capa de servicios y a un tercero la suite de pruebas. Cuando vuelven, decide si lo que traen basta para pasar a implementar. Si un trabajador se equivoca, el sistema tiene que reconocer el fallo y elegir entre reintentar, reasignar o cambiar la tarea.
Anthropic ha documentado ese mismo patrón en su sistema de producción, al que llama arquitectura de orquestador y subagentes. GitHub lo aplica en su modelo de agentes personalizados: cada uno recibe solo los prompts, las herramientas y el contexto que necesita, en lugar de engordar una conversación única.
Lipsig lo sitúa en una tradición conocida: "La necesidad de orquestación en la computación distribuida se ha reconocido repetidamente. Así llegamos a Kubernetes. Estos flujos multiagente son el mismo concepto, solo que en otra parte de la pila técnica".
No todo son ventajas. Repartir el trabajo sube el gasto en tokens y añade riesgo de coordinación e integración, y separar tareas entre agentes no garantiza mejor software. La pregunta que queda abierta ya no es cuánto sabe programar un modelo, sino si el plano de control que lo rodea aguanta cuando la carga se multiplica.
