Durante el año pasado, la comunidad empresarial de IA ha estado enfrascada en un debate sobre cuánta libertad dar a los agentes de IA. Si es demasiado poco, se obtendrá una costosa automatización del flujo de trabajo que apenas justifica la etiqueta de “agente”. Demasiado y tendrás el tipo de desastre de limpieza de datos que afectó a los primeros usuarios de herramientas como OpenClaw. Esta semana, Google Labs lanzó una actualización para Ópalosu creador de agentes visual sin código que llega silenciosamente a una respuesta y tiene lecciones que todo líder de TI que planifique una estrategia de agentes debería estudiar detenidamente.
La actualización introduce lo que Google llama el “paso del agente” que transforma los flujos de trabajo de arrastrar y soltar de Opal, que antes estaban estáticos, en experiencias dinámicas e interactivas. En lugar de especificar manualmente a qué modelo o herramienta llamar y en qué orden, los constructores ahora pueden establecer un objetivo y dejar que el agente determine el mejor camino para lograrlo: seleccionar herramientas, activar modelos como Gemini 3 Flash o Veo para la generación de video e incluso iniciar conversaciones con los usuarios cuando necesitan más información.
Parece una modesta actualización de producto. No lo es. Lo que Google ha lanzado es una arquitectura de referencia funcional para las tres capacidades que definirán a los actores empresariales en 2026:
Enrutamiento adaptable
Memoria persistente
Orquestación humana en el circuito
…y todo esto es posible gracias a la rápida mejora de las capacidades de razonamiento de modelos de frontera como la serie Géminis 3.
El punto de inflexión ‘fuera de las vías’: por qué mejores modelos lo cambian todo en el diseño de agentes
Para comprender por qué la actualización de Opal es importante, es necesario comprender un cambio que se ha estado gestando en todo el ecosistema de agentes durante meses.
La primera ola de marcos de agentes empresariales (herramientas como las primeras versiones de CrewAI y los primeros lanzamientos de LangGraph) se definieron por una tensión entre autonomía y control. Los primeros modelos simplemente no eran lo suficientemente confiables como para confiar en la toma de decisiones abiertas. El resultado fue lo que los profesionales comenzaron a llamar “agentes sobre rieles”: flujos de trabajo estrictamente restringidos donde cada punto de decisión, cada llamada de herramienta y cada ruta de bifurcación tenía que ser predefinida por un desarrollador humano.
Este enfoque funcionó, pero fue limitado. Construir un agente sobre rieles significaba anticipar todos los estados posibles que el sistema podría encontrar: una pesadilla combinatoria para cualquier cosa más allá de tareas simples y lineales. Peor aún, significó que los agentes no podían adaptarse a nuevas situaciones, la misma habilidad que hace que la IA agente sea valiosa en primer lugar.
La serie Gemini 3, junto con lanzamientos recientes como Claude Opus 4.6 y Sonnet 4.6 de Anthropic, representa un umbral en el que los modelos se han vuelto lo suficientemente confiables en la planificación, el razonamiento y la autocorrección como para que las pistas puedan comenzar a soltarse. La propia actualización de Opal de Google es un reconocimiento de este cambio. El nuevo paso del agente no requiere que los constructores predefinan cada ruta a través de un flujo de trabajo. En cambio, se basa en el modelo subyacente para evaluar el objetivo del usuario, evaluar las herramientas disponibles y determinar dinámicamente la secuencia óptima de acciones.
Este es el mismo patrón que hizo viables los flujos de trabajo de los agentes y las llamadas de herramientas de Claude Code: los modelos son lo suficientemente buenos como para decidir el siguiente paso del agente y, a menudo, incluso para autocorregirse sin que un humano revise manualmente cada error. La diferencia en comparación con Claude Code es que Google ahora está empaquetando esta capacidad en un producto de consumo sin código, una fuerte señal de que la tecnología subyacente ha madurado más allá de la fase experimental.
Para los equipos empresariales, la implicación es sencilla: si todavía está diseñando arquitecturas de agentes que requieren rutas predefinidas para cada contingencia, probablemente esté haciendo demasiada ingeniería. La nueva generación de modelos admite un patrón de diseño en el que se definen objetivos y restricciones, se proporcionan herramientas y se deja que el modelo maneje el enrutamiento: un cambio de programar agentes a administrarlos.
Memoria entre sesiones: la característica que separa las demostraciones de los agentes de producción
La segunda gran incorporación a la actualización de Opal es la memoria persistente. Google ahora permite a Opals recordar información a lo largo de las sesiones (preferencias del usuario, interacciones previas, contexto acumulado), lo que permite a los agentes mejorar con el uso, en lugar de empezar desde cero cada vez.
Google no ha revelado la implementación técnica detrás del sistema de memoria de Opal. Pero el patrón en sí está bien establecido en la comunidad de construcción de agentes. Herramientas como OpenClaw manejan la memoria principalmente a través de archivos Markdown y JSON, un enfoque simple que funciona bien para sistemas de un solo usuario. Las implementaciones empresariales enfrentan un problema más difícil: mantener la memoria entre múltiples usuarios, sesiones y límites de seguridad sin filtrar contexto confidencial entre ellos.
Esta división de la memoria entre usuarios únicos y multiusuarios es uno de los desafíos menos discutidos en la implementación de agentes empresariales. Un asistente de codificación personal que recuerda la estructura de su proyecto es fundamentalmente diferente de un agente de atención al cliente que debe mantener estados de memoria separados para miles de usuarios simultáneos mientras cumple con las políticas de retención de datos.
Lo que indica la actualización de Opal es que Google considera la memoria una característica central de la arquitectura del agente, no un complemento opcional. Para los tomadores de decisiones de TI que evalúan las plataformas de agentes, esto debería informar los criterios de adquisición. Un marco de agente sin una estrategia de memoria clara es un marco que producirá demostraciones impresionantes, pero tendrá dificultades en la producción, donde el valor de un agente aumenta a través de interacciones repetidas con los mismos usuarios y conjuntos de datos.
Human-in-the-loop no es un reemplazo, es un patrón de diseño
El tercer pilar de la actualización de Opal es lo que Google llama “chat interactivo”: la capacidad de un agente de pausar la ejecución, hacer al usuario una pregunta de seguimiento, recopilar información faltante o presentar opciones antes de continuar. En la terminología de la arquitectura de agentes, esto es orquestación humana, y su inclusión en un producto de consumo es reveladora.
Los agentes más eficaces en la producción actual no son completamente autónomos. Estos son sistemas que saben cuándo han alcanzado los límites de su confianza y pueden devolver el control a un humano con gracia. Este es el estándar que separa a los actores empresariales confiables del tipo de sistemas autónomos fuera de control que han generado historias de advertencia en toda la industria.
En marcos como LangGraph, human-in-the-loop se ha implementado tradicionalmente como un nodo explícito en el gráfico: un punto de control codificado donde la ejecución se pausa para la revisión humana. El enfoque de Opal es más fluido: el propio agente decide cuándo necesita la intervención humana en función de la calidad e integridad de la información que tiene. Este es un patrón de interacción más natural con mejor escalabilidad, porque no requiere que el constructor prediga de antemano exactamente dónde será necesaria la intervención humana.
Para los arquitectos empresariales, la lección es que la participación humana no debe ser tratada simplemente como una red de seguridad que se coloca después de construir el agente. Debe ser una capacidad de primera clase de la propia estructura del agente, una que el modelo pueda invocar dinámicamente en función de su propia evaluación de incertidumbre.
Enrutamiento dinámico: dejar que el modelo decida el camino
La última característica importante es el enrutamiento dinámico, donde los constructores pueden definir múltiples rutas a través de un flujo de trabajo y permitir que el agente seleccione la ruta adecuada según criterios personalizados. El ejemplo de Google es un agente de información ejecutiva que toma diferentes caminos dependiendo de si el usuario se reúne con un cliente nuevo o existente: buscando información básica en la web en un caso, revisando notas de reuniones internas en el otro.
Esto es conceptualmente similar a la bifurcación condicional que LangGraph y marcos similares han admitido durante algún tiempo. Pero la implementación de Opal reduce drásticamente la barrera al permitir a los constructores describir los criterios de enrutamiento en lenguaje natural en lugar de código. El modelo interpreta los criterios y toma la decisión de enrutamiento, en lugar de requerir que un desarrollador escriba una lógica condicional explícita.
La implicación empresarial es significativa. El enrutamiento dinámico basado en criterios de lenguaje natural significa que los analistas de negocios y los expertos en el dominio (no solo los desarrolladores) pueden definir comportamientos complejos de los agentes. Esto hace que el desarrollo de agentes pase de ser una disciplina puramente de ingeniería a una en la que el conocimiento del dominio se convierte en el principal cuello de botella, un cambio que podría acelerar drásticamente la adopción en unidades de negocios no técnicas.
Lo que Google realmente está construyendo: una capa de inteligencia de agentes
Alejándose de las características individuales, el patrón más amplio en la actualización de Opal es que Google está creando una capa de inteligencia que se sitúa entre la intención del usuario y la ejecución de tareas complejas de varios pasos. Basado en lecciones de un SDK de agente interno llamado “tablero de prueba”, el paso del agente no es simplemente otro nodo en un flujo de trabajo, es un capa de orquestación que puede reclutar modelos, invocar herramientas, gestionar la memoria, enrutar dinámicamente e interactuar con humanos, todo ello impulsado por las capacidades de razonamiento en constante mejora de los modelos subyacentes de Gemini.
Este es el mismo patrón arquitectónico que está surgiendo en toda la industria. Code Claude de Anthropic, con su capacidad para gestionar de forma autónoma tareas de codificación de la noche a la mañana, se basa en principios similares: un modelo capaz, acceso a herramientas, contexto persistente y bucles de retroalimentación que permiten la autocuración. El complemento Ralph Wiggum formalizó la comprensión de que los modelos pueden ser presionados por sus propios defectos para llegar a soluciones correctas: una versión de autocorrección de fuerza bruta que Opal ahora incluye algo de esto en una experiencia de consumidor refinada.
Para los equipos empresariales, la conclusión es que la arquitectura de los agentes está convergiendo en un conjunto común de principios: planificación dirigida a objetivos, herramientas, memoria persistente, enrutamiento dinámico y orquestación humana en el circuito. El diferenciador no será qué primitivas implemente, sino qué tan bien las integre y con qué eficacia aproveche las capacidades de mejora de los modelos de frontera para reducir la cantidad de configuración manual requerida.
El manual práctico para creadores de agentes empresariales
El hecho de que Google proporcione estas capacidades en un producto gratuito y orientado al consumidor envía un mensaje claro: los estándares fundamentales para construir agentes de IA eficaces ya no son investigaciones de vanguardia. Son producidos. Los equipos empresariales que han estado esperando que la tecnología madure ahora tienen una implementación de referencia que pueden estudiar, probar y aprender, sin costo alguno.
Los pasos prácticos son sencillos. En primer lugar, evalúe si las arquitecturas de sus agentes actuales están demasiado restringidas. Si cada punto de decisión requiere una lógica codificada, probablemente no esté aprovechando las capacidades de planificación de los modelos de frontera actuales. En segundo lugar, priorizar la memoria como un componente arquitectónico central en lugar de una idea de último momento. En tercer lugar, diseñar al ser humano en el circuito como un recurso dinámico que el agente puede invocar, en lugar de un punto de control fijo en un flujo de trabajo. Y cuarto, explorar el enrutamiento del lenguaje natural como una forma de incorporar expertos en el dominio al proceso de diseño del agente.
Es poco probable que Opal se convierta en la plataforma adoptada por las empresas. Pero los patrones de diseño que incorpora (agentes adaptativos, ricos en memoria y conscientes de los humanos impulsados por modelos de frontera) son los patrones que definirán la próxima generación de IA empresarial. Google mostró su mano. La pregunta para los líderes de TI es si están prestando atención.
