[NOVA]: Soy NOVA, y esto es AgentStack Daily. Hoy empezamos con la parte de la infraestructura de agentes que decide si toda la pila se siente aburrida de la buena manera: instalaciones, confiabilidad de canales, perfiles de autenticación, sesiones en segundo plano y controles de despliegue. OpenClaw v2026.5.12 es la versión de calidad de host que hay que ver primero. Recorta la instalación central, hace que el polling de Telegram sea más resistente, ajusta el comportamiento de autenticación de Codex y OpenAI, fortalece los plugins y la entrega del gateway, y limpia las rutas del navegador, sandbox y configuración. A su lado, Hermes Agent 2026.5.16 es un salto en distribución y runtime: beta nativa de Windows, instalación vía PyPI, inicio más rápido, un proxy local compatible con OpenAI, rutas de herramientas reales de visión y video, mejoras de velocidad del navegador y verificación después de mutaciones de archivos. ...

[ALLOY]: Soy ALLOY. Claude Code es la historia adyacente del agente de codificación local. Las versiones 2.1.143 y 2.1.142 añaden aplicación de dependencias de plugins, costo de contexto proyectado, preservación de flags de sesiones en segundo plano, comportamiento de PowerShell, opciones de aislamiento de worktree, correcciones de timeout de MCP y límites de stop-hook. Luego pasamos a dos cambios de la plataforma de Google. Gemini Enterprise Agent Platform ahora tiene revisiones de agentes, división de tráfico y Priority PayGo. Y la Interactions API de Google está migrando de salidas planas a una línea de tiempo de pasos tipados. La pregunta práctica a través del episodio es simple: ¿qué debería un operador actualizar, probar e instrumentar antes de que estos cambios se conviertan en suposiciones de producción? ...

[NOVA]: La forma más rápida de entender el panorama de lanzamientos de hoy es comenzar por las superficies que primero se rompen en el trabajo real con agentes. Una demo puede sobrevivir a una instalación inflada, un adaptador de mensajes frágil, una falla de autenticación vaga o un worker en segundo plano que despierta con la configuración incorrecta. Un operador diario no puede. Un host de agentes serio tiene que instalarse limpiamente, sobrevivir a las pausas de canales, mantener las credenciales delimitadas, reanudar el trabajo en segundo plano sin cambiar sus permisos e informar el contenido real de salida incluso cuando ese contenido es una tarjeta rica o un resultado de herramienta en lugar de texto plano. ...

[ALLOY]: Por eso OpenClaw v2026.5.12 importa. No es solo agregar un botón brillante. Está reduciendo los conos de dependencia, aislando el polling de Telegram, preservando el estado del spool local, mejorando el comportamiento de credenciales de Codex y OpenAI, reparando los deltas del gateway y haciendo que las respuestas ricas cuenten como respuestas reales. Esas son las clases de correcciones que hacen que un operador deje de pensar en la plomería. Si un mensaje de grupo debería ser ignorado porque el filtro de menciones está activo, no debería descargarse primero. Si un anuncio programado renderiza HTML, el formateo debería sobrevivir. Si una respuesta es solo una tarjeta con botones, no debería desaparecer porque un campo de texto plano está vacío. ...

[NOVA]: Hermes Agent 2026.5.16 amplía el lente. Hace que el agente sea más fácil de instalar, más rápido de iniciar, más viable en Windows y más útil como puente de proveedor local. Un proxy local compatible con OpenAI para proveedores con respaldo OAuth es especialmente interesante porque permite que herramientas que ya hablan APIs estilo OpenAI apunten a cuentas y proveedores que de otra manera vivirían detrás de una ruta de autenticación diferente. Eso puede cambiar el centro de gravedad para herramientas locales: Hermes se convierte no solo en un agente de chat, sino en un centro de proveedores. ...

[ALLOY]: Los cambios recientes de Claude Code completan la imagen del operador. El trabajo en segundo plano es útil solo cuando preserva las cosas que hacían segura la sesión en primer plano: modelo, esfuerzo, configuración, configuración de MCP, directorios adicionales, directorios de plugins, opciones estrictas de MCP, modelo de respaldo y modo de permiso. La aplicación de dependencias de plugins es igualmente práctica. Si un plugin depende de otro, deshabilitar la dependencia no debería dejar el sistema en un estado medio roto. Este es el tema del agente maduro para el día, sin necesidad de un eslogan: menos estado oculto, más despliegue explícito, más recuperación testeable. ...

[NOVA]: También hay una razón para priorizar la lectura de lanzamientos en lugar de tratarla como mantenimiento. Estas actualizaciones cambian los valores predeterminados del flujo de trabajo que heredan los constructores. Si la instalación es más pequeña, un nuevo operador puede comenzar con menos fallas no relacionadas. Si el adaptador de canal hace spool localmente, un flujo de trabajo de aprobación puede sobrevivir a una pausa del loop de eventos. Si los perfiles de autenticación son respetados por las rutas de medios y Codex, un flujo de trabajo de proveedor mixto tiene menos bucles de reautenticación falsos. Si las sesiones en segundo plano preservan la configuración, un flujo de trabajo de codificación desatendido puede despertar con la misma autoridad que tenía cuando comenzó. Esas no son mejoras abstractas; cambian si los equipos confían en los agentes con trabajos más largos. ...

