Agents
Admin → Agents creates custom assistants. An agent is three things: a model, its instructions, and a set of tools.
Creating one
Section titled “Creating one”- Give it a name — unique, and what people pick from.
- Model — the model it runs on.
- Instructions — the system prompt defining its behaviour.
- Tools — what it can call.
- Active — whether it is available to use.
Tools come from connectors
Section titled “Tools come from connectors”An agent’s tools are drawn from your connectors and MCP servers — the data sources you have already attached. There is no separate tool marketplace: the tool surface is exactly what your data sources expose.
This is why connectors come first in the setup order. An agent with no tools is a prompt with a model behind it.
What makes an agent useful
Section titled “What makes an agent useful”The instructions are the part people underwrite. A good one states:
- what it is for — the question class it handles;
- what it must not do — the boundaries;
- how to behave when it lacks data — say so, rather than inferring.
An agent whose instructions are three words will produce three words of value. The model is rarely the bottleneck.
Where agents are used
Section titled “Where agents are used”Agents are the open mode path: they are not bound to a context scope and are not governed by one. That is the point — they are for workflows a scope would only get in the way of.
The consequence is worth stating plainly: an agent is only as constrained as its tools. See read-only by design for why a read-only database role still matters.
Sharing
Section titled “Sharing”Agents are available to everyone on the tenant once active. They are not scoped, so decide on visibility before activating one.