ai.oz0/setup-assistant
For: tenant administrators and plugin users.
Open the chat drawer and ask oz0-setup-assistant about your tenant's configuration, risks or next steps. The agent from ai.oz0/setup-assistant can explain only what your permissions let you see.
For a requested change, it writes a plan as one change request. You or another admin review and approve the request, which then applies with the approver's permissions. The agent itself writes no configuration.
oz0 plugin install hub:ai.oz0/setup-assistant --accept-reads setup
What it can do
Its agent oz0-setup-assistant asks for the tenant's default model alias with tools, never a vendor's model, so it runs on whichever provider the tenant set up first; map it elsewhere with oz0 model alias set default <provider>/<model>.
| Ask | Function | What happens |
|---|---|---|
| "What is set up here, and what should I do next?" | oz0_setup.overview | Plugins, nodes, agents, the tool policy, four eyes, the budget and quotas, open findings and the tenant's checks; what looks risky (an agent with no owner team, a high risk class, a quality gate that stopped a candidate); the next steps in order |
"Why was job job-… refused?" | oz0_setup.why_refused | The job's refused, denied or failed steps with their reasons, from its trace as you may read it, never what it read or wrote |
| "What can I try first?" | oz0_setup.first_jobs | The verified starters: which you may start now, and which need an install first |
| "Never email outside example.com" | oz0_setup.cel_check, oz0_setup.propose_rule | A tool rule in shadow mode, your sentence as its reason, and a replay of the last week (Rules from plain English) |
| "Install net-diag", "a $200 monthly budget", "post approvals to #ops" | oz0_setup.propose_plan | A plan of setup writes: installing or configuring a plugin, a budget, a quota, a channel binding, a notification rule, the standard model aliases |
What it reads, and for whom
--accept-reads setup lets the plugin read your tenant's setup, and only in the calls of its own agent's jobs. Each
call gets a view built for the person who started the job, as they are now: a part they may not read (the tool
policy without governance.read, findings without findings.read, quotas without usage.read) is left out, and the
assistant says which permission it would need. The view never holds a secret's value, a setting's value, a key, or
anything a job read or wrote.
A job no person started (a routine's, an app's, an API key's, an event's, the quality gate's) gets a view that holds
nothing of the tenant and says why, and its plans are refused: the assistant acts only for a person in front of it.
Reads are audited as setup.read, at most once per plugin every ten minutes. oz0 plugin revoke-reads setup-assistant setup takes the grant back.
Plans
A plan is a list of admin API calls in order, such as SetToolPolicy and StartReplay, or InstallPlugin and SetSetting. The platform checks each call before anyone sees it: only setup writes (never a secret, a key, a member, sign-in, a plugin index, a governance setting, a removal or a deletion), parsed exactly as the admin API takes it, in your tenant whatever the call says, and never about the assistant itself (it cannot install, configure or allow itself, under any source: a fork that takes its name is refused when the plan is applied).
An install in a plan never uses a tenant secret or credentials, never says where dependencies come from, and never installs from a marketplace, keeps an imported plugin's hooks in harness sessions, and never grants what an install asks you to grant: what a plugin provides, the other plugins' tools its agents may call, the hooks and commands an imported plugin runs, or the reads of your tenant it asks for. Without them the install stops with what it asks for, the change request records that, and you grant it with your own command.
A notification rule in a plan notifies people by email or through a channel, never a webhook: where events are posted and the secret that signs them are yours to set. Seeding the standard model aliases names them from your tenant's own providers, and an alias your tenant has keeps its target.
A tool policy call adds plain shadow rules and may change the shadow rules there are into such rules; it never sets a preset, an origin rule or a sequence rule, keeps every rule that is on exactly as it is (its preset too), keeps the rules in their order, and is refused if the platform's own comparison finds it loosens anything. Every field a call sets is in what the plan shows, and a plan that would not fit whole is refused rather than cut. A plan waits as a change request of kind assistant_plan, requested by you:
oz0 change show cr-0af29805-61f3
oz0 change approve cr-0af29805-61f3 # shows it, then approves that delta
The console's Approvals / Changes tab shows each call with what it changes, before and after, and the permission it
needs. Approving applies each call as the approver: a call you may not make is refused and reported, the others
still run, and the change request keeps how each call went. The audit trail has each change under your name, with
via: assistant and the assistant's job. See Reviewed changes.
Tests
oz0 plugin test plugins/setup-assistant replays its evals without a model: the drafter refuses a condition the rules
cannot say and confirms one they can, and a job no person started hears why the assistant cannot read the tenant.
ai.oz0/memory
Notes, decisions and definitions agents keep beyond a job, under the platform's retention, holds and erasure, and the accepted ones in an agent's start-up context.
ai.oz0/public-access
For Swedish public authorities - a public-access copy of records with masking a person decides, and an E-ARK archive package, from a signed tenant export, offline.