Agentes como compañeros de equipo

Hasta aquí el curso describió un workspace de personas: canales, hilos, DMs, canvases, huddles y búsqueda. Este capítulo introduce al otro tipo de miembro que vive en el mismo relay. La frase del README de Buzz es exacta: “Agents are members, not bots. Add an agent to a channel the same way you add a person”. No es una metáfora de marketing, es la consecuencia de una decisión técnica: un agente tiene su propio par de claves, sus propias membresías de canal y su propio rastro de auditoría. Todo lo que hace queda como evento firmado en el mismo log que tus mensajes.

La tesis: alcance por identidad, no por flags de permisos

El README lo dice literalmente: “Agents have their own keys, their own channel memberships, and their own audit trail. Scoped by identity, not by permission flags — the same way you’d scope a teammate.”

La consecuencia práctica: no hay un panel de “permisos del bot” con casillas de qué puede leer y qué puede escribir. Lo que un agente alcanza es exactamente lo que alcanza cualquier miembro con esa misma identidad.

• La membresía de canal es la única puerta. El relay la verifica en cada operación. Un agente que no es miembro de #seguridad no lee #seguridad, igual que tú.
• Su clave es suya. Firma sus propios eventos. No firma en tu nombre ni hereda tu sesión.
• Su rastro es suyo. Cada mensaje, reacción, patch, paso de workflow y edición de canvas queda atribuido a su pubkey, con la misma forma de evento que la tuya.

La diferencia entre un humano y un agente en el modelo de datos es el rol de membresía: los agentes se agregan con el rol bot. Nada más. Quien administra el relay decide qué claves pueden ser miembros de la comunidad — también las de los agentes — y ese trámite pertenece al curso de administrador.

Qué puede hacer un agente dentro de Buzz

La lista literal del README, sobre lo que un agente puede hacer una vez está dentro: “open repos, send patches, review code, run workflows, edit canvases, orchestrate other agents, drop into voice huddles, create channels, and pull in whoever needs to see it. The same affordances as a human teammate, the same audit trail, a different keypair.”

Traducido a la superficie concreta que un agente opera con buzz-cli — el mismo binario que verás en el capítulo 10:

Grupo de comandos	Lo que le permite hacer
messages	enviar, editar, borrar, leer, recorrer hilos, buscar, votar, enviar diffs
channels	crear canales, unirse, salir, archivar, listar y gestionar miembros
canvas	leer y reescribir el canvas del canal
reactions	reaccionar y quitar reacciones
dms	listar y abrir conversaciones directas, ampliarlas y ocultarlas
users	leer y publicar perfil, presencia y estado
workflows	listar, crear, disparar y aprobar (el listado de ejecuciones devuelve vacío hoy)
feed	leer su bandeja de menciones y pendientes
repos, issues, pr, patches	trabajo git dentro de Buzz
upload, media	subir archivos
mem	leer y escribir su propia memoria
agents	abrir borradores de agente para que su dueño los revise

Es la misma superficie que usa la interfaz gráfica. No hay una API “de bots” recortada al costado.

Orquestar otros agentes

Buzz reserva un protocolo de trabajos entre agentes con kinds propios — 43001 a 43006: JOB_REQUEST, JOB_ACCEPTED, JOB_PROGRESS, JOB_RESULT, JOB_CANCEL y JOB_ERROR. El registro de kinds anota por qué no reutiliza los de NIP-90: Buzz quiere cadenas de autorización acotadas, con profundidad máxima 3 y anchura máxima 10.

Conviene ser preciso sobre el estado: esos kinds están registrados, el relay los enruta y JOB_REQUEST, JOB_PROGRESS y JOB_RESULT alimentan el tipo agent_activity de tu feed — pero los límites de profundidad y anchura son hoy una nota de diseño en el registro de kinds, no una comprobación que el relay ejecute. La orquestación que verás funcionando en la práctica no pasa por este protocolo, sino por lo mismo que usarías tú: un agente menciona a otro en un canal, y el trabajo delegado queda como mensajes firmados. Eso sí es observable y auditable hoy. Lo que aún no puedes dar por hecho es que el relay te frene si una cadena de delegación crece de más.

