The AI Monitoring Agent only does what its authorization level allows. An administrator sets the level. Levels 2 and 3 are available when they are turned on. This page explains each level, how a retry is approved or authorised, and every way to stop it.
The principle is simple: the AI model suggests, and fixed rules written as code decide. The model can recommend a retry. It cannot approve one, authorise one or run one.
| Level | What it may do | Who sets it |
|---|---|---|
| 0 Off | Nothing. No sweeps run, no model calls are made and no AI data is written | An administrator |
| 1 Observe | Reads run history and failure data, diagnoses, writes insights and notifications. Changes nothing | An administrator |
| 2 Recommend | Everything in Observe, and proposes a retry for a person to approve | An administrator |
| 3 Act within limits | Everything in Recommend, and retries by itself where a standing authorization covers the failed run | An administrator |
Levels 2 and 3 are available when they are turned on. A level that is not turned on is greyed out on the agent card. Lowering the level takes effect on the next save, and it never deletes anything.
Try level 3 with caution. It lets the agent retry without asking you first, so we recommend working up to it: start at Observe, move to Recommend until the proposals match what you would approve, and only then grant an authorization. Nothing happens at level 3 until an administrator grants one. See Level 3: standing authorizations, below, and Agent cautions and limits.
The only action the agent can take on your runs, at any level, is to retry a failed run. It cannot change a task, job or platform, a schedule, a credential or a pipeline, and it cannot cancel or delete a run.
Every retry is checked by code before it is proposed, and checked again at the moment it would start. The checks come in two tiers.
Checks that stop a retry whoever asks. A person approving cannot override these.
Checks that stop an automatic retry. At level 2 most of these appear as warnings on the proposal and the approver decides. At level 3 they send the retry back to a person.
Statistics about earlier outcomes can lower what the agent is allowed to do and can never raise it.
A proposal that nobody decides expires. The next sweep can propose it again if it still makes sense.
A standing authorization, or grant, is a recorded permission from an administrator for the agent to retry failed runs in a named scope without asking each time. It is the only way the agent acts by itself. Level 3 is available when it is turned on, and you should try it with caution.
A careful way to start:
| Part of a grant | What it means |
|---|---|
| Scope | The tasks, jobs or platforms it covers. A grant must name what it covers, and a whole-organisation grant is not offered. Where more than one grant covers a run, the most specific one applies |
| Limits | How many retries per failed run, per task per day, per platform per hour and per organisation per day. A grant can only narrow what your plan already allows |
| Expiry | Every grant expires. Choose how long it lasts, within the range offered. Nothing renews it automatically, and reminders arrive before it ends |
| Acknowledgement | The administrator must tick a statement of what they are authorising. The wording is stored with the grant |
| Who | An administrator. The role is checked again every time a grant is created, revoked or confirmed |
To grant one, open the agent card, choose Grant authorization, pick the scope, set the limits and the expiry, tick the acknowledgement and choose Authorise retries. The agent must be switched on first. Without a grant that covers a run, the agent proposes a retry for approval instead.
To revoke, choose Revoke beside the grant on the card. It stops applying immediately. Revoking does not undo a retry that has already started.
A suspended grant is one the agent has stopped using without being told to. It happens if the administrator who granted it is deactivated. The card shows it as suspended and offers Confirm to keep it, or Revoke. A suspended grant does nothing until an administrator confirms it.
Every automatic retry is shown in the Monitor with the authorization it relied on, and recorded in the audit trail.
The agent pauses itself before a run of failed retries can do harm.
An administrator can set a window, in the organisation's time zone, every day, on weekdays or at the weekend, when the agent will not retry anything by itself. Proposals still appear during quiet hours. Only automatic retries wait.
Every action is recorded with what was done, who or what caused it, the approval or authorization it relied on and the time. The trail is kept when you delete the agent's other data, because security and change control need it.
| To do this | Use |
|---|---|
| Stop automatic retries, keep the agent watching | Revoke the grants, or lower the level, and save |
| Stop one kind of retry | Set the task, job or platform to Never retry in its AI agent section |
| Stop the agent | Switch it off on the agent card and save. New sweeps stop at once |
| Stop the Copilot and the agent together | Switch off AI features |
| Stop one run | Cancel the run |
Switching the agent off does not cancel a retry that has already started on the platform. Cancel the run if you need it stopped. If you cannot reach settings and need the agent stopped for your organisation, contact support and Polysync can stop it from its side.
Retry one critical load only. Keep the level at 2, so the agent only proposes. Approve the proposal for that load and reject the others. To stop proposals for a task altogether, set it to Never retry in its AI agent section.
Let it handle one flaky platform (level 3, with caution). Grant an authorization scoped to that platform, with tight limits and a short expiry. Set quiet hours for the times you want left alone, and review what it did under Agent activity.
Stop everything now. Switch the agent off on the agent card and save. Then revoke any grants so they do not apply when you switch it back on.