Pizza Bot mete a los agentes en una bandeja de entrada: hilos, no ventanas de chat

Un agente al que no hay que mirar trabajar

El argumento de partida que exponen sus autores es sencillo: encargar a un agente una tarea que merezca la pena delegar obliga a esperar. El agente lee correo, mensajes y lista de tareas antes de responder, y a mitad de camino se detiene porque un paso necesita permiso. Mientras tanto, alguien mira cómo se desplaza una ventana de chat. Eso, escriben, es vigilar a un becario, no colaborar.

Pizza Bot invierte el planteamiento. El usuario lanza una tarea, la programa o deja que la dispare un webhook, y el agente trabaja mientras él hace otra cosa. El trabajo terminado aterriza en la cola 'Unread' (no leídos) y lo que depende de una decisión humana cae en 'Action' (acción). La tercera cola, 'All', es el histórico de hilos.

La elección del correo como metáfora es deliberada: un hilo es una unidad de trabajo a la que se vuelve, no una sesión a la que hay que asistir. El chat en vivo, sostienen los autores, da por hecho que las dos partes están presentes, algo que se rompe en cuanto una tarea tarda varios minutos o se ejecuta de madrugada. Junto a las colas, un panel 'Activity' muestra el trabajo que el agente principal ha delegado en un especialista, con la transcripción de ese especialista incluida.

Lo que no es: ni servicio, ni soporte, ni SLA

Conviene fijar este punto antes que ningún otro, porque el anuncio salió en un blog de AWS y eso induce a error. El propio texto lo advierte sin rodeos: Pizza Bot es un proyecto comunitario y no un servicio de AWS, así que no hay soporte de AWS ni acuerdo de nivel de servicio detrás. Mantenerlo en marcha, con copias de seguridad y actualizado, corre por cuenta de quien lo despliega.

El proyecto se distribuye bajo licencia Apache 2.0 y se ejecuta en la máquina del usuario. No envía telemetría y funciona con el proveedor de modelo que se elija: Anthropic, Amazon Bedrock, Google Gemini, OpenAI, OpenRouter o un modelo local a través de Ollama.

Su origen sí está dentro de Amazon. Versiones anteriores las usaron más de 2.000 personas para preparar reuniones y hacer seguimiento, redactar correos, resumir Slack, registrar apuntes en el CRM, priorizar el día y buscar en la web. El nombre remite a los 'two-pizza teams' de la casa, equipos pequeños con responsabilidad amplia. El equipo reescribió la aplicación desde cero como proyecto abierto.

Esa reescritura tiene un coste declarado. Buena parte de la utilidad inmediata dentro de Amazon venía de un catálogo interno de skills y servidores MCP para los sistemas que allí se usaban a diario; estaban construidos contra herramientas propias de Amazon y se quedaron fuera. Los autores señalan ese hueco como el punto donde más ayuda externa necesitan.

Servidor, cliente y trabajo que sobrevive al cierre

Pizza Bot se reparte en dos piezas: un servidor que ejecuta el agente, guarda su estado y responde por HTTP, y un cliente, que puede ser la aplicación de escritorio en Electron, un navegador o un terminal. La aplicación de escritorio envuelve ambas cosas: arranca un servidor local propio y se conecta a él igual que lo haría un cliente desde otra máquina.

Como el trabajo vive en el servidor, una ejecución continúa aunque se cierre el hilo, se recargue la página o se cambie de dispositivo, y un cliente que vuelve a conectarse recupera lo que se perdió. Puesto el servidor en una máquina siempre encendida o en un contenedor, se llega a los mismos hilos desde un portátil, un móvil o una consola. La contrapartida: salir de la aplicación de escritorio detiene el servidor que ella misma levantó y termina sus ejecuciones; al estar la ejecución registrada por pasos, se pierde el paso en curso, no el hilo.

Todo lo que importa queda en una sola carpeta bajo control del usuario —hilos, puntos de control, memorias, adjuntos, ajustes y registros— como bases de datos SQLite y ficheros corrientes. Se copia con el servidor parado o con una herramienta capaz de leer una base SQLite en uso.

Skills, MCP y permisos que se piden antes, no después

De fábrica el agente ya hace trabajo real: lista, lee, escribe, edita y busca ficheros en un espacio propio, delega mediante la herramienta 'task' y ejecuta un intérprete de JavaScript aislado, sin red ni acceso al sistema de ficheros del anfitrión, para cálculos, análisis de datos y lanzar varias tareas a la vez. El disco del usuario queda fuera de alcance hasta que se concede acceso a una carpeta, y cada concesión es de solo lectura o de lectura y escritura, a elección. Las memorias también son opcionales: al activarlas, el directorio /memories/ persiste entre hilos y se puede editar desde la aplicación.

Más allá de eso, todo llega vía servidores MCP, y las skills deciden quién puede llamar a qué. El agente con el que se conversa es un generalista; los especialistas salen de las skills, un fichero SKILL.md por cabeza, con sus instrucciones y una lista corta de herramientas MCP. La skill de automatización de navegador que viene incluida, por ejemplo, recibe un navegador y ninguna otra herramienta. Mantener corta esa lista es justamente el objetivo: acota la tarea delegada y hace revisable de un vistazo hasta dónde llega el agente.

Una skill también puede exigir aprobación antes de ejecutar herramientas concretas y decidir qué respuestas se admiten. En el fichero SKILL.md, 'tools' enumera las herramientas MCP permitidas e 'interruptOn' define la política de aprobación por herramienta; dentro de ella, 'allowedDecisions' fija los botones disponibles. Merece la pena reparar en la opción 'edit', que permite corregir lo que el agente propuso en lugar de rechazarlo y rehacer la ejecución entera.

Las tareas recurrentes se gestionan desde una pantalla de automatizaciones, con programaciones cron y webhooks protegidos por secreto, una vez activada la función en los ajustes. El servidor es el dueño del planificador y registra cada ocurrencia; cuando arranca tras haber estado apagado o suspendido, ejecuta una sola vez la programación que se saltó en lugar de reproducir todas las que perdió. Una máquina apagada un mes devuelve un resultado, no treinta.

El perímetro de seguridad, según el proyecto

La documentación del proyecto delimita qué sale de la máquina: Pizza Bot envía las instrucciones y los adjuntos al proveedor de modelo elegido, y las llamadas de herramienta a los servidores MCP que se hayan activado. Ahí está el aviso importante que hacen los propios autores: esos servidores pueden actuar en nombre del usuario, algo que conviene recordar en el momento de instalar uno. Instalar un servidor MCP o un plugin significa ejecutar código con los permisos de quien lo instala, y por eso la aplicación lo convierte en una decisión explícita y no en un efecto colateral.

Las credenciales del proveedor se entregan al almacén de secretos del sistema operativo en lugar de quedarse en un fichero de configuración en texto plano, y nunca se envían a un cliente de navegador. Por defecto el servidor solo escucha en la máquina local; un despliegue que deje de ser local exige un token de API y una lista explícita de orígenes permitidos, y sin ambas cosas no atiende a un cliente remoto. El fichero SECURITY.md documenta el perímetro completo y la vía para notificar una vulnerabilidad en privado.

Conviene leer estas garantías por lo que son: descripciones del propio equipo que mantiene el proyecto, no el resultado de una auditoría externa.