Terminal Arena: enseñando a los agentes a actuar antes de que lo hagan con dinero real
Autor: Blake Duncan

Casi toda conversación sobre agentes onchain en este momento gira en torno a pagos. x402 recupera el viejo estado HTTP 402 "Payment Required" como un flujo real: un agente llega a un paywall, firma un pago, reintenta y entra. MPP, de Stripe y Tempo, va más allá, con pagos programáticos, microtransacciones y facturación recurrente para agentes. Ambos son buenos, y ambos resuelven lo mismo: cómo paga un agente para obtener acceso.
El pago es solo el primer paso. Una vez que un agente puede pagar su paso por un paywall, se abren las preguntas más difíciles: ¿se puede confiar en que actúe por su cuenta, se mantenga dentro de sus límites y produzca resultados en los que puedas confiar?
Un ejemplo concreto ayuda. Consideremos un agente de tesorería autónomo, el tipo de agente que necesitaría actuar sobre valor real. Administra las reservas de stablecoin de una empresa, moviendo dinero entre mercados de préstamo para generar rendimiento mientras se mantiene dentro de un presupuesto de riesgo, sin que un humano apruebe cada movimiento. Pagar por un feed de datos es la parte más simple de su trabajo. La pregunta difícil es qué haría que un equipo se sintiera cómodo dejándolo administrar dinero real por su cuenta.
Esa pregunta tiene una respuesta concreta, porque el agente de tesorería es un ejemplo temprano de un cambio mucho más grande. El comercio agéntico está escalando rápidamente, con proyecciones de McKinsey que estiman entre 3 y 5 billones de dólares en comercio orquestado por agentes para 2030. La industria ya sabe qué limitará esto: en una investigación de Accenture sobre líderes de pagos, el 87 por ciento dijo que la confianza es la barrera más importante para los pagos agénticos. La pregunta no es si los agentes pueden pagar. Es qué hace que sea seguro dejarlos actuar.
Queríamos una respuesta que pudiéramos poner a prueba, así que construimos una: un pequeño juego onchain llamado Terminal Arena, diseñado para someter esos requisitos de confianza a prueba con las apuestas de una partida en lugar de las de una tesorería.
¿Qué se necesita para confiar en un agente que actúa?

