Google publica como código abierto Scion, un banco de pruebas experimental para la orquestación de agentes

• Plataforma experimental diseñada para gestionar agentes basados en LLM que se ejecutan simultáneamente dentro de contenedores, tanto en máquinas locales como en clústeres remotos
• Cada agente opera como un proceso aislado con identidad, credenciales y espacio de trabajo independientes, impulsando en paralelo y de forma dinámica distintos objetivos como programación, auditoría y pruebas
• Se define como un "hipervisor para agentes" y adopta una filosofía de aislamiento externo mediante contenedores, worktrees de git y políticas de red, en lugar de inyectar reglas de comportamiento en el contexto
• Integra agentes principales como Gemini CLI, Claude Code, OpenCode y Codex mediante adaptadores harness, y admite Docker, Podman, Apple Container y Kubernetes como runtimes
• Rastrea el ciclo de vida del agente (Phase), la acción actual (Activity) y el estado detallado (Detail) con un modelo de estado tridimensional, y demuestra escenarios de colaboración con una base de código de juego de ejemplo

---

¿Qué es Scion?

• Un banco de pruebas experimental de orquestación para gestionar grupos de agentes basados en LLM que se ejecutan simultáneamente en contenedores, en máquinas locales, VM remotas y clústeres de Kubernetes
• A cada agente se le asignan identidad, credenciales y espacio de trabajo independientes, para ejecutar distintos objetivos como investigación, programación, auditoría y pruebas como un grafo de tareas paralelas que evoluciona dinámicamente
• Google define Scion como un "hipervisor para agentes", e integra la memoria del agente, las salas de chat y la gestión de tareas como intereses independientes (orthogonal)

Filosofía central de diseño: aislamiento por encima de restricciones

• En lugar de limitar el comportamiento del agente con reglas, garantiza la seguridad mediante límites a nivel de infraestructura, como contenedores, worktrees de git y políticas de red
• Los agentes pueden ejecutarse libremente en modo --yolo, mientras que la capa de aislamiento se encarga de las barreras de seguridad desde el exterior
• Gracias a este enfoque, no hace falta inyectar reglas complejas en el contexto del agente, lo que le permite concentrarse solo en su tarea

Conceptos clave (glosario)

Scion usa su propia terminología, por lo que primero hay que entender los siguientes conceptos

• Agent: proceso aislado que ejecuta un bucle de LLM + Harness. Es la unidad básica de ejecución de Scion y cuenta con identidad, credenciales y espacio de trabajo independientes
• Grove: espacio de trabajo del proyecto donde existen los agentes. Corresponde al directorio .scion del sistema de archivos y puede ubicarse en la raíz de un repositorio git o en la carpeta personal del usuario
  • Los Grove basados en git usan UUID v5 (generado de forma determinista a partir de la URL del repositorio), mientras que los Grove nativos de Hub usan UUID v4
• Hub: el plano de control central de la arquitectura de Scion alojada. Actúa como el "cerebro" que coordina el estado entre usuarios, Grove y runtime brokers
  • Gestiona identidad y autenticación basadas en OAuth, guarda en una base de datos central el estado de agentes/Grove/plantillas, despacha comandos del ciclo de vida y ofrece una vista colaborativa mediante un panel web
• Profile: una especificación del entorno de ejecución que define en conjunto un runtime y la configuración de Harness. Al cambiar entre entornos como "Local Docker" o "Production Kubernetes", basta con sustituir el Profile sin modificar la plantilla
• Harness: un adaptador que integra herramientas LLM específicas como Gemini CLI, Claude Code o Codex en el ecosistema de Scion. Permite que comandos genéricos de Scion como start, stop, attach y resume funcionen de manera consistente con cualquier agente
• Template: el plano para crear agentes. Define la configuración base, el system prompt y las herramientas, y se guarda en .scion/templates/
  • Además de las plantillas incluidas (gemini, claude, opencode, codex), se pueden crear plantillas de roles personalizadas como "auditor de seguridad" o "especialista en React"
