Los intents de seguimiento enviados a agentes de Claude Agent SDK ahora reanudan la sesión de conversación original en lugar de iniciar una nueva. El ID de sesión se guarda en disco cuando una tarea se completa, por lo que sobrevive a reinicios de Bridge — en el seguimiento, Bridge lo recupera y lo pasa al SDK para la reanudación completa del historial de conversación. Un nuevo despacho (p. ej. RERUN) siempre limpia la sesión en caché, para que nunca reanude accidentalmente una sesión obsoleta.

Cada seguimiento ahora escribe un archivo de entrada numerado en la carpeta de entrada de la tarea antes de enviarse, con el prompt del agente aumentado automáticamente para apuntar al archivo de salida esperado. Para proveedores sin historial de sesión nativo — Codex, Hermes CLI/ACP, Gemini, Copilot — el registro del agente de la ejecución anterior se antepone como contexto, para que el agente sepa qué se hizo ya. Los proveedores con sesiones nativas (Claude Code, Claude Agent SDK) omiten esto ya que el historial ya está disponible.

Las tareas ahora pueden cancelarse desde la interfaz de CTRL NODE mientras siguen ejecutándose, en lugar de tener que esperarlas hasta el final. Bridge le indica al proveedor activo que se detenga inmediatamente — un SIGTERM limpio (escalando a SIGKILL tras 3 segundos si es necesario) para proveedores basados en CLI, y un AbortController o bandera de cancelación para los basados en SDK. Funciona igual en todos los proveedores compatibles.

Cuando un agente encuentra un prompt de permiso que no puede auto-aprobar, la tarea ya no simplemente se estanca o se cancela en silencio — notifica a la interfaz que está esperando entrada, y puedes responder directamente desde la vista de la tarea. Claude Code soporta esto de forma nativa hoy; los proveedores basados en ACP (Copilot, Gemini, Hermes ACP) registran el prompt para visibilidad por ahora, con soporte de respuesta interactiva completo planeado para una futura versión.

Dos modelos adicionales de Claude ya se pueden seleccionar al configurar un agente: claude-fable-5 y claude-sonnet-5, junto al catálogo existente. Elígelos desde el combobox de modelo en cualquier agente de tipo Claude de la misma forma que cualquier otro modelo compatible.

Bridge ahora soporta Hermes como proveedor nativo vía el protocolo ACP (hermes acp). Hermes es fundamentalmente distinto de cualquier otro proveedor soportado: mantiene un hilo de conversación persistente con memoria respaldada por SQLite entre tareas. Las skills que el agente autogenera se acumulan con el tiempo. Cuando envías una tarea de seguimiento, Hermes ya sabe lo que ocurrió en la anterior — sin necesidad de repetir el contexto. Cada agente se asigna a su propio directorio de perfil Hermes aislado (~/.hermes/profiles/{agentId}/) con su propio config.yaml (selección de modelo), SOUL.md (identidad) y enlaces simbólicos de credenciales — agentes con distintos modelos o roles nunca comparten estado.

Las tareas y rutinas ahora soportan un modo Work Directory junto al modo de solo salida existente. En lugar de generar archivos en una carpeta de salida aislada, el agente opera directamente dentro de una carpeta que elijas — un repositorio entero, un directorio de proyecto, o cualquier subárbol en tu máquina Bridge. Puedes acotar su enfoque a archivos o subcarpetas específicas usando el selector de rutas incorporado, o dejarlo abierto para que el agente explore todo el directorio de trabajo. El agente lee el código existente, edita archivos en el lugar, e informa qué cambió — sin necesidad de preparar archivos manualmente.

El binario de Bridge ahora es ctrlnode[.exe] (antes ctrlnode-bridge). Ejecuta ctrlnode --setup para configurarlo de forma interactiva: el asistente pregunta por la raíz de tu workspace y tu token de emparejamiento (desde Ajustes → Bridge en la app), los guarda en <workspace>/.ctrlnode/.env, y persiste BASE_PATH como variable de entorno de usuario — sin necesidad de edición manual de archivos. En ejecuciones posteriores Bridge muestra qué .env cargó y te recuerda --setup si falta el token. Disponible para Windows x64, Linux x64 (AVX2 y baseline), y macOS Apple Silicon.

