What an agent can see
The exact boundaries an agent works inside — its data model, its metrics, your row-level security and its budget — and the guarantees that follow
An agent never roams freely through your data. It works inside a short, declared set of boundaries that an administrator draws in the Central Management Console, and everything outside them is out of its reach. Knowing those boundaries explains most surprises — a metric the agent will not use, or a total smaller than a colleague's.
What an agent can reach
- The data models bound to it. A data model is made in Model Studio and defines the metrics an agent may compute, the dimensions it may break them down by, the synonyms that map your words onto them, and the named filters your company uses. The agent reaches your data only through what the model names.
- The metrics in its scope. In Agent Studio an administrator can narrow an agent to a chosen set of metrics. An agent with no metrics selected cannot answer metric questions at all — a narrow scope is always an explicit choice.
- The rows you are allowed to see. Row-level security is applied to every query, as described below.
- The tools switched on for it. Each tool can be enabled for conversations, for scheduled runs, or for both.
Every number an agent reports comes from your data through the engine. Text and figures never trade places: a sentence can explain a number, but only a query result can supply one.
Row-level security: who sees which rows
Row-level security decides which rows come back for you. It is applied inside the engine on every query, whichever agent you ask. Administrators never write filter code: they pick a rule and a dimension in the Central Management Console, and the system generates the filter. Values are chosen from the model's own list, so a typo can never quietly hide rows. See Row-level security.
| Your bindings | What comes back |
|---|---|
| One value on a rule | Only that slice |
| Several values on the same rule | All of those values together |
| Values on more than one rule | Only rows that satisfy every rule at once |
| ALL on a rule | Every value of that rule, including values added later |
| No binding (enforced model) | Nothing — the chat says you have no row access yet |
| No binding (model in transition) | Every row — and the answer states this plainly |
A saved binding applies at once. When an answer is narrowed, it carries a Scope badge naming what it was narrowed to, and a brief records its scope in its Declarations strip. Results are cached per scope, so an answer is only ever served to people with the same row visibility.
Budgets and experiment runs
Every run has a money ceiling and a step ceiling, so cost stays predictable.
- Anyone who can run an agent can tighten a run — fewer steps, less money, a shorter wait — using Adjust this run.
- Raising a budget is an experiment. A user with the experiment permission can raise the budget of a manually started run, within the platform's ceilings.
- Authority stays fixed. Tools, metric scope, row-level security and masking are identical in every mode. Only the budget moves.
- Experiment runs stay private. They carry an Experiment badge, never deliver a brief, and are kept out of the product's performance measures — so an experiment can never become someone's morning report.
Track what runs cost in Usage and spend.
People choose the model
The language model behind an agent is chosen by an administrator in the Central Management Console, and it changes only when a person changes it. There is no automatic fallback and no silent switch to another model. Every change is written to the audit record, so you can always tell which model produced an answer.
Everything is on the record
Every run keeps its own evidence. The Activity stream shows the steps in plain language while the run happens and stays as its record afterwards. The query behind every number is kept with the run, and a run that stops at its budget says so in its record.
Deeper technical views are available to the people whose role includes them. Anyone else sees a lock card with Request Technical Review, so the review is always one step away.
The audit record holds every change — who, when and what — and it is read-only for everyone. See Runs and Activity and Audit.
Guarantees at a glance
- Data models are made in Model Studio and used exactly as governed.
- Row-level security filters are generated by the system, never hand-written.
- Every number carries a trust tier. See Trust tiers.
- A run stays within the budget it was given.
- The serving model changes only by a recorded human decision.
- An experiment run never sends a brief.
- Nothing is ever deleted — records are archived with their full history.