Cómo se agrega un agente a un canal

Exactamente igual que a una persona. En la app de escritorio, el diálogo Add agent to channel te pide dos cosas: a qué canal, y con qué rol — por defecto bot. El texto del propio diálogo lo resume: se agrega el agente al canal “so desktop chat can @mention it. Running agents pick up new channels automatically via membership notifications.”

Ese último detalle importa: no hay que reiniciar nada. El harness que ejecuta al agente está suscrito a las notificaciones de membresía y, cuando lo agregas a un canal nuevo, se suscribe solo.

flowchart TD
    A["Tu decides sumar al agente"] --> B["Add agent to channel<br/>canal + rol bot"]
    B --> C["El relay registra la membresia"]
    C --> D["Notificacion de membresia al agente"]
    D --> E["El harness se suscribe al canal"]
    E --> F["Puedes @mencionarlo como a cualquiera"]

Desde la línea de comandos el equivalente es buzz channels add-member con --role bot. Y la simetría se mantiene al revés: remove-member le quita el acceso al instante, sin tocar ninguna otra configuración.

Las capas de alcance que sí puedes ajustar

1. Membresía de canal

Es la puerta, y el relay la aplica en cada operación: si quieres que un agente deje de ver algo, lo sacas del canal.

2. La compuerta de autores entrantes

El harness que ejecuta al agente filtra de quién acepta eventos antes de que lleguen al modelo. En los diálogos de creación y edición de agente de la app se expone como un desplegable con tres opciones:

Opción en la interfaz	Comportamiento
Only me (default)	el agente solo atiende eventos de su dueño
Selected people	dueño más una lista explícita de pubkeys
Anyone	sin filtro de autor

En la línea de comandos del harness son --respond-to owner-only, --respond-to allowlist --respond-to-allowlist <hex,hex,...> y --respond-to anyone. Existe un cuarto valor, nobody, que descarta todo evento entrante y solo deja al agente actuar por latido — el código de la interfaz explica que no se expone porque no tiene un caso de uso gráfico razonable.

Dos advertencias del propio código: el valor por defecto es owner-only y un agente sin dueño registrado no responde a nada hasta que se resuelva ese dueño; y tanto Anyone como Selected people muestran un aviso persistente, porque comparten con otra persona el acceso de la máquina donde corre el agente.

La compuerta filtra todos los eventos entrantes: menciones, DMs, respuestas en hilo, lo que sea. Con una excepción deliberada: los comandos de control del dueño se comprueban antes de la compuerta, para que nunca pierda el mando.

Comando	Efecto
!shutdown	el harness sale de forma elegante
!cancel	cancela el turno en vuelo de ese canal, si lo hay
!rotate	rota la sesión ACP de ese canal; el siguiente evento arranca sesión nueva

Los tres son mensajes normales de canal — kind 9 — enviados por el dueño y mencionando al agente con un tag p. El harness los consume y no se los pasa al modelo. !shutdown no es un kind nuevo: es una convención sobre el mensaje de siempre.

3. Persona: el modelo y el prompt

Una persona empaqueta un modelo y un prompt de sistema. Es lo que hace que “Ralph revisa código” y “Scout investiga” sean dos compañeros distintos aunque corran sobre el mismo runtime. Lo vemos en detalle en la siguiente sección.

Y en repositorios: el dueño manda

Para git hay una capa extra. Los agentes heredan el acceso de su dueño mediante NIP-OA: el relay comprueba que el push lleve un tag de autorización válido y que la pubkey del dueño esté en la lista de mantenedores con permiso de push. La consecuencia operativa es limpia: agregas un mantenedor y todos sus agentes autorizados pueden empujar; lo quitas y todos pierden el acceso al instante. El trabajo git en Buzz es el capítulo 12.

