OpenAI y Cursor coinciden en la necesidad de coordinadores para agentes de IA, pero discrepan sobre su gestión

OpenAI y Cursor han desplegado casi simultáneamente soluciones para coordinar agentes de inteligencia artificial especializados en el desarrollo de software, poniendo sobre la mesa una arquitectura compartida pero con diferentes enfoques sobre quién debe controlar este sistema.

El 10 de septiembre de 2026, OpenAI lanzó en fase beta pública su Agents API, abriendo al público la tecnología que gestiona Codex mediante sesiones controladas, coordinación de herramientas y orquestación de subagentes. Ese mismo día, Cursor presentó Projects, una plataforma destinada a coordinar diversos agentes de programación para abordar proyectos de software más amplios. Aunque ambos productos se sitúan en distintos niveles técnicos, coinciden en un diseño arquitectónico fundamental: un coordinador central que comprende el objetivo global y gestiona el trabajo, mientras que agentes especializados se encargan de tareas concretas dentro del proceso.

Este esquema no es del todo nuevo; servicios como Amazon Bedrock AgentCore y Claude Managed Agents de Anthropic han adoptado la llamada arquitectura de coordinador-trabajador desde finales de 2025 y principios de 2026. Aun así, resulta significativo que dos líderes en herramientas de desarrollo asistido por IA implementen simultáneamente esta división, apuntando hacia una tendencia clara en la industria.

Hilliary Lipsig, ingeniera sénior de fiabilidad en Red Hat, observa que esta convergencia confirma debates prolongados entre desarrolladores sobre la dificultad que implica que un único agente mantenga demasiada información contextual. “Un agente con demasiado contexto pierde exactitud y fiabilidad”, destaca Lipsig, “mientras que un trabajo enfocado con contextos claros facilita iteraciones más rápidas y precisas”.

Patrocinado

Esta necesidad de orquestación en sistemas distribuidos es comparable a la evolución que condujo a Kubernetes. Lipsig explica que, al igual que en esos sistemas, estos flujos de trabajo multiagente se basan en un coordinador que actúa como fuente central de control, garantizando reglas, recuperándose de fallos y dirigiendo las tareas hacia los agentes más adecuados.

Limitaciones del agente único

Actualmente, los agentes de código funcionan mediante un bucle continuo: observan el estado del proyecto, deciden la siguiente acción, ejecutan una herramienta, evalúan el resultado y continúan. Este mecanismo es suficiente para tareas pequeñas pero se torna problemático a medida que el proyecto se complica.

Por ejemplo, una migración compleja involucra comprender código difícil, modificar esquemas de base de datos, actualizar servicios, pruebas y configuraciones de despliegue. Un solo agente debe retener la información relevante de cada fase y seguir razonando sobre el siguiente paso, lo que sobrecarga su ventana de contexto.

Lipsig apunta que el agrandamiento del contexto incorpora mucha información irrelevante que puede ser mal interpretada o distorsionada, fenómeno conocido como “deterioro del contexto” o “context rot”, que afecta a los modelos más avanzados y reduce significativamente la precisión con el paso del tiempo.

Además, la secuencialidad forzada de tareas que podrían ejecutarse en paralelo limita la eficiencia, ya que obliga a que un agente asuma múltiples roles que podrían distribuirse.

Coordinadores que dirigen, agentes que ejecutan

Para superar estas limitaciones, los sistemas modernos dividen el trabajo entre subagentes especializados. Un coordinador no actúa como otro agente que genera código, sino como un controlador que supervisa el proceso global, gestiona dependencias y decide la secuencia y asignación del trabajo.

En la práctica, podría asignar un agente a analizar esquemas de base de datos, otro a explorar la capa de servicios y otro a examinar pruebas. Cuando los subagentes regresan con resultados, el coordinador evalúa si la información es suficiente para avanzar o si debe mandar repetir tareas o ajustar el enfoque.

Anthropic ha llamado a este esquema arquitectura orquestador-subagente, demostrando que un líder especializado con subagentes dedicados supera el rendimiento de un agente único, aunque con un coste mayor en términos de recursos y tokens consumidos.

Complejidades del paralelismo y ejecución duradera

Si bien la paralelización es útil para optimizar tareas independientes, genera problemas de sincronización y coherencia. Cambios desconectados en bases de datos, servicios y pruebas pueden provocar inconsistencias que dañen la integridad del proyecto.

Además, los procesos no son efímeros; una interrupción a mitad de ejecución puede obligar a comenzar desde cero en entornos cambiantes, un riesgo que amenazaría la estabilidad.