[ALLOY]: El primer patrón de construcción es tratar el lanzamiento como un ensayo de actualización. No ejecutes un comando, ve un prompt y declares éxito. Construye un pequeño flujo de trabajo de operador para cada superficie: un flujo de trabajo de canal, uno de proveedor, uno de plugin, uno de gateway, uno de navegador y uno de codificación en segundo plano. Cada uno debería tener un estado esperado antes de la actualización y un estado esperado después. Eso hace que el lanzamiento sea medible. También le da al equipo un disparador de reversión si una superficie retrocede. ...

[NOVA]: Historia uno es la lectura de lanzamientos del stack de agentes: OpenClaw v2026.5.12, Hermes Agent 2026.5.16 y Claude Code 2.1.143 y 2.1.142 mueven la superficie del operador. Empecemos con la forma de dependencia de OpenClaw. Bedrock, Bedrock Mantle, Slack, sandbox de OpenShell, Anthropic Vertex, WhatsApp y los paquetes de proveedores relacionados se mueven fuera del runtime central obligatorio. Eso suena como mantenimiento de paquetes, pero para hosts de agentes es una mejora real de confiabilidad. Los proveedores opcionales no deberían convertirse en fallas de compilación específicas de plataforma para usuarios que nunca los habilitaron. Un núcleo más delgado significa menos construcciones nativas sorpresa, menos conflictos de versiones transitivas y menos fallas de actualización causadas por un servicio que no es parte de la configuración activa. ...

[ALLOY]: Los conos de dependencia son un riesgo operativo silencioso. Si el paquete base del agente obtiene cada proveedor, cada adaptador de canal y cada ruta de sandbox por defecto, entonces la instalación base se convierte en rehén de la dependencia opcional más frágil. El mejor modelo es un núcleo pequeño con extras explícitos. Los operadores pueden decidir entonces si necesitan Slack, WhatsApp, Bedrock, Vertex, un backend de sandbox o un plugin especial de proveedor. La prueba de actualización para esta parte no es glamorosa: crea un entorno limpio, instala el núcleo, inicia el host y luego agrega solo los extras que realmente usas. La ausencia de proveedores no utilizados es la característica. ...

[NOVA]: El segundo grupo de OpenClaw es la resiliencia de canales. El polling de Telegram ahora se ejecuta en un worker aislado con spooling local duradero. El objetivo de diseño es claro: una pausa del loop de eventos principal no debería ser suficiente para perder o retrasar severamente los mensajes entrantes de Telegram. En operaciones de agentes, el chat no es solo una UI. Es un bus de disparadores, bus de aprobación, bus de estado y bus de evidencia. Si el agente principal está ocupado con una llamada de herramienta larga, el adaptador de canal aún necesita comportarse como infraestructura de transporte. Polling aislado más spool local es una respuesta a ese modo de falla. ...

[ALLOY]: El lanzamiento también ajusta varios detalles de Telegram y mensajería que los operadores notarán. Los anuncios cron lazy preservan el formateo HTML renderizado. El medio grupal que no menciona al bot puede omitirse antes de la descarga cuando el filtro de menciones está activo. Las burbujas de borrador solo con progreso de herramienta se limpian antes de que entre la respuesta final. Las respuestas solo ricas, tarjetas, botones y respuestas de fuente se tratan como contenido saliente en lugar de descartarse como vacío. La prueba de humo práctica después de actualizar es una respuesta transmitida, un anuncio programado, un caso límite de medio grupal, una tarjeta rica y un turno interrumpido. ...

[NOVA]: Las rutas de Codex y OpenAI reciben una gran pasada de confiabilidad. Las herramientas de medios respaldadas por perfil de autenticación permanecen disponibles cuando las credenciales viven en el almacén de perfil de autenticación del agente en lugar de en variables de entorno. Los errores de actualización de OAuth de Codex se clasifican más claramente, y las fallas de actualización de servidor de aplicaciones de alta confianza evitan colapsar en fallas de runtime vagas. Los modelos de agente OpenAI seleccionables se tratan como requisitos de runtime de Codex incluso cuando la configuración del modelo primario es Anthropic. Eso importa en configuraciones de host mixtas donde Claude es el asistente primario pero las herramientas respaldadas por Codex u OpenAI aún necesitan rutas válidas de modelo y credenciales. ...

[ALLOY]: El comportamiento de CODEX_HOME también es importante. OpenClaw mantiene el aislamiento de CODEX_HOME por agente sin reescribir HOME por defecto. Esa distinción previene dos malos resultados. Por un lado, no quieres que todos los agentes compartan accidentalmente el mismo estado de credenciales y caché de Codex. Por otro lado, reescribir HOME puede romper procesos secundarios ordinarios que esperan descubrimiento normal de home de usuario. El lanzamiento está eligiendo un aislamiento más estrecho: aísla el estado de Codex que quieres aislar, pero evita convertir cada proceso secundario en un extraño experimento de entorno. ...

[NOVA]: La mecánica de plugins obtiene el siguiente conjunto de cambios. Las instalaciones de plugins preservan las dependencias pares, manejan pnpm 11, restauran un subpath de SDK de memoria en desuso para plugins complementarios, escanean puntos de entrada de runtime más estrechamente, descubren plugins de proveedor a través de credenciales de configuración estructuradas y preservan registros de instalación a través de limpieza de doctor. La lectura a nivel de operador es que la instalación de plugins se está tratando como un grafo de dependencias, no como una copia de carpeta. Si un plugin depende de un par, si un gestor de paquetes cambia de comportamiento o si la limpieza de doctor se ejecuta después de una falla, el sistema debería mantener suficiente estado para recuperarse en lugar de atascar el host. ...

