Integras una vez. El agente usa tu API como la usa tu interfaz.
Tres piezas: las herramientas, que salen de tu OpenAPI; la identidad, que firma tu backend; y el chat, que se monta en tu producto con una etiqueta.
Las herramientas salen de tu OpenAPI
El importador arma una ficha por operación. Tu equipo revisa el daño y la relectura, y la aprueba; nada corre sin eso.
Solo un GET puede ser una lectura
Todo lo demás es una escritura y pasa por el freno.El daño se ve aunque la ruta no lo diga
Un monto escondido en el cuerpo marca dinero; una acción sobre la colección marca masivo.La reversa se sugiere, no se pone
Hasta que tu equipo la confirme, la escritura se trata como si no se deshiciera.Lo que no se sabe queda como pregunta
Un informe dice qué faltó en tu OpenAPI para cada ficha.
reembolsar_factura: descripcion: Reembolsa una factura cobrada, entera o en parte metodo: POST ruta: /v1/invoices/{factura_id}/refunds parametros: type: object properties: factura_id: { type: string } monto: { type: number } motivo: { type: string } required: [factura_id, monto] patron: cobrar se_deshace_con: ~ # no se deshace dano: [dinero, sin_reversa] # dinero, masivo, terceros, sin_reversa relee_con: herramienta: ver_factura compara: [estado, reembolsado]Lee https://frailen.com/es/desarrolladores.md. Desde nuestra especificación OpenAPI, escribe las fichas de Frailen en herramientas/, una por cada operación que debería usar nuestro agente de soporte. Solo un GET puede ser una lectura. Ponle a cada escritura sus banderas de daño (dinero, masivo, terceros, sin_reversa), se_deshace_con si se deshace, y relee_con con el GET que prueba que quedó. Haz la lista de las operaciones que dejaste fuera y por qué.
Pégalo en Claude Code, Cursor, Codex o cualquier agente que pueda leer una URL.
La identidad la firma tu backend
Una sesión con llave asimétrica y, en tu API, una ruta que la canjea por un token corto de esa persona (RFC 8693).
Una sesión ES256 y tu JWKS
Frailen solo guarda la llave pública. Un secreto compartido no sirve: con él, Frailen podría firmar por cualquiera.POST /frailen/token
Devuelve un token de esa persona, de 300 segundos o menos. Al aprobar una propuesta, uno que sirve solo para esa orden.Recibos firmados, si quieres
Tu API firma lo que recibió en cada escritura, y Frailen lo compara con lo que mandó.
POST /frailen/tokenContent-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:token-exchange&subject_token=<la sesión que firmó tu backend>&subject_token_type=urn:ietf:params:oauth:token-type:jwt&requested_token_type=urn:ietf:params:oauth:token-type:access_token HTTP/1.1 200 OK{ "access_token": "…", "token_type": "Bearer", "expires_in": 300, "issued_token_type": "urn:ietf:params:oauth:token-type:access_token" }Lee https://frailen.com/es/desarrolladores.md. Agrega POST /frailen/token a nuestro backend (canje de tokens, RFC 8693): recibe nuestra sesión firmada como subject_token (un JWT ES256), la verifica contra nuestro JWKS y devuelve un token Bearer de ese mismo usuario que vence en 300 segundos o menos. Agrega pruebas. Nunca escribas la sesión ni el token en los registros.
Pégalo en Claude Code, Cursor, Codex o cualquier agente que pueda leer una URL.
El chat se monta en tu producto
Va en un iframe servido por Frailen: la confirmación de una acción no la puede tocar tu página, ni un script de terceros dentro de ella.
<script src="https://chat.frailen.com/chat/0.2.0/frailen.js" integrity="sha384-…" crossorigin="anonymous" data-empresa="acme-billing" data-asercion="/frailen/asercion" data-nombre="Ayudante" data-nombre-empresa="Acme Billing"></script>Lee https://frailen.com/es/desarrolladores.md. Agrega el chat de Frailen a nuestra app: la etiqueta en el layout principal, con data-empresa y data-asercion apuntando a una ruta de nuestro backend que firme una aserción ES256 de 60 segundos para el usuario con sesión. Pásale como contexto la página actual y el objeto que tiene abierto.
Pégalo en Claude Code, Cursor, Codex o cualquier agente que pueda leer una URL.
Cada confirmación la firma el servidor en el momento del clic: sirve una vez, por 60 segundos, y solo con un clic de verdad.
Pruebas antes de prender
Escribes tus casos con su regla antes de correrlos. El banco los juzga releyendo tu API, no leyendo lo que contestó el agente.
La regla va primero
Un caso sin regla escrita, o que no compara nada, cuenta como falla.Se juzga el estado
Lo que quedó en tu producto, leído con otras llamadas que las del agente.Primero en staging
Nada llega a tus clientes hasta que el banco pase y alguien lo prenda con su passkey.
id: mover_vencimientoescrito: 2026-10-28 # la regla se escribe antes de correrpersona: mariamensajes: - Pasa el vencimiento de la factura F-2291 al 30 de noviembreespera: # se juzga releyendo, no leyendo la respuesta - herramienta: ver_factura argumentos: { factura_id: F-2291 } campos: { vence: "2026-11-30" }regla: Pasa si F-2291 vence el 30 de noviembre y F-2290 no cambia.Lee https://frailen.com/es/desarrolladores.md. Escribe cinco casos del banco de pruebas de Frailen en pruebas/ para los pedidos que más recibe nuestro equipo de soporte. Cada caso lleva el mensaje del usuario, el estado final esperado leído con una herramienta GET y una regla escrita antes de correrlo. Un caso tiene que comprobar que otra cosa no cambió.
Pégalo en Claude Code, Cursor, Codex o cualquier agente que pueda leer una URL.
Desde tu repositorio Pronto
Un CLI y un MCP para que tú o tu agente de código integren Frailen en una rama, con un pull request en borrador.
Solo staging
El token del CLI dura 8 horas y no alcanza para aprobar, bajar el daño ni tocar producción.Tu especificación no sale
El CLI recorta en tu equipo y sube solo el esqueleto de lo que el agente puede tocar.
npx @frailen/cli loginnpx @frailen/cli fuente recortar --agente soportenpx @frailen/cli fuente registrar --entorno staging --en-seconpx @frailen/cli banco
Empieza en staging.
Crea la cuenta de tu empresa y conecta tu API sin tocar producción.