El scheduler de CTRL NODE se ejecuta en la nube y activa tu Bridge en el momento exacto que configuraste — ya sea que estés en tu escritorio, lejos de tu ordenador, o con la tapa cerrada. Presets soportados: Hourly Daily Weekdays Weekly además de expresiones cron personalizadas completas. Consciente de zona horaria con configuración de offset UTC.

Cuando una rutina se dispara, Bridge envía las instrucciones a tu agente configurado — Claude, Copilot, Gemini, o cualquier otro proveedor conectado. El agente se ejecuta en tu workspace local, lee los archivos de tu proyecto, y escribe sus salidas directamente en disco. Informes, resúmenes, código generado, registros — todo lo que produce tu agente permanece en tu máquina, rastreable con git e inmediatamente utilizable.

Cada ejecución se registra permanentemente: estado (Running, Done, Cancelled), origen del disparo (scheduler o manual), hora de inicio, duración, y el flujo completo de salida de terminal. Puedes abrir cualquier ejecución histórica y leer todo lo que imprimió el agente. Los archivos generados durante la ejecución se listan y enlazan. El panel de historial es accesible desde la página de detalle de la rutina y desde la vista de detalle de ejecución.

Los archivos escritos por el agente durante la ejecución de una rutina se detectan, catalogan y adjuntan al registro de la ejecución. Cada archivo muestra su nombre, tamaño y hora de escritura. Esto te da un rastro de auditoría claro de lo que produjo cada ejecución programada — especialmente útil para informes recurrentes, documentación generada, o cambios de código confirmados por el agente.

No esperes al horario programado. Pulsa RUN NOW desde la página de detalle de la rutina para disparar una ejecución inmediata. La ejecución queda registrada en el historial exactamente igual que una ejecución programada, con el origen del disparo establecido como "manual". Útil para probar nuevas instrucciones, recuperar una ejecución perdida, o generar informes bajo demanda.

Pausa una rutina para detener que se dispare sin eliminarla — útil durante vacaciones, respuesta a incidentes, o mientras iteras sobre las instrucciones. Reanúdala en cualquier momento y el scheduler retoma el siguiente horario programado. Archiva una rutina para quitarla de la lista activa mientras conservas todo el historial de ejecuciones para fines de auditoría.

v2.0 añadió soporte nativo de Bridge para GitHub Copilot vía el protocolo ACP, Google Gemini CLI vía inicio de sesión en navegador o clave de API, OpenAI Codex CLI con aislamiento de sandbox por agente, la API de agente en segundo plano headless de Cursor vía gRPC, y OpenClaw vía token de gateway. Cada proveedor es un ciudadano de primera clase: documentación dedicada de variables de entorno, listas de modelos específicas del proveedor, y guías de configuración individuales en /start/{provider}.

Una nueva página Team muestra cada agente configurado como una tarjeta con estado en vivo: ONLINE (inactivo, listo), RUNNING (ejecutando una tarea con barra de progreso), OFFLINE, o FAILED. Las actualizaciones de estado llegan en tiempo real vía SignalR. La tarjeta muestra la insignia del proveedor, el nombre del modelo, el último heartbeat, y un enlace a la tarea actual del agente si hay una en curso.

El Dashboard te da una visión instantánea de la actividad de tu organización: ejecuciones de pipeline activas con progreso por paso, finalizaciones de tareas recientes por agente, un flujo de eventos en vivo mostrando notificaciones de Bridge, y estadísticas agregadas (ejecuciones totales, tareas completadas, agentes en línea). Todos los widgets se actualizan en tiempo real sin refrescar la página. Diseñado como la primera pantalla que abres para entender el estado de tu entorno de automatización.

Cuando Bridge se conecta, consulta a cada proveedor sus modelos disponibles y envía el mapa a CTRL NODE vía un nuevo mensaje de WebSocket. Los formularios de creación y edición de agente muestran un desplegable de MODELO con búsqueda, poblado desde la lista en vivo. Empieza a escribir para filtrar, pulsa Enter o haz clic para confirmar. Si no se introduce ningún modelo, el proveedor usa su valor por defecto. La lista se acota al proveedor seleccionado cuando se detecta uno.

