# What Applivery Intelligence Can Do > Chat, Insights, Workflows and Cowork — the four surfaces of Applivery Intelligence, the specialist agents behind them, and how each one works. Source: https://docs.applivery.com/en/intelligence/capabilities/ • Last updated: 2026-09-11 --- Applivery Intelligence is made of four surfaces. **Chat** answers questions and takes actions. **Insights** turns answers into live dashboards. **Workflows** automates what happens next. **Cowork** watches the fleet without being asked.

Surface	Plan required
Chat	Free, Pro, Max, Ultra
Insights	Max, Ultra
Workflows	Max, Ultra
Cowork	Max, Ultra

:::info **Generally Available — and actively evolving.** Applivery Intelligence is generally available and supported. It is also an AI product under continuous research and improvement: answers are generated, capabilities change between releases, and mistakes are possible. Review what it produces before acting on it — particularly anything that changes a Device. ::: ## Chat Chat is the front door. You ask in plain language; it answers from live Applivery data. ### How an answer is produced A single message is not handled by a single model. Intelligence runs a **coordinator** that reads what you are asking for and routes it to one or more **Agentic Specialists** — each with its own brief, its own instructions and its own restricted set of Applivery tools. The coordinator itself has no access to your Devices at all: every answer that carries data came from a specialist that had to go and fetch it.

Specialist	Owns
Compliance Agent	Posture, audits, who is compliant or drifting, violations
Security Agent	Device actions — move, rename, lock, wipe, install — and risk triage
Impact Agent	Read-only "what if": before/after, simulated Policy composition
Policy Agent	Policy design, comparison, priority tuning, Segment permissions
Insights Agent	Fleet analytics — trends, distributions, charted reports
Knowledge Agent	Product and REST API documentation, answered with cited links
Policy Architect	Designs and creates ready-to-apply Policies for Apple, Android, AOSP and Windows
Scripts Engineer	Authors, creates and assigns macOS Bash and Windows PowerShell scripts
Vulnerability Agent	Known CVEs for an OS or app version, with severity, KEV and exploit likelihood

When a request spans domains — "which Devices are non-compliant, and what would fixing the Policy break?" — the coordinator delegates to several specialists in parallel and then writes one answer. The badge on each reply tells you which specialist produced it. ### Artifacts — answers you can work with When an answer contains structure, it is rendered as an **artifact** in the side panel rather than as a wall of text: a sortable Device table, a Policy comparison, a map, a chart, a CVE breakdown. Artifacts are interactive. Depending on the type you can: - **Sort and filter** columns, and click a row to drill into that Device or Policy. - **Download the data as CSV**, from the table's own download button. - **Add it to a dashboard** with **Add to dashboard**, which turns the answer into a live widget that refreshes on its own. - **Copy the raw JSON** behind it. Types include Device lists and Device detail cards, Device maps, Policy lists, Policy detail, Policy composition and Policy comparison, app-usage and data-usage reports, multi-chart data reports, generic data tables, cited documentation, REST endpoint references, and the three vulnerability views. ![List of devices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/041b09c1-5020-4153-a1cf-c067ac627344.png) ### Referencing objects with `@` Type `@` in the message box to search and insert a specific object instead of describing it. You can mention **Devices, Policies, MDM Users, Segments, Device Audiences, Automation Rules** and **Enrollment Templates**. The reference carries the object's identity, so the assistant does not have to guess which "MacBook Pro" you meant. ### Permissions and approvals This is the part worth reading twice. **Intelligence acts as you.** It calls the Applivery API with your own Workspace credentials, under your identity. Your Applivery role is the ceiling — there is no service account, no elevated mode and no way for the assistant to escalate. Actions appear in the Applivery audit log under your name. **Reads and writes are separated by design.** Anything that only reads (`get`, `list`, `search`, `preview`) is classified as a read; everything else is classified as a write, including capabilities that did not exist when the rule was written. The read list is an allowlist rather than a list of things to watch out for, so a new capability with an unfamiliar verb is treated as a write until somebody decides otherwise. This classification is what the platform's own safety rules run on — it is not the same thing as your approval settings below, which you control per capability. **Some actions always ask, and cannot be set not to.** Wiping a Device, locking a Device, and anything that deletes are permanently gated behind a confirmation, regardless of your saved preferences. When one is proposed you see exactly which action, on which Device, with which parameters — and nothing runs until you approve. **You tune the rest yourself.** Open the gear icon in the top bar and go to **Integrations > Applivery MDM > Tool Permissions**. Every capability is listed with what it does, and can be set to:

