Dentro de un sistema multiagente: notas de arquitectura para desarrolladores de criptoactivos

Imagínese una empresa de criptomonedas que vende a empresas y que desea un software capaz de monitorear los protocolos DeFi, evaluar la liquidez, analizar los riesgos de los contratos inteligentes, reequilibrar las reservas financieras, identificar transacciones sospechosas e incluso realizar operaciones según políticas predefinidas. Un agente de IA al que se le encomiende todo esto acaba cargando con demasiadas responsabilidades. Debe leer datos del mercado, consultar la infraestructura de la cadena, evaluar riesgos, llamar a APIs, tomar decisiones financieras y firmar transacciones, todo dentro de un único ciclo de razonamiento. Probar, escalar y proteger algo así se vuelve extremadamente complicado rápidamente.

La respuesta habitual es dividir el trabajo entre agentes especializados y añadir una capa de orquestación encima. Eso es más que simplemente varios modelos de lenguaje conversando entre sí. Se trata de una arquitectura de software en la que el razonamiento del modelo, la lógica de la aplicación, los datos, las herramientas, los permisos y la ejecución se mantienen deliberadamente separados. A continuación se explica cómo encajan estas partes y qué deben considerar quienes desarrollan sistemas en este ámbito.

Qué se considera un sistema multiagente

Varios agentes especializados que cooperan en una tarea más grande de la que cualquiera de ellos podría manejar por sí solo: esa es la definición. Una fórmula útil para un agente individual:

Agente = modelo de IA + instrucciones + contexto + herramientas + estado + bucle de ejecución

Se añade una segunda capa para el grupo:

Agentes + orquestación + estado compartido + comunicación + políticas

Una plataforma de tesorería podría contar con el siguiente conjunto de agentes:

1. Un agente de investigación que recopila datos de protocolo y del mercado.
2. Un agente de riesgos que evalúa los peligros relacionados con los contratos, la liquidez y el protocolo.
3. Un agente de carteras que compara las oportunidades y calcula las asignaciones.
4. Un agente de cumplimiento que aplica las reglas comerciales de la empresa.
5. Un agente de ejecución que prepara y envía las transacciones.
6. Un agente de monitoreo que verifica en la cadena qué ocurrió realmente.

Tomemos esta instrucción: invertir $50,000 en USDC en la opción de mayor rendimiento disponible, siempre y cuando el protocolo cumpla con la política de riesgos y los costos de ejecución sean inferiores al 0.5%. Esto requiere varias habilidades distintas, por lo que el sistema lo divide en una secuencia de pasos:

```text
User Request
     ↓
Orchestrator
     ↓
Research Agent
     ↓
Risk Agent
     ↓
Portfolio Agent
     ↓
Policy Check
     ↓
Execution Agent
     ↓
Blockchain
     ↓
Verification
```

Cada agente se ocupa de un problema pequeño y ninguno tiene que resolver todo el flujo de trabajo.

Las capas de un sistema de producción

Siete componentes aparecen una y otra vez: el entorno de ejecución del agente, un orquestador, estado compartido, una capa de herramientas, una capa de políticas y seguridad, la infraestructura de ejecución y la capacidad de observabilidad. Cada uno responde a una pregunta de ingeniería distinta.

Entorno de ejecución del agente

El entorno de ejecución hace funcionar a un agente. En producción, un agente es más que un mensaje de entrada y una respuesta de salida; funciona como un bucle:

  ```text
Input
 ↓
Build Context
 ↓
Ask Model to Reason
 ↓
Choose Action
 ↓
Call Tool / Agent / Return Result
 ↓
Receive Result
 ↓
Update Context
 ↓
Reason Again
```

Imaginemos que a un agente de investigación se le pide que compare los protocolos de préstamo de DeFi. Este recopilaría una lista de protocolos, obtendría su TVL actual, buscaría las tasas de préstamo, compararía la liquidez, seleccionaría los candidatos más sólidos y se los entregaría al agente de riesgos. El modelo proporciona la lógica detrás de las decisiones, mientras que la aplicación que lo rodea controla qué se ejecuta realmente. Esa separación es importante, ya que un modelo no debería realizar tareas que el software ordinario puede hacer mejor. Multiplicar 50,000 dólares por el 8.2% no requiere un LLM, ya que una función sencilla es más rápida, económica y da siempre el mismo resultado.

Orquestador

El orquestador funciona como el centro de control. Decide qué agente se ejecutará, qué instrucciones recibirá ese agente, qué pasará a continuación, qué tareas pueden realizarse en paralelo, cuándo finalizará el trabajo y qué hacer cuando un agente falla. Existen dos estilos básicos.

Orquestación impulsada por modelos. Un modelo supervisor elige al especialista que necesita.

           ```text
        Supervisor Agent
              │
        ┌─────┼─────┐
        ▼     ▼     ▼
   Research  Risk  Analytics
```

