> ## 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.
# AI agents
> The agent that perceives an issue, reasons over your policy, acts across your software, tells the customer what it did, and learns the pattern.
Most support AI answers questions. Tied's agent finishes jobs.
The difference is not conversational quality — every vendor competes there, and the gap between the good ones is narrow. The difference is **how much of your software the agent can reach**. An agent that can only talk has to ask the customer whether its answer worked. An agent that can see your auth provider, your payment processor and your order system can check for itself, fix what is broken, and prove it.
## The loop
Every turn runs the same five steps.
It reads the message, the conversation so far, the contact record, and the live state of your
connected systems — the order, the subscription, the ticket, the account.
A cheap router picks the intent and decides which specialists to call. Specialists do the
domain work against your policy and your data.
It calls the same registered actions your human agents use — read an order, unlock an account,
issue a refund, reschedule a delivery. Every call is authorized before it runs and recorded
after it does.
One composer writes the customer-facing reply. It says what was done, in plain language, on
whichever channel the conversation is on.
What the agent could not answer, and what a human answered instead, becomes a candidate pair
for your knowledge base — so the next occurrence is autonomous.
## One voice, several workers
Underneath, the agent is not one model doing everything. It is a **router**, a set of **specialist workers**, and a single **composer**.
| Component | What it is | What it does |
| - | - | - |
| **Router** | The cheapest model in the stack, because it runs on every turn | Reads the conversation, picks the intent, decides which specialists to call |
| **Specialists** | Each owns a tool subset, a model tier and its own test suite | Do the actual work and return **structured data** — never customer-facing prose |
| **Composer** | The only component that writes to the customer | Turns specialist output into one message |
**Exactly one component can speak to the customer.** That is a design constraint, not a
performance optimisation: if only the composer can write to the thread, two parts of the agent
can never contradict each other in front of your customer. The
[live trace](/agents/operations) names these components as they run, because they are really
there — the panel is a window into execution, not an animation.
## What bounds it
Two separate things, and they are often confused.
| Bound | Set by | Effect |
| - | - | - |
| **Tool scope** | Your plan and your connected integrations | What the agent is *able* to touch. Enforced at the point of action — a tool the model cannot see is a tool it cannot be talked into calling. |
| **Instructions** | You | How the agent *behaves* within what it can already do — tone, escalation thresholds, topics to refuse. |
Tool scope is the enforceable one. Instructions shape behaviour; they do not grant capability. A five-integration account exposes five tools to the model, never the whole catalogue.
The same scope is what makes the more expensive [resolution classes](/pricing/resolution-pricing) reachable. Buying a plan does not buy a class — granting a scope does. The class is worked out afterwards, from the audit trail, and is used only to price what already happened.
## Agents versus flows
Two different tools, and the distinction matters.
**Decides what to do.** Use it for the long tail — the questions you cannot enumerate, the
phrasings nobody predicted, the cases that need a lookup before they can be answered.
**Follows a path you drew.** Use it where you need determinism: onboarding, a returns process
with strict eligibility, anything with a compliance script.
Most accounts run both, and they hand off to each other. A flow that reaches a question it does not handle passes the turn to the agent rather than straight to a human; the agent handles everything the flow was never built for. The flow keeps the paths that must happen identically every time.
## When it cannot finish
It stops and hands off, leaving a summary so your team starts informed instead of cold. Every turn passes a fixed sequence of gates before the agent is allowed to answer, and the first one to fire ends the turn — including one that can never be switched off: if the customer asks for a person, they get a person. See [Guardrails and safety](/agents/guardrails).
**Handoff is free.** Not a reduced charge, not a routing fee — zero. And once a human sends a
message in the thread, that resolution is not billable at all. See
[What counts as a resolution](/pricing/resolutions).
## Start here
What the agent knows before you teach it anything, and how to give it more.
How the agent reaches your systems, what is allowed, and the receipt it leaves behind.
Where you shape the agent, test it in a sandbox, and publish a version.
Injection defence, typed commitments, topic enforcement, and when it escalates.
Which model answers, whose key pays for it, and what it cost.
Watching it work, auditing what it did, stepping in, and correcting it.
Reaching the customer before they notice the problem.
Work that runs for weeks, across many conversations, with its own billing unit.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.