> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tied.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Actions and tools
> How the agent reaches your systems, what stops it reaching further, and the receipt it leaves behind every time.
An action is anything the agent does outside the conversation: read an order, check a subscription, unlock an account, issue a refund, reschedule a delivery, file a ticket.
Actions are what separate an agent that answers from an agent that finishes. They are also the part that needs the most care, because a wrong action changes something real.
## Humans and the agent use the same actions
There is one action registry, not two.
If one of your people can do something from the reply composer, the agent calls **the same registered action** through **the same connection**. If the agent can do something, a person can too. Nothing is built for the agent alone.
**This is why the audit trail is trustworthy.** Every action — human or agent — writes one record
in one place, stamped with who did it. There is no second substrate that could drift, no parallel
log to reconcile, and no category of agent activity that is invisible because it took a different
path.
## The tool floor
The agent only ever sees tools for integrations you have **connected** and are **entitled to**. A five-integration account exposes five tools. Never the full catalogue.
**This is a security control, not an optimisation.** A tool the model cannot see is a tool it
cannot be talked into calling. No amount of clever prompting reaches a tool that was never loaded,
because the floor is enforced outside the model — on the server, before inference — rather than by
an instruction the model is asked to respect.
It is also where your plan lives. There is no separate entitlement system and no second agent build for cheaper plans: a knowledge-only account is simply an account whose tool floor contains retrieval and nothing else.
## What is allowed, decided three ways
Every call passes three separate checks before it runs.
| Check | Question | Fails how |
| - | - | - |
| **Authorization** | Is this actor allowed to act on this resource at all? | Closed. An authorization lookup that errors denies the action — an outage never opens actions. |
| **Policy** | Under what conditions — amount limits, business hours, approval required, customer tier? | Closed, with the condition that failed named in the trace. |
| **Compliance instrument** | Does your account hold the executed instrument this action's data class requires? | Refused outright. See below. |
The agent does not decide any of this. It calls a tool; the dispatch layer decides. That separation is the point — an agent that could authorize itself is an agent whose authorization means nothing.
## Approvals
Some actions should wait for a person. You can require approval on any action — by action type, by amount, by customer segment.
When an approval is pending, the agent tells the customer plainly that it is waiting on a colleague rather than pretending to be busy. When it clears, the agent continues and reports what happened.
**Turning on an approval chain never raises your price.** Approvals are recorded for governance
and audit, and they do not feed the
[resolution class](/pricing/resolution-pricing) calculation at all. A safety control that
quietly increased your bill would be a safety control nobody switches on.
## Compliance-classed actions
Some actions touch data under a regulatory regime. Three of those classes are gated on an executed instrument, not on your plan:
| Data class | Instrument required |
| - | - |
| `phi` — protected health information | A signed BAA |
| `pci` — cardholder data handled by Tied's own action | A PCI attestation |
| `sox` — SOX-controlled systems | A SOX control attestation |
**Until the matching instrument is recorded on your account, these actions are refused outright** —
on every plan, including the largest contract. The gate is the instrument, never the tier. These
classes are **coming soon**: Tied does not hold a BAA, PCI Level 1 or a SOX instrument today, so
they are defined, refused, and not sold.
Worth knowing: a refund executed through a payment processor is **not** `pci`. The processor holds the card number; Tied refunds against a token and never sees it. That is an ordinary financial write.
## Every action leaves a receipt
The receipt records what ran, against which provider, with which arguments, under which authorization, and what came back — including the provider's own transaction ID where there is one.
Two things follow from that.
**You can prove what happened.** Not "the agent says it issued a refund" — the processor's transaction ID, sitting next to the conversation it came from.
**Your price is derived, not asserted.** The [resolution class](/pricing/resolution-pricing) is worked out afterwards from the action records. The agent never states its own class, never sees it, and structurally cannot game it.
| Class | What the trail has to show |
| - | - |
| `knowledge` | No tool calls other than retrieval |
| `read` | At least one lookup **in a connected external system**, no successful writes |
| `write_simple` | At least one successful write, no money moved |
| `write_financial` | At least one successful write that moved money |
| `orchestrated` | Three or more **distinct providers** successfully written |
Highest class reached wins, and **a failed write does not upgrade the class**. An attempted refund that the processor rejected is not a financial resolution.
## The agent never writes channel JSON
Rich messages — list pickers, forms, date pickers, payment requests — are not something the model composes. It emits an *intent* ("offer these six choices", "collect a delivery date") and a deterministic builder turns that into a validated payload for whichever channel the conversation is on.
This is why a flow authored today still works when you add Apple Messages for Business in six weeks: the flow never named a channel primitive, so there is nothing to re-author. See [how the agent picks a message](/agents/messages).
## Next
The step that changes what your agent is capable of.
How the action trail turns into a class, and what each class costs.
Intent in, validated channel payload out.
Reading the receipts, and disputing one.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.