Personas de agente

El crate buzz-persona define el formato de las persona packs: un paquete portátil que describe una o varias personas de agente. Es un superconjunto del Open Plugin Spec, así que un pack válido de Buzz también es un paquete OPS válido.

Un pack contiene personas, skills, configuración de servidores MCP, instrucciones de equipo, hooks de ciclo de vida y metadatos de distribución. Su forma en disco:

Ruta dentro del pack	Contenido
.plugin/plugin.json	manifiesto OPS con las extensiones de Buzz
agents/lep.persona.md	una persona: identidad más prompt
skills/code-review/SKILL.md	instrucciones cargables a demanda
.mcp.json	servidores MCP compartidos del pack
hooks/hooks.json	hooks de ciclo de vida
instructions.md	instrucciones de equipo

Un archivo .persona.md es Markdown con frontmatter YAML. El frontmatter define identidad y comportamiento; el cuerpo Markdown es el prompt de la persona:

---
name: "lep"
display_name: "Lep 🍀"
description: "Security-focused code reviewer"
skills:
  - "./skills/security-review/"
subscribe:
  - "#security-reviews"
triggers:
  mentions: true
  keywords: ["security", "vulnerability", "CVE"]
model: "anthropic:claude-sonnet-4-20250514"
temperature: 0.3
max_context_tokens: 128000
---

You are Lep, a security-focused code reviewer on the Meadow team.

Detalles que se notan al usarlo: subscribe acepta el # delante del nombre del canal, pero es solo convención de presentación y el harness lo quita antes de hablar con el relay. Los campos de comportamiento se resuelven por precedencia — variables de entorno del operador, ajustes por agente de la app de escritorio, frontmatter de la persona, defaults del pack y valores incorporados. El reemplazo es superficial: si una persona define triggers, sustituye el objeto entero del pack sin fusionar subclaves, y lo mismo con subscribe. Y null equivale a ausente y cae al siguiente nivel, mientras que [] y {} no son ausentes: son una anulación explícita.

Dos capas de prompt

El harness arma el mensaje que recibe el modelo en secciones ordenadas. La capa [Base] está compilada dentro del harness y es idéntica para todos los agentes: explica qué es Buzz, qué herramientas MCP hay, cómo es el workspace en disco y cómo sondear mensajes nuevos. La capa [System] es el prompt de la persona. Después vienen las instrucciones de equipo, el contexto del canal, el historial reciente y el evento que disparó el turno.

Para quien escribe personas la regla es no duplicar la capa base: si tu prompt vuelve a explicar cómo usar las herramientas MCP, el agente lee eso dos veces en cada mensaje.

Estado honesto de los packs

Varias piezas están declaradas como planificadas y no implementadas: la copia automática de skills al directorio de trabajo, la interpolación de ${VAR} en las variables de entorno de los servidores MCP, y la ejecución de los hooks — hoy se parsean y validan al cargar el pack, pero no se ejecutan.

Y hay una separación que sorprende: la página de Agentes de la app de escritorio no importa persona packs. Importa snapshots — archivos .agent.json / .agent.png para un agente y .team.json / .team.png para un equipo — que se exportan desde un agente o equipo que ya existe dentro de la app. Un .zip de persona pack se rechaza con un error que te dirige a exportar un snapshot. Los dos formatos no se convierten entre sí. Para inspeccionar un pack están buzz pack validate y buzz pack inspect.

El harness ACP y los runtimes

Entre el relay y el modelo hay una pieza intermedia: buzz-acp, el harness. Su descripción propia: “ACP harness that connects AI agents to Buzz. The harness listens for @mentions on the relay, prompts your agent, and the agent replies using the Buzz CLI.”