Setting	Effect
Always allow	Runs without asking you
Needs approval	Asks you every time
Blocked	Never runs — the assistant is told the capability is unavailable

Two things follow from where this setting lives: - **It is yours, not the Workspace's.** It applies to your own conversations only. Relaxing a capability for yourself does not stop a colleague being asked about it, and blocking one does not take it away from them. There is no Workspace-wide tool policy — the shared backstop is your Applivery role. - **Everything starts on "Needs approval"**, reads included. A brand-new seat is asked about every single call until you go through the list and allow the ones you are comfortable with. That is deliberately noisy on day one; ten minutes on this page is the fix. Permanently-gated actions show a **Locked** badge and cannot be moved off _Needs approval_, no matter what you save. The **History** tab next to it lists the calls made from your own chat sessions — the capability, its input, the response, latency and time — over the last 7 days, 30 days or 3 months. ![approval required](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d6daac18-bbf7-45e9-b003-3c71e45cf0bc.png) :::warning For anything irreversible — wipe, disenroll, delete — ask for the list first, read it yourself, and only then ask to act on it. Approving a batch you have not read is the one reliable way to get a bad outcome from a good tool. ::: ### Guardrails Chat is scoped to device management. A few protections run on every message: - **Prompt-injection filtering** — attempts to override the assistant's instructions or extract its configuration are refused. - **Scope filtering** — the assistant declines requests unrelated to your fleet. - **Message length and rate limits**, set per Workspace by Applivery. - **A hard block on answering without data.** If the Workspace exposes no Applivery tools — a misconfigured Workspace, a role with no permissions — chat refuses to answer rather than inventing a plausible fleet. - **Anti-fabrication rules.** The assistant may not claim it produced a file, chart or table it did not actually render, and may not claim an action succeeded unless the tool confirmed it in that same turn. ### Managing conversations Your conversations are **yours**. They are saved against your own account, listed in the left panel, titled automatically from the first question, and can be renamed, archived or deleted there. Colleagues with a seat in the same Workspace do not see them — what is shared at Workspace level is dashboards, workflows and Cowork findings, not chat. Switching Workspace switches the list: a conversation belongs to the Workspace it was started in as well as to you. Each answer is followed by suggested next questions, grounded in what Applivery can actually do rather than generic prompts. ## Insights **Insights** turns answers into a monitored view. Available on Max and Ultra. ### Dashboards and widgets A dashboard is a grid of widgets you arrange by dragging and resizing. Widgets are created in two ways: - **By promoting a chat artifact** — ask a question, get a table or chart, click **Add to dashboard**. The widget keeps the query behind the artifact and re-runs it on its own from then on. - **By adding one directly** to an existing dashboard. ![insights dashboard](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3cf793d7-224d-4423-ad4c-f9a7215c4eed.png) Widget formats are **KPI** (a single number with a trend), **line**, **bar**, **donut**, **table**, **map** and **card**. Which formats are available depends on what the underlying data is — a Device list can be a table or a KPI; a location query can be a map. :::tip The fastest way to build a dashboard is to have the conversation first. Ask the four or five questions you would ask on a Monday morning, and pin each answer. ::: ### Refreshing Each dashboard is either **manual** or **scheduled**. Scheduled dashboards refresh on a cron expression with full time-zone support, from every 5 minutes to daily. The header shows the last refresh, the next one, and warns you when a refresh is overdue rather than quietly showing stale numbers. **Refresh all** re-runs every widget on demand. A single widget can also be refreshed on its own, and its underlying query can be edited from the widget menu — **Edit query** renders a form from the real parameter schema, so you can change a filter without going back to chat. ![refresh schedule](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d4b9e8da-7487-4bab-9761-a8f563c2abbc.png) ### Alerts Any widget can carry alert rules, evaluated on every refresh — scheduled or manual.

