---
title: "ai.oz0/setup-assistant"
description: "An agent in the chat drawer that explains your tenant to you, plans changes you approve, and drafts tool rules from plain English into shadow mode."
canonical_url: "https://docs.oz0.ai/build/plugins/verified/setup-assistant"
---
# ai.oz0/setup-assistant

> An agent in the chat drawer that explains your tenant to you, plans changes you approve, and drafts tool rules from plain English into shadow mode.

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.

```bash [Terminal]
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](https://docs.oz0.ai/spend/models-and-keys/aliases#the-standard-aliases) 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>`.

<table>
<thead>
  <tr>
    <th>
      Ask
    </th>
    
    <th>
      Function
    </th>
    
    <th>
      What happens
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      "What is set up here, and what should I do next?"
    </td>
    
    <td>
      <code>
        oz0_setup.overview
      </code>
    </td>
    
    <td>
      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
    </td>
  </tr>
  
  <tr>
    <td>
      "Why was job <code>
        job-…
      </code>
      
       refused?"
    </td>
    
    <td>
      <code>
        oz0_setup.why_refused
      </code>
    </td>
    
    <td>
      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
    </td>
  </tr>
  
  <tr>
    <td>
      "What can I try first?"
    </td>
    
    <td>
      <code>
        oz0_setup.first_jobs
      </code>
    </td>
    
    <td>
      The verified starters: which you may start now, and which need an install first
    </td>
  </tr>
  
  <tr>
    <td>
      "Never email outside example.com"
    </td>
    
    <td>
      <code>
        oz0_setup.cel_check
      </code>
      
      , <code>
        oz0_setup.propose_rule
      </code>
    </td>
    
    <td>
      A tool rule in shadow mode, your sentence as its reason, and a replay of the last week (<a href="https://docs.oz0.ai/govern/tool-policy/review-changes#rules-from-plain-english">
        Rules from plain English
      </a>
      
      )
    </td>
  </tr>
  
  <tr>
    <td>
      "Install net-diag", "a $200 monthly budget", "post approvals to #ops"
    </td>
    
    <td>
      <code>
        oz0_setup.propose_plan
      </code>
    </td>
    
    <td>
      A plan of setup writes: installing or configuring a plugin, a budget, a quota, a channel binding, a notification rule, the standard model aliases
    </td>
  </tr>
</tbody>
</table>

## 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.

<warning>

What the assistant reads goes to your model, through your gateway and under your data rules, like everything an agent
reads: the names, versions and states of your plugins, nodes and agents, the names of your settings (never their
values), your tool rules and quotas, and the text of open findings. If your model provider may not see your configuration, do not install the assistant.

</warning>

## 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:

```bash [Terminal]
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](https://docs.oz0.ai/govern/reviewed-changes/proposals#assistant-plans).

## 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.


## Sitemap

See the full [sitemap](https://docs.oz0.ai/sitemap.md) for all pages.