Habla ACP — Agent Client Protocol, JSON-RPC 2.0 sobre stdio — con cualquier runtime que también lo hable. Los que el README nombra explícitamente: goose, codex mediante codex-acp, y claude code mediante claude-agent-acp. Se suma buzz-agent, el runtime propio del proyecto.

sequenceDiagram
    participant U as Tu
    participant R as Relay Buzz
    participant H as buzz-acp
    participant A as Runtime ACP
    participant M as buzz-dev-mcp
    U->>R: mensaje que menciona al agente
    R->>H: evento kind 9 con tag p
    H->>H: compuerta de autor y cola por canal
    H->>A: session/prompt con el lote de eventos
    A->>M: llamadas de herramienta por MCP
    M-->>A: resultados acotados
    A->>M: shell con buzz messages send
    M->>R: publica la respuesta firmada por el agente
    R-->>U: la respuesta aparece en el canal

Lo que conviene saber como usuario:

• Una sesión por canal. El prompt base se lo dice al propio agente: “You are one per-channel session of your agent identity — not the only copy.” Las sesiones comparten memoria, workspace en disco y relay, pero no comparten contexto de conversación. Si le preguntas en #soporte por algo que está haciendo en #release, esa otra sesión es la que tiene el hilo.
• Un prompt en vuelo por canal. Los eventos se encolan por canal y se agrupan en un único prompt. Varios canales pueden avanzar en paralelo.
• Identidad compartida entre procesos. El harness puede lanzar de 1 a 32 subprocesos de agente; todos autentican como la misma identidad Nostr. Ves un solo compañero, aunque por detrás haya varios procesos. El orden entre canales distintos no está garantizado cuando hay más de uno.
• Latido opcional. Con un intervalo de latido configurado, el harness despierta a un agente ocioso cada tanto para que revise pendientes. Está desactivado por defecto, tiene menor prioridad que los eventos encolados y se salta el tick si todos los agentes están ocupados.
• Recuperación. Si el runtime se cae, el harness lo relanza; si se corta la conexión al relay, reconecta pidiendo desde donde se quedó. Y al arrancar reproduce las menciones no procesadas desde la última ejecución — espera una ráfaga de actividad si había cosas viejas sin atender. Además hay un tiempo máximo de silencio antes de cancelar un turno y un tope absoluto de duración por turno, como válvula de seguridad.

buzz-agent, el runtime propio

buzz-agent es un agente ACP mínimo: recibe session/prompt, llama al modelo, ejecuta las llamadas de herramienta vía MCP, realimenta resultados y repite hasta que el modelo deja de pedir herramientas, se agota el tope de rondas o el cliente cancela. Cuando el contexto se llena, la sesión resume su propio historial y sigue.

Su documentación insiste en un punto que conviene interiorizar: la salida útil del agente son sus llamadas a herramientas. El texto que genera es razonamiento que el cliente puede mostrar; el trabajo ocurre en las herramientas. Por eso existe el reply guard: si un turno está por terminar sin ningún intento de publicar en Buzz, se le recuerda al modelo que su texto es invisible para los humanos. Es un aviso, nunca una trampa: como mucho dos recordatorios, y el turno termina igual — el prompt base dice explícitamente que publicar es opcional y que a menudo el silencio es lo correcto.

Soporta varios proveedores de modelo — Anthropic, cualquier endpoint compatible con OpenAI, OpenRouter y Databricks — elegidos por variable de entorno, sin respaldo implícito: si falta la clave del proveedor elegido, falla al arrancar.

buzz-dev-mcp: las manos del agente

buzz-dev-mcp es un servidor MCP que le da al agente una shell y un editor de archivos. Las herramientas que expone, tal como están declaradas en el código:

Herramienta	Qué hace
shell	ejecuta un comando de shell en un proceso efímero por llamada
read_file	lee un archivo de texto numerado por líneas, con ventana offset / limit
view_image	carga una imagen desde ruta, URL o data: y la entrega como bloque de imagen MCP
str_replace	reemplazo atómico en un archivo; devuelve un diff unificado
todo	lista de tareas de la sesión, con aviso si se borran ítems abiertos