[ALLOY]: Los cambios de protocolo de gateway y sesión son igualmente prácticos para desarrolladores que construyen clientes sobre OpenClaw. El historial de sesión ahora lleva números de secuencia de transcripción monotónicos. El streaming puede enviar texto delta explícito y marcos de reemplazo. Eso significa que un cliente ya no tiene que adivinar cómo hacer diff de la salida del asistente localmente o inferir el orden solo desde el tiempo. Los números de secuencia son una de esas pequeñas características de protocolo que se vuelven esenciales tan pronto como reconexiones, reintentos o múltiples consumidores entran en escena. La prueba no es solo una respuesta de texto plano. Prueba reconexiones, marcos de reemplazo, respuestas ricas, respuestas solo de herramienta de mensaje y salidas de medios o tarjetas. ...

[NOVA]: El endurecimiento de seguridad y configuración completan el lanzamiento de OpenClaw. Las raíces del perfil de usuario de Windows se incluyen en las raíces de hogar bloqueadas del sandbox para que las carpetas con credenciales permanezcan denegadas incluso cuando HOME apunta a otro lugar. Las credenciales de proveedores se resuelven a través de referencias secretas estructuradas en lugar de cadenas amplias que parecen variables de entorno, reduciendo la inferencia accidental de credenciales. Las mutaciones de configuración semánticas se serializan y reintentan centralmente, reduciendo el riesgo de sobrescritura cuando comandos concurrentes editen la misma configuración. Los comandos CLI del navegador solicitan el alcance existente del gateway de operador-admin, lo que evita ruido innecesario del loop de aprobación. ...

[ALLOY]: Ninguno de esos elementos es llamativo en los titulares, pero son exactamente la diferencia entre un agente local divertido y un runtime diario seguro. Las credenciales no deberían filtrarse porque un sandbox adivinó la raíz de hogar equivocada. La configuración no debería corromperse porque dos comandos compitieron. Los comandos del navegador no deberían pedir un nuevo tipo de permiso cuando ya existe un alcance de operador-admin. Las referencias secretas estructuradas deberían hacer explícita la intención de credenciales. Esto es mantenimiento de host, y el mantenimiento de host es donde se construye la confianza. ...

[NOVA]: Hermes Agent 2026.5.16 es la historia más amplia del runtime y la distribución. El lanzamiento nombra el soporte nativo de Windows como beta temprana. Eso incluye un instalador de PowerShell, rutas nativas de subprocess y PTY, gestión de procesos basada en taskkill, auto-instalación de MinGit, detección de stubs de Python, preservación de Ctrl+C y correcciones específicas de Windows. La advertencia es beta, pero la dirección es mayor. Las herramientas de agentes que solo se sienten naturales en sistemas tipo Unix dejan muchas máquinas de desarrolladores y empresas fuera del camino de primera clase. El soporte de Windows no es una casilla de verificación; toca control de procesos, terminales, señales, rutas, instalación de Git, valores predeterminados de shell e integración de navegador. ...

[ALLOY]: Hermes también envía una ruta de instalación real de PyPI: pip install hermes-agent, luego ejecuta hermes. Eso cambia el ciclo de adopción. Un usuario no debería tener que clonar un repositorio, inspeccionar un instalador personalizado y depurar un script de shell antes de probar un agente. La distribución PyPI, las dependencias lazy y los controles advisory juntos dicen que el proyecto está tratando la instalación como producto. Las dependencias lazy difieren las bibliotecas pesadas de proveedores hasta el primer uso. Los fallbacks del instalador se mueven a través de niveles de extras. Las búsquedas de instalación y actualización buscan versiones inseguras. El resultado debería ser una primera ejecución más rápida y menos fallas innecesarias de proveedores. ...

[NOVA]: Los números de rendimiento valen la pena traducirlos a sensación diaria. Hermes dice que el inicio en frío baja aproximadamente diecinueve segundos con skills caching, lazy imports, disk-cache-first model lookup, librerías de providers diferidas, y verificaciones de doctor en paralelo. Las herramientas de Hermes para todas las plataformas caen de aproximadamente catorce segundos a menos de un segundo y medio. Las evaluaciones de consola del navegador se vuelven dramáticamente más rápidas al reutilizar el WebSocket CDP persistente del supervisor en lugar de abrir una sesión DevTools nueva por llamada. Para debugging con mucho navegador, el CDP persistente no es un detalle de implementación. Decide si el loop se siente instantáneo o como si cada observación comienza con un impuesto de configuración.

[ALLOY]: El proxy local puede ser la característica más estratégicamente interesante de Hermes. El proxy de Hermes expone proveedores autenticados con OAuth a través de un endpoint local compatible con OpenAI. Herramientas como Codex, Aider, Cline, o extensiones de editor frecuentemente saben cómo llamar a una API estilo OpenAI. Es posible que no sepan cómo manejar cada cuenta de consumidor respaldada por OAuth o ruta de login específica de un proveedor. Un proxy de compatibilidad local puede salvar esa distancia. La pregunta del operador se convierte en: qué herramientas locales deben apuntar a Hermes como su puente de proveedor, y cuáles deben mantener su configuración directa de proveedor.

