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. 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.
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 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:
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 is worked out afterwards from the action records. The agent never states its own class, never sees it, and structurally cannot game it.
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.Next
Connect an app
The step that changes what your agent is capable of.
Resolution pricing
How the action trail turns into a class, and what each class costs.
How the agent picks a message
Intent in, validated channel payload out.
Operations
Reading the receipts, and disputing one.