> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Agentes > Qué tiene que hacer cada capa de la arquitectura cuando el participante no es una persona: el runtime fuera del protocolo, la admisión bajo carga de agentes, la autorización como transacción y un entorno reejecutable. La dirección para la que se está construyendo es aquella en la que **una persona está representada por varios agentes**, cada uno actuando sobre una parte de lo que esa persona quiere. Ni una persona con una herramienta, ni un bot ejecutando un script fijo: varias contrapartes frente al mercado, todas respondiendo a una sola cuenta. Cuando cambian los participantes, la microestructura del mercado cambia con ellos. Los tamaños de orden bajan y las tasas de mensajes suben, la proporción de cancelaciones frente a ejecuciones se abre todavía más, y el flujo adquiere una correlación que el flujo humano no tiene: agentes que leen la misma señal llegan a la misma conclusión en el mismo instante. Nada de eso se resuelve añadiendo una función. Se resuelve recorriendo la arquitectura capa por capa y preguntando qué tiene que hacer cada una de forma distinta. Esta página es ese recorrido, en orden, con el punto en el que está realmente cada capa.
1 · Aplicación
2 · Red
3 · Ejecución
4 · Estado
El runtime está fuera del protocoloy no tiene privilegio alguno: ni menor latencia, ni datos antes, ni una interfaz a la que un tercero no pueda llegar
La admisión, cuando quienes envían son agentesuna cancelación tardía es peor que una orden tardía, y la equidad se sigue sobre el historial reciente en lugar de por mensaje
La autorización es una transaccióncon una altura de bloque, dentro del conjunto cerrado de instrucciones: y revocarla cancela las órdenes en libro del agente en el mismo bloque
Un entorno reejecutable, versionado por bloquepoint-in-time por construcción y no por disciplina
Las mismas cuatro capas que la visión general de la arquitectura. Solo cambia la pregunta: ¿qué tiene que hacer cada una cuando el participante no es una persona?
| Capa | Qué cambia | Estado | | -------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | **Aplicación** | El runtime — investigación y ejecución — está fuera del protocolo y no tiene privilegio alguno | Comprometido | | **Red** | Admisión bajo un flujo a ráfagas, correlacionado y con muchas cancelaciones | Entregado, con dos preguntas abiertas | | **Ejecución** | La autorización pasa a ser una transacción con términos | Entregada como todo o nada; los términos están comprometidos | | **Estado** | La cadena es el entorno en el que se evalúa a un agente | Entregado |

1 · Aplicación — el runtime está fuera, y tiene que estarlo

El runtime de agente es un marco de investigación y ejecución: forma una visión, la convierte en algo ejecutable y la pone delante del mercado. Corre en la capa de aplicación, al mismo nivel que los front ends y los clientes de API, y **no forma parte del protocolo**. Esa ubicación es una restricción física antes que una preferencia de diseño. Un modelo razona en segundos; un mercado se mueve en milisegundos. Nada que tenga que llamar a un modelo puede estar en la ruta que una orden recorre de verdad, lo que significa que **el protocolo no contiene modelo alguno**. No por omisión, sino porque un modelo en la ruta de liquidación destruiría la única propiedad sobre la que descansa todo lo demás aquí. La ruta de ejecución tiene que producir los mismos bytes en cada nodo, y la inferencia no lo hace. Así que el runtime vive fuera, y la pregunta honesta pasa a ser qué le debe el protocolo. Cinco cosas, todas comprometidas y no entregadas. | | Qué le da a un agente | | --------------------------------- | -------------------------------------------------------------------------------------------------- | | **Simulación previa** | Evaluar qué haría una orden contra el estado confirmado antes de enviarla | | **Envío idempotente** | Reintentar un envío ambiguo sin arriesgar exposición duplicada | | **Estados terminales con nombre** | Ningún desenlace cuyo resultado sea desconocido: toda acción termina en un estado que tiene nombre | | **Reanudación definida** | Un agente que reinicia sabe dónde estaba y qué hacer a continuación | | **Recibos atribuidos** | Qué hizo el agente, bajo qué autoridad y a qué coste — como salida del protocolo | Para los estados, consulta [Qué viene después](/es/protocol/roadmap/whats-next). El runtime no tiene ninguna ruta privilegiada. Ni menor latencia, ni datos antes, ni una interfaz a la que no pueda llegar un runtime de terceros. Conviene decirlo en vez de darlo por supuesto, porque en otra parte la arquitectura afirma que nada se interpone entre un trader y la cámara de compensación — y una herramienta propia con carril reservado sería exactamente ese algo.

