Two separate questions
Oversight in Olano answers two independent questions, and keeping them apart makes the settings much easier to reason about.
- Which actions require approval? A persistent, per-agent decision built from a profile, a couple of toggles, and optional per-tool overrides.
- What happens when one comes up? An inline card if a human is watching the conversation, or a queued item in the approvals inbox if the turn was running unattended.
Trust levels 0-4
Every agent carries a trust level describing how much autonomy it has been granted. The default for a new agent is level 2.
| Level | Name | What it can do |
|---|---|---|
| 0 | Observer | Read-only. It can look and it can suggest, but it changes nothing. |
| 1 | Assistant | May write to its own memory and logs. Still touches nothing outside itself. |
| 2 | Collaborator | May create and edit workspace files and run commands through its configured environment. |
| 3 | Autonomous | Full workspace access, and auto-approves operations classified as low risk. |
| 4 | Developer | The widest setting, including local shell access, and auto-approves most operations. Intended for development, not for an agent facing customers. |
High-risk operations require a human at every trust level. Level 4 does not mean "no approvals ever" - it widens what counts as routine, not what counts as dangerous.
Per-category approval gates
The Oversight card on an agent's Overview tab sets the baseline with a Mode, and each mode adds a category of actions to the approval set:
| Mode | Holds for approval |
|---|---|
| Trusted | Financial actions and writing secrets. |
| Supervised | The above, plus writes to external systems, shell commands, and reading secrets. |
| Locked-down | The above, plus filesystem writes and delegating work to a subagent. |
Two toggles layer on top of whichever mode you chose: Ask before write actions adds external writes, and Ask before shell commands adds shell. Use them when you want Trusted's general looseness but not for one specific category.
Above everything sits the per-tool override. In the agent's Tools tab, the collapsed Approval overrides (advanced) section lists each selected tool with its effective state and a Default / Always ask / Never ask control. That setting wins over the profile and the toggles, which is how you pin one dangerous tool to always ask on an otherwise trusted agent - or the reverse for a tool you have watched a hundred times.
The same card also carries the scanning switches: checking inbound and outbound text for personal information, and hiding secrets from replies. Those run independently of approvals.
Answering an approval
When a human is watching, the request appears inline in the conversation as a card with a risk badge and three buttons: Accept once, Accept all (which auto-approves the rest of that turn) and Reject. An unanswered card times out and is treated as a rejection, so a forgotten conversation never leaves an action pending indefinitely.
The chat header's mode chip overrides the agent's standing setting for that one conversation:
- Auto - approve every tool call for this session. No cards.
- Manual - ask before each gated tool.
- Plan - ask the agent to draft a plan first. The plan appears with an Approve & run button; to refine it, just type a follow-up while still in Plan.
- Act - approve everything, in order to execute a plan you have just approved.
Plan is the mode to use the first few times you give an agent a job with consequences. You get to read the intended sequence before any of it happens.
The approvals inbox
Not every turn has someone watching. When a scheduled run, an autonomous phase or a task delegated from another agent hits a gated tool, it defers the action to the Approvals section on the Overview screen and pauses.
Each item names the tool, shows a risk badge, and identifies the originating agent and the path the call came through. Approve resumes the blocked turn; Reject ends it. The Overview sidebar item carries a live count, and the same count drives the notification bell, so a waiting approval is visible from any section of the dashboard.
Items in the inbox are holding a turn open. If nobody looks at the inbox, the overnight job that was supposed to send the report is sitting there instead of running. Check it as part of the same routine you use for the daily highlights.
Audit history
Several surfaces record what happened, each answering a different question.
| Where | Answers |
|---|---|
| Revisions | What changed in configuration and workspace documents, when, and which agent's turn made the change. Filter to one file to see its history, and view any version exactly as it was. |
| Insights work journal | What was done on a given day, per agent, with a written narrative and per-agent usage. |
| Agent to Agent | Every message between agents, with the ask, the reply and how long it took. |
| Scheduler history | Whether each scheduled run succeeded or failed. |
| Cortex activity | What the improvement engine did on its own, with one-click undo on each change. |
| Logs | The raw runtime log, filterable by level - the place to look when something did not start. |
Revisions is the one worth knowing about before you need it. It records automatically, and a Snapshot now button commits pending changes immediately when you have just edited something and want the record to be exact.
Usage caps
Three separate limits keep an agent's consumption bounded.
- Message rate limits. Per agent, and optionally per channel, across per-minute, per-hour and per-day windows. Set the deployment-wide default in Config and tighten it on any individual agent from its Rate limits card. Over the limit, the message never reaches the model and the sender is told to try again shortly. Scheduled and autonomous work is exempt.
- Per-turn limits. The Access & Safety card caps how long a single turn may keep working - an iteration budget plus retry limits - so a stuck agent stops instead of looping.
- The daily reasoning budget. Cortex has its own cap on expensive autonomous runs per day; when it is spent, autonomous phases skip until tomorrow rather than running on a cheaper model. See chapter 7.
On a managed deployment, the credits balance is visible on Overview and in Insights, split into what is included and what has been purchased, with a monthly reset meter - so consumption is something you watch rather than discover.
The credential vault
Every secret an agent uses lives in the encrypted Vault, and only there. Channel tokens in particular are vault fields, not configuration fields: an agent's configuration file does not name the credential in any form. The vault is administrator-only when team accounts are on.
Each secret can be shared or scoped. A common entry is used by every agent; a per-agent override of the same name gives one agent its own value - which is exactly how ten Telegram bots use one obvious credential name rather than ten invented ones. An agent's Variables tab manages its own overrides and is available to that agent's owner as well as to administrators, while the deployment-wide vault stays administrator-only.
Values are never shown to the model and never logged. When you change one, toolkit credentials take effect on the agent's next turn, while model provider keys and channel tokens are read at boot and need a restart.
If the vault is locked, connectors that need a credential do not start, and a notification says so on Overview. Unlocking it lets those agents reconnect. A locked vault never loses a stored value - it just cannot read it yet.