Glossary
The words, defined.
This product uses a handful of terms precisely, and the precision is the point — a tool is not an integration, a boundary is not a permission set to never, and a capability is not authority. Here is what each one means here.
- Agent
- Something that owns a job rather than answering a question. It has an identity, a purpose, a set of capabilities, a set of limits, an owner and a record. An agent without all six is a script with a language model attached.
- Tool
- One narrow capability with a name, a declared input, a declared output and a risk level — "read an invoice", "send an approved reminder". Deliberately not "query the finance database": a capability whose risk depends on what the agent asks for cannot be reviewed.
- Grant
- The state of one capability for one agent: allow (unattended), approve (a named person decides), or never. The default for everything is never, so you grant upward from nothing rather than restricting downward from everything.
- Boundary
- Something an agent can never do, however it is configured — a refund, a deletion, a permission change. Different from a grant set to never, because a grant could be changed by an administrator and a boundary cannot. Enforced at the capability, not requested in a prompt.
- Authority
- What an agent is allowed to decide, as distinct from what it is technically able to do. An agent can hold the capability that updates a proposal and still be capped at a ten percent discount. Two separate checks, and both have to pass.
- Approval
- A request from an agent to a named person, carrying what it wants to do, why, what the limit is and what it is asking for instead. Three answers: approve once, refuse, or change the rule so it stops asking. Cannot be granted by another agent, on any plan.
- Identity
- The name an agent acts under — agent:accounts-receivable — rather than a shared administrative key. Without it there is nothing to permission, nothing to audit and nothing to revoke without breaking everything else using the same credential.
- Run
- One execution, from its trigger to its result. Produces a timeline of what was read, decided, done and asked about, written as it happens rather than summarised afterwards, so a run that dies halfway still explains how far it got.
- Trigger
- Why a run started: something happened, a time arrived, a person asked, or another agent needed help. Stated in words on the agent's profile — "weekdays at 08:00" — because the person accountable should be able to read when it runs.
- Manifest
- The declarative file an agent lives in: name, purpose, owner, runtime, tools, grants, triggers, approvals, memory scopes, network reach and limits. Reviewable in a pull request, which is the point — a change that widens access shows up in the diff.
- Memory scope
- One of five kinds of context an agent may hold: task, customer, organisation, agent or temporary. Each has its own permissions and its own retention. What an agent remembers is a permission decision rather than a capacity question.
- Risk level
- Low, medium, high or critical — assigned by what happens if a capability is used wrongly, not by how hard it was to build. Policies attach to the level rather than to individual tool names, so "nothing above medium unattended" is one rule instead of forty.
- Budget
- A ceiling on what an agent may do in a period: emails sent, calls per minute, money moved, model cost per month. Reaching one pauses the agent and notifies its owner. An agent with a €120 cap does not spend €121.
- Simulation
- Running an agent against your real history without acting. Shows what it would have done — how many customers contacted, escalated or left alone. Shows the actions it would have taken, never the outcomes they would have produced, because nobody knows how a customer would have replied.
- Evaluation
- A named test suite with a pass rate, runnable in a pipeline. The valuable cases are the refusals: does it decline an unauthorised refund, does it escalate on conflicting information, does it stay inside a customer's scope. Evidence, not a guarantee — a suite only tests what somebody thought to write.
- Owner
- The person or role accountable for an agent. Required to deploy, on every path including the API. Survives the departure of whoever built the agent, and receives its approvals, budget stops and failures.
Give AI a job.
Build an agent, choose what it can access, define what it may do, and deploy it to work safely across your business.
No code required · Full SDKs and API · Stop any agent instantly · [email protected]