El supervisor podría pensar que primero se necesitan datos de protocolo, por lo que llama al agente de investigación; una vez que recibe el resultado, decide que se requiere una evaluación de seguridad y llama al agente de riesgos. Eso es flexible, aunque la ruta de comunicación puede volverse impredecible, se acumulan llamadas adicionales al modelo y, por ende, los costos también.

Orquestación impulsada por código. La aplicación determina la secuencia adecuada.

```text
Research
   ↓
Risk Analysis
   ↓
Policy Check
   ↓
Simulation
   ↓
Approval
   ↓
Execution
```

Esta versión es más sencilla de probar y de mantener bajo control.

Combinar las dos opciones. En el caso de los productos financieros B2B, la configuración más eficaz suele combinarlas. Se deja que el modelo tome decisiones y que el código aplique reglas. El modelo podría concluir que el protocolo A ofrece el mejor rendimiento ajustado al riesgo, mientras que la aplicación insiste en que cualquier cantidad superior a 50,000 dólares requiere una aprobación adicional. La IA hace las recomendaciones y el software las aplica.

Estado compartido

Los agentes necesitan ver los resultados de los pasos anteriores. Pasar toda la conversación a cada uno de ellos es una pérdida de tiempo, por lo que el sistema mantiene un registro estructurado del flujo de trabajo.

En el caso de la solicitud de USDC, ese registro contendría el activo (USDC), la cantidad (50000), la cadena (Ethereum), una lista de protocolos candidatos (Aave y Morpho), y tres campos de estado (riesgo, política y ejecución) que inicialmente serían “pendiente”, “pendiente” y “no iniciado”.

El agente de investigación completa campos como los protocolos de los candidatos, los resultados obtenidos y los datos del mercado. El agente de riesgos agrega una puntuación y sus hallazgos de seguridad. El agente de ejecución solo ve lo necesario para llevar a cabo su tarea. La estructura es ordenada:

               ```text
                Shared State
                    │
         ┌──────────┼──────────┐
         ▼          ▼          ▼
    Research      Risk     Execution
     Agent        Agent     Agent
        └──────────┼──────────┘
                   ▼
             Updated State
```

Un registro compartido también hace que sea mucho más sencillo pausar, reanudar, auditar y depurar un flujo de trabajo.

Comunicación: transferencias y agentes como herramientas

Los agentes colaboran de dos maneras útiles. En una transferencia, el control pasa de un agente al siguiente.

```text
Research Agent
↓
Risk Agent
↓
Portfolio Agent
```

Las transferencias de responsabilidad son adecuadas para los momentos en que cambia la responsabilidad: una vez realizada la investigación de mercado, el agente encargado del riesgo se hace cargo de la evaluación de los candidatos. Cuando un agente se utiliza como herramienta, un agente llama a otro y mantiene el control.

     ```text
      Supervisor
      /    |   \
 Research Risk Analytics
```

El supervisor puede pedir al agente de riesgos que pruebe un protocolo según los criterios de la empresa, obtenga una respuesta estructurada y continúe con su trabajo. Esto es útil cuando un único agente central debe combinar varias opiniones especializadas.

Capa de herramientas

Un agente no puede acceder por sí solo a una blockchain o a una base de datos. Las herramientas son la conexión entre ellos. A un agente de criptomonedas se le pueden proporcionar RPCs de blockchain, APIs de datos de mercado, agregadores de DEX, indexadores, bases de datos de riesgos, infraestructura de billeteras y sistemas internos de tesorería, accesibles a través de operaciones como get_balance(), read_contract(), estimate_gas(), simulate_transaction() y submit_transaction().

Concézcale a cada agente el mínimo acceso necesario para que pueda funcionar. Un agente de investigación podría necesitar únicamente read_market_data() y read_protocol_data(). Un agente de ejecución podría tener acceso a simulate_transaction() y submit_transaction(). No hay motivo alguno para otorgar derechos sobre billeteras o transacciones a todos los agentes, y los permisos restringidos limitan los daños en caso de que alguno se comporte mal o sea comprometido.

La línea entre la IA y la cadena

Este podría ser el punto de diseño más importante en los productos criptográficos. La salida de los modelos es probabilística, mientras que la ejecución en la cadena de bloques es determinista y, con frecuencia, no se puede deshacer. Por lo tanto, ningún agente debería controlar directamente la transacción final. Un enfoque más seguro sería el siguiente:

```text
Agent Decision
     ↓
Schema Validation
     ↓
Policy Check
     ↓
Risk Check
     ↓
Transaction Simulation
     ↓
Authorization
     ↓
  Signing
     ↓
Blockchain
```

Imagínese que el agente decide intercambiar 50,000 dólares en USDC por ETH. La capa de ejecución debe verificar de forma independiente si el USDC es un activo aprobado y el ETH un destino aprobado, si la cantidad está dentro del límite del usuario, si la desviación es aceptable, si el destinatario es correcto, si la transacción se simula sin problemas y si el usuario debe dar su aprobación. El agente sugiere una acción, y una capa determinística decide si dicha acción puede llevarse a cabo. Los sistemas financieros se basan en esa división de responsabilidades.