• Runtime: la capa de infraestructura que ejecuta los contenedores de los agentes. Soporta Docker, Podman, Apple Container y Kubernetes
• Runtime Broker: nodo de cómputo (servidor, laptop o clúster K8s) que se registra en Hub para aportar capacidad de ejecución. Se encarga de gestionar el ciclo de vida del agente, sincronizar espacios de trabajo y transmitir logs

Arquitectura: estructura Manager-Worker

• scion CLI: herramienta del lado del host que orquesta el ciclo de vida de los agentes. También ofrece gestión de Grove (espacios de trabajo de proyecto) y gestión de plantillas (scion templates)
• Agents: ejecutan software de agentes como Gemini CLI, Claude Code y Codex dentro de contenedores de runtime aislados como Docker
• Flujo básico de uso:
  1. scion init — crea el directorio .scion en la raíz del proyecto
  2. scion start <agent-name> "<task>" — ejecuta el agente
  3. scion attach <agent-name> — acceso interactivo a la sesión del agente, o ver la salida con scion logs
  4. scion resume <agent-name> — reinicia un agente detenido preservando su estado

Estrategia de espacio de trabajo: aislamiento con git

El método para dar a cada agente un espacio de trabajo git independiente se divide en dos formas

• Modo local — Git Worktrees: se usa al ejecutar sin Hub
  • Crea un worktree con una rama dedicada en la ruta ../.scion_worktrees/<grove>/<agent>
  • Se monta en /workspace dentro del contenedor, por lo que comparte el mismo historial del repositorio, pero mantiene un directorio de trabajo independiente
  • Al terminar, la fusión se hace manualmente con git merge <agent-branch>
• Modo Hub — Git Init + Fetch: se aplica al usar Hub
  • El broker inyecta SCION_GIT_CLONE_URL, SCION_GIT_BRANCH y GITHUB_TOKEN en el contenedor
  • Dentro del contenedor, sciontool init inicializa el espacio de trabajo, obtiene el repositorio por HTTPS y luego hace checkout de la rama scion/<agent-name>
  • No se requieren credenciales SSH del host; sí se necesita GITHUB_TOKEN
  • Garantiza un comportamiento consistente en todas las máquinas broker, independientemente de si el repositorio existe localmente o no

Mecanismos de aislamiento de recursos

• Sistema de archivos: se monta en el contenedor un directorio home dedicado para cada agente
• Shadow Mounts (tmpfs): se bloquea el acceso a datos de configuración de .scion o a espacios de trabajo de otros agentes mediante shadow mounts tmpfs
• Credenciales: credenciales sensibles como la autenticación de gcloud se exponen de forma limitada solo a ese agente, mediante montajes de solo lectura o inyección de variables de entorno
• Externalización de datos de Grove: los datos de Grove no basados en git y los directorios home de los agentes se externalizan, para que un agente no pueda recorrer (traverse) datos de otros agentes desde el espacio de trabajo

Modelo de estado del agente (3 dimensiones)

El estado del agente se rastrea en tres dimensiones para distinguir entre eventos de infraestructura y el estado cognitivo del agente

• Phase (etapa del ciclo de vida): created → provisioning → cloning → starting → running → stopping → stopped (o error)
• Activity (comportamiento del agente durante running): idle, thinking, executing, waiting_for_input, blocked, completed, limits_exceeded, offline
  • completed, blocked y limits_exceeded son estados "sticky", que se mantienen hasta que el agente se reinicia explícitamente o se detiene
  • blocked lo establece el propio agente e indica que está esperando a que terminen agentes subordinados, evitando que el sistema lo interprete por error como una falla
  • offline ocurre cuando no se detecta el heartbeat del agente durante cierto tiempo, y puede deberse a un fallo al renovar el token de autenticación
• Detail: contexto adicional de la Activity actual (nombre de la herramienta, mensaje, resumen de la tarea, etc. en formato libre)

