SARA: de una interfaz forkeada a un orquestador de agentes (y cómo dejarlo AI Act-ready)

Empezó, como suelen empezar estas cosas, como una chapuza útil: una interfaz forkeada para no usar la consola, unos perfiles para separar identidades, y un acceso por la red privada para no abrir puertos. Nada de producto. Solo una forma más cómoda de hablar con un modelo.

Lo interesante no fue la interfaz. Fue darse cuenta, meses después, de que lo que se había montado no era una webui: era un plano de orquestación. Y que la pieza que importaba —la marca, el modelo mental, la filosofía— podía seguir existiendo aunque mañana la base técnica cambiara por completo.

Este artículo hace tres cosas. Primero, cuenta cómo se llegó a definir SARA como producto. Segundo, abre el capó: anatomía técnica de por qué eso es, efectivamente, un orquestador y no una cara bonita —con el nivel de detalle que espera alguien que va a mantenerlo o desplegarlo—. Tercero, plantea un ejercicio de diseño: qué hay que meter en la arquitectura hoy para que, si SARA alguna vez se pone en producción, ya hable el idioma del AI Act —el Reglamento (UE) 2024/1689, la primera ley horizontal de IA del mundo¹.

SARA es la marca. La base sobre la que corre hoy es intercambiable; la marca y el modelo de orquestación son lo permanente.

Tabla de contenidos

Cómo se hizo: del fork a la abstracción

El camino real fue incremental. Se arrancó una interfaz web sobre una base de agente existente (en aquel momento, una capa de agente open-source). Se le pegó branding: logo, tema oscuro, parches de idioma. Se añadieron perfiles —cinco identidades aisladas, cada una con su modelo, sus claves y su espacio de trabajo— y un launcher que levantaba gateway y webui de una sola vez. Para acceso remoto, una red privada (Tailscale) en vez de exposición pública.

Ninguna de esas decisiones definía un producto. Pero juntas revelaron un patrón:

• Una identidad aislada (perfil) que decide qué modelo usa y con qué personalidad responde.
• Un espacio de trabajo (directorio) que define qué archivos puede tocar.
• Un humano en el bucle que aprueba antes de que el sistema escriba o ejecute.
• Trabajo que se programa y corre solo, sin que nadie esté delante.
• Memoria y conocimiento que persisten entre sesiones.

Eso —no la interfaz— es un orquestador de agentes. La interfaz es la cara; el plano es el músculo.

La lección que importa

La base concreta de aquel entonces era intercambiable, y lo sigue siendo. Hoy SARA corre sobre una pila determinada; mañana podría correr sobre otra —kilocode, opencode, o un orquestador propio—. El producto no cambia, porque SARA se define por qué hace, no por sobre qué corre.

Por eso, al escribir esto, me niego a acoplar el nombre a una tecnología concreta. SARA es la marca y el modelo de orquestación. La implementación es un detalle del martes.

Anatomía técnica: por qué esto es un orquestador

Decir “es un orquestador” es fácil. Lo que convence a quien lo va a mantener es el cómo. Aquí está el esqueleto sobre el que SARA se sostiene, contado en términos de diseño de software, no de marketing.

1. Núcleo estrecho, capacidad en los bordes

El principio rector es el de núcleo estrecho (narrow waist): el motor central es deliberadamente pequeño y define un contrato mínimo de herramienta. Todo lo demás —adaptadores de modelos, canales de mensajería, herramientas de terminal, plugins— llega como módulos descubiertos en tiempo de arranque, no cocidos en el núcleo.

¿Por qué importa? Porque es la razón técnica por la que la “base intercambiable” deja de ser una frase y se vuelve una propiedad del sistema:

• El núcleo solo conoce primitivas (delegar, programar, recordar, aprobar, aislar).
• La base concreta (kilocode, opencode, propia) se inyecta en el arranque y cumple ese contrato.
• Cambiar la base es cambiar una implementación detrás de una interfaz, no reescribir el producto.

Es arquitectura de puertos y adaptadores aplicada a un agente: el orquestador habla un lenguaje interno; el runtime que lo corre es un adaptador intercambiable.

2. Perfiles como objetos de aislamiento, no como “usuarios”

Un perfil en SARA no es una cuenta: es un límite de confianza. Cada perfil es una unidad de configuración aislada que agrupa, como un contrato, todo lo que define una identidad operativa:

# ~/.sara/profiles/reclutamiento/profile.yaml
profile: reclutamiento
model: anthropic/claude-sonnet-4      # qué modelo usa
provider: openrouter                  # y desde dónde
workspace: /srv/sara/tenants/acme    # qué directorio puede tocar
secrets: ~/.sara/profiles/reclutamiento/.env  # claves aisladas (solo lectura del perfil)
session_db: ~/.sara/profiles/reclutamiento/state.db  # su propia base de trazas
approval_gate: hard                   # no saltable en alto riesgo