[NOVA]: Hermes también expande su superficie de herramientas. El caching de prompts de Claude de una hora en sesiones cruzadas puede reducir el costo de prefijos repetidos entre reanudos y nuevas sesiones. Vision analyze ahora pasa píxeles a modelos con capacidad de visión en lugar de reducir la imagen a texto primero. Una herramienta unificada de generación de video apoya proveedores conectables. Computer use obtiene un backend no compatible con Anthropic a través de cua-driver. El handoff puede mover la sesión activa a otro modelo, persona, o perfil mientras preserva el contexto y el historial de herramientas. Las mejoras en X search y navegador lo hacen más útil como centro de investigación y automatización.

[ALLOY]: Para agentes de escritura de código, dos características de verificación merecen atención especial. Los diagnósticos semánticos de LSP se ejecutan después de las operaciones de write file y patch, así que el agente puede ver los errores del language server en el archivo cambiado antes de que el trabajo posterior continúe. Un footer de verificación de mutación de archivo por turno le dice al agente qué cambió realmente en el disco después de un turno que escribió archivos. Eso es una respuesta directa a un modo de falla conocido: el modelo dice que editó el archivo, pero el patch falló, modificó la región incorrecta, o introdujo un error de tipo que es visible inmediatamente. Los diagnósticos y resúmenes de mutación no reemplazan las pruebas, pero acortan el camino hacia la primera corrección real.

[NOVA]: Claude Code 2.1.143 y 2.1.142 redondean el lado del CLI-agent. El enforcement de dependencias de plugins significa que deshabilitar un plugin puede rechazarse cuando otro plugin habilitado depende de él, y el sistema puede mostrar un hint de cadena de deshabilitado. Habilitar un plugin puede forzar-habilitar dependencias transitivas. El panel de浏览 del marketplace muestra el costo de contexto proyectado por turno e invocación. Eso es útil porque un plugin no es gratis solo porque está instalado. Si inyecta contexto o corre frecuentemente, tiene un efecto de presupuesto. Hacer ese costo visible convierte el manejo de plugins de vibes a operaciones.

[ALLOY]: El aislamiento de worktree en background obtiene una nueva opción con worktree background isolation establecido en none. Eso permite que sesiones en background editen la copia de trabajo directamente cuando los Git worktrees son imprácticos. No es el default más seguro para cada equipo, pero es una compuerta de escape del mundo real. La limpieza de worktree tampoco recurre ya a eliminación destructiva si git worktree remove falla. Eso importa porque los paths de limpieza son peligrosos. Una limpieza fallida debe ser visible y conservadora, no una invitación a eliminar más agresivamente.

[NOVA]: Los fixes de sesiones en background son los que yo probaría primero. Las sesiones en background preservan el modelo y el nivel de esfuerzo después de despertar del estado idle. El comando background preserva la configuración MCP, settings, add-dir, plugin-dir, configuración MCP estricta, modelo fallback, y disponibilidad de bypass-permission a través de respawn o detach. Los agentes de Claude aceptan flags para add-dir, settings, configuración MCP, directorios de plugins, modo de permiso, modelo, esfuerzo, y defaults de skip-permission. Las sesiones en background lanzadas desde el dashboard honran el modo de permiso por default configurado. Esa es la diferencia entre un worker que reanuda el mismo trabajo y un worker que reanuda con un contrato de seguridad sutilmente diferente.

[ALLOY]: Las llamadas de herramientas MCP HTTP y server-sent-event ahora respetan el timeout configurado en lugar de estar limitadas a sesenta segundos. Los stop hooks que siguen bloqueando ahora terminan con una advertencia después de ocho blocks consecutivos a menos que se sobrescriba. El comportamiento de PowerShell está mejorado. Las dependencias de plugins son más estrictas. La confiabilidad en background mejora. El resumen para operadores es claro: después de actualizar Claude Code, corre un trabajo real en background, déjalo idle, despiértalo, detacharlo, revisa la configuración MCP, revisa el modo de permiso, y fuerza una llamada MCP larga. No trates el número de versión como prueba de que tu workflow local sobrevivió.

[NOVA]: Así que la checklist de release es concreta. Para OpenClaw, prueba install extras, polling de Telegram y comportamiento de spool, respuestas ricas, perfiles de auth de Codex, deltas del gateway, instalación de plugins, alcance del navegador, sandbox blocked roots, y ediciones de configuración concurrentes. Para Hermes, prueba instalación de PyPI, Windows si es relevante, inicio en frío, consola de navegador persistente, el proxy local, visión, video, handoff, diagnósticos LSP, y verificación de mutación. Para Claude Code, prueba cadenas de dependencia de plugins, costo proyectado de plugins, flags de background, modo de worktree, timeout de MCP, stop hooks, PowerShell, y sesiones en background lanzadas desde el dashboard.

[ALLOY]: La segunda historia es que Google Gemini Enterprise Agent Platform añade revisiones de agentes, traffic splitting, y Priority PayGo. La actualización del 15 de mayo de Google añade una primitiva de deployment que los equipos de agentes necesitan: revisiones de agentes desplegados inmutables con traffic splitting. Antes de esto, muchos deployments de agentes se comportaban como endpoints mutables. Cambiabas el prompt, herramientas, routing, configuración del modelo, o código del contenedor, y el endpoint simplemente se volvía diferente. El rollback entonces dependía de cuán disciplinado era tu proceso de release fuera de la plataforma. Las revisiones dan a la versión del agente un artifact de deployment con nombre. El traffic splitting permite que un equipo mueva un slice del tráfico a una revisión nueva mientras la revisión vieja todavía sirve a la mayoría de los usuarios.

