--- title: "The execution model" description: "Your agent names an action and Anlyon makes the production call. What that changes, and what it makes enforceable." --- Anlyon puts shared limits and receipts on the actions AI agents take through it. Your agent does not perform the production operation. It names an action and passes input, and Anlyon performs the operation on its behalf. Everything else in these docs follows from that one move, so it is worth being precise about it before anything else. ## Without Anlyon ```text your agent -> an API credential in your process -> production API ``` The model is driving a process that holds a live key. Whatever sits between a stray sentence in a scraped web page and a real refund is code you wrote and have to remember to run on every path. There is nothing outside your process that can refuse, pause, cap or attribute the call, because by the time anything could look at it the request has already left. ## With Anlyon ```text your agent -> a named action -> Anlyon -> production API ``` You define the call once, referencing credentials rather than pasting them. From then on your agent's side of the boundary contains no URL, no header and no key: ```typescript await anlyon.actions.invoke('refund-order', { charge: 'ch_3P9x', amount: 12000 }); ``` Anlyon owns what happens next. ## What happens between those two arrows Every invocation passes the same checks, in this order. Nothing here is optional per call. What varies is whether a given stage has anything to do. 1. **Check the caller's authority** Invoking needs `actions:invoke`. Referencing a secret is checked when the action is saved, and needs `secrets:read`, because a reference is a use. No key receives `secrets:read` by default. 2. **Reserve budget** The calling key's monthly cap on action invocations is checked and reserved. Past the cap the invocation stops with `429 BUDGET_EXCEEDED`. 3. **Resolve the action and its version** The name resolves to an action in the calling key's environment. If the call is attributed to a run whose agent pins a version of that action, the pinned definition runs. Otherwise the current definition runs. The response reports which one actually executed. 4. **Evaluate policy** Approval policies are evaluated on **every** invocation, so a policy can tighten the gate and not only relax it. A policy scoped to an identity the request does not carry is treated as indeterminate and requires approval, so withholding attribution is not a way around it. 5. **Park for a human, if required** A gated invocation returns `202` with `pendingApproval: true` and an approval id. The request that the approver reviews is frozen at this point, so editing the action while they decide cannot change what their yes sends. 6. **Resolve credentials and build the request** Immediately before dispatch, Anlyon re-checks that the environment is not halted, decrypts the referenced secrets, interpolates them into the frozen definition, re-validates the destination, and sends the request. A workspace secret is decrypted here, at dispatch. The read-back of a governed action resolves it again under the same bindings. 7. **Record the outcome** The invocation records the response status, the action version that ran, and the run and span it belongs to. Where the outcome cannot be confirmed it says so rather than guessing. A governed action also returns a receipt grade. See [Receipts and grades](/execution/outcomes). ## Why this is the interesting part The controls Anlyon offers are not a separate product sitting alongside your agent. They are consequences of owning the call: **[Credentials the model never sees](/execution/secrets)** The key is resolved at dispatch, inside Anlyon, from a vault with no read endpoint. It is never in the context the model reads. **[Approvals that mean something](/trust-control/approvals)** Anlyon can hold the call because Anlyon is the one making it. A wrapper around your own function can only ask your code to wait. **[A stop control](/trust-control/environments)** Halting stops new dispatch at the point requests leave. You cannot halt a request that never passed through you. **[Pinned definitions and rollback](/trust-control/promotion)** An agent version pins the exact action definitions it shipped with, so rolling back restores behaviour and not just a pointer. It does not undo a request already dispatched. **[Idempotency](/execution/idempotency)** A retried request replays the original outcome rather than performing the operation twice. **[Attribution](/execution/outcomes)** An invocation records the action version and the approval that released it. Pass a `runId` and it also names the agent and run. ## The boundary of these claims All of the above applies to **actions routed through Anlyon's hosted executor**. A tool your own code calls directly, with a credential your own process holds, is not routed through Anlyon and is not governed by it. The SDK also ships a local approval gate, `approvals.gate()`, which wraps one of your own functions and waits for a decision before it runs. It is genuinely useful when a call cannot move, and it is a different thing: your process still executes the call with your credential, so it gives you the human decision and the record, not credential isolation, and Anlyon cannot attest that your function ran or did not. See [Local approval gates](/guides/approval-gates). ## Where to go next **[Actions](/execution/actions)** Define a production call once and invoke it by name. **[Secrets](/execution/secrets)** A write-only vault, referenced from an action rather than read. **[Idempotency and retries](/execution/idempotency)** Safe replays, and why an ambiguous side effect is not retried for you. **[Receipts and grades](/execution/outcomes)** What is recorded about every call Anlyon made for you, and the grade a governed action returns. **[Governed effects](/execution/governed-effects)** Three adapters and declared actions, side by side, and what happens when a response is lost. **[Bound approvals](/execution/previews)** An approval bound to a digest of the exact request, recomputed before dispatch. **[Impact limits](/execution/impact-limits)** Shared caps on money, resource changes or a unit you declare, reserved before dispatch.