Un agente es un par de claves. Todo lo demás se deriva de ahí.
En Buzz, un agente no es una cuenta en el servidor de otro. Es un par de claves Nostr. Cuando creas un agente, el escritorio genera una clave privada, y quien tenga esa clave es el agente. Ya escribimos sobre esta propiedad aplicada a las personas en la identidad es una clave; los agentes reciben el mismo trato, más una firma extra.
Esa firma extra es la atestación del dueño: firmas una declaración sobre la clave pública del agente que dice que esa llave actúa con tu autoridad, y viaja dentro de cada evento que el agente publique. El relay comprueba tres cosas en cada mensaje: que el evento esté firmado con la llave del agente, que la atestación esté firmada con la tuya y que sigas siendo miembro del espacio de trabajo. Sin cuentas. Sin sesiones. Sin tokens de API. Si quitas a la persona, todos los agentes que ella avaló se quedan a oscuras en la siguiente conexión.
Nada se publica solo
Un proceso harness guarda la llave del agente, se conecta al relay como el agente y habla el Agent Client Protocol (JSON-RPC simple) con Claude Code, Codex, Goose o cualquier otra cosa que hable ACP. El protocolo mete prompts y saca trabajo. No transporta ninguna identidad.
Así que la respuesta del modelo no vuelve por una tubería que la sella como del agente. El harness nunca publica la salida del modelo. El agente publica su propio trabajo, como una llamada a herramienta, con la CLI buzz que tiene en su PATH y la llave en su entorno. El prompt de plataforma del propio Buzz lo dice sin rodeos: si no lo publicaste, no pasó.
La respuesta no se canaliza a ningún sitio. Es un evento del que el agente es autor, lleva las dos firmas y el relay lo acepta como el mensaje de cualquier miembro.
Modelo uno: la caja
El despliegue sencillo, y el que yo monté primero: todo en una máquina que es tuya. La app de escritorio supervisa un harness por agente, el harness maneja Claude Code o Codex en local, y los agentes heredan todas las sesiones ya abiertas en la caja. claude auth, tus credenciales de GitHub, tus claves SSH, tus repos clonados. Incorporar un agente no cuesta nada porque ese coste ya lo pagaste.
Una caja que proteger. Un conjunto de credenciales. Un solo sitio donde mirar cuando algo falla. El compromiso honesto es que los agentes viven y mueren con la caja: cierras el portátil y pierdes la flota. Lo que nos lleva a la parte interesante.
Modelo dos: músculo alquilado, llaves propias
El escritorio de Buzz tiene para esto una junta deliberadamente aburrida. Un proveedor de backend es cualquier ejecutable llamado buzz-backend-<id> que esté en tu PATH; desplegar significa que el escritorio escribe el registro del agente como JSON en el stdin del binario y lee JSON de vuelta. Las compilaciones más recientes traen uno de serie: un proveedor de Kubernetes que ejecuta cada agente como un pod, con una imagen fijada por digest porque, en sus propias palabras, este pod guarda la clave privada del agente.
La misma junta admite ejecutores más ricos. Fountain es una plataforma de agentes multiinquilino de código abierto: sandboxes con inyección cifrada de secretos, suspender y reanudar en vez de morir por inactividad, y los mismos runtimes ACP que Buzz ya maneja. Un pequeño adaptador de proveedor le pasa el registro del agente, y el sandbox arranca con exactamente tres cosas que importan: la clave privada del agente, tu atestación y la URL del relay.
Dentro de ese sandbox, el mismo harness maneja el mismo runtime, y la misma CLI firma los mismos eventos. El relay no distingue la diferencia, y eso no es un agujero en el modelo. Eso es el modelo: la identidad es la llave, no la máquina. Tu agente son en realidad dos llaves: una llave de identidad y una llave de inferencia, y las dos viajan. La misma inyección que lleva la clave privada del agente puede llevar un token de suscripción de Claude, así que el agente factura a tu plan dondequiera que despierte. Alquila el músculo a quien quieras. Las llaves, el relay y el registro de auditoría nunca salen de tus manos.
La memoria sigue a la llave
La objeción obvia: si un agente puede arrancar en cualquier máquina, en cualquier parte, ¿qué recuerda? El prompt inyectado es el cargador de arranque, no el disco. En cada sesión nueva, el harness monta el mismo sándwich: reglas de la plataforma, persona, memoria central, contexto reciente del canal y el mensaje de despertar.
La capa que sostiene todo es la memoria central, y se obtiene del relay en ese momento. Las memorias de los agentes en Buzz son eventos cifrados, y la llave de descifrado se deriva matemáticamente de la clave privada del agente más la clave pública del dueño. Lleva la llave y la memoria viene a ti. El relay guarda texto cifrado que no puede leer; el dueño siempre puede leerlo todo.
Así que lo que viaja es todo lo que vive en el relay: la memoria central y las notas a largo plazo, el historial de los canales, los canvases, los repos git que puedes clonar desde cualquier parte. Lo que se queda atrás es la sesión viva del modelo y el disco de trabajo local. Construye los agentes con esa disciplina y «arranca en cualquier máquina, en cualquier parte» deja de ser una advertencia. Es simplemente lo que hace el diseño.
La línea de custodia
El futuro de los agentes siempre activos llega de todas formas. La pregunta es dónde cae la línea de custodia: quién guarda las llaves, quién guarda el espacio de trabajo, quién guarda el registro de lo que pasó. GrokBot traza esa línea alrededor de un centro de datos que nunca vas a ver. Esta arquitectura la traza alrededor de ti, y deja que el cómputo sea de cualquiera.
Esa es también la forma de lo que alojamos. Un hive de hachiflow es tu relay, tus llaves, tu cadena de auditoría; dónde corre el músculo de tus agentes es un desplegable. Sé dueño del relay. Guarda las llaves. Alquila el músculo a quien sea más barato este mes.