# The roadmap and path to autonomous AI in software monitoring The difference between the future and the status quo of production monitoring operations is vast. The Future: At one end, a human reads alerts, opens issues, and fixes manually. At the other end is the future, where humans are rarely involved in Day 2 operations; a system finds the problem, works out the cause, and fixes itself, while a human is only tagged in when needed. The useful question there isn't "are we automated?" It's like: what specifically is stopping us from moving up one level? And is there any merit in moving another layer up? At DrDroid, we've been iterating over the different layers of automation & autonomy in production monitoring systems. In this blog, we have discussed a model to define different levels of autonomy in software systems and what each of these levels means. ![](https://cdn.hashnode.com/uploads/covers/6a0febdbd8e265f60d9348f4/0f527814-b7da-4a90-be80-beeb421da590.jpg align="center") ## Level 0: Observability Observability is the first layer of moving towards autonomous infrastructure. Here's what it means for a software system to be classified as a Level 0 system: * **Data exists:** Your stack is instrumented with fair coverage of logs/metrics/traces/events so that unknowns can be identified and resolved (by humans). * **Signals exist:** Exhaustive coverage of alerts across infrastructure, application, and CUJs (Critical User Journeys) that help your team identify/detect early on. * **Human driven:** A human does everything. An alert tells you something is wrong; you decide what that means, where to look, and what to do about it. ### Level 0: Outcome An engineering team has enough data at most points to be able to detect, diagnose, and fix an issue with the data points. And that is where the first level ownership comes in. **Ownership:** Engineers & Teams own everything. ## Level 1: Scripted automation This is where most of the Pre-AI era automations reside. For example, * Have a known issue where pods need to be restarted. * Have a user related alert - auto fetch 5 more data points and append them to the alert. Folks automated the runbook. Beyond the runbooks, engineers handle everything the scripts don't cover, which is still most of the work to do. ### L1 outcome: The biggest value add often of the first layer is * Fallbacks with quick remediations come into picture. * Automations by engineers who would otherwise manually do the exact same steps. Scripted automation is reliable and brittle at the same time. It does exactly what you told it and nothing else. The moment an incident doesn't match a known pattern (which is quite often!), you end up in the same loop of humans doing things. Also, they can get outdated as systems evolve. **Tools:** Automation & workflow frameworks like [Playbooks](https://github.com/DrDroidLab/playbooks) and StackStorm, or just plain vanilla bash/python scripts are the common strategies used by teams here. ## Level 2: Agentic investigation This is the first level where the machine comes into play and does real work instead of being an NPC. For example, an alert fires, and an agent pulls the relevant logs, correlates the recent deploy, checks the downstream service, and hands you a first read on what's going on. But you still have to decide and act. You don't start things from scratch - the agent compresses the first twenty minutes of every incident into something you can read in a few minutes, instead of manual assessment. ### L2 Outcome: When an L2 layer is successfully implemented, here's what teams benefit from it: * Humans receive an alert along with detailed investigation - Agent identifies what triggered this issue, accurately and consistently. * While humans might have skipped analysis or serialised analysis when there's a surge of alerts, here the agent can run parallel investigations and help get up to speed faster. Note: A successful Level 2 autonomy layer in your software infrastructure means that the system can auto-identify the triggers ***accurately***. "Accurately" is important because a system used in production infrastructure needs high reliability for engineers to trust in high stakes environment. ### Pre-requisites: While this investigation agent sounds simple early on, there are nuances that make it tricky to get to the end line: * **Agent with access to tools:** As you retrospect over more and more production incidents, it's clear that only the logs and metrics don't tell the full picture. Teams often end up checking deployment configs (in CI/CD tools), code review (in GitHub repository), customer level data (in internal tools/databases), security/configs in cloud and more. For an agent to be able to pinpoint triggers better, it needs access similar to the access that a senior engineer might have. * **Context:** Tribal knowledge, company infrastructure, and known patterns are a big giveaway when it comes to production troubleshooting. You need to setup a basic layer of Context for the agent to be able to operate well - it could begin, initially, with some architecture docs and some skills, but eventually as you try to iterate and improve the agent's accuracy so it becomes near accurate in every instance, it needs to be a continuously updating context map/knowledge graph about your infrastructure. ![A representative of what a mental model of context could look like](https://cdn.hashnode.com/uploads/covers/63200bf16c86d75accc7fd61/46217875-fb3c-4b9d-8e51-0c105bb06794.png align="center") **Ownership:** * At this stage, tickets & alerts are still assigned to humans. Dedicated engineers (on-call) are still looking at noisy alerts in Slack. The first responder on a Pager is still an engineer. * The engineer does not have the full burden of doing the heavy lifting, but validating the AI's insight & recommendations. * The builder of the AI Agents + service owner has the implicit responsibility to ensure that the Agent has the right context + right harness to avoid hallucinations, poor correlations. ## Level 3: Cognitive decisioning At Level 3, we are turning the tables with regards to ownership and workflows. Humans are not dedicatedly looking at Day-2 ops every now & then. The agent doesn't just investigate an issue after it's identified as an alert or incident. It triages every signal, identifies if it's actually an issue, clusters it with other existing/ongoing issues and routes it to the right owner (with the root cause proposed). ### Level 3 Outcome: * The ownership of sifting through alerts & signals --> detecting issues and identifying the owners of the actual trigger of the issue are not done by on-call engineer, but by the Agent. * Agents consume all alerts & signals, run all investigations and cluster them into actionable buckets. Humans review this on demand. * The agent also has access to known fixes and can apply them without approval. It can also apply new fixes but needs peer (human) review, as is the norm with any process today. ### Pre-Reqs: * **Root cause quality:** If your agent isn't able to investigate well, it will have exponentially higher risk here because the failure would compound across multiple queries, and poor data can lead to partial assessments. * **Context Map:** When an agent needs to be able to discover and navigate a given architecture, skills alone wouldn't help. * **Self-learning:** The architecture upgrades every day. The agent's context map needs to be able to continuously update itself - learning from everyday changes, patterns and more. The effect here is that it has what you can call a pseudo world model - where all the known components are known. What makes this possible is the context graph, which I'd call a **pseudo world model**: a representation of services, dependencies, ownership, and normal behavior that lets the agent reason about consequences instead of pattern-matching on symptoms. It knows that restarting this pod drains that queue and that the queue feeds a job someone cares about. The word "pseudo" is doing a lot of work here. The model is good enough to propose the right action most of the time, which is why the human role collapses to a single thing: approve. The agent does the thinking; you say yes or no. And nothing gets resolved on the agent's say-so alone, because the model is approximate, and approval is where a person catches the cases it gets wrong. This is where on-call changes shape. The reason is specific, and it's the part most people get backwards. > And after level 3, you even don't need human on on-call People go on call because someone has to be accountable for acknowledging an incident and seeing it through to resolution. That's the actual job. Below level 3, that ownership can't be handed off. The machine can investigate, but it can't be trusted to act, so a human has to be reachable to make the call and give the fix. Here, the shape inverts. The agent triages, routes, and proposes around the clock. A person isn't tagged for every incident anymore. They get pulled in for two cases: the agent got stuck, or it found something critical enough that it wants a human in the loop before making a decision. On-call stops being "wake up for every alert" and becomes "be reachable when the system asks for you." That's the real reason to climb the ladder. ## Level 4: Autonomous resolution This is the highest level in AIOps. The system detects, decides, fixes, and closes the loop on its own; we can also say it is self-healing. Humans provide oversight, not sign-off, on each action. The gap between level 3 and level 4 is just one word, and that changes the whole game: the model goes from pseudo to true. A pseudo world model is a good map. A true world model is one which is accurate enough that the system can act on its own predictions without a person checking each one. The difference is trust, and trust here is earned through accuracy on the consequences that actually matter. At level 3, you approve because the model might be wrong. At level 4, you don't, because it's been right often enough, on the decisions that count, that supervision can replace approval. That's a research problem, not a ship date. Building a model of a live distributed system that's accurate enough to trust with self-healing is hard for the same reason modeling is hard everywhere in AI; the map drifts from the territory the moment you finish drawing it, and a distributed system rewrites its own territory every deploy. ## How We're Building This Future At [DrDroid](https://drdroid.io/), we don't think the journey to autonomous operations happens overnight. The biggest gap today isn't better LLMs; it's reliable context. Production incidents require reasoning across monitoring systems, deployments, cloud infrastructure, code repositories, ownership information, historical incidents, and internal documentation. Without that context, AI agents remain assistants instead of operators. That's why our focus has been on building AI SRE agents that combine deep infrastructure context with access to operational tooling. Today, those agents help engineering teams investigate incidents automatically, correlate signals across systems, identify likely root causes, and reduce the manual effort required during on-call. We're also investing heavily in the next stage: creating a continuously evolving infrastructure context graph that enables higher levels of autonomy, including intelligent alert grouping, issue clustering, ownership discovery, and eventually AI-assisted operational decision making. We don't believe autonomous operations arrive through one breakthrough model. They arrive by solving each layer of the maturity model with enough reliability that engineers naturally trust the next one. ## So, where are the teams actually? Most teams are still at ground level. A growing number are reaching for agentic investigation, and that reach is realistic today. Cognitive decisioning is the current frontier, where the context graph/knowledge graph is the thing separating the teams that talk about it from the teams shipping it, actually. Autonomous resolution is where organisations wanted to go, but very few products are actually there today. > The maturity model isn't about measuring how "AI-powered" your operations are. It's about identifying the single capability that unlocks the next stage. Progress isn't made by adding another LLM or another dashboard, it's made by removing the biggest problem in your incident response workflow and that we already know.