Sistema de plugins

• Arquitectura de plugins basada en hashicorp/go-plugin, extensible mediante comunicación gRPC
• Plugin de message broker: proporciona un backend personalizado de entrega de mensajes para notificaciones de agentes y mensajería estructurada
• Plugin de agent harness: permite implementar harness personalizados para integrar nuevas herramientas LLM en Scion sin modificar el código base principal
• Actualmente está en una etapa inicial (foundational stage), y se ofrecen implementaciones de referencia para ambos tipos de plugin

[GN⁺]

Comentarios de Hacker News

• Tengo muchas ganas de probar Scion
  Antes probé Gastown del mismo tipo, y aunque los resultados fueron buenos, la variabilidad era alta
  Mis principales quejas sobre Gastown son: (1) es caro, (2) te obliga a usar solo modelos de Claude, (3) es difícil respaldar o conectarse en remoto a la base de datos interna, (4) durante las actualizaciones ocurre con frecuencia pérdida de contexto
  Aun así, logra resultados “mágicos” de conversación y colaboración que otras herramientas del mercado no dan

• El enfoque de Google me parece interesante
  Yo hice una plataforma de orquestación de agentes llamada Optio, diseñada para integrarse con sistemas de tickets como Notion, Github Issues, Jira y Linear, y para que los agentes de código lleguen incluso a fusionar PRs
  Me impresiona que Scion soporte agentes de larga ejecución y comunicación entre contenedores
  Pero yo lo construí sobre k8s, y Scion parece intentar reimplementar su propio control plane, así que soy algo escéptico

• La filosofía de “aislamiento en vez de restricciones” parece ir en la dirección correcta
  Los contenedores dan límites, pero no permiten ver lo que ocurre dentro
  Me pregunto cuánto contexto de ejecución expone Scion. Si no, podrían darse situaciones como el ataque a LiteLLM, donde solo te enteras del daño después de ejecutar

  • Soy el desarrollador principal de Scion
    Hay varios niveles de estado y telemetry
    Básicamente, el sistema de hooks recopila datos y, si hay soporte para OpenTelemetry, los envía a un recolector en la nube
    Parte de la actividad la reportan los propios agentes, y esa información se refleja en el control plane

• El código estaba enterrado en lo profundo de la documentación
  Tuve que buscar el repositorio de GitHub

  • Sí, igual yo; lo había marcado con estrella a finales de marzo y luego me olvidé, pero ahora que lo volví a ver, se ve bastante interesante

• La dirección es parecida a Gastown, pero parece que le faltan algunas funciones clave
  En especial, la función de fórmulas fue un cambio de juego

  • Soy el desarrollador principal de Scion
    Las funciones que faltan son parte del diseño intencional. Scion se parece más a lo que Gastown llama “gascity”: una estructura donde el usuario trae sus propios personajes y definiciones de orquestación
    Si ves este ejemplo, es una orquestación simple basada en Markdown
    Scion cumple el papel de motor de juego, y se está trabajando en portar Gastown sobre Scion

• El proyecto todavía está en una fase experimental temprana, así que me da desconfianza
  Dicen que el modo local es estable, pero los flujos de trabajo basados en Hub están validados en un 80% y el runtime de Kubernetes está verde
  Así que por ahora quizá Gastown sea la mejor opción

  • Me cuesta imaginar que Gastown sea mejor que cualquier otra cosa

• Al ver el título pensé en otro SCION (arquitectura de internet)
  Véase el artículo de Wikipedia

• Quiero experimentar más con agentes, pero en mi empresa solo me pagan Claude Code
  Encima, por el TOS no se puede usar la API para otros fines
  ¿Alguien más está en una situación parecida? El cobro por tokens también se vuelve caro muy rápido

  • Esto básicamente ejecuta Claude Code dentro de un contenedor, así que no viola el TOS

• ¡Está realmente genial! Yo también hice algo parecido hace poco
  Estuve hackeando Parallax y resumí lo relacionado en este blog