Condition	Fires when
Threshold	A number crosses a boundary (`>`, `>=`, `<`, `<=`, `==`, `!=`)
Change	The value moves by more than N %, or N in absolute terms, up or down
Absence	The widget has not refreshed within a time window

Two independent gates sit between "condition met" and "you are notified": - **Notify mode** — _on change_ (the default) fires only on the transition from healthy to triggered, and stays quiet while the condition remains true. _Every_ fires on each evaluation. - **Cooldown** — a minimum number of minutes between notifications, regardless of mode. Every fire is recorded in the widget's alert history with the value that caused it. A fired alert can also start a Workflow. ## Workflows **Workflows** are visual automations: a canvas of nodes joined by edges, run in order, with branching, loops, human approval and AI steps. Available on Max and Ultra. ### Triggers Every workflow has exactly one trigger:

Trigger	Fires when
Alert	A dashboard alert rule fires. One alert can start several workflows.
Schedule	A cron expression, in the time zone you choose
Webhook	A third-party system posts to a private URL (Jira, PagerDuty, a script)
Manual	Somebody presses Run

A workflow can also be invoked by another workflow as a sub-workflow, synchronously or in the background. ### What a node can do

Group	Nodes
Actions	Call any Applivery capability; send an HTTP request; run another workflow
AI	Ask a model to classify, summarise or draft, and use the result downstream
Notifications	Email, Slack, Google Chat, generic webhook
Logic	Conditional, switch, filter, transform, aggregate, merge
Loops	For-each over a list; retry with exponential backoff
Human	Approval gate — pauses the run and waits for a person
Utility	Delay, expression evaluation

