Los agentes de IA son sistemas que no se limitan a responder preguntas: ejecutan tareas completas de forma autónoma, con acceso a herramientas externas y memoria del trabajo en curso. En una demostración publicada por OpenAI en su canal de YouTube, un ingeniero llamado Ali mostró cómo usó su "dot" para hacer el triage de incidentes de una alerta que recibió a las 3 a.m., revisar la causa del problema y abrir un hilo de trabajo que él pudo dirigir desde el celular, sin levantarse de la cama.
La escena vale la pena desarmarla, porque el titular es fácil de malinterpretar. No se trata de que la IA "arregló" el sistema sola a las 3 de la mañana. Se trata de que alguien llegó a la alerta y ya encontró el diagnóstico hecho, el contexto ordenado y un espacio de trabajo listo para continuar. Eso cambia dónde empieza el trabajo humano, no si existe.
Si administras un área de tecnología o un negocio mediano en Perú o Latinoamérica, este caso responde una pregunta muy concreta: ¿qué parte del soporte nocturno o de las tareas repetitivas puede asumir un agente antes de que una persona intervenga? Veamos qué mostró la demo, qué límites tiene y cómo se traduce a la operación de una empresa real.
¿Qué hizo exactamente el agente de OpenAI a las 3 a.m.?
Según la demostración de Ali, ingeniero de OpenAI, la configuración fue sorprendentemente simple. Dentro de la aplicación Codex conectó su dot a Slack, lo que le dio al agente una identidad propia dentro del servicio: cualquiera puede etiquetarlo en un hilo, igual que a un compañero de equipo. Luego escribió una instrucción corta en el compositor: monitorear el canal y, ante cada alerta entrante, triagear la página y crear un hilo de investigación.
Esa instrucción se convirtió en una automatización permanente. Cuando llegó la alerta de madrugada, ocurrieron tres cosas en cadena. Primero, el dot detectó la página. Segundo, investigó qué estaba fallando y ya tenía un diagnóstico cuando Ali abrió la aplicación de ChatGPT en su teléfono. Tercero, había creado un hilo de trabajo o Codex thread que el ingeniero podía dirigir con mensajes desde el celular, y ese mismo hilo aparecía también en su laptop.
El detalle técnico que más importa no es el diagnóstico en sí, sino dónde vive ese hilo. Al estar sincronizado entre dispositivos, Ali podía resolver el caso desde el teléfono si era simple, o pasar a la laptop si requería más profundidad, sin reconstruir el contexto de cero. Ese salto —de "me despertaron para que averigüe" a "me despertaron y el trabajo ya empezó"— es el corazón de la historia.
Vale la pena ser preciso con las cifras: la única hora que aparece en la fuente es 3 a.m. No hay datos públicos sobre cuánto tiempo ahorró el agente, cuántas alertas procesa por noche ni cuántas personas lo usan. Lo que se muestra es una demostración de flujo de trabajo, no un reporte de resultados medidos.
¿Cómo se construye una automatización con IA similar hoy?
Aquí conviene separar la vitrina del taller. El dot es un producto que OpenAI mostró en su demo y que, en la práctica, funciona como un agente persistente con su propio computador en la nube y acceso a tu computador local. Ese nivel de integración todavía corresponde a una demostración, no a algo que contrates mañana para tu empresa.
Pero el principio que se ve en la demo —un flujo que observa un canal, clasifica lo que llega, investiga con herramientas y deja el resultado listo para que una persona decida— ya se puede armar con herramientas que existen hoy. Piensa en la lógica como una cadena: un disparador (llega una alerta o un mensaje), un paso de clasificación (qué tan grave es y de qué tipo), un paso de investigación (consultar el sistema, leer registros, revisar un ticket) y un paso de entrega (dejar el resumen donde la persona lo va a ver).
En proyectos de automatización es común construir esta cadena conectando modelos de lenguaje con APIs externas, bases de datos y sistemas de gestión como Odoo. La diferencia con la demo es de grado, no de naturaleza: el flujo hace el primer tramo y la persona toma la decisión final. Esa distinción importa, porque define qué puedes prometerle a tu equipo y qué no.
Lo que la fuente no demuestra es igual de importante que lo que muestra. No hay evidencia pública de que el agente resuelva el incidente de punta a punta sin intervención, ni datos de ahorro medidos en un entorno de producción, ni información sobre qué pasa cuando el agente se equivoca en el diagnóstico. Y hay un riesgo operativo que la demo no aborda: si delegas el triage, también delegas la selección de información; un diagnóstico equivocado a las 3 a.m. puede enviar a la persona correcta por el camino incorrecto. Mi lectura es que el valor hoy está en el primer barrido y en la organización del contexto, no en la resolución autónoma.
¿Qué significa esto para una empresa en Perú?
El caso de uso que Ali menciona al final de la demo es, curiosamente, el más cercano a la realidad peruana: enviar un prompt para que el agente triagea la retroalimentación entrante de un canal específico. Traducido a nuestro contexto, eso es leer y clasificar lo que llega por WhatsApp, correo y formularios, identificar los problemas más frecuentes que nadie está atendiendo y dejarlos listos para que alguien decida.
Muchas empresas medianas en el país tienen exactamente ese problema: canales llenos de retroalimentación que nadie procesa de forma sistemática. El cliente escribe, alguien lee, se resuelve lo urgente y lo demás se pierde. No es falta de voluntad, es falta de tiempo. Un agente que hace el primer ordenamiento no reemplaza al equipo: le devuelve horas que hoy se gastan en leer y clasificar antes de decidir.
El segundo escenario donde esto pega fuerte es el soporte 24/7. Una PYME peruana no puede pagar una guardia nocturna de tres personas. Sí puede diseñar un flujo que, ante una caída o una alerta, haga la investigación inicial y deje el resultado disponible en el celular del responsable. La lógica es la misma que la del ingeniero de OpenAI: el work humano empieza donde termina el diagnóstico. Si quieres ver cómo se conecta esto con sistemas de gestión, puedes revisar el blog de Consultoría TI.
Hay una diferencia cultural que conviene nombrar. En la demo, Ali no supervisó cada paso: confió en que el agente había hecho su parte y tomó el control cuando lo necesitó. Ese cambio de mentalidad —pasar de "yo hago todo" a "yo dirijo y decido"— es, probablemente, el obstáculo más grande en empresas donde el conocimiento operativo vive en la cabeza de dos o tres personas clave.
¿Cómo aplica esto en tu empresa?
El punto de partida no es elegir la herramienta, sino mapear la fricción. Antes de pensar en agentes, haz una lista de las tareas repetitivas que consumen más tiempo de tu equipo y que siguen un patrón predecible: revisar alertas, clasificar correos, ordenar tickets, consolidar reportes, responder preguntas frecuentes. Si una tarea se repite, tiene reglas reconocibles y termina en una decisión humana, es candidata.
Después, define con claridad dónde se detiene el agente. Este es el paso que más se salta y el que más problemas evita. En la demo, el agente investigaba y preparaba, pero Ali decidía. Escribe esa frontera explícitamente: qué puede hacer solo, qué debe dejar listo para revisión y qué nunca debe tocar sin aprobación.
En tercer lugar, mide el "antes". Si no sabes cuánto tiempo se pierde hoy entre que llega una alerta y que alguien empieza a trabajar en ella, no vas a poder demostrar el retorno ni mejorar el flujo. Registra dos o tres semanas de tiempos reales antes de automatizar. Con ese dato, la conversación deja de ser sobre tecnología y se vuelve sobre horas y decisiones.
Finalmente, empieza por un solo flujo. Un canal, una tarea, un responsable. La tentación de automatizar todo a la vez es la forma más rápida de no automatizar nada. Si quieres revisar qué flujo de tu operación tiene más sentido como primer paso, puedes conversar con nosotros sobre tu caso. Y si ya estás pensando en generar contenido y procesos internos con IA, vale la pena conocer ContentFlow.
Preguntas Frecuentes
¿Los dots de OpenAI ya están disponibles para empresas?
No. Lo que se mostró en la demostración, incluida la conexión con Slack y la ejecución en Codex, forma parte de una presentación de capacidades, no de un producto disponible para contratación general. Para una empresa en Perú, lo relevante hoy es el modelo de trabajo que muestra —delegar el primer tramo y decidir el resto— porque ese mismo patrón se puede construir con herramientas disponibles.
¿En qué se diferencia un agente de IA de un chatbot normal?
Un chatbot responde preguntas y espera tu siguiente instrucción. Un agente como el de la demo actúa sobre herramientas externas: monitorea un canal, investiga una alerta, abre un hilo de trabajo y deja el resultado donde tú lo vas a encontrar. La diferencia práctica está en el punto de partida: con un chatbot empiezas a trabajar desde cero, con un agente llegas a un trabajo ya iniciado.
¿Por dónde debería empezar una PYME que quiere usar agentes de IA?
Por la tarea más repetitiva y mejor definida, no por la más compleja. Elige un solo flujo, documenta cuánto tiempo consume hoy, define exactamente hasta dónde llega el agente y qué decisión queda en manos de una persona, y mide el resultado durante un mes. Un primer flujo que funciona enseña más que un plan de automatización completo que nunca se ejecuta.
Conclusión: ¿el valor está en la tecnología o en la pregunta que haces?
La escena de las 3 a.m. es memorable por lo que no pasó: alguien no tuvo que levantarse a investigar desde cero. Pero el mérito real no estuvo en el modelo ni en la nube, sino en que el ingeniero había definido antes una tarea concreta, un disparador claro y un punto de entrega útil. Eso es trabajo de diseño de procesos, y es exactamente lo que una empresa mediana en Perú puede hacer hoy, incluso sin acceso a la tecnología de la demo.
La invitación es simple: antes de preguntar qué herramienta comprar, pregunta qué tarea repetitiva te está quitando más horas y quién decide al final. Esa respuesta te va a decir más sobre tu camino hacia los agentes de IA que cualquier comparación de productos. Si quieres ayuda para identificar ese primer flujo en tu operación, puedes contactar a Consultoría TI.
Por Edgar Vásquez, Consultoría TI · actualizado el 17 de octubre de 2026
Fuentes y Referencias
- OpenAI — Put your dot on call (YouTube)
- Subvolts — OpenAI's AI Agent Triage On-Call Incident in ChatGPT
- The Futurist — Put your dot on call
✨ Contenido generado con ContentFlow — Consultoría-Ti