[NOVA]: Eso suena como práctica estándar de release de software, y esa es exactamente la razón por la que importa. Los agentes necesitan la misma disciplina de rollout que los servicios, más métricas comportamentales extra. Un canary de API determinístico vigila tasa de errores, latencia p95, y tal vez saturación. Un canary de agente debería vigilar todo eso más completación de tareas, conteo de llamadas a herramientas, tasa de escalamiento, tasa de corrección de usuario, tasa de miss de retrieval, tasa de rechazo, costo por resultado exitoso, y latencia por path de herramienta. Un tweak de prompt puede reducir alucinaciones pero duplicar las llamadas a herramientas. Un cambio de herramienta puede mejorar el éxito para una clase de request y romper otra. Sin observabilidad consciente de revisiones, esos cambios se confunden.

[ALLOY]: La recomendación de logging es simple: los IDs de revisión deben aparecer en traces, logs, registros de evaluación, registros de feedback, y bundles de soporte. El nombre del endpoint solo no es suficiente. Si un usuario reporta que el agente de repente empezó a elegir la herramienta incorrecta, la investigación necesita saber qué revisión sirvió el turno, qué share de tráfico tenía esa revisión, qué modelo y herramientas estaban activas, y si el mismo comportamiento apareció en evals offline. Los IDs de revisión son la join key entre rollout y calidad.

[NOVA]: El traffic splitting da a los equipos un lane más seguro. Empieza con un pequeño porcentaje del tráfico de producción o un cohorte interno estrecho. Vigila latencia, costo, errores de herramientas, éxito de tareas, y escalamiento humano. Luego haz roll forward, pausa, o haz rollback. La diferencia importante del rollout web ordinario es que la calidad del agente es parcialmente semántica. Puedes necesitar harnesses de evaluación, revisión humana, e inspección de transcripts muestreados junto con telemetría numérica. Una revisión puede ser saludable operacionalmente y peor comportamentalmente. El traffic splitting te da una manera de encontrar eso antes de que todos lo vean.

[ALLOY]: Priority PayGo, generalmente disponible un día antes, añade el lado de costo y latencia. Provisioned Throughput es mejor cuando el tráfico es suficientemente predecible como para justificar un commitment. Standard PayGo es flexible pero puede tener rendimiento más variable. Priority PayGo se sienta entre ellos: rendimiento más consistente que el consumo estándar sin el mismo commitment de throughput por ahead. Para agentes de producción, eso mapea a workloads que son importantes pero bursty: triaje de soporte al cliente, helpers de incidentes, asistentes de investigación internos, o agentes de workflow que hacen spike durante horas de negocio.

[NOVA]: La trampa del builder es mezclar diagnóstico de rollout con varianza de capacidad. Si una nueva revisión de agente se ve más lenta durante un canary, ¿la revisión está causando retrieval más profundo, más llamadas a herramientas, y razonamiento más largo? ¿O la plataforma está bajo carga variable? Priority PayGo puede reducir una fuente de ruido para que la señal de rollout sea más fácil de leer. No hace que una mala revisión sea buena, y no borra el costo. Las métricas por revisión todavía necesitan mostrar llamadas al modelo, llamadas a herramientas, uso de tokens, latencia, y tasa de éxito.

[ALLOY]: El dashboard mínimo útil de rollout de agentes de Gemini debe mostrar revisión, share de tráfico, latencia, costo de modelo y herramientas, errores de herramientas, escalamiento humano, éxito de tareas, tasa de rechazo, y estado de rollback. También debe separar latencia de plataforma de comportamiento de agente donde sea posible. Si la nueva revisión aumenta la profundidad de retrieval, eso es una elección de producto. Si la varianza de Standard PayGo hace spike al mismo tiempo, eso es ruido de capacidad. El punto de los releases de mayo es que el deployment de agentes ahora puede verse más como management de release de software. Usa esa disciplina.

[NOVA]: La tercera historia es que la migración de la Interactions API de Google reemplaza outputs planos con una timeline de steps tipeada. La guía de breaking changes dice que el schema legacy está siendo removido el 8 de junio. La forma vieja retornaba un array de outputs plano. La forma nueva retorna un array de steps con discriminadores de tipo y un formato de respuesta polimórfico. Para una aplicación simple, puede ser tentador agarrar el último item de texto y seguir moviendo. Para sistemas de agentes, eso perdería el punto. Un turno se está convirtiendo en una timeline estructurada, no solo un string generado final.

[ALLOY]: La migración práctica comienza con request y response readers. Si tu código asume outputs en el top level, actualízalo. Si los fixtures en tests incluyen solo la forma vieja, añade fixtures nuevos. Si tu base de datos almacena solo texto final, considera almacenar el objeto de interacción crudo o al menos la timeline de steps. Si tus herramientas de replay, herramientas de eval, herramientas de soporte, o herramientas de audit parsean outputs old, necesitan una capa de compatibilidad. La fecha de removal está lo suficientemente cerca como para que los equipos no dejen esto para la última semana.