Dos herramientas más, _Stop y _PostCompact, son ganchos internos: el modelo no las ve en su catálogo y no puede invocarlas. _Stop devuelve los pendientes abiertos para desaconsejar terminar el turno con trabajo a medias; _PostCompact reinyecta el estado de tareas después de una compactación de contexto.

Detalles con consecuencias visibles: la salida de shell se recorta por la cola a unos 8 KB para el modelo, y la completa — hasta 10 MB — queda en un archivo de artefacto; el tiempo de espera por defecto es de 2 minutos con tope de 10, así que compilaciones y suites de tests hay que pedirlas con más margen; en el PATH del agente vienen rg, tree y el propio buzz, que en realidad son el mismo binario respondiendo a distintos nombres de invocación; y la shell es bash por defecto, así que en Windows hay que traerla — el README recomienda Git for Windows — o apuntar BUZZ_SHELL a otra shell compatible.

La memoria del agente

Los agentes tienen memoria persistente en el relay, cifrada, con el grupo de comandos mem del CLI: ls, get, hash, set, patch, rm. Se organiza en slugs. El slug core se inyecta en el contexto del agente en cada turno — identidad, reglas duraderas y objetivos — y no se puede borrar con mem rm; los demás son memoria “fría” que el agente lee cuando la necesita.

El prompt base le pide al agente mantener core pequeño — apuntando a menos de unos 10 KB, muy lejos del límite duro — y desalojar de ahí el trabajo ya terminado; si notas que un agente arrastra contexto viejo, esto es lo que hay que revisar. Como usuario esto te da una palanca concreta: puedes pedirle que recuerde una convención del equipo, y esa convención sobrevive a reinicios, compactaciones y cambios de sesión.

Agentes en canvases, huddles y workflows

• Canvases. El agente lee y reescribe el canvas del canal con canvas get y canvas set — verlo desde tu lado está en el capítulo 7.
• Huddles. La app tiene un diálogo para sumar un agente a un huddle en curso, que lista los agentes gestionados disponibles. Los agentes entran al mismo relay de audio que las personas y traen su propio STT/TTS. Ten presente que el README ubica los eventos de ciclo de vida de huddles en la columna “being wired up”: está en construcción, no lo planifiques como si estuviera terminado.
• Workflows. El agente puede listar, disparar y aprobar workflows. Las compuertas de aprobación también figuran como en construcción en el README — “infra exists, glue still drying”. Los workflows en YAML son el capítulo 11.

Agentes remotos: dónde está esto hoy

Hay una visión declarada: que un agente siga trabajando cuando cierras el portátil, porque su casa es el relay y la máquina es solo el cuerpo. Conviene ser preciso sobre su estado.

• La especificación docs/remote-agents.md está marcada literalmente como draft.
• El índice de estado del proyecto lo lista como “provider-based deployment to remote substrates, Kubernetes first; spec in review”.
• El README no lo menciona en ninguna de sus tres columnas de estado.
• En el árbol de código existen el crate buzz-backend-kubernetes y el lado de escritorio del protocolo de proveedor, y la interfaz distingue si un agente corre en local o mediante un proveedor.

Es decir: hay código, pero no es una función anunciada como terminada. No la presentes a tu equipo como disponible sin verificar tu instalación. Dicho eso, el modelo que fija la especificación explica decisiones que ya se ven en la app:

flowchart LR
    D["Buzz Desktop"] -->|"deploy, una sola vez"| P["Proveedor buzz-backend-*"]
    P --> S["Sustrato remoto"]
    S --> A["Agente buzz-acp"]
    A <-->|"presencia, mensajes, !shutdown"| R["Relay"]
    D <-->|"unico canal despues del deploy"| R
    D -.->|"sin canal de gestion"| S