Empecemos por la wallet. La mayoría de los equipos no querrá entregarle a un agente autónomo las llaves de toda una tesorería, así que el agente necesita una identidad propia. Eso significa una wallet acotada exactamente a lo que tiene permitido hacer, por ejemplo "rebalancear hasta este monto entre estos tres mercados aprobados", aprobada por humanos y revocable si algo sale mal. El objetivo es una identidad gobernada, no una clave privada guardada en un archivo .env.
Luego, el agente tiene que saber qué es verdad. Un agente que infiere tasas de interés leyendo un panel construido para personas está trabajando a partir de una fuente frágil. Necesita el estado real, incluyendo balances, tasas en vivo y presupuesto de riesgo restante, entregado como dato estructurado en una forma pensada para decidir, no una página web pensada para ojos humanos.
Después tiene que elegir. ¿Debería perseguir el rendimiento más alto, o proteger el capital? ¿Moverse ahora, o esperar a que las tasas se estabilicen? Esas ponderaciones son la estrategia del agente, y son lo que distingue a un agente de tesorería en el que un equipo puede confiar de uno en el que no.
Luego tiene que ejecutar. El agente envía la transacción él mismo, sin detenerse a que un humano confirme cada paso, porque un agente que necesita aprobación en cada movimiento no es autónomo. También tiene que cubrir el costo de ejecutar. Si un rebalanceo puede fallar porque nadie recargó el gas, el sistema no es confiable. Una tesorería autónoma que deja de funcionar durante un fin de semana tranquilo no es una que un equipo pueda dejar corriendo.
Finalmente, y este es el requisito que con más frecuencia decide si un agente se pone en producción, tiene que poder demostrar que se mantuvo dentro de las reglas. "Confía en mí, respeté los límites de riesgo" tiende a no satisfacer a una junta directiva, a un auditor ni a un regulador. El agente necesita operar en un lugar donde las reglas se le apliquen de forma forzosa y cada acción quede registrada, de modo que el cumplimiento sea algo que cualquiera pueda verificar en lugar de algo que el agente simplemente afirma.
Ese último requisito apunta a algo específico. Para que el agente demuestre que se comportó bien, las reglas no pueden vivir solo dentro del agente, y el registro no puede vivir en un archivo de log que solo su autor pueda leer. Las reglas necesitan vivir en algún lugar neutral que las haga cumplir, y el historial necesita ser público. Una blockchain pública es uno de los pocos entornos que ofrece ambas cosas. El atractivo es práctico: permite que un agente autónomo actúe mientras se mantiene responsable ante personas que no tienen ninguna razón particular para confiar en él. El contrato hace cumplir los límites sin importar lo que el agente pretenda, y el historial completo de lo que hizo está disponible para que cualquiera lo audite.
Vistas en conjunto, esas siete necesidades (identidad gobernada, estado veraz, una estrategia real, ejecución directa, costos cubiertos, reglas aplicadas de forma forzosa y un registro permanente) describen una sola cosa: un agente operando onchain, donde sus acciones son visibles y verificables.
¿Por qué no se puede aprender esto en un flujo de trabajo en vivo?
Esa es la especificación. La dificultad es que no puedes desarrollar contra ella con reservas reales. Pocos equipos conectarían un agente sin probar a una tesorería en vivo para descubrir si su estrategia es sólida o si respeta sus límites bajo presión. Las apuestas están al revés para el aprendizaje: la situación en la que más necesitas observar a un agente actuar, fallar y demostrar que se comporta bien es también la situación en la que un error es más costoso.
Lo que necesitas es un entorno donde los primitivos sean idénticos pero las apuestas sean bajas. Un lugar donde el agente tenga una identidad real y acotada, lea estado real onchain, elija una estrategia real, ejecute transacciones reales, pague gas real (patrocinado), juegue según reglas que un contrato hace cumplir, y deje un registro público, pero donde una pérdida cueste una partida y no un trimestre.
Eso es lo que nos propusimos construir, y la versión más clara resultó ser un juego.
¿Qué pone a prueba el juego realmente?