[NOVA]: Los cambios de configuración de respuesta también. En lugar de response mime type, los output controls se mueven bajo response format. Eso es más limpio para una API creciente porque evita una pila de request fields one-off. Un formato de respuesta polimórfico le da a la plataforma espacio para añadir modos estructurados sin convertir el request schema en switches no relacionados. Para maintainers de SDK, esto es un issue de generación de tipos y compatibilidad. Para constructores de aplicaciones, es un issue de persistencia y parser. Tu app debe saber qué formato de respuesta fue solicitado y qué tipos de steps regresaron.

[ALLOY]: El detalle de control de migración es el header Api-Revision. Eso permite a los equipos hacer pin del comportamiento durante la transición en lugar de descubrir la remoción del schema a través de fallos de producción. Un buen plan de migración es soporte de lectura dual, captura de objeto crudo durante la transición, resúmenes y herramientas de replay actualizadas, y un pequeño suite de transcripts old o interacciones corriendo a través del parser nuevo. Si los logs de agentes se usan para soporte, evals, analytics, o audit, no aplanen los tipos de steps solo para preservar un modelo mental old de solo texto.

[NOVA]: La razón por la que la línea de tiempo de pasos importa es la capacidad futura. Google dice que la nueva forma soporta características futuras como la navegación en pleno vuelo y las llamadas a herramientas asíncronas. Esas características necesitan estructura de eventos. Una llamada a herramienta puede iniciar, esperar, reanudar, producir salida intermedia, o recibir navegación antes de la respuesta final. Si tu cliente colapsa la línea de tiempo en una cadena inmediatamente, podrías ser técnicamente compatible mientras te vuelves arquitectónicamente atrás. El mejor diseño es almacenar ID del paso, tipo de paso, marcas de tiempo, contenido, metadatos de herramienta, y enlace a la interacción. ...

[ALLOY]: Esto se alinea con el resto del episodio. OpenClaw está agregando secuencias de transcripción más limpias y semántica delta de gateway. Hermes está agregando diagnósticos y verificación de mutación. Gemini Enterprise Agent Platform está agregando revisiones y división de tráfico. La API de Interacciones de Google está haciendo que la interacción misma sea una línea de tiempo. Diferentes capas, misma lección operativa: los sistemas duraderos necesitan estado estructurado. El texto final es útil para el usuario, pero no es suficiente para depuración, navegación, reproducción, facturación o evaluación. ...

[NOVA]: La prioridad de actualización es directa. Si operas OpenClaw, prueba v2026.5.12 contra tus canales reales, perfiles de autenticación de Codex y OpenAI, clientes de gateway, comandos de navegador, instalaciones de plugins, expectativas de sandbox, y flujos de mutación de configuración. No te detengas en el éxito de inicio. Envía una respuesta rica. Interrumpe un turno. Prueba medios de grupo con restricción de menciones. Reconecta un cliente de gateway. Ejecuta una instalación de plugin y una limpieza de doctor. Confirma que el host se comporta como infraestructura de transporte, no como una demo afortunada. ...

[ALLOY]: Si operas Hermes, prueba la nueva ruta de instalación, ruta de Windows si importa a tus usuarios, velocidad de inicio, llamadas persistentes de consola del navegador CDP, proxy local, herramientas de imagen y video, transferencia, diagnósticos LSP, y verificador de mutación de archivos en un repositorio real. La parte del repositorio real importa. Un prompt de juguete no te dirá si los diagnósticos se disparan cuando un parche crea un error semántico o si el resumen de mutación captura los archivos exactos cambiados. ...

[NOVA]: Si usas agentes de fondo de Claude Code, actualiza y verifica que las sesiones de fondo preserven modelo, esfuerzo, configuraciones, configuración de MCP, add-dir, directorios de plugins, configuración estricta de MCP, modelo de respaldo, modo de permiso, y comportamiento de PowerShell a través de desconexión, inactividad y activación. Prueba cadenas de habilitación y deshabilitación de dependencias de plugins. Prueba una llamada larga de MCP. Prueba el bloqueo de stop-hook. Los agentes de fondo solo son valiosos cuando continúan el mismo trabajo bajo las mismas suposiciones de seguridad. ...

[ALLOY]: Para constructores de plataformas, las revisiones y la división de tráfico de Gemini Enterprise Agent Platform son el patrón de despliegue a copiar: los agentes necesitan canarios, rollback, observabilidad consciente de revisión, y puertas de despliegue conscientes de costo. Priority PayGo es útil donde la varianza de latencia confundiría el diagnóstico de despliegue o dañaría la experiencia del usuario, pero no reemplaza las métricas de calidad por revisión. ...

[NOVA]: Antes del cierre final, hagamos explícito el playbook de workflow. El primer workflow es un workflow de actualización de OpenClaw. Empieza desde el inventario de hosts activos: canales, proveedores de modelo, perfiles de Codex, clientes de gateway, uso de navegador, plugins, trabajos programados, y expectativas de sandbox. Luego ejecuta una construcción escalonada del nuevo host en un entorno limpio. El objetivo no es probar que cada integración existe. El objetivo es probar que el runtime base inicia solo con las integraciones que realmente usas. Un runtime base más pequeño significa una superficie de falla más pequeña, y ese es el punto de mover proveedores opcionales fuera del núcleo. ...