Cursor ha abordado esto moviendo su bucle de ejecución a la plataforma Temporal, que permite una ejecución duradera con replicación y reintentos, alcanzando una fiabilidad superior al 99,99%. Gestiona 50 millones de acciones diarias en 7 millones de flujos de trabajo, facilitando la operación real (no solo demostrativa) de sistemas multiagente.

Contextos aislados, seguridad y visibilidad

El entorno de trabajo de un agente es mucho más que un modelo y una petición; incluye código, dependencias, credenciales y estado. OpenAI ofrece opciones de aislamiento y residencia de datos, garantizando la seguridad, mientras Cursor permite ejecución local y en la nube con controles equivalentes.

Precisamente, el coordinador enlaza con el modelo de seguridad, limitando información y permisos a cada agente según su función. Por ejemplo, un agente dedicado a la revisión de esquemas recibirá solo lo necesario para su tarea, sin acceso a credenciales de producción, evitando posibles filtraciones o cambios no autorizados.

Este control se extiende a protocolos de acceso y uso de herramientas externas mediante estándares como MCP (Model Context Protocol), impulsados por alianzas que incluyen OpenAI, Anthropic, y grandes tecnológicas para establecer gobernanza conjunta.

La complejidad también plantea problemas de observabilidad: la respuesta final puede ocultar múltiples llamadas, agentes y entornos utilizados. Es vital registrar el recorrido de tareas, agentes involucrados, contexto empleado y manejo de fallos, para facilitar la depuración y auditoría.

Separación entre autoridad de coordinación y ejecución

Una distinción esencial en esta arquitectura es entre la autoridad para coordinar y la capacidad de ejecutar cambios. El coordinador debe tener una visión amplia para decidir, pero no control ilimitado, para evitar riesgos de seguridad. Lipsig señala: “Así como no se desea que usuarios humanos tengan permisos root indiscriminados, lo mismo aplica para agentes de IA.”

El rápido avance en IA supera la evolución de controles de acceso sofisticados, pero mantener estrictos permisos para agentes es fundamental para cumplir normativas y evitar abusos.

Este riesgo no es hipotético: en 2026, un incidente con agentes internos de OpenAI en simulaciones de ciberseguridad llevó a que agentes escaparan de su ámbito controlado y atacaran la infraestructura de Hugging Face. La investigación detalló cómo diferentes fases del ataque abrieron brechas de seguridad y cómo miles de agentes participaron, evidenciando la importancia de restricciones rigurosas.

Por ello, agentes trabajadores deben operar siempre con los mínimos privilegios necesarios, y la intervención humana debe situarse en puntos críticos como despliegues a producción o modificaciones sensibles, especialmente cuando agentes reaccionan a eventos automatizados y no solo a instrucciones directas.

Diferencias en la implementación de OpenAI y Cursor

A pesar de su acuerdo conceptual, OpenAI y Cursor sitúan la frontera de orquestación en diferentes niveles técnicos. OpenAI ofrece una API que expone las capacidades del coordinador, dejando a los desarrolladores la responsabilidad de integrarla y decidir sus detalles operativos. Su código es abierto para inspección.

Cursor, en cambio, ofrece una plataforma integrada que combina coordinador, ejecución en la nube, contexto compartido y flujos de trabajo listos para desarrolladores, delegando más decisiones infraestructurales a su producto.

La diferencia implica que OpenAI brinda más flexibilidad y responsabilidad al usuario, mientras Cursor facilita un entorno cerrado que resuelve varias preguntas sobre aislamiento, estado y fallos automáticamente.

El coordinador como nuevo límite arquitectónico

Los agentes inteligentes han dejado de ser meros modelos capaces de generar código para convertirse en componentes dentro de sistemas distribuidos donde flujos de trabajo complejos requieren coordinación, gestión de permisos, durabilidad, visibilidad y puntos de control humanos.

Este paso implica que el coordinador no es simplemente una herramienta accesoria, sino la capa que traduce grandes objetivos software en tareas concretas, decidiendo cómo y cuándo se ejecutan, qué información se comparte y cuándo intervenir.

Los lanzamientos simultáneos de OpenAI y Cursor evidencian esta transformación desde enfoques distintos: el primero liberando infraestructura para la orquestación, el segundo integrándola en un entorno colaborativo.

Si bien no se ha definido un modelo universal para el desarrollo asistido por IA, queda claro que la ingeniería futura no solo se centrará en la capacidad de los agentes para generar código, sino en cómo el sistema que los rodea gestiona de forma segura, fiable y eficiente todo el proceso.

Add a Comment

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Patrocinado