# Frailen: todo el sitio > Todas las páginas de https://frailen.com/es en Markdown, en un archivo, para agentes. Cada página también está sola: agrega .md a su ruta. --- # Frailen: la infraestructura de agentes para empresas de software > Haz tu empresa agéntica en dos clics. Frailen es la infraestructura de agentes para empresas de software. Conectas tu API una vez y los agentes operan tu producto a nombre de tus usuarios: con sus permisos, con freno en lo que tiene riesgo y con cada escritura comprobada. - Pedir una demo: [/es/demo](/es/demo) - Para desarrolladores: [/es/desarrolladores.md](/es/desarrolladores.md) - Instálalo con tu agente de código: [/es/agentes.md](/es/agentes.md) - Todo el sitio en un archivo: [/es/llms-full.txt](/es/llms-full.txt) ## Un pedido, por dentro Un ejemplo en Acme Billing, un producto inventado. Un usuario escribe: «Reembolsa la factura F-2291, al cliente le cobraron dos veces». El motor pasa por estos pasos: 1. **Canal:** chat dentro de Acme Billing. 2. **Identidad:** sesión firmada por Acme Billing · María, finanzas. 3. **Enrutador:** las herramientas de facturación, con el índice de todas. 4. **Modelo:** reembolsar la factura F-2291 por 480 USD. 5. **Política de daño:** mueve dinero, así que María confirma en la tarjeta. 6. **Ejecutor:** `POST /v1/invoices/F-2291/refunds`, con una Idempotency-Key. 7. **Relectura:** estado = reembolsada · verificado. 8. **Respuesta:** «Reembolsé 480 USD. Lo releí y quedó». ## Instálalo con tu agente de código Lo deja listo el agente que ya usas: Claude Code, Cursor, Codex, GitHub Copilot, Gemini CLI, Windsurf o cualquier agente que lea una URL y edite archivos. Copia esta línea en él: ```text Prepara Frailen por mí. Lee https://frailen.com/es/get-started.md y síguelo. ``` Apunta a [/es/get-started.md](/es/get-started.md), una guía que el agente sigue en una rama. Una persona aprueba las herramientas y prende el agente. ## Un modelo con las llaves de tu API puede actuar como cualquiera. Frailen no. Conectar un modelo a tu API es fácil. Lo difícil es todo lo que pasa cuando se equivoca. Frailen es esa capa, para cualquier agente que pongas encima. | Conectarlo por tu cuenta | Con Frailen | | --- | --- | | Actúa con una llave de servicio que puede hacer de todo. | Actúa con la sesión del usuario: si él no puede hacerlo, el agente tampoco. | | El prompt decide qué necesita aprobación. | El freno vive en el código, marcado en cada herramienta según el daño que puede hacer. | | Una respuesta 200 cuenta como hecho. | Cada escritura se relee: verificado, no aparece o no se pudo leer. | | Un timeout se reintenta, y a veces pasa dos veces. | Una Idempotency-Key por escritura; lo incierto nunca se repite a ciegas. | | Los registros quedan repartidos entre servicios. | Una bitácora que solo crece: qué hizo, a nombre de quién y cómo salió. | | Los datos de un cliente pueden colarse en el contexto de otro. | Cada fila lleva la empresa y la base impone el aislamiento, también al motor de Frailen. | ## Una conexión. Cualquier producto con API. El mismo motor decide, herramienta por herramienta, qué va directo, qué espera un clic y qué no intenta. Pedidos de ejemplo en productos inventados: | Producto | Pedido | Lo que decide el freno | | --- | --- | --- | | Facturación | «Reembolsa la factura F-2291» | Pide confirmación: mueve dinero | | Logística | «Pasa las 40 recogidas de mañana al jueves» | Pide confirmación: toca a muchos de golpe | | Recursos humanos | «Dale a Sofía el rol de administradora» | Pide confirmación: cambia un rol, se confirma siempre | | CRM | «Mándale esta cotización al cliente» | Pide confirmación: le llega a un tercero | | Clínicas | «Mueve la cita de María al viernes a las 3» | Se hace directo: se deshace y no le llega a nadie más | | Facturación | «Borra las facturas de prueba» | No lo intenta: quien lo pide no tiene ese permiso en tu producto | Hoy el primer agente es el de soporte dentro de tu producto. Las mismas herramientas, el freno y la relectura sirven para los que vengan después. ## El freno lo decide tu equipo, no el modelo. Cada herramienta lleva marcado el daño que puede hacer. Con eso, el código decide qué va directo y qué espera un clic de la persona, diga lo que diga el modelo. - **Mueve dinero:** cobros, precios, cortesías, devoluciones. - **Toca a muchos de golpe:** cambios o avisos sobre muchos registros a la vez. - **Le llega a terceros:** correos, WhatsApp, avisos a clientes. - **No se deshace:** borrar, cancelar, enviar. Cambiar con qué entra alguien (correo, teléfono, credenciales o rol) se confirma siempre, diga lo que diga la herramienta. La confirmación es una tarjeta en la que la persona hace clic; un «sí» escrito no cuenta. ## De tu API al agente, en staging primero. Nada llega a tus clientes hasta que tu equipo apruebe las herramientas, el banco de pruebas pase y alguien lo prenda. 1. **Conecta tu API.** El importador arma las herramientas desde tu OpenAPI, con su daño y su relectura. Tu equipo las revisa y aprueba. 2. **Pruébalo con tus casos.** Escribes los pedidos que debe resolver y la regla de cada uno. El banco los juzga releyendo tu API. 3. **Prende el agente en dos clics.** «Prender» y la passkey de quien lo aprueba. Desde ahí ves en el panel qué hizo, a nombre de quién y cuánto costó. ## Para quien lo integra: una etiqueta y una ruta. El chat va en un iframe de Frailen. Tu backend firma quién es cada persona; Frailen nunca tiene una llave para firmar por nadie. - **Las herramientas, desde tu OpenAPI.** Solo un GET puede leer; todo lo demás pasa por el freno. - **La identidad, desde tu backend.** Una sesión ES256 y una ruta que la canjea por un token corto de esa persona. - **El chat, con una etiqueta.** O con código o React, para pasarle lo que la persona tiene abierto. ```html ``` ## Seguro por cómo está hecho. - **Sin llave maestra.** Frailen solo recibe tu llave pública. Sin la sesión de la persona, no puede actuar. - **El token no se guarda.** Vive en memoria mientras dura la llamada. No va a la base ni a los registros. - **Nada de una empresa mejora a otra.** Sin aprendizaje compartido entre empresas. Las cachés llevan la empresa en su clave y la base no deja leer lo de otra. ## Preguntas frecuentes - **¿Qué necesitamos para integrarlo?** Tu OpenAPI (o solo la parte que el agente puede tocar), una ruta en tu backend que firme quién es cada usuario y una etiqueta para el chat. Todo corre primero en staging. - **¿El agente toca nuestra base de datos?** No. Todo entra por tu API, con los permisos del usuario a cuyo nombre actúa. - **¿Qué pasa si el modelo se equivoca?** El modelo solo elige. El código arma la llamada, aplica el freno y relee el resultado. Si una escritura no quedó, lo dice y pasa el caso a tu equipo. - **¿Entrenan con nuestros datos?** No. Nada de lo que pasa en una empresa mejora a otra: sin aprendizaje compartido y con las cachés separadas por empresa. - **¿Qué modelos usa?** Modelos de Google Cloud, en una región fija. Los elige Frailen y los mide con tu banco de pruebas. - **¿Cuánto cuesta?** Un mínimo mensual con un cupo de tareas, nunca por puesto ni por token. Durante los pilotos no hay cobro. Mira [/es/precios.md](/es/precios.md). ## Más páginas - Cómo funciona: [/es/producto.md](/es/producto.md) - Seguridad y datos: [/es/seguridad.md](/es/seguridad.md) - Precios: [/es/precios.md](/es/precios.md) - Para desarrolladores: [/es/desarrolladores.md](/es/desarrolladores.md) - Con tu agente: [/es/agentes.md](/es/agentes.md) - Esta página en inglés: [/index.md](/index.md) --- # Cómo funciona Frailen > Un motor para que los agentes actúen, no solo respondan. Cada pedido pasa por la identidad, el freno, una escritura única y la relectura, en tu API y con los permisos de tu usuario. El agente de encima puede cambiar; las garantías no. ## Un turno, por dentro Cada pedido es un turno con pasos que se guardan antes de hacerse. Si algo se cae a la mitad, se sabe dónde quedó. 1. **Entiende el pedido**, con lo que la persona escribió y lo que tiene abierto en tu producto. 2. **Lee lo que hace falta**, con las herramientas de lectura de tu API, con los permisos de esa persona. 3. **El freno decide.** Lo que no tiene daño, lo hace. Lo que lo tiene, sale como una tarjeta que la persona confirma. 4. **Escribe una sola vez**, con la identidad de la persona y una clave que evita hacerlo dos veces. 5. **Relee y compara.** Vuelve a leer en tu API y compara con lo que pidió. Si no coincide, lo dice. 6. **Lo deja en la bitácora**: qué hizo, a nombre de quién y cómo salió la relectura. Nadie la edita. Traza de ejemplo en Acme Billing (un producto inventado): | Paso | Detalle | | --- | --- | | Canal | Chat dentro de Acme Billing | | Identidad | Sesión firmada por Acme Billing · María | | Modelo | Pasar el vencimiento de la factura F-2291 al 30 | | Política de daño | Cambiar una fecha se deshace: va directo | | Ejecutor | `PATCH /v1/invoices/F-2291` | | Relectura | vence = 2026-11-30 · verificado | | Respuesta | «Listo: F-2291 vence el 30 de noviembre» | ## El freno, según el daño Tu equipo marca en cada herramienta qué daño puede hacer. El freno no depende de lo que el modelo diga: lo decide el código con esas marcas. - **Mueve dinero:** cobros, precios, cortesías, devoluciones. - **Toca a muchos de golpe:** cambios o avisos sobre muchos registros a la vez. - **Le llega a terceros:** correos, WhatsApp, avisos a clientes. - **No se deshace:** borrar, cancelar, enviar. - **Correo, teléfono, credenciales y rol:** cambiar con qué entra alguien se confirma siempre, diga lo que diga la herramienta. Tres resultados posibles: - **Se hace directo:** mover un vencimiento se deshace moviéndolo de vuelta. - **Pide confirmación:** porque mueve dinero y toca a muchos de golpe. - **No lo intenta:** esa persona no tiene permiso para cobrar en tu producto. ## Relee lo que escribe Una respuesta 200 no prueba que el cambio quedó. El agente vuelve a leer en tu API y compara con lo que pidió. Tres veredictos, nunca otro: - **verificado:** se releyó y el cambio quedó como se aprobó. - **no aparece:** se releyó y el cambio no está. No se repite a ciegas. - **no se pudo leer:** no sabe si quedó. No se repite: ofrece pasar a una persona. Si no se puede saber si quedó, no lo repite a ciegas: lo dice, lo marca como incierto y ofrece pasar a una persona. ## Lo que ve tu equipo Un panel con lo que hizo el agente, cuánto costó y lo que espera una decisión. Cada acción del panel pide la passkey de quien la hace. - **La bitácora:** hora, herramienta, objeto, a nombre de quién y el resultado de cada acción. Solo se agrega. - **El medidor de tareas:** las tareas del mes contra el cupo del nivel («hasta»), y cuántas se resolvieron con una acción verificada. - **El tope de gasto:** al llegar, el agente pasa cada caso a una persona hasta que lo subas o empiece el mes. ## Cuando no puede, lo dice Si falta un permiso, la API falla o el pedido no está en sus herramientas, no inventa: ofrece pasar el caso a una persona de tu equipo, y la respuesta vuelve al mismo chat. ## Más - Portada: [/es/index.md](/es/index.md) · Seguridad: [/es/seguridad.md](/es/seguridad.md) · Desarrolladores: [/es/desarrolladores.md](/es/desarrolladores.md) - Esta página en inglés: [/producto.md](/producto.md) --- # Seguridad y datos en Frailen > El agente actúa como la persona, nunca como Frailen. Frailen no tiene una llave con la que pueda firmar a nombre de nadie. Cada cambio sale con la identidad de quien lo pidió, pasa por los permisos de tu producto y queda escrito. ## Identidad Tu producto ya sabe quién es cada persona y qué puede hacer. Frailen se apoya en eso, no lo reemplaza. - **Tu backend firma la sesión.** Con una llave asimétrica que es tuya. Frailen solo recibe la llave pública: no puede firmar una sesión, así que no puede actuar por alguien que no la tiene. - **Los permisos son los de tu producto.** El agente lee y escribe en tu API con un token corto de esa persona. Si ella no puede hacer algo, el agente tampoco. - **El token no se guarda.** Vive en la memoria mientras dura la llamada. No va a la base, ni a los registros, ni a una URL. - **Las acciones del panel piden passkey.** Aprobar una herramienta, publicar una configuración o prender el agente pide la passkey de quien lo hace, en ese momento. ## Tus datos Qué guarda Frailen, para qué y cuánto tiempo. - **Tu especificación se queda contigo.** De tu OpenAPI sube solo el esqueleto de lo que el agente puede tocar. La fuente no sale de tu equipo. - **Cada empresa, aislada.** Todo lo que se guarda lleva la empresa, y la base no deja leer lo de otra: ni el propio motor de Frailen puede saltarse esa regla. - **Una bitácora que solo crece.** Cada acción, a nombre de quién y cómo salió la relectura. La base no deja cambiarla ni borrarla. - **Modelos en una región fija.** Los modelos corren en Google Cloud, en una sola región y no en el endpoint global, con la caché apagada. ## Lo que el agente no se deja hacer Defensas que no dependen de que el modelo se porte bien. - **Instrucciones escondidas en los datos.** Si una respuesta de tu API trae texto que intenta dar órdenes, el turno pierde la confianza y todo lo que escriba pasa a pedir confirmación. - **Recibos firmados por tu API.** Tu API puede firmar un recibo de cada escritura. Si lo que se ejecutó no es lo que se pidió, el caso pasa a una persona. ## Lo que todavía no tenemos Para que lo sepas antes de preguntar. - Una certificación como SOC 2. - Una prueba de penetración externa. Va antes del primer cliente fuera de nuestro piloto. - La política de tratamiento de datos publicada. Si tu equipo de seguridad necesita algo más para evaluarnos, escríbenos en la demo: [/es/demo](/es/demo). ## Más - Portada: [/es/index.md](/es/index.md) · Cómo funciona: [/es/producto.md](/es/producto.md) · Desarrolladores: [/es/desarrolladores.md](/es/desarrolladores.md) - Esta página en inglés: [/seguridad.md](/seguridad.md) --- # Precios de Frailen > Pagas por lo que el agente atiende. Nunca por puesto ni por token. Un mínimo mensual por empresa, con un cupo de tareas. Una tarea es una conversación atendida, de hasta ocho turnos. Son precios de referencia mientras medimos el costo real: los cupos se publican como «hasta». Durante los pilotos no hay cobro. ## Niveles | Nivel | Precio | Cupo | Para | Incluye | | --- | --- | --- | --- | --- | | Entrada | 99 USD al mes | Hasta 600 tareas | Empezar con un agente de soporte | Un agente de soporte con acciones; el chat dentro de tu producto; cobrar y borrar solo proponen, tu equipo decide | | Crecimiento | 400 USD al mes | Hasta 3.000 tareas | Cuando el agente ya resuelve buena parte del soporte | Todo lo de Entrada; cobrar y borrar, con confirmación; 8 horas al mes de acompañamiento | | Enterprise | Desde 1.000 USD | A medida | Volúmenes grandes o reglas de datos propias | Cupo a medida; 40 horas al mes de acompañamiento; cláusulas de datos negociadas; implementación a precio fijo, aparte | ## En todos los niveles Lo que sube de nivel es el volumen y el acompañamiento. La seguridad no se cobra aparte. - **El freno y la relectura.** Lo que tiene daño se confirma y cada escritura se relee. Nunca se cobra el freno. - **La identidad de cada persona.** El agente actúa con los permisos de quien escribe. - **La bitácora.** Cada acción, a nombre de quién y cómo salió. - **La promesa de datos.** Tu especificación se queda contigo y cada empresa va aislada. - **Un tope de gasto.** Al llegar, el agente pasa los casos a una persona de tu equipo. - **Staging primero.** Todo se prueba sin tocar producción. ## Preguntas frecuentes - **¿Qué es una tarea?** Una conversación atendida, de hasta ocho turnos. Las que pasan del cupo del mes se cobran aparte, hasta el tope de gasto que pongas. - **¿Qué pasa al llegar al tope de gasto?** El agente deja de atender y pasa los casos a una persona de tu equipo. No se cobra de más. - **¿Hay un plan gratis?** No hay un plan gratis permanente. Durante los pilotos no hay cobro. - **¿En qué moneda se cobra?** Cuando haya cobro, en pesos colombianos o mexicanos, con factura electrónica local. Los precios de esta página están en dólares como referencia. - **¿Por qué no por puesto?** Porque el agente no es una persona más del equipo: cobra por lo que atiende, y lo que atiende lo ves en el medidor. ## Más - Pedir una demo: [/es/demo](/es/demo) · Portada: [/es/index.md](/es/index.md) - Esta página en inglés: [/precios.md](/precios.md) --- # Frailen para desarrolladores > 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. Si eres un agente de código: lee esta página y después sigue los prompts de [/es/agentes.md](/es/agentes.md). Prepara la integración en una rama; nunca apruebes, publiques ni despliegues. ## 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. Banderas de daño: `dinero`, `masivo`, `terceros`, `sin_reversa`. Patrones: `consultar`, `cambiar`, `pausar`, `agendar`, `cobrar`, `avisar`, `borrar`, `reportar`. ```yaml # herramientas/facturas.yaml 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] ``` ## 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ó. ```http POST /frailen/token Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:token-exchange &subject_token= &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" } ``` ## 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. 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. Una etiqueta: ```html ``` Con código: ```js import { montar } from "@frailen/chat-web" const chat = montar({ empresa: "acme-billing", marco: "https://chat.frailen.com", asercion: "/frailen/asercion", // tu backend la firma (ES256, 60 s) alEvento: (e) => e.tipo === "escritura" && releer(e.id), }) // Lo que la persona tiene abierto: el agente lo usa de pista. chat.contexto({ ruta: location.pathname, objeto: { tipo: "factura", id: "F-2291" } }) ``` React: ```tsx import { FrailenChat } from "@frailen/chat-web/react" releer(e)} /> ``` `@frailen/chat-web` todavía no está publicado en un registro público. ## 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. ```yaml # pruebas/mover_vencimiento.yaml id: mover_vencimiento escrito: 2026-10-28 # la regla se escribe antes de correr persona: maria mensajes: - Pasa el vencimiento de la factura F-2291 al 30 de noviembre espera: # 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. ``` ## 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. Están en construcción y todavía no se pueden usar. - **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. ```bash npx @frailen/cli login npx @frailen/cli fuente recortar --agente soporte npx @frailen/cli fuente registrar --entorno staging --en-seco npx @frailen/cli banco ``` ## Más - Con tu agente (prompts): [/es/agentes.md](/es/agentes.md) · Seguridad: [/es/seguridad.md](/es/seguridad.md) - Esta página en inglés: [/desarrolladores.md](/desarrolladores.md) --- --- name: frailen-empezar area: Empezar description: |- Pásale esta guía a tu agente de código para preparar Frailen en un repositorio: las fichas desde el OpenAPI, la ruta del token, la etiqueta del chat y los primeros casos del banco de pruebas, todo en una rama. title: 'Prepara a tu agente para Frailen' url: https://frailen.com/es/get-started.md --- # Prepara Frailen con tu agente de código Usa esta guía para preparar el repositorio actual para Frailen. Tú haces el trabajo en una rama nueva; una persona de la empresa aprueba las herramientas y prende el agente con su passkey. ## Cómo correrla Corre las secciones en orden, en el repositorio actual. Haz tú las acciones cuando tengas acceso a la terminal o a los archivos; no te limites a devolver comandos para que el usuario los copie. Detente solo para las decisiones que son de una persona: qué operaciones puede tocar el agente, el id de la empresa y cualquier cosa sobre producción. Si un paso queda bloqueado, anota por qué y sigue con los demás. Nunca apruebes, publiques ni despliegues nada. Nunca pongas sesiones, tokens ni llaves en registros, commits ni URLs. El CLI de Frailen (`@frailen/cli`) y su servidor MCP todavía no están: todo aquí funciona con archivos del repositorio. Referencia: [llms.txt](https://frailen.com/es/llms.txt) · [Para desarrolladores](https://frailen.com/es/desarrolladores.md) · [Seguridad](https://frailen.com/es/seguridad.md) ## 0. Abre una rama ```sh git status git switch -c frailen ``` Si hay cambios sin commit, pregunta antes de cambiar de rama. ## 1. Encuentra la API Busca una especificación OpenAPI (`openapi.yaml`, `openapi.json`, `swagger.json`, o la que genere el framework). Si no hay, haz la lista de rutas desde el código: routers, controladores, handlers. Escribe en `frailen/operaciones.md` las operaciones que necesitaría un agente de soporte, una por línea, y marca las que mueven dinero, tocan muchos registros a la vez, le llegan a terceros (correos, WhatsApp, avisos) o no se deshacen. Pídele al usuario que confirme la lista antes de escribir las fichas de escrituras. ## 2. Escribe las fichas Una ficha por operación en `herramientas/.yaml`. El formato tiene sus claves en español: ```yaml 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 } required: [factura_id, monto] patron: cobrar # consultar, cambiar, pausar, agendar, cobrar, avisar, borrar, reportar se_deshace_con: ~ # la herramienta que lo deshace, o ~ si no se deshace dano: [dinero, sin_reversa] relee_con: herramienta: ver_factura compara: [estado, reembolsado] ``` Reglas: - Solo un GET puede ser una lectura. Todo lo demás es una escritura y pasa por el freno. - Ponle a cada escritura sus banderas de daño: `dinero`, `masivo`, `terceros`, `sin_reversa`. Un monto en el cuerpo es `dinero`; una acción sobre toda una colección es `masivo`. - Pon `se_deshace_con` solo si existe una reversa de verdad. Si dudas, deja `~`. - `relee_con` nombra la herramienta GET y los campos que prueban que la escritura quedó. - Nunca bajes ni quites una bandera de daño para que algo pase. Termina con la lista de operaciones que dejaste fuera y por qué. ## 3. Agrega la ruta del token Agrega `POST /frailen/token` al backend (canje de tokens, RFC 8693): - Recibe como `subject_token` la sesión que firma tu backend: un JWT ES256, verificado contra tu JWKS. - Devuelve un token Bearer de ese mismo usuario, con `expires_in` de 300 segundos o menos. - Agrega pruebas para una sesión válida, una vencida y una alterada. Si las sesiones se firman con un secreto compartido (HS256), detente y pregunta: Frailen necesita una llave asimétrica, porque con un secreto compartido podría firmar por cualquiera. Nunca escribas la sesión ni el token en los registros. ## 4. Monta el chat Agrega la etiqueta al layout principal de la app: ```html ``` - Pídele al usuario el id de la empresa si no lo sabes. - Agrega la ruta `/frailen/asercion`: firma una aserción ES256 de 60 segundos para el usuario con sesión. - `@frailen/chat-web` (código y React) todavía no está publicado: usa la etiqueta. ## 5. Escribe los primeros casos del banco De tres a cinco casos en `pruebas/.yaml`, para los pedidos que más recibe el equipo de soporte: ```yaml id: mover_vencimiento escrito: # la regla se escribe antes de correr persona: mensajes: - Pasa el vencimiento de la factura F-2291 al 30 de noviembre espera: # 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. ``` Al menos un caso tiene que comprobar que otra cosa no cambió. ## 6. Deja las reglas para los próximos agentes Agrega esto al `AGENTS.md` (o al `CLAUDE.md`), y créalo si no existe: ```markdown ## Frailen - Antes de tocar archivos de Frailen, lee https://frailen.com/es/llms.txt (y https://frailen.com/es/llms-full.txt si necesitas el detalle). - Las fichas van en herramientas/*.yaml y los casos del banco en pruebas/*.yaml. - Solo un GET puede ser una lectura. Toda escritura lleva sus banderas de daño; nunca quites una para que pase una prueba. - Nunca escribas en registros ni subas al repositorio sesiones, tokens ni llaves. - Tú preparas la integración en una rama. Una persona aprueba las herramientas y prende el agente con su passkey: tú nunca apruebas, publicas ni despliegas. ``` ## 7. Termina Haz commit en la rama. No hagas push a menos que el usuario lo pida. Después informa: - Los archivos que creaste o cambiaste. - Las operaciones cubiertas y las que quedaron fuera, con el motivo. - Las banderas de daño o las reversas que necesitan la decisión de una persona. - Cualquier paso bloqueado y por qué. - Lo que sigue para la empresa: aprobar las herramientas en el panel de Frailen, correr el banco de pruebas en staging y prender el agente con una passkey. --- # Frailen, instalado por tu agente > Tu agente de código puede leer todo el sitio, armar las fichas desde tu OpenAPI y preparar la integración en una rama. Tú revisas y apruebas; él nunca publica. ## Empieza con una línea Cópiala en Claude Code, Cursor, Codex o cualquier agente que pueda leer una URL. Apunta a [get-started.md](https://frailen.com/es/get-started.md), una guía que tu agente sigue paso a paso en una rama. ```text Prepara Frailen por mí. Lee https://frailen.com/es/get-started.md y síguelo. ``` En Claude Code, desde tu terminal: ```bash claude "Prepara Frailen por mí. Lee https://frailen.com/es/get-started.md y síguelo." ``` ## O el prompt completo El mismo trabajo en un solo prompt, si prefieres verlo todo antes de pegarlo. ### Instala Frailen en este repositorio ```text Lee https://frailen.com/es/llms.txt y https://frailen.com/es/desarrolladores.md. Después prepara Frailen en este repositorio, en una rama nueva: 1. Busca nuestra especificación OpenAPI, o las rutas de la API que un agente de soporte puede tocar. Escribe una ficha de Frailen por operación en herramientas/*.yaml, con su patrón, sus banderas de daño (dinero, masivo, terceros, sin_reversa), cómo se deshace y cómo se relee. Solo un GET puede ser una lectura. 2. Agrega POST /frailen/token a nuestro backend: canjea nuestra sesión firmada (un JWT ES256) por un token de API de ese mismo usuario, de 300 segundos o menos (RFC 8693). 3. Agrega la etiqueta del chat de Frailen al layout principal de la app. 4. Escribe tres casos del banco de pruebas en pruebas/ para nuestros pedidos de soporte más comunes. No apruebes, publiques ni despliegues nada. Termina con un resumen de lo que hiciste y de lo que necesita una decisión de una persona. ``` ## Un prompt para cada paso Pega cualquiera en Claude Code, Cursor, Codex o cualquier agente que pueda leer una URL. ### Pregúntale si encaja con tu producto ```text Lee https://frailen.com/es/llms-full.txt. Después mira nuestro código y dime si Frailen encaja con nuestro producto: qué operaciones de la API serían herramientas, cuáles tendrían daño, qué nos faltaría construir y qué preguntarías en la demo. No cambies nada. ``` ### Arma las fichas desde nuestro OpenAPI ```text 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é. ``` ### Agrega la ruta del token ```text 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. ``` ### Monta el chat en la app ```text 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. ``` ### Escribe el banco de pruebas ```text 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ó. ``` ### Revisa la seguridad con tu agente ```text Lee https://frailen.com/es/seguridad.md y https://frailen.com/es/llms.txt. Revisa el modelo de seguridad de Frailen contra nuestro producto: identidad y tokens, qué se guarda y por cuánto tiempo, el aislamiento entre empresas y cómo funciona el freno. Haz la lista de preguntas que nuestro equipo de seguridad debería hacer antes de un piloto, y de lo que Frailen dice que todavía no tiene. ``` ### Calcula qué nivel les sirve ```text Lee https://frailen.com/es/precios.md. Nuestro producto atiende unas [conversaciones al mes] conversaciones de soporte al mes. Calcula qué nivel de Frailen nos sirve, cuánto pagaríamos con esos precios de referencia y qué tope de gasto pondrías. Di qué números son supuestos. ``` ## Lo que tu agente puede leer - [https://frailen.com/es/llms.txt](https://frailen.com/es/llms.txt): el resumen, con enlaces. - [https://frailen.com/es/llms-full.txt](https://frailen.com/es/llms-full.txt): todo el sitio en un archivo. - Cada página en Markdown: agrega `.md` a su ruta, como https://frailen.com/es/precios.md o https://frailen.com/es/desarrolladores.md. La portada es https://frailen.com/es/index.md. - En inglés, los mismos archivos sin /es: https://frailen.com/llms.txt. ## Reglas para tu agente Agrega esto al AGENTS.md o al CLAUDE.md de tu repositorio: ```markdown ## Frailen - Antes de tocar archivos de Frailen, lee https://frailen.com/es/llms.txt (y https://frailen.com/es/llms-full.txt si necesitas el detalle). - Las fichas van en herramientas/*.yaml y los casos del banco en pruebas/*.yaml. - Solo un GET puede ser una lectura. Toda escritura lleva sus banderas de daño; nunca quites una para que pase una prueba. - Nunca escribas en registros ni subas al repositorio sesiones, tokens ni llaves. - Tú preparas la integración en una rama. Una persona aprueba las herramientas y prende el agente con su passkey: tú nunca apruebas, publicas ni despliegas. ``` ## Lo que viene El CLI (`@frailen/cli`) y un servidor MCP para agentes de código están en construcción. Mientras tanto, tu agente trabaja con estos archivos y estos prompts. Esta página en inglés: [/agentes.md](/agentes.md)