[ALLOY]: El segundo workflow es la prueba de canales. Elige un canal de chat real y ejecuta cuatro verificaciones. Primero, una respuesta transmitida normal, porque el streaming revela comportamiento de delta y reemplazo. Segundo, una respuesta rica, porque las tarjetas y botones deben contar como contenido saliente real. Tercero, un turno interrumpido, porque las burbujas de borrador y los mensajes de solo progreso no deben contaminar el resultado final. Cuarto, un caso de medios grupales restringidos, porque el agente no debe pagar costo de descarga y procesamiento por medios que fue configurado para ignorar. Si esas cuatro verificaciones pasan, el workflow de mensajería está más cerca de la confiabilidad de transporte en lugar de comportamiento de UI afortunado. ...

[NOVA]: El tercer workflow es la autenticación de Codex y proveedor. Usa un perfil que depende de autenticación estructurada en lugar de una variable de entorno amplia. Ejecuta una herramienta de OpenAI con capacidad de medios, una acción de Codex, y un cambio de modelo donde el agente principal no es OpenAI. Observa la clasificación de errores. Una buena actualización convierte un problema de refresh en un evento de autenticación claro, no en un crash de runtime inexplicable. El patrón de construcción aquí es simple: cada lane de proveedor necesita una fuente de credenciales deliberada, una ruta de refresh clara, y un mensaje de falla en el que un operador puede actuar. ...

[ALLOY]: El cuarto workflow es la gobernanza de plugins. Trata los plugins como un grafo de dependencias. Instala el conjunto de plugins que usas. Deshabilita un plugin opcional y confirma que nada no relacionado se rompe. Intenta deshabilitar una dependencia y confirma que el sistema da una advertencia de cadena de dependencias en lugar de crear un estado medio habilitado. Revisa el costo de contexto proyectado donde la plataforma lo expone. Un plugin que silenciosamente agrega gran contexto en cada turno no es solo una extensión. Es una decisión de presupuesto recurrente. Los workflows maduros de constructor hacen visible el costo de extensión y la dependencia de extensión antes del incidente. ...

[NOVA]: El quinto workflow es compatibilidad de cliente-gateway. Si construyes contra el gateway de OpenClaw, prueba más de una respuesta de happy-path. Prueba ordenamiento de secuencia, reconexión, frames de reemplazo, tarjetas ricas, respuestas de fuente, medios, y una respuesta de solo herramienta de mensaje. Un cliente que maneja solo texto final es fácil de escribir y fácil de romper. Un cliente que almacena secuencia de transcripción, delta, reemplazo, tipo de contenido, y estado de entrega es más trabajo, pero es el cliente que quieres cuando el agente corre todo el día. Esta es la misma lección arquitectónica que la migración de la API de Interacciones: guarda la línea de tiempo, no solo el resumen. ...

[ALLOY]: El workflow de Hermes comienza con instalación e inicio. Prueba la ruta de PyPI, luego prueba la primera acción que trae una dependencia de proveedor más pesada. Eso captura la diferencia entre un inicio vacío rápido y un primer uso útil. Luego haz benchmark de los comandos que impulsan tu loop diario. Si las llamadas de consola del navegador son parte de tu workflow de depuración, mídelas antes y después de la ruta persistente de CDP. Las mejoras de rendimiento importan más cuando eliminan la hésitación del operador. Si una herramienta responde en un segundo en lugar de quince, la gente la usa diferente. ...

[NOVA]: El workflow de proxy de Hermes merece un lanzamiento cuidadoso. No apuntes cada herramienta local al proxy el primer día. Elige una herramienta que ya habla una API compatible con OpenAI. Configúrala contra el proxy local. Ejecuta un pequeño conjunto de prompts que cubran generación normal, cancelación, manejo de errores, y límites específicos del proveedor. Luego decide si el proxy se convierte en tu puente por defecto o un puente específico para herramientas que no pueden manejar la autenticación nativa del proveedor. El patrón de construcción es compatibilidad primero, luego conveniencia. ...

[ALLOY]: El workflow de agente de código es diagnósticos primero. Crea una rama en un repositorio real. Pide a Hermes que haga un pequeño cambio que debería disparar retroalimentación del language-server si algo sale mal. Confirma que los diagnósticos aparecen después de la operación de escritura o parche. Luego inspecciona el resumen del verificador de mutación. Debería decirle al agente y al operador qué cambió. Este workflow no se trata de reemplazar pruebas. Se trata de atrapar el primer desajuste obvio entre lo que el agente cree y lo que el árbol de trabajo realmente contiene. ...

[NOVA]: Para Claude Code, usa un workflow de sesión de fondo que se parezca al trabajo de producción. Lanza un agente de fondo con un modelo específico, nivel de esfuerzo, perfil de configuraciones, configuración de MCP, modo de permiso, directorio adicional, directorio de plugins, y modelo de respaldo. Déjalo inactivo. Actívalo. Desconéctalo. Reanúdalo desde el dashboard. Luego pídele que llame a una herramienta MCP que corra más de sesenta segundos. Si alguna parte de ese contrato cambia silenciosamente, el workflow aún no es seguro. Los agentes de fondo no son solo chats de larga duración. Son compromisos de larga duración sobre autoridad, contexto, y acceso a herramientas. ...

[ALLOY]: El workflow de worktree necesita una decisión de equipo. Si tu equipo puede usar worktrees de Git aislados limpiamente, eso sigue siendo un patrón de seguridad fuerte. Si tu repositorio o herramientas hacen los worktrees imprácticos, la nueva opción sin aislamiento es útil, pero debe ser explícita. Agrega una nota de política en tu workflow de equipo: cuando el trabajo de fondo puede editar la copia de trabajo activa, quién revisa el diff, qué comandos están permitidos, y cómo se manejan los conflictos. El patrón de construcción seguro no es un ajuste universal. Es hacer coincidir el modo de aislamiento con la realidad del repositorio y hacer visible el tradeoff. ...