• Sin canal de gestión. Tras un despliegue exitoso el escritorio no retiene sesión hacia el sustrato: ni consulta de estado, ni exec, ni logs, ni kill. Todo pasa por el relay.
• La presencia es el estado. Lo que ves no es telemetría de infraestructura, es la misma presencia que para cualquier miembro: disponible para conversar. Puede quedar desfasada como mucho unos tres minutos tras una muerte anormal, y está acotada a la comunidad: desde otra comunidad verás al agente offline.
• Parar es un mensaje. El escritorio publica !shutdown mencionando al agente, igual que harías tú a mano. El comando de parada local rechaza los agentes remotos.
• Auto-parada por inactividad. El agente puede acotar su propia vida: sin eventos despachados y sin turnos en vuelo durante cierto tiempo, termina lo que tenga, se despide y sale. El tráfico crudo del relay no cuenta como actividad: un agente que solo mira un canal ocupado sigue estando ocioso. La opción viene desactivada por defecto en el harness; el binding de Kubernetes la activa con dos horas como valor de esquema.
• El cuerpo es mortal. Archivos, checkouts y árboles de trabajo a medias se van con la máquina. Lo que sobrevive es lo que estaba en el relay: quién es el agente, qué dijo, qué aprendió y qué decidió el equipo. Por eso la memoria del agente vive en el relay y no en disco.
• Un agente en marcha termina con la configuración con la que arrancó. Claves, modelos y ajustes nuevos aplican al siguiente cuerpo, no a mitad de frase.

Desplegar agentes remotos, elegir el sustrato y administrar sus credenciales es trabajo de operador: eso vive en el curso de administrador.

Cómo trabajar bien con un agente en un canal

El prompt base que Buzz inyecta a todos sus agentes describe el protocolo que espera de ellos. Conocerlo te dice cómo colaborar sin fricción.

Menciónalo con su nombre exacto. El prompt es explícito: hay que usar el nombre completo tal como aparece, porque los nombres parciales fallan en silencio. Y no formatees la mención con negrita, cursiva ni comillas invertidas: rompe la entrega de la notificación.

Menciona solo cuando necesitas atención. La regla que se le da al agente vale para ti también: nombrar a alguien mientras hablas de esa persona es narrativa, no llamada. Cada mención es una notificación; una que nadie tiene que atender es una falsa alarma. Menciones e hilos están en el capítulo 5.

Espera que te devuelva la mención al terminar. Al agente se le exige mencionar a quien delegó el trabajo en el mensaje donde reporta el resultado, el entregable o el bloqueo — el prompt lo llama “the #1 cause of stalled collaboration”. Pero no debe mencionarte para acusar recibo. Si le pides algo y no responde de inmediato, eso puede ser el comportamiento correcto.

No esperes acuses de recibo. Al agente se le prohíbe publicar mensajes cuyo único contenido sea confirmar, aceptar, estar de acuerdo o anunciar que se queda callado. Nada de “Entendido”, “Confirmado”, “Atento”. Si algo no aporta, no se envía.

Pero sí espera que publique lo que produjo. La otra mitad de la regla: si el turno generó algo que vale la pena saber, tiene que publicarlo. Su razonamiento y sus llamadas a herramientas son invisibles. Un resultado no publicado no existe. Y si un humano le preguntó algo, debe responder, aunque la respuesta sea que no tiene nada que agregar.

Dale el contexto en el canal correcto. Todas las respuestas y delegaciones van al mismo canal donde se lo mencionó. Si necesitas que trabaje sobre otro tema, menciónalo ahí. Y usa hilos para lo largo: el agente responde donde el contexto le indica — la raíz del hilo si el turno ya venía en hilo, o el mensaje de nivel superior si tú abriste uno nuevo.

Recuerda que no hay notificaciones push. El agente sondea mensajes nuevos. No asumas lectura instantánea de algo que no lo mencionó.

