Agentes con su propia computadora.

Cada agente corre en su sandbox, con su repo y su memoria.
Lo sumás a tu Slack y trabaja.

Sandbox propio
Memoria en git
Tus llaves, tuyas

Un agente prearmado, listo para trabajar

No es un chatbot con plugins: es un rol con su máquina.

Plantillas por rol

Hoy hay dos: un asistente general y un revisor de código. Cada plantilla trae su identidad, sus herramientas y la lista de dominios que ese rol necesita. La instanciás y ya tenés un agente que funciona; desde ahí lo especializás.

Se le habla desde Slack

Responde en el canal donde ya trabajás, en streaming, y va mostrando qué herramienta está usando y cómo le fue. También podés hablarle desde la web.

Memoria que sobrevive al contenedor

Lo que aprende lo escribe en .memory/ y lo commitea a su repo. El sandbox es descartable por diseño; el repo no. Y como es git, su memoria se puede leer, corregir y revertir.

Se escribe sus propias herramientas

Cuando le falta una capacidad, escribe el archivo en tools/, lo pushea y lo usa en los turnos siguientes. Lo único que no toca es su imagen: el Dockerfile lo mantenemos nosotros, a propósito.

Vas viendo qué está haciendo

Cada paso del turno llega a tu pantalla mientras pasa: qué herramienta usó, con qué resultado, y qué le bloqueó la red.

Un turno, por dentro

Herramienta por herramienta, mientras corre.

Memoria durable

Lo que aprende termina escrito en su repo.

Tu API key nunca entra al sandbox. Está probado, no prometido.

La diferencia

Aislado por diseño, no por promesa

El agente corre en su propio contenedor, sin salida a internet salvo la que vos le abrís. La llave que paga el modelo se queda de este lado.

Tus llaves son tuyas

La key vive fuera del sandbox

El modelo lo pagás con tu propia API key, y vive en el proceso que orquesta el turno: nunca dentro del contenedor del agente. Alguien con la única misión de robarla no pudo.

Red cerrada por default

Allowlist por agente, fail-closed

El sandbox no sale a internet. La única puerta es un proxy que deja pasar los dominios de ese agente y nada más; sin configuración válida, no deja pasar nada.

Su memoria es un repo git

Versionada, legible, reversible

Lo que aprende son archivos commiteados, no un vector opaco. Podés leerlos, corregir lo que entendió mal y revertir un aprendizaje como cualquier commit.

Su imagen no la edita él

El Dockerfile es del operador

El agente edita su identidad, sus herramientas y su memoria. La imagen la mantenemos nosotros y el build corre con la red apagada.

Empezá por un agente

Elegís una plantilla, le ponés nombre y ya tenés un agente con su máquina, su repo y su memoria.