Panas: cómo convertir máquinas ociosas en un mercado punto a punto para agentes

Los agentes necesitan infraestructura y cómputo para operar, mientras miles de máquinas potentes se quedan ociosas en los escritorios durante casi todo el día. Si te compraste una Mac mini en la fiebre de OpenClaw a principios de año, lo más probable es que tengas hardware caro prendido solo para clasificar correos y correr tareas pequeñas que desperdician el equipo, cuando esa misma capacidad ociosa podría estar sirviendo a otros agentes y generando dinero.

Mientras casi todos los proyectos de hackathon le ponen una interfaz web encima a una API ajena, Erick Rico y yo quedamos en segundo lugar en el hackathon de la comunidad de Codex en Guadalajara con Panas, un sistema de infraestructura distribuida que levantamos de cero en 24 horas entre dos personas. Como ya teníamos varias Mac con cómputo libre y MCPWire para conectarlas punto a punto, construimos la capa que faltaba para que cualquier agente encuentre una máquina disponible por su cuenta, amarre un precio y ejecute trabajo real sin intervención humana.

Cómo funciona Panas

Panas expone todo ese ciclo a través de MCP para que un agente compre y ejecute cómputo remoto exactamente igual que cuando llama a una herramienta local. El agente descubre un proveedor disponible y obtiene una cotización fija, y luego el proveedor verifica un permiso criptográfico que amarra la solicitud a un modelo, a ciertos límites de trabajo y a un precio antes de aceptar la tarea. Con eso validado, la carga viaja por un túnel cifrado de MCPWire hasta un contenedor gateway que le pasa el trabajo a un segundo contenedor worker aislado en un sandbox con la red apagada, sistema de archivos de solo lectura, privilegios recortados y topes estrictos de recursos, de modo que lo que se ejecuta ahí jamás toca la máquina anfitriona, sus archivos ni su red privada.

Orquestando agentes en paralelo sobre 18 Git worktrees

Levantar un plano de control, un libro contable inmutable, validación de pagos en blockchain, transporte punto a punto y un runtime aislado en Docker en un solo día entre dos personas nos obligó a orquestar múltiples agentes de Codex en paralelo sobre 18 Git worktrees distintos. En lugar de dejar que los agentes se pisaran los archivos, partimos el repositorio según lo que cada rama podía implementar y verificar por su cuenta, uniendo todos los worktrees mediante contratos compartidos en TypeScript para cada estructura de datos que intercambiaban. Así la rama provider validaba el aislamiento de contenedores, la de transport probaba los túneles cifrados entre pares y la de registry verificaba en qué momento dar de baja a una máquina desconectada, avanzando todas al mismo tiempo sin chocar en Git.

Las herramientas MCP del comprador fueron el punto donde todas esas ramas paralelas tuvieron que converger, porque una sola llamada cruza descubrimiento, reservas contables y transporte antes de que el proveedor ejecute nada. Usamos fixtures para avanzar el lado del comprador mientras los demás worktrees seguían en movimiento, y después metimos pruebas de integración diseñadas para romper las entregas de estado entre servicios. Hay un caso que resume lo difícil de hacer esto entre máquinas reales: el proveedor termina el trabajo, el comprador pierde la conexión justo antes de recibir la respuesta y el reintento tiene que recuperar el resultado original y el recibo sin volver a ejecutar el modelo ni cobrar dos veces.

Más allá de la inferencia: un paywall para cualquier herramienta en MCP

Para la prueba en vivo conectamos los cuatro equipos que teníamos en la mesa, y desde uno de ellos un agente descubrió un proveedor disponible por su cuenta, mandó el prompt "Say hello in one short sentence" y recuperó la respuesta con su recibo por $0 en dos segundos. Lo importante de esa prueba no eran las cinco palabras que devolvió el modelo, sino todo lo que ocurrió debajo de una sola llamada: descubrimiento autónomo entre máquinas distintas, verificación criptográfica de presupuesto, un túnel cifrado directo sin abrir puertos, ejecución aislada sin red y un recibo liquidado sin intervención humana. Y aunque usamos proveedores gratuitos para la demo, el paywall y el cobro con USDC en Solana ya están funcionando, así que basta con pasar tu wallet y tu tarifa en los parámetros de arranque para empezar a cobrar en automático.

Usamos Macs simplemente porque era el hardware que traíamos en la mochila y fijamos un modelo ligero para responder rápido en vivo, pero todo el sistema corre sobre Linux y el modelo es configurable, así que si tienes un servidor DGX o una Mac mini con 128 GB de RAM puedes despachar modelos pesados cambiando un solo parámetro. Además, la inferencia fue solo el pretexto para la demo, porque esa misma tubería sirve para exponer una base de datos, dar acceso controlado a un sistema privado o publicar cualquier capa de software para agentes, cobrando cada llamada de forma transparente, segura y anónima. Hoy casi todo el mundo usa MCP apenas para conectar scripts locales en localhost, y en unas cuantas horas demostramos que llevar el protocolo al límite permite operar un mercado completo de cómputo y herramientas entre máquinas reales sin depender de un solo data center.