Values flow between nodes as `{{templates}}` — `Device {{trigger.deviceName}} — battery {{trigger.battery}}%`. ![workflow](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4520b400-e5c6-4176-8e88-57ea7ecaaa10.png) ### The approval gate An **approval** node pauses the run and sends a link. The recipient approves or rejects, and the workflow continues down the matching branch. If nobody answers within the timeout, the run takes the **rejected** branch and records that it timed out — it does not sit paused forever, and it does not proceed by default. This is the node to put in front of anything that touches Devices in bulk. ### The AI Workflow Builder Rather than drawing the graph yourself, describe it: > Create a Slack alert when a Device goes non-compliant. > Every Monday at 9 a.m., send a Google Chat summary of total Devices by platform. The builder proposes a concrete set of changes and **waits for you to approve them** before touching the canvas. Applied turns can be reverted one at a time. ### Integrations Notification and AI nodes need credentials, configured once per Workspace under the gear icon > **Integrations**: API keys for Anthropic, OpenAI or Google, a Resend key for email, and Incoming Webhook URLs for Slack and Google Chat. Each entry carries setup instructions with links to the right page on the provider's side. They are encrypted at rest, belong to the Workspace rather than to you, and are separate from the credentials chat uses. ### History Every run is recorded with its trigger, its duration, its outcome and the input and output of each node, so a failure can be read rather than guessed at. Node-level history is kept for 30 days; run status is kept indefinitely. ## Cowork **Cowork** inverts the initiative. Instead of waiting to be asked, Applivery Intelligence's **Agentic Specialists** run in the background, examining the fleet on a schedule and producing **findings** — inbox items you acknowledge, accept, discuss or approve for execution. Available on Max and Ultra. ### Monitors, checks and findings A **check** is a fixed thing to look for, shipped by Applivery. A **monitor** is your Workspace's instance of that check: enabled or disabled, on a cadence, with a scope, thresholds and a minimum severity. Two Agentic Specialists run them. The **Posture Auditor** takes the hygiene, access, inventory and configuration checks, and may propose a remediation from a fixed catalogue of actions. The **Threat Analyst** takes the anomaly checks and never proposes a write at all — its job ends at telling you what changed. You configure monitors. You do not write checks — and that is the point. Detection is deterministic code, not a specialist deciding what looks wrong. The specialist receives what the check already found, along with the evidence, and its job is to triage it, write it up clearly, and where the check allows it, propose a remediation. A number in a finding was computed, not generated, and it is recomputed afterwards to confirm it. ### What the catalogue covers - **Posture and hygiene** — stale check-in, compliance drift, unassigned Policies, obsolete OS versions, low battery, empty Audiences, inert Automation Rules. - **Access and people** — over-broad grants, conflicting roles, Collaborators without MDM access, privileged accounts without 2FA, dormant privileged accounts, never-activated accounts, grants that reach nobody, redundant app roles. - **Inventory** — assets linked to deleted Devices, duplicate serials, asset type contradicting the hardware, managed Devices with no asset record. - **Effective configuration** — Policy composition conflicts, kiosk hardening gaps, trivial secrets in an applied configuration, Policies that compose to nothing. - **Usage and anomalies** — idle managed assets, data-usage spikes, app-usage spikes, enrolment-rate spikes, changes to privileged grants. Anomaly checks compare a Device only against **its own** history, so a heavy user is not flagged for being a heavy user. ### Reading the inbox Findings arrive as a **list** or a **board**, filterable by monitor. Every card names the check that produced it, its severity, and the Devices or people it covers. ![cowork list](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/53420cbf-fb65-44b4-a934-de49a8163906.png) ![cowork detail](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a6a18bd1-e13e-4c60-8f0b-33d70b134bc4.png) The status of a run matters as much as its result. Cowork distinguishes "the check ran and found nothing" from "the check could not run" — a credential problem, an empty population, a budget stop. An empty inbox only shows the green _Nothing to review_ state when there is positive evidence that the fleet was actually examined. For each finding you can: - **Discuss it** in a side chat with the specialist that produced it, which still has the evidence. - **Accept** it — it stays detected and recorded, but stops asking. Accepted findings are listed separately and acceptances can be reviewed and undone. - **Dismiss** it. - **Approve** the proposed remediation, where the check offers one. ### Approve, execute, revert When you approve a remediation: - It runs a **fixed, versioned template** shipped by Applivery, not a plan the model composed. Cowork can name a remediation; it cannot invent one. - It targets **only** the subjects in the finding that survived re-verification. The model is structurally prevented from naming a target of its own. - It runs under **your** Applivery credentials, so Applivery's own permissions are the real backstop and the audit log names the right person. - **Revert** undoes only the steps that actually succeeded, and only the exact changes that execution made, per Device. Reverting does not re-open the finding: the problem is back exactly as it was. ### Limits and stopping it Cowork is the only surface that spends without a human waiting on it, so it is bounded separately: its own daily token budget, a cap on runs per Workspace per day, and caps per run on iterations, tool calls, findings emitted and actions executed. Your own controls are per monitor, on **Cowork > Monitors**: enable a check or disable it, change its cadence, narrow its scope, move its thresholds, raise its severity floor. A disabled check does not run and reports nothing, and the page says so on the card rather than leaving it looking healthy. To stop Cowork entirely in a Workspace, disable every enabled monitor. Applivery also operates platform-level switches that can suspend Cowork detection, delivery or execution across the service — for an incident, or at your request. Those are not in your dashboard; ask your Applivery contact.