La pila agente tiene cuatro capas. La mayoría de los despliegues carecen de tres

La identidad, la reputación, el mandato y el pago deben vivir en cadena. En muchos despliegues de producción, aún no lo hacen, y eso es un problema arquitectónico, no una reflexión posterior de cumplimiento.

Dedico mucho tiempo a observar cómo están realmente conectados los despliegues de agentes en producción, y el patrón suele ser el mismo: el modelo es capaz, y el marco de orquestación es razonable, pero la capa de autenticación sigue siendo una clave API compartida que no se ha rotado en meses.

La infraestructura de agentes autónomos no ha seguido el ritmo de los modelos que se ejecutan sobre ella. La pila agente tiene cuatro componentes que deben ser nativos de la cadena: identidad, reputación, mandato y pago. En la mayoría de los despliegues de producción que veo, todavía se añaden después del hecho, si es que existen.

Y esto es más importante en finanzas reguladas que en cualquier otro lugar. Un agente que pueda transaccionar con valores tokenizados, aprobar acciones de tesorería o asignar entre posiciones debe poder demostrar qué estaba autorizado a hacer, quién lo autorizó, dentro de qué límites y dónde vive el registro en cadena de esa autoridad. La mayoría de los despliegues no pueden responder eso de manera clara hoy. Sin ese registro, el propio agente es el riesgo de auditoría y cumplimiento.

Por qué las claves API compartidas son el primitivo equivocado

El modelo de autenticación que la mayoría de los despliegues de agentes heredan de SaaS es un secreto compartido pasado en un encabezado. Autentica el servicio que llama pero no dice nada sobre el agente específico que realiza la llamada, ni sobre lo que ese agente tiene permitido hacer, y no deja ningún registro que sobreviva a una auditoría en una forma que un regulador pueda inspeccionar. Cada acción del agente es atribuible solo a quien posee la clave, lo que en la práctica significa que la atribución colapsa una vez que tienes más de un agente o más de un operador.

La alternativa es la liquidación basada en firmas por solicitud. Cada solicitud es firmada por la propia billetera del agente y liquidada criptográficamente en el momento de la llamada. Para eso está construido x402 , con la autenticación y el pago manejados juntos. Eso brinda a las instituciones un registro de qué billetera actuó, cuándo lo hizo y por qué pagó, un libro mayor que puede resistir el escrutinio de auditoría.

La brecha de identidad

ERC-8004 establece la identidad en cadena para agentes sin confianza: un registro donde un agente se registra con una billetera controladora, un punto de servicio y una referencia de modelo. En este momento, ese agente es solo un proceso opaco que se ejecuta dentro de la infraestructura de un proveedor. La entrada del registro lo convierte en un actor de primera clase en cadena con un origen verificable, que un contrato inteligente o un panel de cumplimiento puede comprobar directamente, sin confiar en un intermediario.

La capa de reputación se construye sobre esto. Las señales de retroalimentación escritas en el registro ERC-8004 son inmutables, con marca de tiempo y atribuibles. Cualquier sistema que quiera tomar decisiones de confianza sobre un agente puede leer ese registro directamente. A diferencia de una puntuación gestionada por el proveedor o una calificación en Discord, la confianza aquí es una propiedad de la red más que de quien controla la base de datos.

Ambas capas son implementables hoy sin ingeniería exótica. La mayoría de los despliegues no las tienen porque la ruta de implementación de menor resistencia sigue siendo tratar a los agentes como cuentas de servicio en lugar de como actores de primera clase. Un atajo razonable en un prototipo se convierte en deuda arquitectónica que se compone en producción.

El problema del mandato es donde las finanzas reguladas divergen de todo lo demás

La identidad y la reputación te dicen quién es un agente y cómo se ha comportado. No establecen qué está autorizado a hacer el agente. En muchos casos de uso de agentes, los controles de capa de aplicación pueden cubrir esa brecha. Para los agentes que operan con activos regulados, la cuestión de la autorización se vuelve una cuestión legal. La respuesta debe existir en una forma que pueda satisfacer a un regulador.

