The term "AI-native" is doing a lot of work right now, and most of it dishonestly. Every legacy ITSM vendor has shipped a chatbot, called it AI-native, and continued to ship the same 1,200-step workflow editor underneath. That is not what we mean by the phrase, and it is worth saying out loud what we do mean — because the difference is not cosmetic.
The legacy shape
Pick any of the big-three ITSM suites. The product is built around a configurable workflow engine: states, transitions, approvals, fields. To make it useful for a specific company, somebody — usually a paid implementation partner — spends three to nine months modelling that company's processes into the engine. The "AI" layer that gets bolted on at the end is almost always one of these:
- A natural-language wrapper around the same workflow ("create an incident assigned to the network team for a database outage" → fills in the form).
- A summarisation widget on existing tickets.
- A knowledge-base search that uses embeddings instead of keyword match.
These are useful. They are not the product. The product is still the workflow engine, and the workflow engine still demands the three-to-nine-month modelling exercise before anyone benefits.
What changes when AI is upstream of the config
The interesting question is what a product looks like if you assume from line one that there is a model in the loop. Three things change.
The schema gets smaller. You do not need a severity field that the user has to pick from a dropdown — the model classifies it from the title and description, and the dropdown is the override. You do not need a category field with thirty options the user has to remember — the model picks the right team. The fields that remain are the ones a human genuinely has judgement on: who owns it, when it should be done, whether to wake somebody.
The setup screens disappear. Argus has no CMDB-modeller, no workflow editor, no field-builder. The first incident you create is the first incident you create — there is no "implementation phase" before it. The model handles the cold-start by classifying from the text; the structure accretes from your real incidents over time, not from a planning document up front.
The search changes. A legacy ITSM search is "filter by status, assignee, severity, label, date range." That works if you remember the metadata. An AI-native search is "incidents with the queue lag pattern from last quarter" — plain English, semantic match, the result is a list of incidents you can scan. Both still exist in Argus; the second is the one people actually use.
What does not change
It is important to be honest about this part because the hype cycle is currently overstating it.
- Humans still own decisions. The model classifies, suggests, drafts. The human accepts, overrides, publishes. The audit log records who did what, and "the model" is a who.
- The data layer is still a data layer. Multi-tenant Postgres with strict row-level isolation, audit log on every entity, encryption at rest. None of that changes because there is a model in the loop. If anything, the audit-log requirement becomes stricter, because "the AI did it" is not an acceptable answer to a customer asking what happened to their incident.
- Integrations still matter. A model that cannot read your alerting feed, your change-management system, your on-call rotation, is a model that can only guess. The AI surface is only as good as the data surface underneath it. We spend a lot of engineering on the boring integration plumbing for exactly this reason.
The honest version
AI-native ITSM means the model is a citizen of the schema, not a feature on a tab. It means the dropdowns shrink, the setup screens go, and the search becomes a sentence. It means the implementation phase that used to take a quarter takes an afternoon, because the structure comes from the data, not from a planning document.
It does not mean the humans go away. It does not mean the audit trail relaxes. It does not mean the model is always right. It means we have re-drawn the line between "where the human's judgement is load-bearing" and "where the model can do the dull reconstruction work" — and we have re-drawn it honestly, not by gluing a chatbot onto a workflow engine.
That is the bar we hold ourselves to with Argus. The rest of the category will get there too, but they will have to ship the smaller, simpler product to do it — and most of them will struggle, because their revenue depends on the bigger one.