# 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
<script src="https://chat.frailen.com/chat/0.2.0/frailen.js"
  data-empresa="acme-billing" data-asercion="/frailen/asercion"></script>
```

## 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)