2 · Red — la admisión, cuando quienes envían son agentes

El mempool decide qué merece guardarse, qué transacción de un emisor va después, qué pares se enteran de ella y qué se descarta cuando la demanda supera la capacidad. El flujo de agentes presiona las cuatro cosas, y dos de las propiedades que lo absorben ya están ahí por razones anteriores a los agentes. **Una cancelación tardía es peor que una orden tardía.** El [mempool](/es/protocol/architecture/mempool) trata por diseño el tráfico de órdenes y el de cancelaciones como asimétricos. Los agentes hacen esa asimetría más extrema, porque su proporción de cancelaciones frente a ejecuciones es mayor que la de una persona, pero la forma del problema es aquella alrededor de la cual se construyó esta capa. **La equidad se sigue sobre el historial reciente, no por mensaje.** El mempool mantiene un registro rodante de qué emisores y qué tipos de tráfico han consumido capacidad últimamente, y con eso moldea lo que sirve a continuación. **Esta es la parte que importa para las ráfagas correlacionadas**: cuarenta agentes cancelando ante la misma señal no son cuarenta veces la carga media repartida de forma uniforme, son un pico. Un límite por mensaje no lo ve. Una memoria de quién ha hecho ruido últimamente sí. **El consenso no crece con el rendimiento.** Las transacciones llegan a los validadores en lotes cuya disponibilidad se demuestra antes de que una propuesta pueda referenciarlos, así que una propuesta de bloque lleva resúmenes y no cuerpos. Una población de agentes que multiplica por diez las tasas de mensajes no aumenta en nada el tamaño de los mensajes de consenso. El bloque elimina la carrera **dentro** de él: dos transacciones del mismo bloque tienen una precedencia que todos los nodos calculan igual. **Esa garantía empieza en la frontera del bloque.** Entrar en el bloque sigue siendo una carrera, moldeada por la equidad a nivel de emisor y no eliminada por ella. La admisión en el mempool no es la inclusión. Dos preguntas siguen abiertas en esta capa, y ambas se vuelven materiales a volúmenes de agentes, no a volúmenes humanos. **Cuánto debería costar una cancelación.** La ejecución ya pone las cancelaciones primero: corren en la fase anterior a todo lo que puede tomar liquidez. La versión de red de esa misma pregunta está sin resolver: una cancelación barata y prioritaria es lo que hace defendible cotizar, y es también la forma más barata de inundar un mempool. Si las cancelaciones deben llevar su propia contabilidad de capacidad, separada de las colocaciones, no está decidido. **A qué capa pertenece la idempotencia.** Un agente que no recibe respuesta reenvía. El envío idempotente está comprometido en la capa de ejecución y resuelve la consecuencia que importa: sin exposición duplicada. No resuelve la versión de red: si el mempool debe reconocer un reenvío como la misma intención, o llevar los dos y dejar que la ejecución desduplique. Bajo una tormenta de reintentos, esas dos opciones se comportan distinto. Hay algo deliberadamente ausente de la lista: un carril de admisión aparte para los agentes. El acceso prioritario es lo que toda plaza centralizada acaba vendiendo, y contradiría la afirmación de que nada se interpone entre un trader y la cámara de compensación. El flujo de agentes pasa por la misma puerta.

3 · Ejecución — la autorización es una transacción