[NOVA]: Para Gemini Enterprise Agent Platform, el workflow es canario por revisión, no canario por esperanza. Crea una nueva revisión. Envía una pequeña porción de tráfico. Registra el ID de revisión en todas partes. Compara éxito de tarea, latencia, errores de herramientas, correcciones de usuario, escalación, costo, y tasa de rechazo contra la revisión actual. Mantén el rollback a una acción de distancia. Si la latencia es crítica y el tráfico es irregular, prueba Standard PayGo y Priority PayGo por separado para que puedas separar la varianza de la plataforma del comportamiento del agente. El hábito de construcción es hacer el despliegue observable antes de que el despliegue sea dramático. ...

[ALLOY]: Para la API de Interacciones, el workflow es migración de parser antes de migración de producto. Agrega el nuevo lector de respuestas. Mantén el lector viejo durante la transición. Almacena interacciones crudas por un tiempo. Actualiza eval replay. Actualiza herramientas de soporte. Actualiza cualquier trabajo de analytics que asuma que el texto final es el único artefacto. Luego ejecuta ejemplos viejos a través del nuevo parser de pasos y compara resultados. La migración peligrosa es la que pasa la primera demo pero rompe auditoría, soporte, o evaluación dos semanas después. El almacenamiento consciente de línea de tiempo previene eso. ...

[NOVA]: Si hay un patrón de construcción para llevarse de todo el episodio, es este: cada workflow de agente necesita una clave de estado. Los clientes de gateway de OpenClaw necesitan secuencia de transcripción. El despliegue de Gemini necesita ID de revisión. Interacciones necesita ID de paso. El trabajo de fondo de Claude Code necesita configuraciones de sesión preservadas. Las ediciones de código de Hermes necesitan resúmenes de mutación y diagnósticos. Cuando el workflow tiene una clave de estado, puedes observarlo, compararlo, hacer rollback, y explicarlo. Cuando el workflow solo tiene una respuesta final, estás depurando una memoria del sistema en lugar del sistema mismo. ...

[ALLOY]: Y el segundo patrón de construcción es probar primero el borde aburrido. Prueba el refresh de autenticación antes de la gran demo. Prueba la restricción de medios grupales antes del canal ocupado. Prueba la deshabilitación de plugins antes de una actualización urgente. Prueba la activación de inactividad antes de una corrida de fondo de fin de semana. Prueba el replay de parser antes de la fecha de remoción. Prueba el rollback antes de que la nueva revisión del agente tome la mayor parte del tráfico. Las pruebas aburridas no son un lastre para el shipping; son lo que permite que los workflows de agente se envíen sin convertir cada mejora en un nuevo misterio de operador. ...

[NOVA]: El tercer patrón de construcción es conectar cada flujo de trabajo a una prueba. Un flujo de trabajo de canal debe generar un mensaje que el operador pueda ver. Un flujo de trabajo de proveedor debe demostrar qué fuente de credencial se usó sin exponer el secreto. Un flujo de trabajo de plugin debe mostrar la decisión de dependencia. Un flujo de trabajo gateway debe mostrar el comportamiento de secuencia y reemplazo. Un flujo de trabajo en segundo plano debe mostrar la configuración preservada después de despertar. Un flujo de trabajo de despliegue debe mostrar la revisión y la proporción de tráfico. Un flujo de trabajo de migración de API debe mostrar la línea de tiempo de pasos analizados. La prueba es lo que impide que una nota de lanzamiento se convierta en un sistema de creencias. ...

[ALLOY]: El cuarto patrón de construcción es decidir qué capa posee cada garantía. OpenClaw debe poseer el comportamiento de transporte, la semántica de gateway, el alcance de credenciales y la seguridad del host. Hermes debe poseer la delegación, el puente de proveedor, el diagnóstico y la visibilidad de mutaciones. Claude Code debe poseer los controles de sesión de codificación local y la autoridad en segundo plano. Gemini Enterprise Agent Platform debe poseer los primitivos de despliegue en producción para agentes implementados. Interactions API debe poseer el historial estructurado de turnos. Cuando esos límites están claros, los constructores pueden depurar la capa correcta en lugar de culpar al modelo por cada fallo. ...

[NOVA]: Para los constructores de API, la migración de Interactions es el recordatorio de que las API de agentes se están convirtiendo en líneas de tiempo de eventos. Almacena los pasos. Mantén los metadatos de tipo. Construye el parser ahora. Usa deliberadamente la cabecera Api-Revision. Una limpieza de esquema no debe convertirse en una interrupción, y una cadena de respuesta final no debe ser lo único que tu sistema recuerda sobre un turno. ...

[ALLOY]: Eso es AgentStack Daily por hoy. Actualiza las superficies del host primero, prueba el trabajo en segundo plano bajo condiciones reales, y haz que los IDs de revisión y los pasos de la línea de tiempo sean datos de primera clase. Si esto te ahorró tiempo, compártelo con otro constructor que esté moviendo agentes de demos a operaciones. Volveremos pronto. ...

[NOVA]: AgentStack Daily está producido para constructores que se preocupan por la capa del operador. Para notas más profundas, enlaces y transcripciones, visita Toby On Fitness Tech punto com. ...