Cada agente ahora tiene un workspace dedicado en la máquina Bridge. Un archivo AGENTS.md — generado a partir de plantillas almacenadas en la base de datos y personalizable por agente — se inyecta en cada tarea para que el agente conozca su rol, restricciones y herramientas disponibles. Vuelve a ejecutar la consola de Migrations tras editar las plantillas para propagar los cambios a todos los agentes de tu organización.

El runtime de Bridge es completamente de código abierto bajo licencia MIT y se distribuye como binarios precompilados para Windows x64, Linux x64 (AVX2 y baseline), y macOS Apple Silicon vía GitHub Releases. Sin paso de compilación necesario — descarga el binario, configura tus variables de entorno, y ejecútalo. El plano de control de CTRL NODE (API + aplicación web) sigue estando alojado, pero la capa de ejecución es tuya para auditar, bifurcar y extender.

Bridge es un binario único (sin dependencias) que se ejecuta en cualquier máquina que controles — portátil, servidor doméstico, VM en la nube, o estación de trabajo corporativa. Al arrancar establece una conexión WebSocket persistente saliente hacia CTRL NODE, autenticada con un token de emparejamiento que generas en la app web. Sin puertos entrantes, sin reglas de firewall, sin VPN, sin configuración de proxy. ¿Detrás de NAT o dentro de una red corporativa restrictiva? Simplemente funciona. Bridge se reconecta automáticamente al desconectarse y encola comandos durante ventanas fuera de línea.

Diseña automatizaciones complejas en un lienzo infinito: coloca nodos de agente en el escenario, conecta sus entradas y salidas para formar un grafo acíclico dirigido, y asigna un agente distinto a cada nodo. Cuando pulsas Deploy, Bridge activa el flujo de trabajo y comienza a orquestar tareas en orden de dependencia — un nodo no empieza hasta que cada predecesor se ha completado y su archivo de salida está disponible como entrada del sucesor. Cada paso transmite su salida de vuelta al navegador en tiempo real.

El tablero Kanban es la alternativa ligera a los flujos de trabajo: crea una tarea, escribe las instrucciones, asígnala a cualquier agente en línea, y pulsa Run. Las tareas avanzan por cuatro columnas — BACKLOG, INBOX (en cola para Bridge), ACTIVE (el agente está ejecutando), DONE — con actualizaciones de estado en tiempo real vía SignalR. Cada tarea obtiene su propio workspace dedicado y panel de salida para que puedas leer la salida de terminal del agente sin salir del tablero.

Cada byte que el agente escribe en stdout se reenvía por el WebSocket de Bridge y se muestra en el navegador en tiempo real — sin polling, sin retrasos de buffer. El panel de salida renderiza códigos de color ANSI, maneja líneas largas con elegancia, y hace auto-scroll a medida que llega nueva salida. Puedes ver un pipeline de investigación de varias horas ejecutarse paso a paso desde cualquier dispositivo en cualquier red, sin conexión a tu máquina local aparte del socket saliente único de Bridge.

Cada agente en tu Bridge obtiene su propio directorio en el sistema de archivos local. Los archivos creados durante una tarea persisten entre ejecuciones, permitiendo a los agentes acumular contexto, mantener estado, y referenciar salidas previas. Los nodos de flujo de trabajo que se alimentan entre sí comparten archivos vía un manifiesto estructurado de entrada/salida: los archivos de salida del predecesor se preparan automáticamente como entradas del sucesor antes de que el siguiente nodo empiece. El workspace es un directorio normal en disco — puedes abrirlo en tu editor, confirmarlo en git, o compartirlo con otras herramientas.

CTRL NODE está construido multi-tenant desde cero: cada consulta a la base de datos se acota a la organización del llamador vía seguridad a nivel de fila de PostgreSQL, aplicada por OrganizationMiddleware en cada solicitud de la API. La autenticación usa JWTs de Clerk en producción y un modo de bypass para desarrollo local. Ningún dato de una organización puede ser leído por otra jamás — el aislamiento se aplica a nivel de base de datos, no solo a nivel de aplicación.