Esta es la capa donde cambia el modelo de cuenta, y todo el cambio se sigue de un solo hecho. **Entregar una cuenta a un agente es una transacción on-chain.** No un formulario enviado, no una clave de API emitida desde una página de ajustes, no una fila en la base de datos de un operador. Una transacción, en un bloque, a una altura, firmada por la cuenta que la concedió — y por tanto algo que cualquier tercero puede encontrar, leer y comprobar sin pedirle permiso a nadie. De ahí se siguen tres consecuencias, y cada una es algo que una clave de API no puede hacer. **Está en el conjunto cerrado de instrucciones.** La autorización de agente es una de las operaciones enumeradas del [kernel](/es/protocol/architecture/kernel). Una cadena de propósito general no puede expresarla: el significado de la llamada sería bytecode opaco. Una plaza centralizada la impone dentro de software que no puedes inspeccionar. Aquí la autoridad y sus límites **son** la instrucción, y por eso el límite es comprobable en lugar de prometido. **Lleva lo que el agente puede hacer, y no puede llevar lo que no puede.** Una autorización puede decir qué puede mantener el agente, cuánto puede perder, qué mercados puede tocar y si puede cambiar el modo de margen. **No puede decir «retirar».** No es un ajuste dejado apagado: no existe ese término para escribirlo. Un agente que opera una cuenta no tiene ninguna ruta expresable para sacar fondos de ella. **Revocarla cancela las órdenes en libro del agente.** La revocación también es una transacción, y aterriza en un bloque cuya [secuenciación](/es/trading/tx-sequencing) ya ejecuta las cancelaciones antes que cualquier cosa que pueda tomar liquidez. Así que las órdenes que el agente dejó en el libro se van en el mismo bloque que la autoridad. En una plaza donde la revocación es una escritura en base de datos, la clave deja de funcionar y las órdenes en libro quedan en un estado indefinido. Aquí la parada es demostrable y cualquiera puede encontrar la altura a la que ocurrió.
ConcederUna transacción en el bloque NLleva el alcance: qué puede mantener el agente, cuánto puede perder, qué puede negociar. No puede llevar un retiro: ese término no existe
ActuarCada acción nombra su autoridadAtribuida a la cuenta que la concedió, no solo al agente que la envió
RevocarUna transacción en el bloque MLas órdenes en libro del agente se cancelan en el mismo bloque, antes de que se ejecute nada que pueda tomar liquidez
Ninguna de las tres es una escritura en base de datos de la que haya que avisarte. Cada una es una transacción que cualquiera encuentra en una altura.
Hoy la concesión es todo o nada con caducidad. Los términos más ricos de arriba — qué puede mantener un agente, cuánto puede perder, qué puede hacer después — están comprometidos y no entregados; consulta [Qué viene después](/es/protocol/roadmap/whats-next). **Lo que ya se sostiene es la parte que no se puede añadir luego**: la autoridad es un objeto del protocolo y no el registro que un operador hace de ella.

Lo que la plaza ya carga por el runtime

Un runtime de trading que tiene que proteger a un usuario en una plaza corriente acaba construyéndose su propio núcleo privilegiado: un libro de posiciones que mantiene y concilia él mismo, una comprobación de riesgo previa que ejecuta por su cuenta esperando que la plaza calcule igual, y un registro de auditoría que escribe y del que no puede demostrar que no fue alterado. **Las tres cosas son redundancia frente a una plaza que no enseña sus libros.** Aquí tres de esas cosas son propiedades del protocolo. La [cámara de compensación](/es/protocol/architecture/clearinghouse) es la única que escribe el libro. La etapa de riesgo corre antes de la casación, en el mismo bloque. El registro de auditoría es la cadena, y cada cambio de estado lleva la transacción que lo causó. Al runtime le queda la cuarta — una pasarela de órdenes idempotente — y eso es un problema de interfaz, no de confianza.

Casación: el bloque ya es el lote