ERC-8226, el Estándar de Mandato de Agente Regulamentado (RAMS), está diseñado para cerrar esta brecha. RAMS define una capa de delegación de cumplimiento que se sitúa entre la identidad del agente y los marcos de cumplimiento a nivel de token. Un principal verificado mediante KYC otorga a un agente un mandato con un alcance definido, jurisdicción, límites de valor y fecha de expiración. En la práctica, funciona como un poder notarial en cadena que puede verificarse antes de la liquidación. El contrato de token regulado entonces verifica ese mandato de forma atómica dentro de su gancho de cumplimiento previo a la transferencia antes de que ocurra cualquier liquidación.

Dos interfaces llevan el diseño. `ComplianceProvider` es implementado por cualquier operador de KYC o atestación y garantiza la elegibilidad del principal para un alcance dado. `IAgentMandate` es el registro que registra concesiones, extensiones, revocaciones, ejecuciones y congelaciones a nivel de regulador. La aplicación ocurre a través de `recordExecution`, que verifica los límites del mandato activo en el momento de la transferencia y revierte si la transacción los violaría.

Esta arquitectura se sitúa entre la identidad ERC-8004 y los marcos de cumplimiento de tokens como ERC-7943, en lugar de reemplazar a ninguno de los dos. La identidad indica que el agente existe y es verificable; el cumplimiento de tokens, que el principal es elegible para poseer este activo específico. RAMS añade la parte que ninguno cubre: autoridad de este principal, para este alcance, dentro de estos límites, hasta esta fecha. La capa de delegación legalmente ejecutable que actualmente solo vive en PDFs y hojas de cálculo de back‑office se traslada a cadena, donde realmente puede aplicarse en el momento de la transferencia.

La separación de preparar y ejecutar no es fricción

Una decisión de diseño merece una defensa directa: separar la preparación de la transacción de la firma y difusión. Se elimina en muchos sistemas que intentan que los agentes se sientan más fluidos.

El instinto es colapsar esto en un solo paso porque parece más eficiente. Pero la brecha entre la preparación y la difusión es exactamente donde pertenece la supervisión institucional. Es donde un oficial de cumplimiento revisa lo que un agente está a punto de hacer antes de que la cadena lo conozca, donde una verificación de mandato RAMS valida la carga preparada contra el alcance activo, los límites de valor y la jurisdicción antes de que se produzca cualquier firma, y donde un CFO aprueba una acción de tesorería que un agente ha preparado pero aún no ha comprometido.

Muchas instituciones que despliegan agentes autónomos a escala significativa eventualmente reconstruyen esta separación cuando descubren que falta. Construirla como un primitivo arquitectónico deliberado en lugar de una adaptación que lleva a un sistema a través de su primera revisión de cumplimiento.

Cómo se ve la pila cuando está completa

Cuando las cuatro capas están en su lugar, se componen de manera limpia. ERC-8004 ancla la identidad del agente y la reputación en cadena, y ERC-8226 añade la capa de mandato que delimita lo que cada agente puede hacer y en nombre de quién. x402 gestiona la liquidación, firmando cada solicitud para que cada acción sea atribuible y auditable. Por debajo, los marcos de activos regulados como ERC-7943 hacen cumplir el cumplimiento en el momento de la transferencia contra tanto la elegibilidad del principal como el mandato activo del agente.

Estas piezas están en diferentes niveles de madurez, pero ninguna de ellas es puramente  

Estas piezas están en diferentes niveles de madurez, pero ninguna de ellas es puramente teórica. ERC-8004 es un ERC de la pista de estándares preliminares con primitivas de identidad y reputación desplegables. ERC-7943 es un estándar final de Ethereum. ERC-8226 está en la pista de estándares, y las interfaces centrales son lo suficientemente estables para trabajos de implementación temprana. x402 está en vivo y ya está diseñado alrededor de pagos HTTP programáticos para humanos y agentes.

Los equipos que lo hagan bien pueden construir esta pila ahora o esperar hasta que la presión de auditoría y cumplimiento obligue la adaptación. Las instituciones que lo hagan bien serán las que traten las capas de mandato e identidad como requisitos de infraestructura desde el primer día, de la misma manera que tratan KYC y custodia. Puede que los reguladores aún no hayan exigido explícitamente cada pieza. Los equipos que construyen sistemas de producción en este espacio ya saben lo costoso que es añadir estos controles después del hecho.