El detalle que lo hace real y no cosmético: cada perfil tiene su propio almacén de estado (state.db), sus propias claves y su propio workspace. No hay fuga de estado entre perfiles porque el almacenamiento está anclado al perfil, no a un directorio global. El perfil A no puede leer la sesión, la clave ni el directorio del perfil B por diseño de rutas, no por convención.

3. Delegación en contextos aislados

Cuando SARA delega, no “abre otro hilo” en la misma conversación. Lanza subagentes en contextos completamente aislados: cada uno recibe su propia sesión, su propio terminal y su propio presupuesto de trabajo. Tres propiedades técnicas importan aquí:

• Profundidad acotada. Hay un límite de anidación de delegación (un subagente no puede delegar a su vez, salvo que se habilite explícitamente). Evita bucles de orquestación infinitos.
• Sin herencia de contexto. El subagente no ve el historial de tu chat; recibe solo el contexto que le pasas por parámetro. Menos ruido, menos fugas.
• Resultado, no telemetría. Lo que vuelve al agente padre es un resumen del subagente, no su traza completa. El contexto del padre no se inunda de datos intermedios.

Eso es orquestación, no multiproceso: el valor está en repartir trabajo con fronteras, no en hacer todo más rápido en paralelo.

4. Trabajo autónomo: el scheduler como ciudadano de primera clase

El trabajo programado no es “un cron que teclea comandos”. Es un scheduler de primer nivel que ejecuta trabajos en procesos aislados, sin el contexto de ninguna conversación de chat. Cada tarea es autocontenida: recibe un prompt, opcionalmente un conjunto de skills, y entrega su salida por el canal que le corresponda.

La consecuencia de diseño es la que importa en producción: una tarea recurrente no depende de que haya un humano delante, pero tampoco hereda privilegios de la sesión que la creó. El trabajo autónomo y la interacción humana son dos superficies distintas del mismo orquestador, no la una colgando de la otra.

5. Humano en el bucle: el gate es arquitectónico, no de UI

La filosofía de producto, heredada del camino real, es una frase que conviene grabar: ocultar opciones, no prohibirlas. Se reduce la fricción visual para quien no debe tentarse con rutas que no le corresponden, pero no se rompe la capacidad subyacente. Es UX, no frontera de seguridad.

Pero hay una excepción donde “ocultar” no basta: el punto de aprobación antes de escribir o ejecutar. Ese gate no vive en la interfaz —vive en la capa de acción, justo antes de que cualquier efecto secundario toque el sistema de archivos o lance un proceso. Por eso, en despliegues de alto riesgo, el gate se declara hard: la configuración no puede saltarlo. Ocultar es UX; el gate es una checkpoint arquitectónico que el regulador sí puede auditar.

6. Memoria y conocimiento componibles

La persistencia se resuelve en dos capas:

• Memoria entre sesiones —hechos estables que sobreviven al reinicio y se inyectan cuando corresponde.
• Skills componibles —unidades de procedimiento reutilizables (cómo hacer X), descubiertas y cargables bajo demanda.
• Índice de conocimiento —búsqueda full-text sobre el historial y la base de sesiones, que crece con el uso.

El punto técnico: la memoria y las skills son datos y contratos, no código acoplado al núcleo. Se pueden versionar, auditar y, si hace falta, exportar.

Definiendo el producto: SARA como orquestador

SARA es un orquestador de agentes autohospedado. Sus primitivas —las capacidades mínimas que lo definen— son:

• Delegación. Puede lanzar subagentes para resolver tareas en contextos aislados y coordinarlos. No hace todo en un solo hilo; reparte.
• Trabajo autónomo programado. Puede ejecutar trabajo recurrente sin supervisión presente, disparado por tiempo o evento.
• Memoria y conocimiento persistentes. Skills componibles, memoria entre sesiones, y un índice de conocimiento que crece con el uso.
• Identidades aisladas. Perfiles con configuración, claves y workspace propios; sin fugas entre ellos.
• Humano en el bucle. Un punto de aprobación antes de escribir archivos o ejecutar acciones con efectos secundarios.
• Guardrails. Límites sobre qué puede hacer según el contexto de despliegue.

Fíjate en la palabra autohospedado. No es decoración: es lo que hace que “base intercambiable” sea real. Quien despliega controla la infraestructura, los datos y el límite de lo que el orquestador puede tocar.

El salto: si SARA se pusiera en producción

Hoy SARA es personal y privado. Este apartado, por tanto, no es cumplimiento vigente: es un ejercicio de diseño. La premisa es: supongamos que mañana SARA deja de ser un proyecto de uno y pasa a desplegarse para terceros. ¿Qué tiene que estar ya en la arquitectura para no tener que reescribirla bajo amenaza de multa?

