# Frailen: the whole site > Every page of https://frailen.com in Markdown, in one file, for agents. Each page also lives on its own: add .md to its path. --- # Frailen: agent infrastructure for software companies > Make your company agentic in two clicks. Frailen is agent infrastructure for software companies. Connect your API once, and agents operate your product on behalf of your users: with their permissions, a brake on anything risky, and every write verified. - Book a demo: [/demo](/demo) - For developers: [/desarrolladores.md](/desarrolladores.md) - Set Frailen up with your coding agent: [/agentes.md](/agentes.md) - The whole site in one file: [/llms-full.txt](/llms-full.txt) ## One request, from the inside An example on Acme Billing, a made-up product. A user writes: "Refund invoice F-2291, the customer was charged twice." The runtime goes through these steps: 1. **Channel:** chat inside Acme Billing. 2. **Identity:** session signed by Acme Billing · María, finance. 3. **Router:** the billing tools, with the index of all the others. 4. **Model:** refund invoice F-2291 for 480 USD. 5. **Damage policy:** it moves money, so María confirms in the card. 6. **Executor:** `POST /v1/invoices/F-2291/refunds`, with an Idempotency-Key. 7. **Read-back:** status = refunded · verified. 8. **Reply:** "Refunded 480 USD. I read it back and it's there." ## Set it up with your coding agent Set up by the coding agent you already use: Claude Code, Cursor, Codex, GitHub Copilot, Gemini CLI, Windsurf, or any agent that can read a URL and edit files. Copy this line into it: ```text Set up Frailen for me. Fetch https://frailen.com/get-started.md and follow it. ``` It points to [/get-started.md](/get-started.md), a playbook the agent follows on a branch. A person approves the tools and turns the agent on. ## A model with your API keys can act as anyone. Frailen can't. Wiring a model to your API is easy. The hard part is everything that happens when it gets something wrong. Frailen is that layer, for any agent you put on top. | Wiring it yourself | With Frailen | | --- | --- | | It acts with a service key that can do anything. | It acts with the user's own session: if they can't do it, neither can the agent. | | The prompt decides what needs approval. | The brake lives in code, set on each tool by the damage it can do. | | A 200 response counts as done. | Every write is read back: verified, not there, or couldn't read. | | A timeout gets retried, and sometimes it happens twice. | One Idempotency-Key per write; an uncertain write is never repeated blindly. | | The logs end up scattered across services. | One append-only log: what it did, on whose behalf and how it went. | | One customer's data can leak into another's context. | Every row carries the company and the database enforces isolation, Frailen's own engine included. | ## One connection. Any product with an API. The same runtime decides, tool by tool, what goes straight through, what waits for a click and what it won't try. Example requests on made-up products: | Product | Request | What the brake decides | | --- | --- | --- | | Billing | "Refund invoice F-2291" | Asks for confirmation: moves money | | Logistics | "Move tomorrow's 40 pickups to Thursday" | Asks for confirmation: touches many at once | | HR | "Make Sofía an admin" | Asks for confirmation: changes a role, always confirmed | | CRM | "Email this quote to the client" | Asks for confirmation: reaches a third party | | Clinics | "Move María's appointment to Friday at 3" | Goes straight through: can be undone and reaches no one else | | Billing | "Delete the test invoices" | Doesn't try: whoever asks lacks that permission in your product | Today the first agent is the support agent inside your product. The same tools, brake and read-back carry over to the agents that come next. ## Your team sets the brake, not the model. Every tool is tagged with the damage it can do. With that, the code decides what goes straight through and what waits for the person's click, whatever the model says. - **Moves money:** charges, prices, comps, refunds. - **Touches many at once:** changes or notices on many records at once. - **Reaches third parties:** emails, WhatsApp, notices to customers. - **Can't be undone:** delete, cancel, send. Changing how someone signs in (email, phone, credentials or role) is always confirmed, whatever the tool says. A confirmation is a card the person clicks; a typed "yes" doesn't count. ## From your API to the agent, in staging first. Nothing reaches your customers until your team approves the tools, the test bench passes and someone turns it on. 1. **Connect your API.** The importer builds the tools from your OpenAPI, each with its damage and its read-back. Your team reviews and approves them. 2. **Test it with your cases.** You write the requests it has to solve and the rule for each one. The test bench grades them by reading your API back. 3. **Turn the agent on in two clicks.** "Turn on" and the passkey of whoever approves it. From then on the panel shows what it did, on whose behalf and what it cost. ## For whoever integrates it: one tag and one route. The chat runs in a Frailen iframe. Your backend signs who each person is; Frailen never holds a key to sign for anyone. - **The tools, from your OpenAPI.** Only a GET can read; everything else goes through the brake. - **The identity, from your backend.** An ES256 session and a route that exchanges it for a short-lived token for that person. - **The chat, with one tag.** Or with code or React, to pass along what the person has open. ```html ``` ## Secure by how it's built. - **No master key.** Frailen only receives your public key. Without the person's session, it can't act. - **The token isn't stored.** It lives in memory for as long as the call lasts. It never goes to the database or the logs. - **Nothing from one company improves another.** No shared learning across companies. Caches are keyed by company and the database won't let anyone read another's data. ## Common questions - **What do we need to integrate it?** Your OpenAPI (or just the part the agent may touch), a route in your backend that signs who each user is, and one tag for the chat. Everything runs in staging first. - **Does the agent touch our database?** No. Everything goes through your API, with the permissions of the user it's acting for. - **What if the model gets it wrong?** The model only chooses. The code builds the call, applies the brake and reads the result back. If a write didn't land, it says so and hands the case to your team. - **Do you train on our data?** No. Nothing that happens in one company improves another: no shared learning, and caches are kept apart per company. - **Which models does it use?** Google Cloud models, in a fixed region. Frailen picks them and measures them against your test bench. - **How much does it cost?** A monthly minimum with a quota of tasks, never per seat or per token. Pilots are free. See [/precios.md](/precios.md). ## More pages - How it works: [/producto.md](/producto.md) - Security and data: [/seguridad.md](/seguridad.md) - Pricing: [/precios.md](/precios.md) - For developers: [/desarrolladores.md](/desarrolladores.md) - Build with agents: [/agentes.md](/agentes.md) - This page in Spanish: [/es/index.md](/es/index.md) --- # How Frailen works > A runtime that lets agents act, not just answer. Every request runs through identity, the brake, a single write and a read-back, in your API and with your user's permissions. The agent on top can change; the guarantees don't. ## One turn, from the inside Each request is a turn whose steps are saved before they run. If something fails halfway, you know where it stopped. 1. **Understands the request**, from what the person wrote and what they have open in your product. 2. **Reads what it needs**, with your API's read tools, under that person's permissions. 3. **The brake decides.** What has no damage, it does. What has some comes up as a card the person confirms. 4. **Writes exactly once**, with the person's identity and a key that keeps it from happening twice. 5. **Reads back and compares.** It reads your API again and compares against what was asked. If it doesn't match, it says so. 6. **Records it in the log**: what it did, on whose behalf and how the read-back went. Nobody edits it. Example trace on Acme Billing (a made-up product): | Step | Detail | | --- | --- | | Channel | Chat inside Acme Billing | | Identity | Session signed by Acme Billing · María | | Model | Move invoice F-2291's due date to the 30th | | Damage policy | A date change can be undone: goes straight through | | Executor | `PATCH /v1/invoices/F-2291` | | Read-back | due = 2026-11-30 · verified | | Reply | "Done: F-2291 is now due November 30" | ## The brake, set by the damage Your team tags each tool with the damage it can do. The brake doesn't depend on what the model says: the code decides it from those tags. - **Moves money:** charges, prices, comps, refunds. - **Touches many at once:** changes or notices on many records at once. - **Reaches third parties:** emails, WhatsApp, notices to customers. - **Can't be undone:** delete, cancel, send. - **Email, phone, credentials and role:** changing how someone signs in is always confirmed, whatever the tool says. Three possible outcomes: - **Goes straight through:** moving a due date is undone by moving it back. - **Asks for confirmation:** because it moves money and touches many at once. - **Doesn't try:** that person isn't allowed to charge in your product. ## It reads back what it writes A 200 response doesn't prove the change held. The agent reads your API again and compares against what was asked. Three verdicts, never another: - **verified:** read back, and the change is there as approved. - **not there:** read back, and the change isn't there. It isn't retried blindly. - **couldn't read:** it can't tell if it held. It isn't retried: it offers a person instead. If it can't tell whether the change held, it doesn't retry blindly: it says so, marks it as uncertain and offers to hand off to a person. ## What your team sees A panel with what the agent did, what it cost and what's waiting for a decision. Every action in the panel asks for the passkey of whoever takes it. - **The log:** time, tool, object, on whose behalf and the result of each action. Append-only. - **The task meter:** tasks this month against the tier's quota ("up to"), and how many were resolved with a verified action. - **The spending cap:** when it's reached, the agent hands every case to a person until you raise it or the month starts over. ## When it can't, it says so If a permission is missing, the API fails or the request isn't among its tools, it doesn't make things up: it offers to pass the case to someone on your team, and the answer comes back to the same chat. ## More - Home: [/index.md](/index.md) · Security: [/seguridad.md](/seguridad.md) · Developers: [/desarrolladores.md](/desarrolladores.md) - This page in Spanish: [/es/producto.md](/es/producto.md) --- # Security and data at Frailen > The agent acts as the person, never as Frailen. Frailen holds no key it could use to sign on anyone's behalf. Every change goes out with the identity of whoever asked for it, passes through your product's permissions and is written down. ## Identity Your product already knows who each person is and what they can do. Frailen builds on that; it doesn't replace it. - **Your backend signs the session.** With an asymmetric key that belongs to you. Frailen only receives the public key: it can't sign a session, so it can't act for anyone who doesn't have one. - **The permissions are your product's.** The agent reads and writes in your API with a short-lived token for that person. If they can't do something, neither can the agent. - **The token isn't stored.** It lives in memory for as long as the call lasts. It never goes to the database, the logs or a URL. - **Panel actions ask for a passkey.** Approving a tool, publishing a configuration or turning the agent on asks for the passkey of whoever does it, right then. ## Your data What Frailen stores, what for and for how long. - **Your spec stays with you.** Only the skeleton of what the agent can touch is uploaded from your OpenAPI. The source stays on your side. - **Every company, isolated.** Everything stored is tagged with its company, and the database won't let anyone read another's: not even Frailen's own engine can get around that rule. - **A log that only grows.** Every action, on whose behalf and how the read-back went. The database won't let it be changed or deleted. - **Models in a fixed region.** Models run on Google Cloud in a single region, not on the global endpoint, with caching turned off. ## What the agent won't be talked into Defenses that don't depend on the model behaving. - **Instructions hidden in the data.** If a response from your API carries text that tries to give orders, the turn loses trust and everything it writes from then on asks for confirmation. - **Receipts signed by your API.** Your API can sign a receipt for every write. If what ran isn't what was asked for, the case goes to a person. ## What we don't have yet So you know before you ask. - A certification such as SOC 2. - An external penetration test. It comes before the first customer outside our pilot. - A published data processing policy. If your security team needs anything else to evaluate us, tell us in the demo: [/demo](/demo). ## More - Home: [/index.md](/index.md) · How it works: [/producto.md](/producto.md) · Developers: [/desarrolladores.md](/desarrolladores.md) - This page in Spanish: [/es/seguridad.md](/es/seguridad.md) --- # Frailen pricing > You pay for what the agent handles. Never per seat, never per token. A monthly minimum per company, with a quota of tasks. A task is one handled conversation, of up to eight turns. These are reference prices while we measure the real cost, so quotas are listed as "up to." Pilots are free. ## Tiers | Tier | Price | Quota | For | Includes | | --- | --- | --- | --- | --- | | Starter | 99 USD a month | Up to 600 tasks | Getting started with a support agent | A support agent that takes actions; the chat inside your product; charging and deleting only propose, your team decides | | Growth | 400 USD a month | Up to 3,000 tasks | When the agent already solves a good share of support | Everything in Starter; charging and deleting, with confirmation; 8 hours a month of hands-on support | | Enterprise | From 1,000 USD | Custom | Large volumes or your own data rules | Custom quota; 40 hours a month of hands-on support; negotiated data clauses; fixed-price implementation, separately | ## In every tier What goes up with each tier is volume and hands-on support. Security is never an extra. - **The brake and the read-back.** Anything with damage is confirmed and every write is read back. The brake is never charged for. - **Each person's identity.** The agent acts with the permissions of whoever is asking. - **The log.** Every action, on whose behalf and how it went. - **The data promise.** Your spec stays with you and every company is isolated. - **A spending cap.** When it's reached, the agent hands cases to someone on your team. - **Staging first.** Everything is tested without touching production. ## Common questions - **What is a task?** One handled conversation, of up to eight turns. Tasks over the monthly quota are charged separately, up to the spending cap you set. - **What happens when the spending cap is reached?** The agent stops handling and passes cases to someone on your team. Nothing extra is charged. - **Is there a free plan?** There's no permanent free plan. Pilots are free. - **In what currency?** When there's billing, in Colombian or Mexican pesos, with a local electronic invoice. The prices on this page are in dollars as a reference. - **Why not per seat?** Because the agent isn't one more person on the team: it charges for what it handles, and you see what it handles in the meter. ## More - Book a demo: [/demo](/demo) · Home: [/index.md](/index.md) - This page in Spanish: [/es/precios.md](/es/precios.md) --- # Frailen for developers > Three pieces: the tools, built from your OpenAPI; the identity, signed by your backend; and the chat, mounted in your product with one tag. If you're a coding agent: read this page, then follow the prompts in [/agentes.md](/agentes.md). Prepare the integration on a branch; never approve, publish or deploy. ## The tools come from your OpenAPI The importer builds one tool card per operation. Your team reviews its damage and read-back and approves it; nothing runs without that. - **Only a GET can be a read.** Everything else is a write and goes through the brake. - **Damage shows even when the route doesn't say so.** An amount hidden in the body flags money; an action on a whole collection flags bulk. - **An undo is suggested, never assumed.** Until your team confirms it, the write is treated as if it can't be undone. - **What isn't known stays a question.** A report says what was missing from your OpenAPI for each tool. Damage flags: `dinero` (moves money), `masivo` (touches many at once), `terceros` (reaches third parties), `sin_reversa` (can't be undone). Patterns: `consultar`, `cambiar`, `pausar`, `agendar`, `cobrar`, `avisar`, `borrar`, `reportar`. The card format keeps its keys in Spanish. ```yaml # herramientas/facturas.yaml reembolsar_factura: descripcion: Refunds a paid invoice, in full or in part 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: ~ # it can't be undone dano: [dinero, sin_reversa] # dinero, masivo, terceros, sin_reversa relee_con: herramienta: ver_factura compara: [estado, reembolsado] ``` ## Your backend signs the identity A session signed with an asymmetric key and, in your API, a route that exchanges it for a short-lived token for that person (RFC 8693). - **An ES256 session and your JWKS.** Frailen only keeps the public key. A shared secret won't do: with it, Frailen could sign for anyone. - **`POST /frailen/token`.** Returns a token for that person, valid for 300 seconds or less. When a proposal is approved, one that works only for that order. - **Signed receipts, if you want them.** Your API signs what it received on every write, and Frailen compares it with what it sent. ```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" } ``` ## The chat mounts in your product It runs in an iframe served by Frailen: neither your page nor a third-party script inside it can touch the confirmation of an action. The server signs each confirmation at the moment of the click: it works once, for 60 seconds, and only with a real click. One tag: ```html ``` With code: ```js import { montar } from "@frailen/chat-web" const chat = montar({ empresa: "acme-billing", marco: "https://chat.frailen.com", asercion: "/frailen/asercion", // your backend signs it (ES256, 60 s) alEvento: (e) => e.tipo === "escritura" && releer(e.id), }) // What the person has open: the agent uses it as a hint. 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` isn't published to a public registry yet. ## Tests before turning it on You write your cases with their rule before running them. The test bench grades them by reading your API back, not by reading what the agent replied. - **The rule comes first.** A case with no written rule, or one that compares nothing, counts as a failure. - **The state is what's graded.** What ended up in your product, read with different calls than the agent's. - **Staging first.** Nothing reaches your customers until the bench passes and someone turns it on with their passkey. ```yaml # pruebas/mover_vencimiento.yaml id: mover_vencimiento escrito: 2026-10-28 # the rule is written before it runs persona: maria mensajes: - Move invoice F-2291's due date to November 30 espera: # graded by reading back, not by reading the reply - herramienta: ver_factura argumentos: { factura_id: F-2291 } campos: { vence: "2026-11-30" } regla: Passes if F-2291 is due on November 30 and F-2290 doesn't change. ``` ## From your repository (soon) A CLI and an MCP so you or your coding agent can integrate Frailen on a branch, with a draft pull request. They're being built and aren't available yet. - **Staging only.** The CLI token lasts 8 hours and can't approve, lower the damage or touch production. - **Your spec stays put.** The CLI trims it on your machine and uploads only the skeleton of what the agent can touch. ```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 ``` ## More - Build with agents (prompts): [/agentes.md](/agentes.md) · Security: [/seguridad.md](/seguridad.md) - This page in Spanish: [/es/desarrolladores.md](/es/desarrolladores.md) --- --- name: frailen-get-started area: Getting Started description: |- Hand your coding agent this playbook to set up Frailen in a repository: the tool cards from the OpenAPI, the token route, the chat tag and the first test bench cases, all on a branch. title: 'Onboard your agent to Frailen' url: https://frailen.com/get-started.md --- # Set up Frailen with your AI coding agent Use this playbook to prepare the current repository for Frailen. You do the work on a new branch; a person at the company approves the tools and turns the agent on with their passkey. ## How to run Run the sections in order, in the current repository. Perform the actions yourself when you have terminal or file access; do not merely return commands for the user to copy. Pause only for decisions that belong to a person: which operations the agent may touch, the company id, and anything about production. If a step is blocked, record why and continue with the rest. Never approve, publish or deploy anything. Never put sessions, tokens or keys in logs, commits or URLs. Frailen's CLI (`@frailen/cli`) and MCP server aren't available yet: everything here works with files in the repository. Reference: [llms.txt](https://frailen.com/llms.txt) · [For developers](https://frailen.com/desarrolladores.md) · [Security](https://frailen.com/seguridad.md) ## 0. Start a branch ```sh git status git switch -c frailen ``` If the working tree has uncommitted changes, ask before switching. ## 1. Find the API Look for an OpenAPI spec (`openapi.yaml`, `openapi.json`, `swagger.json`, or one the framework generates). If there's none, list the routes from the code: routers, controllers, handlers. Write the operations a support agent would need in `frailen/operaciones.md`, one per line, and mark the ones that move money, touch many records at once, reach third parties (emails, WhatsApp, notices) or can't be undone. Ask the user to confirm the list before writing tool cards for writes. ## 2. Write the tool cards One card per operation in `herramientas/.yaml`. The format keeps its keys in Spanish: ```yaml reembolsar_factura: descripcion: Refunds a paid invoice, in full or in part 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: ~ # the tool that undoes it, or ~ if it can't be undone dano: [dinero, sin_reversa] relee_con: herramienta: ver_factura compara: [estado, reembolsado] ``` Rules: - Only a GET can be a read. Everything else is a write and goes through the brake. - Give every write its damage flags: `dinero`, `masivo`, `terceros`, `sin_reversa`. An amount in the body means `dinero`; an action on a whole collection means `masivo`. - Set `se_deshace_con` only when a real undo exists. If unsure, leave `~`. - `relee_con` names the GET tool and the fields that prove the write held. - Never lower or remove a damage flag to make something pass. Finish with a list of the operations you left out and why. ## 3. Add the token route Add `POST /frailen/token` to the backend (RFC 8693 token exchange): - It receives the session your backend signs as `subject_token`: an ES256 JWT, verified against your JWKS. - It returns a Bearer token for that same user, with `expires_in` of 300 seconds or less. - Add tests for a valid session, an expired one and a tampered one. If sessions are signed with a shared secret (HS256), stop and ask: Frailen needs an asymmetric key, because with a shared secret it could sign for anyone. Never log the session or the token. ## 4. Mount the chat Add the tag to the app's main layout: ```html ``` - Ask the user for the company id if you don't know it. - Add the `/frailen/asercion` route: it signs a 60-second ES256 assertion for the signed-in user. - `@frailen/chat-web` (code and React) isn't published yet: use the tag. ## 5. Write the first test bench cases Three to five cases in `pruebas/.yaml`, for the requests the support team gets most: ```yaml id: mover_vencimiento escrito: # the rule is written before it runs persona: mensajes: - Move invoice F-2291's due date to November 30 espera: # graded by reading back, not by reading the reply - herramienta: ver_factura argumentos: { factura_id: F-2291 } campos: { vence: "2026-11-30" } regla: Passes if F-2291 is due on November 30 and F-2290 doesn't change. ``` At least one case must check that something else did not change. ## 6. Leave the rules for future agents Append this to `AGENTS.md` (or `CLAUDE.md`), creating it if needed: ```markdown ## Frailen - Before touching Frailen files, read https://frailen.com/llms.txt (and https://frailen.com/llms-full.txt if you need the detail). - Tool cards live in herramientas/*.yaml and test bench cases in pruebas/*.yaml. - Only a GET can be a read. Every write carries its damage flags; never remove one to make a test pass. - Never log or commit sessions, tokens or keys. - You prepare the integration on a branch. A person approves the tools and turns the agent on with their passkey: you never approve, publish or deploy. ``` ## 7. Finish Commit on the branch. Don't push unless the user asks. Then report: - The files you created or changed. - The operations covered and the ones left out, with the reason. - The damage flags or undo tools that need a human decision. - Any blocked step and why. - What the company does next: approve the tools in the Frailen panel, run the test bench in staging, and turn the agent on with a passkey. --- # Build Frailen with your agent > Your coding agent can read the whole site, write the tool cards from your OpenAPI and prepare the integration on a branch. You review and approve; it never publishes. ## Start with one line Copy this into Claude Code, Cursor, Codex or any agent that can read a URL. It points to [get-started.md](https://frailen.com/get-started.md), a playbook your agent follows step by step on a branch. ```text Set up Frailen for me. Fetch https://frailen.com/get-started.md and follow it. ``` In Claude Code, from your terminal: ```bash claude "Set up Frailen for me. Fetch https://frailen.com/get-started.md and follow it." ``` ## Or the whole prompt The same work in a single prompt, if you'd rather see all of it before pasting. ### Set up Frailen in this repository ```text Read https://frailen.com/llms.txt and https://frailen.com/desarrolladores.md. Then set up Frailen in this repository, on a new branch: 1. Find our OpenAPI spec, or the API routes a support agent may touch. Write one Frailen tool card per operation in herramientas/*.yaml, with its pattern, damage flags (dinero, masivo, terceros, sin_reversa), how it's undone and how it's read back. Only a GET can be a read. 2. Add POST /frailen/token to our backend: it exchanges our signed session (an ES256 JWT) for an API token for that same user, valid for 300 seconds or less (RFC 8693). 3. Add the Frailen chat tag to our app's main layout. 4. Write three test bench cases in pruebas/ for our most common support requests. Don't approve, publish or deploy anything. Finish with a summary of what you did and what needs a human decision. ``` ## Prompts for each step Paste any of these into Claude Code, Cursor, Codex or any agent that can read a URL. ### Ask whether it fits your product ```text Read https://frailen.com/llms-full.txt. Then look at our codebase and tell me whether Frailen fits our product: which API operations would become tools, which would carry damage, what we'd still need to build and what you'd ask in the demo. Don't change anything. ``` ### Write the tool cards from our OpenAPI ```text Read https://frailen.com/desarrolladores.md. From our OpenAPI spec, write Frailen tool cards in herramientas/, one per operation our support agent should use. Only a GET can be a read. Give every write its damage flags (dinero, masivo, terceros, sin_reversa), se_deshace_con if it can be undone, and relee_con with the GET that proves it held. List the operations you left out and why. ``` ### Add the token route ```text Read https://frailen.com/desarrolladores.md. Add POST /frailen/token to our backend (RFC 8693 token exchange): it receives our signed session as subject_token (an ES256 JWT), verifies it against our JWKS, and returns a Bearer token for that same user that expires in 300 seconds or less. Add tests. Never log the session or the token. ``` ### Mount the chat in our app ```text Read https://frailen.com/desarrolladores.md. Add the Frailen chat to our app: the tag in the main layout, with data-empresa and data-asercion pointing to a backend route that signs a 60-second ES256 assertion for the signed-in user. Pass the current page and the open object as context. ``` ### Write the test bench ```text Read https://frailen.com/desarrolladores.md. Write five Frailen test bench cases in pruebas/ for the requests our support team gets most. Each case has the user's message, the expected final state read back through a GET tool, and a rule written before it runs. One case must check that something else did not change. ``` ### Review the security with your agent ```text Read https://frailen.com/seguridad.md and https://frailen.com/llms.txt. Review Frailen's security model against our product: identity and tokens, what's stored and for how long, isolation between companies, and how the brake works. List the questions our security team should ask before a pilot, and what Frailen says it doesn't have yet. ``` ### Estimate which tier fits ```text Read https://frailen.com/precios.md. Our product handles about [conversations per month] support conversations a month. Estimate which Frailen tier fits, what we'd pay with those reference prices, and what spending cap you'd set. Say which numbers are assumptions. ``` ## What your agent can read - [https://frailen.com/llms.txt](https://frailen.com/llms.txt): the summary, with links. - [https://frailen.com/llms-full.txt](https://frailen.com/llms-full.txt): the whole site in one file. - Every page in Markdown: add `.md` to its path, such as https://frailen.com/precios.md or https://frailen.com/desarrolladores.md. The home page is https://frailen.com/index.md. - In Spanish, the same files under /es: https://frailen.com/es/llms.txt. ## Rules for your agent Add this to your repository's AGENTS.md or CLAUDE.md: ```markdown ## Frailen - Before touching Frailen files, read https://frailen.com/llms.txt (and https://frailen.com/llms-full.txt if you need the detail). - Tool cards live in herramientas/*.yaml and test bench cases in pruebas/*.yaml. - Only a GET can be a read. Every write carries its damage flags; never remove one to make a test pass. - Never log or commit sessions, tokens or keys. - You prepare the integration on a branch. A person approves the tools and turns the agent on with their passkey: you never approve, publish or deploy. ``` ## Coming next The CLI (`@frailen/cli`) and an MCP server for coding agents are being built. Until then, your agent works from these files and these prompts. This page in Spanish: [/es/agentes.md](/es/agentes.md)