Límites y manejo de fallos

Se deben establecer límites determinísticos alrededor de cada decisión tomada por la IA. Una configuración podría indicar: monto máximo de transacción de 50,000 dólares, desviación máxima del 0.5%, liquidez mínima de 5 millones de dólares, y cadenas permitidas como Ethereum, Arbitrum y Base. Un modelo no puede eludir esos límites formulando sus respuestas de manera diferente.

También recuerde que una estructura válida no es prueba de que el contenido sea correcto. Una salida como {"risk_score": 0.04} puede estar perfectamente formada y, aun así, basarse en un razonamiento completamente erróneo. Un sistema de producción debe verificar el formato, las reglas de negocio, cuán actualizados están los datos, cuán fiables son las fuentes y los resultados de las llamadas a las herramientas finales:

```text
Agent Output
     ↓
Schema Validation
     ↓
Business Validation
    ↓
Data Validation
    ↓
Tool Execution
    ↓
Result Verification
```

Idempotencia. Considere una solicitud que se agota el tiempo de espera. El agente podría decidir que la transacción falló e intentarlo de nuevo, pero es posible que el primer intento ya haya tenido éxito, lo cual duplicaría una acción financiera. El servicio de ejecución debe asignar a cada solicitud un identificador único, por ejemplo exec_829192, y vincularlo a la transacción resultante. Si la misma solicitud llega nuevamente, el servicio devuelve el resultado existente y no envía nada nuevo. En los flujos de trabajo financieros, esta propiedad no es opcional.

Observabilidad

Los registros simples no son suficientes para los sistemas de agentes, ya que los ingenieros necesitan conocer todo el camino de toma de decisiones. Para cada paso, es necesario registrar qué agente lo ejecutó, qué modelo utilizó, qué herramientas llamó con qué parámetros, qué resultados se obtuvieron, qué políticas se activaron, cuánto tiempo duró cada paso y qué transacción finalmente se envió. Cuando una transacción falla, se debe poder determinar quién tomó la decisión, sobre qué datos, qué política la aprobó, cómo se construyó la transacción y qué ocurrió realmente en la cadena de bloques. Sin ese nivel de visibilidad, operar estos sistemas en producción se convierte en una especulación.

Alrededor de este núcleo, una implementación en producción debe incluir control de identidad y acceso, custodia de claves, un almacenamiento para el estado, mecanismos de limitación de carga, monitoreo, pruebas de evaluación y un registro de auditoría. Una demostración nunca muestra estos elementos, pero son ellos los que determinan si la solución funciona a escala empresarial.

Sistemas distribuidos con LLMs integrados

La forma más clara de comprender el desafío es dejar de tratar a un sistema multiagente como un conjunto de chatbots. Se trata de un sistema distribuido en el que algunas decisiones se toman de forma probabilística por un modelo, por lo que siguen siendo aplicables todas las preocupaciones clásicas: gestión de estados, autenticación, autorización, concurrencia, intentos repetidos, idempotencia, recuperación ante fallos, validación de datos y observabilidad.

El modelo es la capa de razonamiento y la arquitectura es la capa de control. Cuando están en juego activos reales y transacciones irreversibles, esa diferencia es de gran importancia. Un sistema bien construido no busca una autonomía ilimitada, sino una autonomía controlada: agentes libres para razonar, cooperar y adaptarse, mientras que el software determinista se encarga de los permisos, los límites financieros, la validación y la ejecución.

Conclusión

El valor no radica en tener varios modelos, sino en dividir los flujos de trabajo complejos en unidades más pequeñas y especializadas que puedan controlarse. En el ámbito de las criptomonedas B2B, este principio puede expresarse de manera sencilla:

• El razonamiento corresponde a los agentes.
• La recuperación de datos y las operaciones corresponden a las herramientas.
• La coordinación corresponde al orquestador.
• Las reglas de negocio se aplican mediante políticas.
• Las transacciones pasan por la capa de ejecución, que las controla.
• El liquidación final tiene lugar en la propia blockchain.

Una vez que estas responsabilidades están separadas, el sistema es más fácil de escalar, probar, proteger y auditar. El objetivo no es hacer que la IA parezca inteligente, sino lograr que los flujos de trabajo complejos impulsados por la IA sean lo suficientemente fiables para su uso en producción.

Leer más

• Cómo los subagentes y los sistemas multiagente dividen el trabajo y los tokens de costo — Una explicación sencilla sobre los subagentes frente a los sistemas multiagente, el diseño de orquestador-trabajador, cuatro topologías, los costos de los tokens y cuándo es mejor elegir un solo agente.
• Diseño de un buscador de empleos multiagente: pipeline, HyDE y observabilidad — Un pipeline de LangGraph de nueve pasos que relaciona currículos con empleos, con ocho opciones de diseño para HyDE, enrutamiento de modelos, límites de tasa y seguimiento.