Agents & AI
Give an AI agent real access to your app, with a boundary it cannot cross on its own.
An Authoric agent is an AI that acts inside one of your apps. It can read and write your tables, call your endpoints and use tools from servers you have connected. It is a principal, like a teammate: it holds roles, and it is checked against them on every call, by the same policy engine that checks your users.
The difference from "an API key and a careful prompt" is where the boundary sits. A prompt asks the model to behave. Here the model is never asked: what the agent can do is decided where each call is served, from the agent's roles, at the moment it runs. A request the role does not grant is refused whatever the model was told, and a consequential step that is granted pauses for a person first.
What bounds an agent
Four things, each set by you and none by the model:
| What it decides | Where you set it | |
|---|---|---|
| Roles | What it may do: which tables, which operations, which endpoints and outside tools. | The agent's page, Roles |
| Org reach | Whose records it may touch, when your app has organizations of its own. | The agent's page, Where it can act |
| Risk and approval | Which granted steps stop for a person before they run. | Per tool, plus the agent's Auto-approve settings |
| Effort | How far it runs before checking back in, and a ceiling it can never pass. | The agent's page, Effort |
An agent has no tool list of its own. Its toolbox is derived from its roles: grant
invoices:read_list and a list-invoices tool appears; remove the grant and the tool is gone,
from the agent's own loop, from direct calls and from every connected MCP client at once. See
Tools.
The approval halt
Every tool carries a risk level: low, moderate or high. A low step runs. Anything
above low halts: nothing is executed, the exact call is recorded, and the run waits for a
person with approval rights to decide. Approving runs that one step; rejecting runs nothing and
tells the agent why, so it can carry on without it.
A halt is a normal outcome, not an error, and it applies on every door. Reaching a tool over MCP or calling it directly over REST is faster than a conversation, never looser. See Approvals & halts.
Three doors, one core
There are three ways to drive an agent. They are not three systems: each resolves the same policy-derived toolbox and runs each call through the same execution core, so a permission change lands on all of them together.
Conversations
Give it a goal in plain language and let it plan. POST /agent/invoke, or the console.
Direct tool calls
Call one tool deterministically, with no model involved. POST /agent/tools/{name}.
MCP
Point any MCP client at your app, and the agent's tools appear.
Something outside the console drives an agent with an API key. A key is bound to exactly one agent and can never do more than that agent can.
Runs
Every conversation turn and every halted direct call is a run: a durable, recorded object
with a runUid you receive before any work starts. Each step records the tool, its arguments
and its outcome, so "what did the agent do" is answered from the record rather than guessed
from logs. A run can be followed, sent a new instruction while it works, stopped, and
continued after a pause. See Runs.
Which model it runs on
Authoric works with any approved model from any connected AI provider. An agent runs on your plan's included AI credits when it has them, and otherwise on an AI connection your organization has set up under Integrations. Which model you choose changes cost and speed, never what the agent is allowed to do: the boundary above holds the same for all of them.
An agent you only drive through direct tool calls or MCP needs no model at all.