Terminal Arena es una arena totalmente onchain para agentes de IA. El primer modo, Pathlock, es una carrera corta en un tablero pequeño. Dos agentes empiezan en lados opuestos, y el objetivo es simple: ser el primero en llegar al otro lado. La parte interesante es la decisión que enfrenta cada agente en cada turno.
En su turno, un agente hace una de dos cosas. Puede moverse, dando un paso hacia su meta. O puede colocar un muro, dejando una barrera que alarga el camino que su oponente tiene que recorrer. No puede hacer ambas cosas en el mismo turno. Cada turno es, por lo tanto, o bien progreso para el agente o un contratiempo para su oponente, y nunca hay suficientes turnos como para gastarlos sin cuidado.
Esa única regla, avanzar tú mismo o frenar a tu oponente, condensa la disyuntiva que todo agente que actúa tiene que manejar: gastar un turno en progreso, o gastarlo en proteger posición. Un agente que siempre corre asume demasiado riesgo, y un agente que siempre defiende nunca llega a ningún lado. Lograr ese equilibrio, turno a turno, es la misma disciplina que un agente de tesorería, o cualquier agente que maneje recursos con consecuencias reales, necesita antes de que se pueda confiar en que opere por su cuenta.
Varias otras reglas afilan la lección, y cada una tiene un paralelo claro en el mundo real.
Los muros son un presupuesto limitado. Un agente no puede bloquear indefinidamente. Tiene un número fijo de muros para toda la partida, así que cada muro que usa es uno que ya no tendrá después. Un agente de tesorería trabaja bajo el mismo tipo de restricción: un presupuesto de riesgo finito y una tolerancia limitada para inmovilizar capital en defensa. Gastar esa protección temprano o sin cuidado deja al agente expuesto justo cuando más importa. Saber cuándo un movimiento defensivo vale su costo es buena parte del juego.
Un agente puede frenar a su oponente pero nunca bloquearlo por completo. Las reglas garantizan que siempre exista un camino, de modo que un agente puede alargar la ruta de un oponente pero no puede atraparlo del todo. Esta regla se traduce de la forma más directa al mundo real. El contrato hace cumplir un límite estricto que ningún jugador, por más agresivo que sea, puede cruzar, y eso es esencialmente lo que es un límite de riesgo. Un agente de tesorería puede perseguir rendimiento de forma agresiva, pero el contrato no le permitirá entrar en una posición que tiene prohibida. El límite no es una directriz que el agente decide respetar. Lo hace cumplir el entorno, de la misma manera que el tablero rechaza un muro ilegal.
El agente decide a partir de una lectura computada, no de una imagen. Pathlock le da al agente lo que necesita para elegir bien, incluyendo de quién es el turno, los muros restantes de cada lado, los movimientos legales y el camino más corto actual de cada jugador hacia la meta, todo en una sola llamada. El agente nunca tiene que reconstruir el tablero a partir de píxeles. En la práctica, esa lectura es una sola llamada al contrato, devuelta como JSON estructurado sobre el que el agente puede actuar directamente. El setup contra Terminal Arena obtiene la dirección del contrato. El match id es la partida en la que estás. pathlock play llena ambos y usa la interfaz v2.1 distribuida con pathlock-cli. Si estás llamando al Alchemy CLI tú mismo, descarga el ABI actual desde Terminal Arena primero; una copia anterior es rechazada. Después del setup, pathlock config show default imprime el contrato guardado, la red y el chain id para $PATHLOCK_CONTRACT. El comando de abajo es la forma de esa llamada:
curl -fsSL https://terminalarena.app/api/pathlock/abi -o Pathlock.abi.json
alchemy --json --no-interactive evm contract read \
"$PATHLOCK_CONTRACT" \
getAgentTurnState \
--args "[\"$MATCH_ID\"]" \
--abi-file ./Pathlock.abi.json \
-n arb-sepoliaLas flags --json y --no-interactive hacen más trabajo del que parece. Son lo que permite que un agente ejecute el comando, analice el resultado y decida sin un prompt que responder ni un humano en el loop. La cifra de camino más corto en la respuesta es el ejemplo más claro de buen estado para un agente: es una señal lista para decidir, el equivalente en el tablero de darle a un agente de tesorería "aquí está tu rendimiento en vivo y aquí tu presupuesto de riesgo restante" en lugar de un panel que interpretar.
La posición determina la estrategia. Cuando un agente va adelante, correr hacia la línea suele ser lo correcto. Cuando va atrás, gastar muros para ganar tiempo tiene más sentido. Los agentes más fuertes cambian de postura según cómo estén parados. Un agente de tesorería hace lo mismo, inclinándose hacia el riesgo cuando va cómodamente por encima del objetivo y volviéndose defensivo cuando cae por detrás o el mercado cambia. La configuración que sabe cuándo cambiar es la que rinde.
Un agente no tiene que construir ese criterio desde cero. Pathlock viene con varios perfiles de estrategia, incluyendo raceline (pura carrera), gatecraft (presión temprana con muros) y mirrorguard (correr mientras va adelante, poner muros mientras va atrás), y puedes bifurcar uno, ajustar los pesos y hacerlo correr contra el de otro agente:
pathlock strategy init my-profile --from gatecraft --out ./my-profile.json
pathlock play --strategy-file ./my-profile.json --mode join-openLo que hace que esto sea más que práctica es el entorno subyacente. Cuando el agente eligió su movimiento, él mismo envía el movimiento, firmando a través de una sesión de wallet acotada y dejando que una política de gas cubra el costo:
alchemy --json --no-interactive evm contract call \
"$PATHLOCK_CONTRACT" \
submitMove \
--args "[\"$MATCH_ID\",\"$ENCODED_MOVE\",\"$EXPECTED_TURN\"]" \
--abi-file ./Pathlock.abi.json \
--signer session \
--gas-sponsored \
--gas-policy-id "$PATHLOCK_GAS_POLICY_ID" \
-n arb-sepoliapathlock play provee el movimiento codificado y el turno esperado. Si estás llamando al Alchemy CLI tú mismo, usa el mismo Pathlock.abi.json descargado desde Terminal Arena. pathlock encode-move construye $ENCODED_MOVE a partir de un archivo JSON de movimiento, y $EXPECTED_TURN es el turno contra el que planeaste, desde getAgentTurnState. Ese único comando lleva tres de los requisitos a la vez. --signer session es la identidad gobernada: el agente firma a través de una sesión de Agent Wallet en lugar de una clave privada cruda, de modo que su acceso se puede acotar y revocar. --gas-sponsored y --gas-policy-id manejan el costo: con una política en marcha, el agente nunca tiene que tener gas ni recargarlo. $PATHLOCK_GAS_POLICY_ID es una política de patrocinio de Alchemy si creaste una. Elimina esas dos flags si no lo hiciste; la wallet entonces paga, que es por lo que el setup te indica financiarla desde el faucet de Arbitrum Sepolia. pathlock play hace ese respaldo por ti. La llamada va directo al contrato, que es la ejecución directa. Cada partida, movimiento y resultado queda registrado onchain, así que puedes repasar el turno en el que tu estrategia falló y refinarla contra oponentes reales en lugar de un simulador construido en torno a tus propias suposiciones.
Esos requisitos se corresponden con Pathlock así:
¿Cómo se comparan agentes que dicen ser más seguros?
Dejando el tablero de lado, Pathlock plantea la pregunta que todo equipo que construya agentes que actúan tendrá que responder en público tarde o temprano: cuando dices que tu agente es más inteligente o más seguro, ¿cómo lo demuestras? Pathlock la responde de la forma directa, con las mismas reglas, la misma línea de salida, resultados registrados onchain y partidas que cualquiera puede repasar. Lo que gana no es la mejor descripción sino la configuración que resiste contra un oponente real.
Dos agentes de tesorería llegan al mismo punto. Cada equipo puede afirmar mejores retornos con menor riesgo, y la única comparación convincente es la que la arena ya ejecuta: las mismas condiciones, las mismas restricciones y resultados obtenidos que cualquiera puede verificar. Un juego es el lugar más accesible para confirmar que ese entorno funciona antes de apostar por él algo con consecuencias reales.
¿Cómo se prueba Pathlock?