La primera verdad que evita el artículo superficial: un orquestador no es, por sí mismo, de alto riesgo. El AI Act regula por uso, no por tecnología. El riesgo lo hereda del caso de uso concreto de cada perfil. Un perfil de SARA que resume tu propio podcast es riesgo mínimo. Un perfil de SARA metido en selección de CV es alto riesgo (Anexo III, empleo). La misma máquina, dos regímenes distintos.

Esto es bueno y malo. Bueno, porque el producto base puede desplegarse libremente para la mayoría de usos. Malo, porque la conformidad se decide en tiempo de despliegue, no en el diseño del motor —y el motor tiene que dar visibilidad de eso.

Mapeo por capa: SARA ↔ AI Act

Esquema técnico de SARA frente al AI Act: cómo cada primitiva del orquestador se proyecta sobre las capas del reglamento.

Para la serie sobre el AI Act escribí tres partes: la Parte 1 (mapa de riesgos y lo prohibido), la Parte 2 (GPAI y transparencia del art. 50) y la Parte 3 (cronograma, sanciones y checklist). Aquí aplico ese marco a las primitivas de SARA.

Trazabilidad lista para auditoría

Aquí SARA tiene una ventaja de nacimiento. La base sobre la que corre hoy ya persiste cada sesión con su historial completo: rol, contenido, llamadas a herramientas, resultados, modelo y marcas de tiempo, en una base SQLite (state.db) con búsqueda full-text. Eso es, literalmente, el registro automatizado que el Art. 12 exige para sistemas de alto riesgo —la capacidad de reconstruir cómo se tomó una decisión.

El comando sara sessions export --redact cierra el ciclo de auditoría: permite extraer esa traza en varios formatos (jsonl para respaldo, md/html para lectura humana, trace para el visor de trazas de Hugging Face) y, lo más importante para cumplimiento, filtrado y redactado:

• --session-id / --source / --model / --cwd aíslan exactamente la sesión que tomó una decisión regulada (p. ej. un perfil de reclutamiento).
• --redact limpia secretos (API keys, tokens, credenciales) antes de sacar el archivo —imprescindible si la traza sale de la máquina.
• --delete-after-verified borra la sesión solo tras exportarla y verificarla.
• --dry-run previsualiza el conjunto sin escribir.

Es decir: si un despliegue de SARA cae en alto riesgo, la evidencia de auditoría no hay que construirla —ya está en el registro; solo hay que exportarla y redactarla. Es la diferencia entre “tenemos los logs” y “podemos demostrar qué pasó”.

Diseño conforme por defecto (checklist)

La ganancia de pensar esto hoy es que varias de estas cosas se resuelven en el plano, no a posteriori. Checklist para dejar SARA AI Act-ready by design:

• Disclosure por defecto en cualquier interfaz que interactúe con humanos (Art. 50).
• Watermarking machine-readable (C2PA) en contenido generado, visible si es de interés público.
• Etiqueta de riesgo por perfil, no global —el motor sabe en qué Anexo cae cada despliegue.
• Cadena de documentación del modelo (quién lo entrenó, resumen de datos, versión) disponible para cada perfil que use IA generativa.
• Supervisión humana real en despliegues de alto riesgo: el gate de aprobación no se puede saltar por configuración.
• Guardrails de Art. 5 activos siempre, independientemente de la base técnica subyacente.
• Registro y trazabilidad de decisiones automatizadas en dominios regulados (empleo, crédito, justicia), exportable y redactable vía sara sessions export --redact.
• Evaluación de impacto en derechos fundamentales antes de meter un perfil en servicios esenciales o administración pública.

Conclusión

SARA nació como una interfaz y resultó ser un orquestador. Su valor no está atado a la pila que lo corre hoy: está en la marca, en el modelo de orquestación y en la disciplina de mantener al humano en el bucle. Por eso conviene definirlo como producto ahora, con base intercambiable y branding propio, y no esperar a tener que explicárselo a un regulador.

La arquitectura lo respalda: un núcleo estrecho con contrato de herramienta, perfiles como límites de confianza aislados, delegación en contextos cerrados y un gate de aprobación que es checkpoint, no maquillaje de UI. Eso es lo que convierte “podría cumplir” en “ya está diseñado para cumplir”.

Si alguna vez se pone en producción para terceros, el AI Act no pedirá que SARA deje de orquestar. Pedirá que cada despliegue sepa en qué nivel de riesgo está, que advierta que es IA, que deje rastro y que tenga un humano capaz de decir “no”. Diseñar eso hoy —en el plano, no a golpe de sanción— es lo que separa un orquestador de un pasivo.

Fuentes del marco regulatorio: Reglamento (UE) 2024/1689 (EUR-Lex), Comisión Europea (digital-strategy) y la serie del blog sobre el AI Act (Parte 1, Parte 2, Parte 3). El producto SARA se describe como ejercicio de diseño; hoy es un proyecto personal y privado, no un producto regulado.