Incident agents

The Incident Management blueprint ships two AI agents that do the routine reading a service desk lead does on every incident. When an incident is created, Incident Triage answers in one call: it reads the record together with the application’s own teams, categories and a short list of similar resolved incidents, and proposes a category, a team, an impact and an urgency, with a plain-language reason and, where one genuinely fits, a cited precedent. It never calls a tool and it never loops; the platform builds everything it needs up front and sends one request. When the incident is resolved, the Incident Closure Reviewer audits the resolution notes, code and category before the record is closed, taking as many turns as it needs to look things up. Neither agent writes a field on its own: each proposes a plan that a person approves, and Incident Triage’s reasoning lands on the incident timeline as a plain-language note.

When you’d use it

No incident leaves intake unclassified or unowned. An incident that arrives without a category, a team, or a clear impact and urgency gets a proposal for whichever of those four is missing, sourced from the application’s own category-to-team routing and from how similar past incidents were resolved. When nothing in the catalog genuinely fits a field, Incident Triage says so instead of guessing: it leaves that field unproposed and, when neither category nor team fits, flags the incident for a person to look at.
A fast, consistent first read. Because Incident Triage is one call rather than a multi-step investigation, every new incident gets the same four-field read within seconds, with its confidence and the precedent it relied on stated plainly.
Trustworthy closed records. Closed incidents feed reporting and future recall. The closure reviewer flags empty or vague resolution notes and proposes corrections to the resolution code or category when they contradict what happened.

What you manage

The two agents install with the Incident Management blueprint and appear under Admin → AI → Agents as Incident Triage and Incident Closure Reviewer. Each is a standard agent you can open and tune:

Status. Both agents ship active on a new tenant. An already-installed tenant that paused Incident Triage keeps that choice when the blueprint updates; a package upgrade never flips a switch a tenant already set. Set either to paused in its designer page to stop dispatch temporarily, or retired to stop it for good; runs and history stay.
Approval routing. The suite ships with no default approver, so proposals route to your tenant admins with a visible routing label. Set a Default approver (user or group) on each agent, or add an approval policy, to direct review to your service desk leads.
Model. Incident Triage is pinned to a fast, low-effort model call by design, since it answers one structured question rather than investigating; the Closure Reviewer uses the tenant default model, and you can pick a stronger one per agent if your volume warrants it.
The charters. Each agent’s behavior is written in a skill (for example Incident Triage Charter). Incident Triage’s charter is desk knowledge only, how to read the category and team list and the precedent list, when to cite one, when to ask for human review, when to abstain rather than guess. Edit it under Admin → AI → AI Skills to change that judgment, not a workflow: Incident Triage holds no tool and takes no step-by-step instruction.
Triggers. Incident Triage fires on every new incident that is not marked a duplicate; the Closure Reviewer fires when the state changes to resolved, using the Has Changed To operator in the trigger condition editor. Resolving an incident Incident Triage is still working closes its own pursuit on that same transition, so the Closure Reviewer wakes without waiting for Triage to finish first.

Good to know

Every change is human-gated. Incident Triage holds no tool at all; the Closure Reviewer holds read tools only. A proposed change arrives as a plan on the incident, fenced to record updates, and applies only when an approver accepts it. Rejecting costs nothing.
“Nothing to change” is a normal outcome. When every field already looks right, Incident Triage completes with an empty plan and posts its reasoning to the timeline as a plain note. No review work is created.
Abstaining is a normal outcome too. When nothing in the category or team list genuinely fits, Incident Triage proposes neither rather than naming the closest-sounding entry, and a thin or conflicting read is flagged for a person before it reaches the queue.
Plans carry a field fence, enforced by the platform. Each agent declares the only fields its plans may touch (Incident Triage: category, assignment group, impact, urgency; Closure Reviewer: resolution code, category). A step naming any other field is rejected before the plan is even created. The closure reviewer can never write resolution notes: it was not there when the incident was worked, so any notes it wrote would be invented history.
Incident Triage never retries a bad answer. If its one call comes back unusable, the run fails with a stated reason and a note that a person should triage the incident, rather than guessing or asking the model again.
Precedent needs history. Similar-incident recall reads the operational memory index, which fills as incidents reach a terminal state. On a fresh tenant the first triage runs will find little precedent; quality improves as resolved incidents accumulate.
Re-runs are deduplicated. One live run per incident per agent; rapid edits do not spawn parallel runs. Incident Triage never re-enters an incident after its plan is approved and run; a later @agent mention on that incident reaches the table’s usual front door, not Incident Triage again.

How it connects

These agents are ordinary agents wired to record triggers; the blueprint only supplies the specs and charters. Reviewing and approving their proposals is the standard plans flow. Similar-incident recall is operational memory. Intake routing itself, the chain that stamps the assignment group Incident Triage checks, belongs to Service Hub; the agents challenge its verdict but never re-implement it.

Now do it: Design an agent covers the designer surfaces these agents use.

Exact shapes: the agent spec and trigger shapes are in the blueprint reference on Agents.