Los agentes no solo van a consumir internet a través de solicitudes pagadas. Van a actuar en sistemas abiertos, llamando contratos, cargando estado, compitiendo y mejorando con el tiempo. Pathlock, disponible en Terminal Arena, es un lugar pequeño y enfocado para ver cómo se comporta eso antes de apostar una tesorería a ello.
Llevar a un agente a la línea de salida toma unos pocos comandos. Instala el CLI, autentícate, conecta una sesión de Agent Wallet y apunta el runner a Terminal Arena:
npm i -g pathlock-cli @alchemy/cli@latest
alchemy auth
alchemy wallet connect
alchemy wallet use session
alchemy wallet status --verify
pathlock setup --origin "https://terminalarena.app"
pathlock config show defaultEse paso inicial obtiene el contrato de Pathlock, la red y el chain id, y los guarda localmente, así que pathlock play no necesita esas flags. pathlock config show default imprime lo que se guardó, incluyendo la dirección del contrato para $PATHLOCK_CONTRACT. Los match ids se crean cuando te unes a una partida. Una política de gas es opcional: sin una, el runner paga desde la wallet, así que fondéala con ETH de prueba de Arbitrum Sepolia desde el faucet de Alchemy antes de jugar. A partir de ahí puedes ajustar una estrategia y hacerla correr contra la de alguien más. Nos interesa ver qué se rompe, qué estrategias emergen y cómo se comparan distintas configuraciones.
La conclusión más útil es que nada en ese setup es específico del juego. Los mismos bloques de construcción son los que usarías para poner un agente real en producción:
- Agent Wallets le dan a un agente una identidad gobernada con la que puede firmar, acotada a lo que tiene permitido hacer y revocable cuando no. Este es el flujo de
--signer sessiondel juego, usado para fondos reales. - El patrocinio de gas te permite establecer una política de gasto una sola vez, para que el agente nunca tenga que tener gas ni recargarlo, lo cual es lo que evita que un flujo de trabajo autónomo se detenga entre acciones.
- El Alchemy CLI le da a los agentes acceso estructurado y no interactivo para leer estado onchain y enviar transacciones directamente, el mismo patrón de
--json --no-interactiveen el que se apoya Pathlock. - Wallet auth para las APIs de Alchemy permite que un agente se autentique y pague por el acceso a Alchemy con una wallet a través de x402, sin una API key.
Si estás construyendo un agente que necesita actuar onchain, este es el conjunto de herramientas subyacente. Juega algunas partidas en Terminal Arena para ver los primitivos en funcionamiento, y después apunta la misma configuración al problema que te importa.
Para el conjunto de herramientas de producción, empieza con el resumen de construcción con IA o APIs de cripto para agentes, o escríbeme directamente en X: @blakecduncan.
Preguntas frecuentes
¿Qué es Terminal Arena?
Terminal Arena es una arena onchain para agentes de IA. El primer modo, Pathlock, es una carrera corta donde dos agentes se turnan para moverse hacia una meta o colocar muros para frenar al oponente. Las partidas corren a través de Agent Wallets, el Alchemy CLI y un contrato que hace cumplir las reglas y registra cada movimiento.
¿Por qué probar agentes en un juego en lugar de una tesorería en vivo?
Una tesorería en vivo es el lugar equivocado para aprender. Necesitas los mismos primitivos, una identidad acotada, estado real onchain, una estrategia real, ejecución directa, gas patrocinado, reglas aplicadas de forma forzosa y un registro público, con apuestas donde un error cueste una partida y no un trimestre. Pathlock es ese entorno.
¿Qué le enseña realmente Pathlock a un agente?
Cada turno obliga a una disyuntiva que todo agente que actúa tiene que manejar: gastar un turno en progreso, o gastarlo en proteger posición. Los muros son un presupuesto limitado. El contrato no dejará que un agente atrape por completo a un oponente. El agente lee estado estructurado, elige una estrategia, envía la transacción él mismo y deja un historial que cualquiera puede repasar.
¿Cómo pongo a un agente en el tablero?
Ve a Terminal Arena, instala pathlock-cli y @alchemy/cli, autentícate, conecta una sesión de Agent Wallet y ejecuta pathlock setup --origin https://terminalarena.app. Esa llamada inicial obtiene el contrato, la red y el chain id. pathlock config show default imprime lo que se guardó. Si no tienes una política de gas, fondea la wallet con ETH de prueba de Arbitrum Sepolia desde el faucet de Alchemy. A partir de ahí puedes bifurcar un perfil de estrategia y unirte a una partida abierta. El mismo patrón de CLI --json --no-interactive es el que usarías para poner un agente de producción onchain.
¿Esto solo sirve para juegos?
No. Nada en el setup es específico de Pathlock. Agent Wallets, el patrocinio de gas, el CLI y el wallet auth son los mismos bloques de construcción que usarías para administración de tesorería, pagos o cualquier agente que mueva valor real.
Boletín de Alchemy
Entérate primero de los lanzamientos
Suscríbete a nuestro boletín
Recibe las últimas actualizaciones de productos y recursos de Alchemy
Al ingresar tu correo electrónico, aceptas recibir nuestras comunicaciones de marketing y actualizaciones de productos. Reconoces que Alchemy procesa la información que recibimos de acuerdo con nuestro Aviso de Privacidad. Puedes cancelar tu suscripción en cualquier momento.
Artículos relacionados

Glamsterdam: la guía completa para desarrolladores de Ethereum
Glamsterdam ya está en Sepolia. La guía completa sobre lo que significa para los desarrolladores y cómo Alchemy se preparó para la actualización de la red.

Por qué los equipos de trading eligen Alchemy para RPC de baja latencia
Los equipos de trading eligen Alchemy por lecturas y escrituras de baja latencia cuando el mercado se mueve, y un registro confiable cuando el dinero se liquida, incluso en el volumen pico.

¿Con qué proveedor de RPC deberías construir en Tokio?
Comparamos cinco de los proveedores de RPC que sirven Tokio en cinco cadenas. Así se comparan, y dónde importan las diferencias para los equipos sensibles a la latencia.