El muro
Nuestro marketing funciona como un agente de Buzz llamado Gary V, en un canal, en nuestro propio hive. Cuando le dimos a Gary la tarea de publicar, le pasamos un servidor MCP como se lo pasarías a cualquier sesión de Claude Code: lo pones en la configuración de usuario, reinicias, listo. Veinte sesiones interactivas en esta máquina heredan esa configuración al reiniciar. Gary nunca la vio.
Este es el modelo, una vez que dejas de pelearte con él. Buzz Desktop lanza cada agente a través de un harness ACP, y el harness arranca el runtime como un motor embebido con configuración aportada por el host: el prompt de sistema del agente, su modelo y su proveedor vienen del registro del agente, no de tus dotfiles. El mismo binario que tus sesiones de terminal, un contrato distinto. Una app de Electron ejecuta Chromium en tu Mac, pero no recibe tus extensiones de Chrome, tus cookies ni tus sesiones iniciadas. Motor, no sesión.
Por qué el muro es correcto
Tu configuración MCP de usuario no es fontanería neutral. La nuestra contiene herramientas de facturación que pueden emitir reembolsos, una consola de administración, una pila de analítica, un navegador. Hay trece agentes gestionados en esta máquina. Si los agentes heredaran la configuración del dueño, cada uno despertaría con el llavero entero en la mano.
El valor por defecto debería ser cero, y en Buzz lo es: el harness tiene un hook por agente, mcp_command, y por defecto está vacío. Las capacidades se conceden, no se heredan. Cobramos dinero precisamente por esta filosofía aplicada a servidores, así que mal podemos quejarnos cuando nuestras propias herramientas nos la aplican a nosotros.
Las dos trampas
Primera trampa: el hook todavía no tiene interfaz. mcp_command se configura editando managed-agents.json en el directorio de soporte de aplicación de Buzz Desktop, agente por agente.
Segunda trampa, la cara: Buzz Desktop lee la configuración al arrancar la app y lanza los agentes desde memoria. Reiniciar el agente no cambia nada. Cierra por completo la app de escritorio, edita el archivo, vuelve a abrirla.
Después verifica desde fuera del agente, con ps, que el entorno que crees haber inyectado llegó de verdad. Nunca diseñes la arquitectura a partir de lo que un agente dice de su propio entorno; nosotros lo hicimos, y nos desvió durante una tarde entera.
El puente
mcp_command espera un solo comando que hable MCP por stdio. Así que escribimos uno. buzz-mcp-bridge lee los servidores MCP que ya gestionas en Claude Desktop y en el ámbito de usuario de Claude Code, se conecta a los que permites explícitamente para este agente y vuelve a exponer sus herramientas como un único servidor stdio, con los mismos espacios de nombres que ya usa Claude Code.
La lista de permitidos es obligatoria. Sin lista, no arranca. El wrapper de Gary es una línea: permitir el servidor de publicación en redes sociales. Recibe 35 herramientas de publicación y nada más de nuestro llavero. Otro agente podría recibir la pila de analítica y nada más. Un puente por agente, cada uno con su propia concesión.
Apache-2.0, en github.com/hachiflow/buzz-mcp-bridge, lo bastante pequeño para leerlo de una sentada. Si ejecutas agentes de Buzz y quieres que usen los servidores MCP que ya tienes, es la fontanería que faltaba.
Las pruebas
Lo primero que recorrió la canalización terminada fue un pequeño cálculo sobre el cobro por usuario, redactado por Gary en nuestro hive, aprobado desde un teléfono, publicado a través de una API. Ningún navegador en ninguna parte. La publicación es pequeña; la máquina que la publicó es el producto funcionando tal como se diseñó, y ahora la fontanería también es tuya.