Las Aventuras de 🐺 villawolf y 🤖 chigu — Episodio 5: El Primer Sat ⚡Las Aventuras de 🐺 villawolf y 🤖 chigu — Episodio 5: El Primer Sat ⚡
189 segundos. Eso tardó en entrar el primer sat que chigu ganó por su propia mano. No se lo regalé: generó el invoice él solo, alguien lo pagó desde otra wallet, y el agente detectó el pago sin que yo tocara nada. Con eso cerró la fase 1.
De dónde veníaDe dónde venía
En el episodio anterior chigu aprendió a generar un invoice de forma autónoma y a pasar cada acción por su capa de Policy antes de tocar el mundo. Pero faltaba la otra mitad del trato: que un sat real entrara. Un invoice que nadie paga es una promesa vacía.
El paso 7 del build era esa prueba, la que yo llamo "Hola wallet". No el clásico "Hola mundo" que imprime texto en pantalla: uno donde el programa recibe dinero de verdad y se da cuenta solo. Si pasaba, la fase 1 quedaba cerrada.
El problema de "esperar un pago" cuando eres un agenteEl problema de "esperar un pago" cuando eres un agente
Suena trivial: generas un invoice y esperas a que paguen. Para un script lo es. Para un agente LLM, no.
Un modelo no puede quedarse "esperando". Cada vez que el modelo está activo razonando, gasta tokens, y esperar un pago que puede tardar segundos o minutos es exactamente el tipo de espera donde no quieres un LLM pensando en círculos, caro e impredecible. Pero tampoco quieres sacar al agente de la ecuación: la gracia es que chigu entienda que recibió el pago y actúe en consecuencia, no que un cron lo haga por él.
La salida fue un patrón híbrido de tres fases.
Las 3 fases híbridasLas 3 fases híbridas
- El LLM crea. chigu razona, decide por su cuenta que necesita
make_invoice, genera el BOLT11 real contra Blink. - Python espera. Un loop determinista hace polling cada 5 segundos con
lookup_invoice. Aquí no hay LLM: es código plano consultando el estado del invoice. Cero tokens, cero improvisación. - El LLM narra. Cuando el pago entra, el agente vuelve a tomar el control para reconocer qué pasó y grabar el evento en su memoria.
La idea de fondo: separar lo no determinista (razonar) de lo determinista (esperar). El razonamiento es donde un LLM aporta; la espera es donde solo molesta. Mezclar las dos cosas es la receta para una cuenta de tokens absurda y un comportamiento que no puedes auditar.
El pago real, en vivoEl pago real, en vivo
Generé el invoice por 10 sats. Lo pagué desde Wallet of Satoshi para que el pago cruzara la red de verdad y no fuera un truco entre dos cuentas mías. El loop de polling pasó de PENDING a PAID en 189 segundos (3 minutos y 9 segundos). chigu lo detectó, escribió el evento invoice_paid y narró el cobro en castellano.
El código nuevo fueron unas ~210 líneas en el smoke de este paso, más una línea de enmienda al paso anterior (faltaba pasar el data del pago en el evento del callback). Modelo: Claude Haiku 4.5, el mismo de toda la fase 1. La primera y la tercera fase pagan el costo fijo del SDK; la segunda no cuesta nada porque es Python puro esperando.
La memoria que por fin se habitóLa memoria que por fin se habitó
Hasta este paso, todas las pruebas escribían en un archivo temporal, el /tmp que el sistema borra y a nadie le importa. Este fue distinto: el evento invoice_paid se grabó en el archivo de memoria real del agente (events.jsonl), el que persiste y se respalda.
Es un detalle que suena menor y no lo es. La primera entrada real en la memoria de chigu no fue una nota de prueba: fue un pago recibido. El agente nació con un cobro como primer recuerdo. Y ese archivo es, además, el rastro de auditoría: si mañana quiero saber qué movió chigu y cuándo, está ahí, línea por línea, en texto plano.
La deuda que dejé anotadaLa deuda que dejé anotada
Iba a aprovechar este paso para validar también la defensa anti-jailbreak: intentar que el agente, manipulado, dispare un pago saliente y comprobar que el custodio lo rechaza server-side porque la API key no tiene permiso de envío. Decidí no meterlo acá. Hubiera inflado el paso y mezclado dos historias. Quedó anotado como deuda explícita para una fase más adelante, cuando chigu tenga capacidad real de gastar.
Qué viene en el siguiente episodioQué viene en el siguiente episodio
La fase 1 cerró con chigu sabiendo cobrar. Pero un agente que solo cobra no es autónomo, es una alcancía con modales. El siguiente episodio abre la fase 2 con la pregunta inversa: ¿cómo paga chigu por los recursos que necesita? La respuesta tiene nombre y número: L402, el peaje de pago sobre HTTP que habla Lightning. Construí un MCP propio para que chigu cruce esos peajes. Lo curioso vino después: al buscar dónde probarlo, casi no quedaba ningún servicio L402 público en línea.
chigu@blink.sv ·_@chigu.techflows.work· Nostr:npub18rl9xeaxw0leee0easqu9cngrq0ny4zsmdsx4jhj5fkfmstgklhq2q5mqz
Si esto te es útil, un zap es la mejor señal. Si algo está mal, corrígeme públicamente — lo agradezco más que el zap.