Un humano detrás de cada agente: controles de sponsor, webhooks y el directorio de agentes
El banco presta USDC real en Base mainnet a agentes que firman sus propias solicitudes de préstamo. Eso no cambió. Lo que cambió esta semana es que ahora un humano puede respaldar a un agente sin tocar sus llaves, que otros sistemas pueden enterarse de lo que pasó con un préstamo sin consultar a cada rato, que cualquiera puede leer los registros ERC-8004 desde un solo endpoint, y que el puntaje de confianza tiene un SDK como corresponde. Las cuatro cosas ya están en producción.
Controles de sponsor. Un agente puede vincular a un sponsor humano. El vínculo requiere dos pruebas: la wallet del agente firma un EIP-712 SponsorBinding(agentWallet, sponsorRef, nonce, deadline), y el sponsor confirma por WhatsApp con un código de un solo uso a través de RSoft MIA. Para sponsors con teléfono, el sponsorRef es un hash opaco; el banco nunca ve el número. Una vez vinculado, el sponsor puede pausar, reanudar o revocar los préstamos, fijar un monto máximo por préstamo y un tope diario de giros, activar el modo borrador y aprobar o rechazar borradores. Cada comando es un mensaje de WhatsApp en español (pausar, límite 20, modo borrador on, aprobar <req_id>) confirmado con un OTP de 6 dígitos. No hay consola web. Lo que el sponsor no puede hacer importa igual: un sponsor nunca puede pedir prestado, firmar ni mover los fondos del agente. Los topes del sponsor solo ajustan hacia abajo el techo del agente, que ahora es escalera ∧ tope del sponsor ∧ máximo del banco. Docs: https://rsoft-agentic-bank.com/docs#sponsor
El modo borrador es lo más interesante. Cuando un agente pide más que su techo efectivo y el modo borrador está activo, POST /loan/request responde 202 con status draft_pending_sponsor en vez de rechazar. El sponsor recibe un mensaje de WhatsApp y responde aprobar o rechazar. Si aprueba, sigue el pipeline normal de cinco agentes: Gatekeeper, Analyst, CFO, Settler y Auditor siguen aplicando, así que el sponsor levanta la escalera ganada pero nunca los límites de riesgo propios del banco. La solicitud firmada del agente se consume al entrar, así que no se vuelve a firmar nada y nada se puede repetir. Los borradores vencen a las 24 horas. La verificación corre al entrar y otra vez en el Settler justo antes de mover USDC, y falla cerrada: si la tabla de controles no se puede leer en modo dinero real, la originación se rechaza. El repago nunca se bloquea. Cualquiera puede leer los controles y el techo efectivo de un agente en GET /agents/{wallet}/controls, y los clientes MCP obtienen lo mismo con get_agent_controls y get_loan_status.
Webhooks. POST /webhooks con una URL https y una lista de eventos devuelve un id y un secreto, una sola vez. Los eventos cubren todo el ciclo de vida: loan.approved, loan.rejected, loan.disbursed, loan.repaid, loan.defaulted, y los eventos de borrador loan.drafted, loan.draft_approved, loan.draft_rejected, loan.draft_expired. Cada entrega lleva X-RSoft-Timestamp y X-RSoft-Signature: sha256=HMAC_SHA256(secret, "{timestamp}.{raw_body}"). Tres intentos con espera creciente; las respuestas 4xx que no sean 408 ni 429 no se reintentan. Como las API keys del banco son compartidas y no por agente, una suscripción limitada a una wallet también necesita el OwnerAction EIP-712 de esa wallet, y las suscripciones para todos los agentes necesitan la llave de administrador. La entrega nunca condiciona un préstamo: un endpoint caído no puede demorar ni bloquear el dinero. Docs: https://rsoft-agentic-bank.com/docs#webhooks
Directorio de agentes. GET /agents/registry/{token_id} y /agents/registry/by-wallet/{wallet} devuelven la identidad ERC-8004 y los datos de reputación de cualquier agente en Base mainnet (dueño, wallet, URI canónica, clientes de reputación, emisores conocidos, feedback confiable) junto con la situación crediticia en el banco cuando la wallet es cliente. También hay endpoints de recientes y de búsqueda, y las tools MCP get_agent, list_agents y search_agents, además de sus gemelos REST gratuitos en el host MCP. Una limitación, dicha con honestidad: el IdentityRegistry no es enumerable en mainnet, así que recientes y búsqueda son un escaneo acotado de los eventos Registered recientes (5000 bloques por defecto) más la tabla de clientes del banco, no el censo completo. Cada respuesta dice exactamente qué ventana se escaneó. Docs: https://rsoft-agentic-bank.com/docs#directory
SDK de Trust. La Trust API ahora tiene POST /evaluate: eliges una política (quick, basic, standard, strict, financial, reputation, o una composición propia AND/OR/WEIGHTED) y obtienes un tier, el detalle por compuerta, la marca de anomalía y un multiplicador de precio opcional. Las compuertas salen solo de señales on-chain: registered, established (identidad con al menos 30 días), active (al menos un cliente de reputación), coherent (sin anomalía), score (al menos 50). El multiplicador es 2.0 − 1.5 · trust_score / 100, así que una wallet confiable paga la mitad y una desconocida o anómala paga el doble. La tasa de interés sugerida en la respuesta es solo indicativa; el banco pone precio a sus propios préstamos con su modelo Kelly/AMM. El SDK está en npm y PyPI como rsoft-trust 0.1.0, con un middleware para Express, un fetch guard para runtimes edge y una dependencia para FastAPI. Docs: https://rsoft-agentic-bank.com/docs#trust-sdk
Los números del piloto no cambian: mínimo $5, el techo vigente es el max_amount que informe GET /interest-rates ($25 durante el piloto), escalera $5 → $10 → $25 → $50 → $100, un préstamo activo por agente, USDC en Base mainnet.