Picture an assistant that asks for approval at every step. "Shall I open this file?" "Shall I write this line?" "Shall I save now?" By the third question you start doing the job yourself, because granting approval takes as long as the work.
In Orbi, no approval is asked during task and flow execution. Once an agent starts a job it carries it through to the end. That decision was thought over for a long time and modelled on a human colleague. You do not expect an employee to ask permission for every keystroke. You look when they hand the work in.
But "no approval" and "no control" are not the same thing. The balance is built in four other places.
First layer, authority is narrow from the start
The tools an agent can reach are granted on the principle of least privilege. Orbi's orchestrator sees every tool, because its job is to distribute rather than produce. Directly assigned agents, and the sub-agents they call, get a narrowed set.
For external services the rule is stricter still. An agent sees only the connections explicitly given to it. If no connection is ticked, that agent can use no external tool at all.
So you give the approval at setup time rather than at run time. The answer to "which agent can touch what" is written down before the work starts.
Second layer, a gate independent of the agent's judgment
Is telling the agent "do not write personal data" enough?
It is not, because an instruction is text the agent reads and tries to follow. Alongside that, Orbi has policies, and a policy is a gate that works independently of the agent's judgment. When an agent wants to write a record into a collection, a file or a channel message, the content passes through this gate first.
The agent tries to follow an instruction. A policy works even when the agent does not want to follow it.
You can write a rule in two forms. If you describe it in your own words, a small checker evaluates the content against that rule on every write. If what you are looking for is a clear pattern, you use pattern matching, and then no model runs, so there is no cost and the result is identical every time.
When a rule is violated you choose one of two behaviours. With Block selected, the content is not written at all, the agent sees why and tries to bring the content in line with the rule. With Log only, the content is written but the violation lands in the event list. The second is the right choice for watching a new rule's effect without stopping the work.
If the check itself cannot be performed, the content is still written and the event is listed as "check could not be performed". A policy was designed as a safety net, and it does not halt the system when it cannot run.
If you define no policy, nothing about the workspace's behaviour changes. You can start from three ready-made templates, personal data protection, a card-number block and a tone check.
Third layer, a ceiling against runaway cost
The biggest risk in an autonomous system is an agent that runs forever. An agent that keeps replanning itself could in theory never stop.
Orbi applies two ceilings against that. The number of revision rounds the orchestrator can make on one task is limited to ten by default, and the total number of agent runs to thirty.
If a ceiling is exceeded the task drops into the error state on its own and a comment explaining why is left behind. So even in the worst case, what you face is a stopped card, not a silently growing bill.
Fourth layer, the human who takes delivery
When an agent finishes a job it does not mark the card done. It moves it to review and hands it back to the person who opened it.
That is where the approval sits. Not in the middle of the work but at the end, once. Under the card sits a comment explaining what was done and why, and the checklist shows which steps were completed.
What cannot be seen cannot be checked
Above the four layers there is also transparency. Every run is recorded step by step, and which tool was called and what came back is visible. The same record does not sit only inside the card. There is a page showing the whole workspace in one list, with a view that filters down to what needs attention.
Flows have one more step. The Test button really runs the flow but runs none of the tools that write outward, and a "this is what I would have done" preview lands instead. It is the way to try a newly built job without letting it touch the real world.
Where to start
To trust an agent, narrow its authority first. Give it only the connections its job needs and leave the rest closed.
Then write a policy, but on the first pass pick Log only instead of Block. You watch the event list for a few days, and if your rule is catching what you actually meant to catch, you switch it to Block.
Policy types and their behaviour are covered in Policies in the help center. For budget ceilings and how work is distributed see Orchestrator, and for narrowing authority, Tools and integrations.
If you want to try it, you can open a free account and write your first policy.