El flujo de agentes sube la frecuencia y baja el tamaño de lo que llega al libro, que es justo la microestructura que más se usa para defender una subasta por lotes: intervalos discretos, liquidados juntos, sin ventaja por llegar un microsegundo antes. Esa propiedad **ya** se cumple aquí, y no porque se haya añadido una subasta por lotes. El tiempo dentro de un bloque es la posición que confirmó el consenso, no un reloj local, así que **dentro de un bloque no existe ventaja por debajo del milisegundo**; y las cancelaciones corren antes que cualquier orden agresiva, de modo que una cotización rancia puede retirarse y no puede ser recogida por una orden que llegó junto con la cancelación. El bloque es un intervalo discreto que se liquida junto. Llegó como **consecuencia** de ejecutar un ordenamiento confirmado, no como un añadido de diseño de mercado. Si algo más allá de eso está justificado — y la prioridad continua precio-tiempo y las subastas por lotes frecuentes son **alternativas y no añadidos**, ya que un lote elimina deliberadamente la prioridad temporal dentro de sí — se está explorando, no construyendo.

4 · Estado — la cadena es el entorno

Un agente vale lo que valga aquello contra lo que se le evaluó, y en la evaluación es donde ocurre la mayor parte del fracaso. Una estrategia que parecía rentable en un simulador y falla en producción normalmente no se encontró con un mercado nuevo: se encontró con un simulador que no era la plaza. La [capa de estado](/es/protocol/architecture/state/model) elimina esa brecha por construcción y no por disciplina. El estado está versionado por bloque y cada cambio se atribuye a la transacción que lo causó, así que reejecutar un bloque reejecuta **el entorno** y no un modelo de él: la misma máquina de estados que ejecutará al agente, sobre las entradas que la red confirmó. Esa es la quinta comprobación de [Verifícalo tú mismo](/es/developers/verify), y es lo que hace que un backtest aquí sea un objeto de otra naturaleza que un backtest contra la API histórica de un exchange. La propiedad más sutil es que esto es **point-in-time por construcción**. Un conjunto de datos armado desde la API de un exchange es point-in-time solo si quien lo armó fue cuidadoso, y el sesgo de anticipación se cuela por huecos que nadie nota: un campo rellenado a posteriori, una corrección aplicada al histórico, un precio de referencia revisado. Aquí la pregunta no se plantea: el estado de un bloque es lo que era cierto en ese bloque, porque es la única forma que el estado ha tenido nunca.

Qué se vuelve más difícil

Construir para agentes no es solo una lista de cosas que mejoran. **El determinismo corta por los dos lados.** Un agente puede predecir qué hará su propia orden antes de enviarla, porque la misma entrada produce el mismo resultado en cada nodo. **El agente de cualquier otro también puede hacerlo con la tuya.** La reproducibilidad sube a la vez tu capacidad de planificar y tu previsibilidad, y lo segundo no es gratis. **La liquidez de agentes es liquidez correlacionada.** Los creadores de mercado humanos se retiran en momentos distintos porque se dan cuenta en momentos distintos. Los agentes que leen el mismo estado público llegan juntos a la misma conclusión. Un libro sostenido por agentes es más profundo un día corriente y puede adelgazar más rápido el día que importa: es un riesgo de estructura de mercado para el que están diseñados los absorbedores del protocolo, no uno que eliminen. **El oráculo lee plazas en las que los agentes también operan.** La certificación ata un precio al bloque que lo consumió; no vuelve inmanipulable el mercado subyacente, y una población de agentes actuando sobre señales correlacionadas es una vía más para que el subyacente se mueva a la vez. Consulta [qué garantiza y qué no garantiza el oráculo](/es/protocol/architecture/oracle). **La autoevaluación de un agente no es evidencia.** La retroalimentación del trading es ruidosa y no estacionaria de un modo en que la del código no lo es: un compilador te dice que te equivocaste, una semana rentable no te dice que acertaste. Cualquier cosa que una plaza construya para agentes tiene que tratar el relato que un agente hace de su propio rendimiento como **entrada adversaria** y no como una medición. Esa es una de las razones por las que las comprobaciones de [Verifícalo tú mismo](/es/developers/verify) se construyen alrededor de lo que se puede recalcular y no de lo que se puede reportar.

Qué leer a continuación

Las cuatro fases, y por qué lo que tiene que cambiar es la cuenta. Las comprobaciones que hacen de la evaluación de un agente algo distinto de una afirmación. Lo que queda por dar por bueno, una vez comprobado lo comprobable. El estado del runtime de agente y de los términos de autorización.