El 28 de septiembre de 2026, OpenAI subirá al escenario a presentar su "salto más importante en años": un modelo (GPT-6, o un proyecto llamado "Astra") enfocado en tareas de larga duración y sistemas multi-agente. Los medios ya hablan de "la IA que trabaja por ti durante días". Las demos mostrarán a un agente que corre por 25 horas seguidas, edita código, navega, ejecuta y "remata el trabajo".
Vas a ver el espectáculo más pulido de la industria. Y la pregunta que nadie hará en el keynote es la única que importa: ¿qué es eso, exactamente, más que darle a un LLM una VM con acceso a internet y a un shell?
Porque eso — darle a un modelo un sandbox con terminal, navegador y ejecución de código — es literalmente una copia de Grok Bot, el agente cerrado de xAI que lanzó su beta en agosto. Y es algo que nosotros ya tenemos implementado hace tiempo, no como demo, sino operando en producción. La diferencia no está en la VM: está en lo que la rodea.
Un LLM con una VM no es productividad: es una demo. La productividad real nace de la integración del agente con tu stack completo — tus datos, tus procesos, tus políticas, tu contexto empresarial. Y en ese terreno, los protocolos de moda (MCP) no solo no resuelven el problema: agregan más puntos de riesgo y vulnerabilidades de los que eliminan.
1. Qué anunció OpenAI (y qué es realmente)
Los reportes apuntan a un anuncio el 28/09/2026: GPT-6 o el proyecto "Astra", con dos capacidades estrella: long-running tasks (tareas que duran horas o días) e interacciones multi-agente (varios agentes coordinados). La narrativa oficial: superar la limitación de los LLMs actuales de "perder el hilo" en proyectos largos.
Pero mira la letra chica de lo que ya vienen empujando. En su propio blog de desarrolladores sobre long-horizon tasks con Codex, OpenAI describe su agente así:
"The model is designed to operate flexibly across a range of harness shapes, including the built-in Responses API computer tool, custom tools layered on top of existing automation harnesses, and code-execution environments that expose browser or desktop controls."
— OpenAI Developers, "Run long horizon tasks with Codex" (2026)
Lee esa cita con calma: hasta OpenAI usa la palabra "harness". El modelo "opera a través de formas de harness": herramientas de computadora, harness de automatización existentes, entornos de ejecución de código con control de navegador o escritorio. Es decir, el propio OpenAI confirma la tesis que venimos postulando desde marzo: el modelo no es el producto, el harness lo es. Ellos construyen el modelo; el valor lo define la capa alrededor.
Y ¿qué es esa capa, en concreto? Un sandbox con: shell (ejecutar comandos), apply_patch (editar archivos), navegador (acceder a internet) y memoria persistente. Su demo estrella fue un run de Codex de 25 horas trabajando "end to end" en un proyecto.
2. Una copia de Grok Bot (y de lo que ya tenemos)
Ahora compara. Grok Bot (xAI, beta pública agosto 2026): agentes 24/7 con un PC propio en la nube (16GB RAM), que opera apps sin API automatizando el navegador, "remata el 100% del trabajo", cerrado de punta a punta, desde $120 a $300/mes.
¿Ves el patrón? Grok Bot = VM + navegador + LLM. OpenAI long-running = VM + shell + navegador + LLM. La misma arquitectura, distinto logo. No es innovación: es la misma idea de "darle al modelo una computadora" que ya venimos implementando en Wagner Solutions hace tiempo — con una diferencia fundamental:
- Grok Bot: su computadora está en la nube de xAI, aislada de tu operación, conectada a internet genérico. Lo que ve: lo que cualquier persona podría ver en un navegador.
- OpenAI (Codex/Astra): su sandbox está en la nube de OpenAI, también aislado de tu stack. Lo que ve: tu repositorio si se lo pasas, y nada más.
- Nuestro harness: el agente corre en la misma VPS que tu stack — con acceso directo a tu base de datos, tu ERP, tus APIs internas, tus archivos — gobernado por políticas y contexto empresarial. Lo que ve: tu operación completa, no una página web.
Esa es la línea que separa una demo de 25 horas de un sistema que genera valor todos los días: el acceso real al stack.
3. Por qué el hype no es productividad real
El marketing de esta nueva ola se apoya en demos impecables: un agente que "trabaja 25 horas seguidas". Impresionante en video. Pero en el mundo real, la productividad de un agente no se mide en horas continuas: se mide en qué fue capaz de cambiar en tu operación.
Un LLM en una VM aislada puede ejecutar código, sí. Pero si no conoce tu catálogo de productos, tus reglas de negocio, tu historial de clientes, tus flujos de aprobación, tu esquema de base de datos, tus políticas de compliance… puede trabajar 25 horas y producir 25 horas de irrelevancia con mucha confianza. Es el problema clásico del agente sin contexto: hace exactamente lo que le pides, y lo que le pides no es lo que necesitas.
No preguntes "¿cuántas horas puede trabajar tu agente?". Pregunta: "¿tu agente puede leer tu base de datos, respetar tus políticas, ejecutar dentro de tu ERP y rendir cuentas de lo que hizo?" Si la respuesta es no, tienes una demo — no un sistema productivo.
La integración completa al stack es la condición necesaria para el impacto real en producción. Y aquí es donde la industria está tomando el atajo equivocado.
4. Por qué MCP no lo resuelve (y lo empeora)
El intento de la industria de "conectar el modelo a todo" se llama Model Context Protocol (MCP). La promesa: un estándar para que el agente hable con tus herramientas. La realidad, medida por la propia industria de seguridad:
- 14 CVEs documentados contra MCP y su ecosistema en 2026 (decryptiondigest, SentinelOne).
- +200,000 servidores MCP expuestos públicamente, muchos sin autenticación real.
- Vectores de ataque estructurales: prompt injection (el servidor MCP te inyecta instrucciones maliciosas que el modelo obedece), tool poisoning (envenenar las herramientas que el agente usa), rug pulls de marketplaces de servidores MCP.
MCP no integra: agrega una capa de intermediación entre el agente y tus sistemas. Cada servidor MCP que conectas es un nuevo punto de entrada que tu agente — y un atacante — puede usar. Le das a un modelo que alucina la llave de tu API, y además le das un protocolo para que la use. La solución no es más protocolos: es arquitectura, gobernanza y acceso directo controlado.
El problema de fondo: MCP conecta herramientas genéricas, no tu operación. Conectar un servidor MCP a una API de Slack no es integrar el agente a tu negocio. Es abrir otra puerta sin las políticas de quién entra, qué toca y cómo se audita.
5. La alternativa efectiva: el agente en tu stack
La arquitectura que sí genera productividad real (y la que usamos en cada implementación de Wagner Solutions) no necesita un sandbox remoto ni 15 servidores MCP:
- El agente corre en la misma VPS que tu stack (o con acceso directo y controlado a él). Sin intermediarios: habla nativo con tu base de datos, tu ERP, tus archivos y tus APIs internas.
- Políticas de gobernanza explícitas: qué puede hacer, qué requiere aprobación humana, qué está prohibido. Permisos granulares, no "todo o nada".
- Contexto empresarial como primera clase: el agente no "aprende de cero" cada vez: tiene memoria persistente de tu negocio, tus reglas, tus datos — en tu infraestructura.
- Auditabilidad: cada acción registrada, cada decisión trazable. No es opcional: la Ley 21.719 lo exige.
Tabla: sandbox remoto vs agente integrado
| Dimensión | Sandbox remoto (OpenAI/Grok Bot) | Agente en tu stack (enfoque WS) |
|---|---|---|
| Acceso al stack | Aislado, solo internet público | Directo: BD, ERP, APIs, archivos |
| Contexto de negocio | Lo que le pases en el prompt | Memoria y datos reales de tu operación |
| Gobernanza | Políticas genéricas de la plataforma | Políticas tuyas, granulares, auditables |
| Seguridad | + superfície: navegador, MCP, egress | Menos puntos de entrada, controlados |
| Datos | En sus nubes (Cloud Act, jaula dorada) | En tu VPC (Ley 21.719, soberanía) |
| Resultado | Demo impresionante, productividad marginal | Impacto real en producción, todos los días |
6. El anuncio del 28/09: qué vas a ver (y qué debes mirar)
El 28 de septiembre vas a ver la demo más pulida de la historia de OpenAI. Habrá ovaciones, métricas de benchmark y un agente haciendo cosas en pantalla durante horas. Todo real, todo impresionante, y casi todo desconectado de tu operación.
Mira la demo con tres preguntas en la cabeza:
- ¿Dónde corre este agente? Si corre en su nube, tus datos también. Pregunta por despliegue on-prem / VPC.
- ¿Qué ve de mi empresa? Si solo ve lo que yo le pego en un prompt, no está integrado. Pregunta por conectores a tu stack real.
- ¿Quién gobierna lo que hace? Si no hay políticas granulares y auditoría, no es producción: es un experimento con acceso.
La ironía final: OpenAI está validando nuestra tesis con cada diapositiva. Su modelo "opera a través de harness shapes"; su demo más ambiciosa es un harness de 25 horas; su SDK multi-agente existe porque el modelo solo no basta. El futuro que ellos presentan como novedad, en LATAM ya lo estamos construyendo de forma soberana: agentes integrados al stack, con gobernanza, con datos en casa.
El hype vende VMs con internet. La productividad vive en la integración. Mientras el mundo aplaude demos, la ventaja competitiva real está en quienes conectan el agente a la operación — con acceso directo, políticas claras y datos soberanos.
¿Tu agente está integrado a tu stack — o es una demo con acceso?
En Wagner Solutions diseñamos e implementamos harness agénticos desplegados en tu propia infraestructura: acceso directo a tus datos y sistemas, políticas de gobernanza granulares, contexto empresarial persistente y auditoría completa bajo la Ley 21.719. Agenda una conversación de 30 minutos — con la arquitectura de tu caso, no con demos.
Agendar diagnóstico gratuito →