Ask what the stages of AIOps are and you get two different answers depending on who you ask. One describes what happens to a signal as it travels through the system. The other describes how far along an organisation is. Both are called stages, they are not the same thing, and a fair amount of confusion in this area comes from one person using the first while the other hears the second.
This follows on from my general introduction to AIOps, which covered what the category is for.
Table of contents
Open Table of contents
The pipeline: observe, engage, act
The first framing splits the work into three parts.
Observe is collection. Metrics, logs, traces and events arrive from everywhere that emits them and get centralised into something with a consistent shape and a common clock. Nothing clever happens here. It is plumbing, and it is where most of the effort actually goes.
Engage is analysis. Correlate the events, separate signal from noise, group what belongs together, detect the anomalies and put a plausible cause in front of a person. This is the part that gets demonstrated in every sales meeting.
Act is response. Notify the right team, open the ticket, or run the fix: restart the service, add capacity, roll back the change. Some of it can happen before anyone reads an alert, which is both the appeal and the risk.
The split is old and it maps onto the loop any operations team already runs by hand, which is a point in its favour. It describes a real sequence rather than a product category. The three parts also fail independently, so knowing which one is weak in your setup is genuinely useful. Most teams I have seen are strong on observe, thin on engage, and nervous about act.
The maturity ladder
The second framing is a ladder with five rungs. Names vary between sources, but it usually runs something like this.
Reactive. Data is collected after the fact and used to explain what already happened. Teams work in isolation and the systems do not talk to each other.
Integrated. The silos start coming down. Data sources are pulled into a common structure and service management processes are joined up.
Analytical. There is a deliberate strategy for the data rather than an accumulation of it. Metrics are defined, measurement is agreed, and the information reaches whoever needs it rather than only whoever owns the tool.
Prescriptive. Machine learning is in routine use and automation is part of the process rather than a project. The system recommends, and increasingly acts, alongside people.
Automated. Predictive models run without intervention, data moves freely between stakeholders, and the analytics are transparent.
You will recognise the shape. It is the same capability maturity ladder that has been applied to software process, security and data governance, and it inherits the strengths and the weaknesses of that lineage.
What counts as a standard here
Worth being blunt about this, because the language sounds more official than it is. There is no standards body for AIOps. No committee published these stages, there is no certification against them, and no two vendors describe them identically.
What exists is analyst framing. Gartner introduced the term, along with the three part pipeline and the usual split between tools that cover one domain and tools that span many. Vendors adopted the vocabulary because shared language sells more easily than proprietary language. That is not a scandal, it is how most operational vocabulary spreads. It does mean the stages are a description rather than a specification, and a vendor claiming your organisation sits at level four is offering an opinion, not an audit result.
The real standards sit next to AIOps rather than inside it. ITIL and ISO 20000 define service management practice, including how events and incidents are handled. OpenTelemetry has become the practical standard for how telemetry is produced and shipped, which matters enormously to the observe stage and is the one I would actually hold a vendor to. Site reliability engineering supplies the measurement discipline, error budgets in particular. If you want something with weight behind it, look there. AIOps is a category, not a conformance target.
Single domain and cross domain
One more distinction, because it decides what you end up buying.
Some tools work inside one area and know it well. A network tool that understands routing, or an application tool that understands request paths. Depth is the selling point, and the models tend to be better because the problem is narrower.
Others sit above everything, taking feeds from the monitoring tools, the security stack and the ticket system, looking for connections no single tool can see. Breadth is the selling point, and the trade is that they know less about each domain they cover.
The analyst terms for these are domain centric and domain agnostic. Most organisations that get real value end up running both, using the deep tools for detection inside a domain and a broad one for correlation across them. That is a more expensive answer than either vendor will give you on its own, which is presumably why neither leads with it.
What the ladder is good for
The maturity model earns its place as vocabulary. It gives a team a way to say where they are without the conversation collapsing into an argument about tooling, and it makes clear that the dull integration work on the middle rungs is a prerequisite rather than a detour. That matters, because the middle rungs are exactly where budget tends to evaporate.
As a target it is weaker, for three reasons.
Maturity is not uniform. You can sit near the top for one service and at the bottom for another in the same building. A single number for a whole organisation is an average that describes nothing in particular. Rate the domain, not the company.
The ladder also implies value is spread evenly across the rungs, and it is not. Most of the return arrives between reactive and analytical, which is the unglamorous part, and the curve flattens after that. A team that stops at the third rung and does it properly is usually in better shape than one that reached the fourth by buying something.
Then there is the top rung. Total automation without human intervention reads well on a slide and is a strange thing to aim at. Automation that acts alone needs a signal you trust completely, and the cases where you trust the signal completely are largely the cases that were easy anyway. The interesting failures are ambiguous by nature, which is precisely when you want a person. A better version of that rung is not the absence of humans but good judgement about which decisions get delegated, and that is not further along the same ladder. It is a different question.
Using it honestly
Three suggestions if you want to get something out of the model rather than quote it.
Rate one domain at a time, and write down the reasoning. The reasoning is worth more than the number.
Aim one rung up rather than at the top. The next rung is a piece of work you can describe, scope and fund. The top of the ladder is an aspiration and cannot be planned against.
Check the pipeline separately from the ladder. A team can look mature on the ladder while its act stage is entirely manual, or look immature while quietly running very good automation on the three things that actually matter.
The stages are worth knowing because everyone in the market uses them, and you need the vocabulary to have the conversation at all. Just hold them loosely. They are a map somebody drew, not a standard anybody has to follow.