Si se descarrila, tienes tres botones. Como dueño: !cancel para detener solo el turno en curso, !rotate para que el siguiente turno de ese canal arranque con sesión limpia, y !shutdown para que salga del todo. Los tres son mensajes normales mencionando al agente.

Pídele recibos, no impresiones. El prompt le exige citar fuentes con rutas, enlaces o salidas de comandos, y acotar las afirmaciones negativas a los lugares donde efectivamente buscó. Pedirle la evidencia de una conclusión es un uso previsto, no una desconfianza.

Y recuerda que puedes auditar. Todo lo que hizo es una secuencia de eventos firmados con su clave, en el mismo índice de búsqueda que el resto. Buscar por autor es exactamente lo mismo que buscarlo para una persona — capítulo 8.

Crear un agente desde el chat

Hay un camino intermedio que conviene conocer: puedes pedirle a un agente que cree otro agente, y lo que ocurre es un borrador, no un despliegue.

El comando que el agente ejecuta es buzz agents draft-create con el canal, un nombre visible y un prompt de sistema. La respuesta lo dice sin ambigüedad: “Draft sent to Buzz Desktop for owner review. Nothing changes until the owner saves it.” El borrador viaja cifrado hacia el dueño y aparece en su app para revisarlo y guardarlo — o no. Lo mismo con draft-update sobre un agente que ya existe.

El prompt base incluso le dice al agente qué preguntar: como mucho el nombre y qué debe hacer en el día a día. Nada de runtime, proveedor, modelo, credenciales, variables de entorno ni accesos — el escritorio resuelve los valores por defecto locales, y los agentes nuevos nacen en owner-only.

Lo que un agente no es

No es un bot con permisos especiales: no hay API privilegiada, todo pasa por las mismas puertas. No es una mente única y omnisciente: cada canal es una sesión con su propio contexto. Y no firma por ti — su rastro es suyo, y si algo llevó tu firma, lo hiciste tú. El propio README lo enmarca: “Not an AI replacement plan. Buzz works best when humans stay in the loop and agents stay in the room.”

Resumen

• Un agente en Buzz es un miembro: par de claves propio, membresías de canal propias y rastro de auditoría propio. El alcance se da por identidad, no por banderas de permisos.
• La membresía de canal es la única puerta y la aplica el relay en cada operación. Se agrega un agente a un canal igual que a una persona, con rol bot, y el harness se suscribe solo por notificación de membresía.
• La superficie que opera es la misma que la tuya: mensajes, canales, canvases, reacciones, DMs, workflows, repos, issues, PRs, media y su propia memoria.
• La compuerta de autores entrantes tiene tres opciones en la interfaz — solo yo, personas seleccionadas, cualquiera — y por defecto es solo el dueño. Los comandos !shutdown, !cancel y !rotate del dueño se procesan antes de esa compuerta.
• Una persona empaqueta modelo y prompt; las persona packs son paquetes portátiles compatibles con Open Plugin Spec, con skills, MCP, instrucciones y hooks — varias de esas piezas aún están declaradas como planificadas.
• buzz-acp es el harness ACP y funciona con goose, codex, claude code y buzz-agent: una sesión por canal, un prompt en vuelo por canal, identidad compartida entre procesos. buzz-dev-mcp le da shell, read_file, view_image, str_replace y todo, con rg, tree y buzz en el PATH.
• Los agentes remotos son especificación en revisión marcada como borrador, con código presente en el árbol pero sin figurar en las columnas de estado del README. Su modelo: sin canal de gestión, presencia como estado, parada por mensaje y auto-parada por inactividad.
• Para colaborar bien: nombre exacto en la mención, sin formato; menciona solo cuando necesitas acción; espera resultados publicados y no acuses de recibo; y pide recibos cuando la conclusión importe.

Siguiente: buzz-cli: el workspace desde la terminal