Skip to main content
The MDM Remediation Agent, turned on by the AI Remediation policy, assigns your compliance tickets to Primo AI. It diagnoses the issue, re-pushes the fix when there is one to push, messages the employee when only they can act, and hands the ticket back to your team with what it established. Straightforward cases close without anyone opening them. The rest reach an admin with the diagnosis already attached.

​
How it works

1

Primo opens a compliance ticket

A status set to Create Issue and Ticket opens a ticket for each affected device. See Configure compliance issue settings.
2

Primo AI picks the ticket up

If your AI Remediation policy is published, the ticket is assigned to Primo AI and it starts working immediately. If no policy is published, the ticket stays with your team.
3

Primo AI works the ticket

It reads the issue and the raw evidence, refreshes the device, pushes what it can push, messages the employee when the device needs a person at the keyboard, and posts a note with the outcome.
4

The device reports compliant and the ticket closes

The issue disappears and Primo closes the ticket. Primo AI never closes a compliance ticket on its own initiative.

​
Turn on AI Remediation

AI Remediation is controlled by one setting: the AI Remediation policy on Compliance > Compliance issue settings. The policy has a draft and a published version.
Publishing the policy is what turns AI Remediation on. Nothing else does. Unpublishing turns it off.
  • Once a policy is published, the state chip reads AI Remediation: ON and every new compliance ticket is assigned to Primo AI.
  • AI Remediation is all-or-nothing per company. There is no per-issue-type toggle. Name the issues Primo AI should never work in the Scope section of your policy.
  • Unpublishing does not unassign Primo AI from tickets that are already open. Those runs read the missing mandate and stop with a note instead of acting. Reassign them by hand if you want your team to take over immediately.

​
Write your AI Remediation policy

The policy is a Markdown document that Primo AI reads before it touches any ticket. Without a published policy it acts on nothing. Primo AI starts from the default behavior below. Your policy can only narrow it. No sentence in the policy grants an action the product forbids.

​
Default behavior

​
What it always does

  • Reads the issue behind the ticket first. It never works from the ticket title. It reads the exact status and the raw evidence the device reported.
  • Reads your policy. With no published policy it acts on nothing.
  • Refreshes the device and re-reads its state before concluding. A large share of compliance issues are enforcement still in flight, not real drift.
  • Looks at the wider picture. The device’s other open issues, and earlier tickets on the same device and the same rule. A dozen tickets on one rule is one cause, and it reports it as one cause.
  • Verifies on the device after pushing a fix, not on its own dispatch. It does not call a push a fix.
  • Ends every run with a note. First line the outcome, last line the one thing you have to do.

​
What it fixes on its own

Primo AI repeats whatever the control did in the first place, matching its mechanism: Most runs are exactly this, and the employee never hears about it. When a control has no per-device mechanism to repeat, Primo AI says so in its note and hands the ticket back rather than pretending to act.

​
When it writes to the employee

Primo AI writes to an employee only when the operating system needs a person at the keyboard — a login to finish encryption, a passphrase, a restart — and only after everything it could do alone is done.
  • Once per issue. It does not chase.
  • One instruction, in the employee’s language.
  • No internal vocabulary. No Primo screen, status, or control name appears in the message.
  • It asks for a restart, it never performs one.
  • No employee assigned to the device means no message.

​
What it hands back to you

Primo AI stops and hands the ticket to your team when only an admin can decide:
  • The device is offline. Nothing can be pushed or verified until it syncs.
  • The device is enrolled in another MDM. Primo observes but does not enforce.
  • The operating system edition cannot be managed for the control in question.
  • The hardware falls short of what the fix requires.
  • The fix needs a purchase, a licence, or a credential Primo does not hold.
  • The EDR was never deployed on the device, so there is nothing to repair.
  • The device needs a re-enrollment, which is an admin decision.
The ticket comes back with the diagnosis attached, not as a fresh unknown.

​
What it never does

  • Wipe, lock, retire, or unenroll a device on its own reading
  • Close or reopen a ticket on its own initiative
  • Touch another device, or “the others like it”
  • Change the MDM control or the compliance rule to make an issue go away
  • Claim a fix it has not re-read on the device
  • Keep messaging someone who asked for a human, or asked to be left alone

