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