Tools & approvals
What an agent is allowed to do, and where a human has to say yes first.
Tools are what an agent can actually do. Beta Without them it can only write text; with them it can look up an order, draft a reply, or create a record. This page is the trust boundary: which tools an agent gets, and which of those pause for a human before they take effect.
Everything here sits inside the agent's role. A tool grant can only ever narrow what the role already permits — it can never widen it. If the role does not allow updating customers, granting a customer-update tool changes nothing: the call is rejected when it reaches the API.
Two kinds of tools
Built-in tools are Augno's own capabilities, attached directly to the agent definition. There are five:
| Tool | Group | What it does |
|---|---|---|
create_artifact | General | Produces an artifact — a report, document, or data export — with a name, MIME type, and content |
read_doc | Knowledge | Reads a page of Augno's documentation, discovering what is available from the docs site's llms.txt index |
fetch_url | Knowledge | Fetches a public HTTPS URL and returns its body as text |
send_email | General | Sends an email reply through the conversation's bound inbox, threaded to whoever last wrote in |
draft_reply | General | Proposes a reply to the external party on a case, held as a draft for a teammate to review — it does not send |
send_email and draft_reply look similar and are not. draft_reply stages a message and stops; a person edits and approves it, and Augno then delivers it over whichever channel the case uses — email if the case is bridged to an inbox, an in-app portal message otherwise. send_email actually sends.
Endpoint tools are Augno's own API operations exposed to the agent as tools — over 200 of them, covering the same list/create/update operations your integrations use. They are granted separately from built-ins, through an explicit allowlist on the agent.
Granting endpoint tools
The grant is an allowlist of tool slugs on the agent's config, and it is deliberately strict:
- Empty grants nothing. An agent with no entries gets no endpoint tools at all. That is the default for a new agent.
- Named slugs grant exactly those tools, and nothing else. Unknown slugs are ignored. This is what the dashboard's tool picker writes: one entry per tool you tick.
- The single entry
*grants the entire catalog. This is an API-only shortcut — the tool picker never produces it, so you can only set it by writing the allowlist through the agent API. Use it only for an agent whose role is already tightly scoped, because with*the role is the only thing standing between the agent and every operation.
Adding or removing tools is an ordinary edit to the agent's configuration and takes effect on the next run.
Progressive discovery
Injecting the full tool catalog into every model turn would drown the agent in context and make it worse at its job, so Augno does not do that. Instead, an agent that has been granted at least one endpoint tool gets a single meta-tool, search_api_tools.
The agent describes what it needs in plain language — "list open sales orders", "create a customer" — and the search returns up to 10 matching tools from its grant. Those matches become directly callable on the agent's next step. Anything outside the grant is not searchable and never appears.
Two consequences worth knowing:
- An agent with no endpoint-tool grant never even sees the search tool, so it cannot discover what it is missing.
- The agent is told, up front, which broad areas it can act on — Customers, Sales Orders, and so on — so it knows to search rather than telling a user it cannot help.
Human review
Review is a per-tool setting with two values: not required (the tool just runs) and required (the run pauses first).
How the default is decided:
| Tool | Default review | Can you change it? |
|---|---|---|
| Built-in, read-only | Not required | Yes — switch it on per agent |
Built-in that acts externally (send_email) | Always required | No. The gate cannot be cleared for any agent |
| Endpoint tool | Not required | Yes — set review per tool slug on the agent |
The floor on externally-visible built-ins is intentional: send_email puts mail in front of a customer, and that is not something an agent should be able to do unsupervised no matter how it is configured. Every call to it pauses for approval.
Endpoint tools take the opposite starting point — the runtime does not gate them unless you say so — but the dashboard nudges you the right way. When you grant a tool that changes data (anything that is not a read), the tool picker switches review on for it automatically. You can turn it off, but you have to choose to.
What a paused run looks like
When an agent calls a gated tool, the call is not executed. Instead:
- The blocked call is recorded on the run's timeline, and an action is recorded in
pending_review. - The run moves to
awaiting_approvaland stops. - Augno writes a plain-language summary of what the agent is asking to do, generated from the run's own context so raw IDs appear as the names the agent already looked up. If a summary cannot be produced, the run falls back to naming the tools it is blocked on.
That summary is the whole point of the gate. A reviewer should be able to decide from one sentence, without reading a JSON payload.
Approving and denying
You resume a paused run with a message plus your decisions. You can approve some calls and deny others in the same response.
Decisions can be made two ways:
- By tool slug — approves or denies every pending call of that tool. Simple, and right when there is one call.
- By individual call — approves or denies one specific call. Use this when several pending calls share the same tool and you only want to allow some of them; deciding by slug would decide all of them at once.
The outcomes:
- Approved — the call executes and the run continues.
- Denied — the call is answered with a "denied by user" result and the run keeps going without it. Denying a tool is not the same as killing the run; the agent is told no and works around it. If you want the run stopped, cancel it.
- Neither — a pending call you do not decide on stays pending. The run resumes without it, and the agent is asked to review again the next time it calls that tool.
Cancelling a run while it is awaiting_approval counts as denying everything still pending; each of those actions is recorded as rejected and attributed to you.
There is no "always allow"
Every approval is one-time. Approving a tool now does not approve it later — the next call to the same tool pauses again, even within the same run.
This is a deliberate design choice, not a missing feature. A tool that should run unsupervised belongs in the agent's definition with review switched off, where the decision is visible, reviewable, and applies to every run. A per-run "always allow" button would move that same decision somewhere nobody can audit it.
Every attempt is recorded
The run records the tools an agent attempted, not only the ones that took effect — including calls that were held for review and never executed. Each carries its own status: awaiting review, auto-approved, approved by a person, rejected, executed, or failed. So a run that was stopped at the gate still tells you exactly what the agent wanted to do.