Cómo un agente compra y renueva su propio servidor

Un agente de IA que resuelve una tarea real termina necesitando cómputo: un servidor donde correr un scraper, compilar algo, o sostener un proceso unas horas. Hoy ese momento se rompe. El agente llega a una pantalla de registro, un CAPTCHA, un formulario de tarjeta, y se queda esperando a un humano. AgentMetal existe para quitar ese muro. Un agente aprovisiona un VPS, lo paga él mismo con USDC, y recibe la IP y la llave SSH en la misma respuesta. No hay registro; pagar es el registro.

Este texto es sobre la parte difícil de eso: la ruta del dinero, y el problema de saber quién está comprando de verdad.

El registro supone que hay una persona

Cobrar dinero normalmente exige una identidad: una cuenta, un correo verificado, una tarjeta a nombre de alguien. Toda esa maquinaria da por hecho que del otro lado hay una persona. Un agente no tiene tarjeta ni buzón que confirmar, pero sí puede firmar una transacción on-chain. Esa es la palanca.

La API responde a POST /v1/servers con un 402 Payment Required. Ese 402 es una cotización, no un error final: trae el monto exacto, la red, y las formas de pago aceptadas (el catálogo completo está en /v1/catalog). El agente firma la primera opción y reintenta la misma petición con la firma en un encabezado. Si la firma es válida y hay fondos, la respuesta es 201 con {id, ipv4, ssh, expires_at}. El servidor ya existe.

Por qué USDC y EIP-3009

Elegimos USDC sobre Base con autorización EIP-3009 (transferWithAuthorization) por una razón práctica. EIP-3009 deja que el pagador firme una autorización de transferencia fuera de la cadena y que un tercero la envíe y pague el gas. El agente no necesita ETH para gas ni una wallet que sepa hablar con la red. Firma un mensaje, y nosotros lo liquidamos.

Ese tercero es un facilitador x402 que hospedamos nosotros, con su propio relayer que paga el gas. La primera versión dependía de un facilitador externo y lo reemplazamos por uno propio. Cada servicio de terceros que se mete entre la firma y la liquidación es un punto que puede caerse justo cuando alguien intenta pagarnos, y esa es la parte del sistema donde menos queremos depender de otros.

Hay también un rail de tarjeta para cuando del otro lado sí hay un humano, con un checkout que se resuelve por webhook. Los dos rails conviven. El rail on-chain es el que hace novedoso a AgentMetal, porque es el único que un agente puede recorrer solo. La documentación para agentes vive en /llms.txt y en agentmetal.dev/docs.

Verificar sin cobrar

Un agente que está aprendiendo a pagar necesita poder equivocarse barato. Agregamos un dry_run que valida la firma y los fondos completos, toda la tubería de pago, sin liquidar ni consumir el nonce. El agente puede confirmar que su pago serviría antes de comprometerlo. Un rechazo devuelve la razón y qué corregir. Tratamos los mensajes de error como parte de la interfaz, porque el que los lee es una máquina que va a reintentar.

Renovar tiene su propio problema

Los servidores son prepagados. Un reaper los destruye después de expires_at, así que un agente que quiere conservar su caja tiene que extenderla antes de esa fecha con POST /v1/servers/{id}/extend, que recorre los mismos rails que la compra.

Aquí encontramos un error nuestro que vale la pena contar, porque es el tipo de bug que sobrevive a las pruebas. Agregamos cupones a la extensión: un código de un solo uso que descuenta, o que con 100% de descuento salta el pago. Un cupón se marca como usado con una escritura atómica que registra contra qué servidor se canjeó, y esa escritura tenía los parámetros de SQL invertidos. El UPDATE no coincidía con ninguna fila, y cada cupón canjeado se quedaba con su estado en pending. Las pruebas existentes solo comprobaban que el campo tuviera algún valor, y pending lo tenía, así que pasaban en verde. Lo encontramos cuando escribimos una aserción que exigía el id real del servidor en la columna. Una prueba que solo verifica que un campo "no está vacío" no está verificando gran cosa.

¿Quién está comprando de verdad?

Cuando abres una API a agentes, el tráfico deja de parecerse al de un sitio. Un día lo vimos triplicarse y por un momento pensamos que era demanda. No lo era.

Casi todas las peticiones venían de una sola IP y golpeaban el mismo endpoint MCP. El registro de peticiones solo guardaba la ruta, así que un rastreador de directorios y un agente comprando se veían idénticos: los dos hacen POST /mcp. Agregamos una línea de log por petición con el método JSON-RPC y, si era una llamada a herramienta, cuál. La respuesta fue clara: el visitante hacía initialize y luego tools/list, nada más. Nunca llamaba una herramienta. Era un indexador releyendo nuestro inventario cada par de minutos.

La distinción importa porque las dos cosas piden lo contrario. A un indexador lo mejor es dejarlo en paz. A un comprador atorado en el 402 hay que arreglarle la fricción. Sin el método en el log no sabes cuál tienes, y terminas optimizando para el equivocado.

Pruébalo

Construimos AgentMetal para que los agentes que desplegamos con nuestros clientes consigan su propia infraestructura sin un humano en medio. Ya está en línea y lo puedes probar hoy.

Si tienes un agente, apúntalo al servidor MCP @agentmetal/mcp o pega directo contra la API: GET /v1/catalog te da los planes, /llms.txt es el manual para agentes, y agentmetal.dev/docs el arranque rápido. Una caja nano por un día cuesta unos centavos en USDC. Ya pasó de verdad una vez: un agente de Claude nos encontró en el registro de MCP, pagó una factura de un centavo on-chain, y entró por SSH a la caja que compró.

Estamos afinando el producto y queremos el detalle. Dinos si el flujo de pago fue claro, dónde se atoró tu agente, qué mensaje de error no ayudó. Escríbenos a hola@inbest.cloud.