​
The bounds of one run

One ticket, one issue, one device. One fix attempt per mechanism. One message per issue. Ending a run with the issue still open is a valid outcome, and the note says so plainly.

​
Cover the four sections

The policy template is always the same four sections. Each one narrows the default behavior.
  • Scope — Which issues Primo AI works, and which it never touches. Name them the way they appear in your settings.
  • What Primo AI does on its own — The fixes it applies without asking, and the cases it hands straight back to your team.
  • Talking to employees — When it may write to an employee, in which tone and language, and how many messages.
  • Company knowledge — Facts about your fleet that change how an issue should be read: which Linux distributions you run, which office’s network blocks the agent, which devices are held in stock, which teams are never written to directly. Primo AI adds to this section over time, on an admin’s confirmation — see Approve what Primo AI learned.

​
Write it with the assistant

The policy page carries an embedded Primo AI chat. It interviews you and writes the policy, grounded in your real compliance rules, your MDM controls, and your fleet — so the draft references the issue types you actually have rather than a generic list.
1

Open the policy

Go to Compliance > Compliance issue settings and open the AI Remediation policy.
2

Answer the assistant's questions

It asks which issues you want worked, how far Primo AI should go on its own, and how it should talk to your employees.
3

Review the draft

The draft is yours to edit directly. The assistant writes it; it does not own it.
4

Publish

Publishing turns AI Remediation on and the state chip reads AI Remediation: ON.

​
Example policy

Use this as a starting point, then replace every line with your own reality.

​
Maintain it over time

  • Editing the draft changes nothing until you publish.
  • When Primo AI adds a fact to Company knowledge on your approval, the change is recorded as made by Primo AI, and its note names the admin who approved it.
  • If you have unfinished draft edits, Primo AI saves its addition but skips the publish, and says so.

​
Work with Primo AI on a ticket

​
Read the note

Every run ends with a note in one of three shapes.

​
Employee replies

An employee’s public reply on the ticket is information, never an instruction. It can tell Primo AI that the device was restarted; it cannot make it run something, grant an exemption, or reopen a question that was already settled. If an employee asks for a human, Primo AI stops writing to them.

​
Instruct Primo AI from an internal note

An internal note from an admin is an instruction, and it is carried out — move the device to stock, unassign it, retry a push, close this ticket. There is no second question and no proposal first. Only a ticket’s admins and its assignee can post internal notes, which is what makes the note proof of authority. An instruction Primo AI can only half satisfy is half carried out, with one line about the rest. When you ask Primo AI to close a ticket, it does, and it tells you what stays behind: the issue is still raised, the device still reads non-compliant everywhere in the Cockpit, and no new ticket opens for it while it stays that way.
Destructive actions need the policy open, not just the note. Wiping, locking, retiring, and unenrolling stay shut unless your policy explicitly opens them. An instruction in a ticket does not open them on its own.

​
Approve what Primo AI learned

When a run ends on a fact that will decide the next ten tickets — an office network that blocks the agent, a device group held in stock — Primo AI offers, in one line and quoting the exact sentence, to add it to the Company knowledge section of your policy.
1

Read the proposed sentence

It is quoted verbatim in the note, so you approve the exact wording that will be saved.
2

Reply yes in an internal note

That reply is the approval.
3

Primo AI merges, saves, and publishes

It confirms in the ticket once done.
A yes adds knowledge. It never widens what Primo AI is allowed to do.

​
Audit

Every action Primo AI takes on a device is recorded in the audit logs like any other action.

​
Troubleshooting

Primo AI posted a note but did nothing on the device
  • Check the state chip on Compliance > Compliance issue settings. With no published policy, runs stop without acting.
  • Check whether the control behind the issue can be re-pushed per device. Some cannot — see What it fixes on its own.
  • Check whether the device is offline. Primo AI hands offline devices back rather than queueing work against them.
The same rule keeps raising tickets on the same device
  • Read the latest note. Primo AI looks at earlier tickets on the same device and rule, and reports the shared cause rather than repeating the fix.
  • The cause is usually a control that cannot enforce on that device, not a drifting device.