La configuración es lo que nadie quiere hacer a clics
Un workspace nuevo implica crear agentes, escribir sus instrucciones, conectar herramientas y definir programaciones. Hacerlo una vez es aceptable. Hacerlo para diez proyectos, o para cada cliente que incorpora una agencia, son horas de formularios.
Por eso hicimos que Waggle pueda manejarse desde el asistente que ya tiene. Hay dos puertas. hachi es una CLI pensada para agentes: siempre JSON por stdout, errores tipados, códigos de salida estables, --dry-run y una puerta --yes para todo lo destructivo. Y hay un endpoint MCP, que expone las mismas herramientas a cualquier cliente MCP.
Ambas están disponibles hoy. Instale la CLI con brew install hachiflow/tap/hachi y ejecute hachi mcp serve para un servidor stdio local. O prescinda de la instalación y use el endpoint alojado en https://api.hachiflow.com/mcp. Las herramientas son las mismas en ambos casos.
Cómo lo usamos nosotros
Conectamos un asistente de programación con IA al endpoint alojado y describimos unos diez proyectos en un solo archivo: un workspace para cada uno, con sus agentes, conectores y programaciones. Le pedimos que ejecutara hachi_plan, leyera el diff y después ejecutara hachi_apply.
Una llamada después había diez workspaces con sus agentes, conectores y programaciones en su lugar. Nadie pasó por diez asistentes de configuración a clics.
Quedaron las credenciales de cada workspace, que es justo lo que debe quedar en manos de una persona. Más sobre esto abajo.
Una agencia, dos clientes, un archivo
Supongamos que una agencia incorpora dos clientes y quiere un agente de bandeja de entrada y uno de informes para cada uno. Primero añada el endpoint alojado a Claude Code y luego inicie sesión en el navegador con su acceso habitual de hachiflow. Es OAuth mediante WorkOS AuthKit, así que no hay que pegar ninguna clave de API.
Después describa el trabajo. La especificación de abajo muestra la forma completa: dos workspaces, dos agentes en cada uno y una programación en días laborables para cada agente de bandeja de entrada. Cada agente lleva el nombre de su cliente, para distinguirlos fácilmente en una lista.
Ejecute primero el plan. No cambia nada e imprime lo que haría apply. Luego aplique. Apply es declarativo y convergente: si se ejecuta de nuevo, informa que no hay nada que hacer, y si se edita una instrucción, se convierte en una sola actualización.
El ejemplo completo. El archivo no contiene nada secreto: los inicios de sesión de los conectores y la credencial del modelo de cada workspace vuelven como traspasos a una persona para que los termine.
El asistente se encarga de la configuración, una persona de los secretos
Apply no finge que puede hacerlo todo. Devuelve una lista de traspasos a una persona, los pasos que solo una persona puede dar: credenciales de conectores, la credencial del modelo de cada workspace e invitaciones. Vuelva a ejecutar plan cuando terminen y debería quedar solo sin cambios.
Los secretos nunca van en el archivo de especificación y nunca pasan por el modelo. Las credenciales viven en custodia y los agentes reciben arrendamientos (leases), nunca los valores. Además se guardan por workspace por diseño. Los clientes de una agencia tienen cada uno sus propias claves y su propio acceso, y una clave única para toda la cuenta difuminaría justamente esa frontera.
Así, el asistente puede encargarse de teclear, y la persona hace la parte que requiere confianza: iniciar sesión una vez en las herramientas de cada cliente.
Por qué encaja con una agencia
La configuración de una agencia es repetitiva por naturaleza. Cada cliente recibe un workspace, algunos agentes con el nombre de ese cliente, el mismo puñado de conectores y una programación matutina. Es una plantilla en la que se cambia un nombre, algo que un agente hace bien.
Con el archivo en control de versiones, añadir un cliente son unas pocas líneas nuevas y un plan para comprobarlas. El asistente de la agencia hace la configuración y las personas de la agencia hacen los traspasos a una persona. Nada cambia en cómo se ejecutan los agentes: siguen ejecutándose en la máquina de la persona a quien pertenecen.
Configurar es gratis, ejecutar agentes no
Una cuenta puede crear workspaces y configurar agentes sin un plan y sin una máquina. Un agente creado así espera hasta que haya un lugar donde ejecutarlo. Solo ejecutar agentes cuesta dinero, porque ejecutarlos consume cómputo.
Lo hicimos a propósito. Un asistente debería poder construirle todo y mostrárselo antes de que a alguien se le pida una tarjeta. Se paga cuando empieza el trabajo, no por la planificación.
Lo siguiente: agentes que contratan el servicio por sí mismos
Esta parte está planificada, no construida. Trabajamos hacia un agente que pueda pagar el servicio por sí mismo mediante HTTP 402, usando los pagos de máquina de Stripe: el Machine Payments Protocol con Shared Payment Tokens. Hemos solicitado ser proveedor de Stripe Projects y figurar en Stripe Directory. Ninguna de las dos solicitudes está aprobada todavía, así que nada de esto funciona hoy.
La segunda mitad es un flujo de reclamación por parte de una persona, también planificado. Un agente lo configura todo, envía un enlace de reclamación y la persona entra a un workspace que es exactamente lo que pidió. Lo único que le queda son los secretos.
Hoy un agente puede hacer la configuración, pero una persona todavía debe crear la cuenta y, para ejecutar agentes, elegir un plan. El objetivo es cerrar esa brecha sin sacar a la persona de las decisiones que importan.
Disponible hoy, y lo que sigue
Disponible: la CLI hachi, MCP local y alojado, plan y apply desde un solo archivo, traspasos a una persona para las credenciales y configuración gratuita. Planificado: agentes que pagan mediante HTTP 402 y el flujo de reclamación. Si dirige una agencia y quiere probar la mitad disponible, el endpoint y el ejemplo de arriba bastan para empezar.