The 2026 Agentic Ops Buyer's Guide: Four Vendor Categories, Ten Guidelines, and One Very Optimistic ROI Model

Somebody finally wrote the document everyone in this space keeps asking for.

Toshal Khawale is an AWS Community Hero, leader of the AWS User Group in Pune, and a managing director at PwC India. In July 2026 he published a 15-page paper called The Rise of AI-Agents & Agentic Automation for Enterprise Operations, built on Gartner, Forrester, RAND and MIT research, and posted it on LinkedIn.

We are reproducing it here, PDF and all, because it is the most complete public buyer's guide to agentic ops we have seen, and because the vendor landscape section is the kind of thing that usually only exists behind an analyst paywall.

Download the full 15-page paper (PDF)

The setup: two numbers that do not agree

The paper opens by putting two research findings next to each other and refusing to resolve the tension.

Gartner's first-ever Market Guide for AI Site Reliability Engineering Tooling, published January 2026, projects that 85% of enterprises will use AI SRE tooling by 2029, up from under 5% in 2025. That is a 17x adoption jump in four years, one of the steepest curves the analyst has forecast in a decade.

Against that: RAND puts the enterprise AI project failure rate at 80%. MIT's Project NANDA found 95% of generative AI pilots deliver no measurable P&L impact. Gartner's own April 2026 I&O research says only 28% of AI infrastructure projects deliver expected returns, and that 84% of failures trace to leadership decisions, not technical limitations.

Both things are true at once. Everybody is going to buy this, and most of them are going to do it badly. The rest of the paper is an attempt to be in the other group.

The core argument: hybrid routing, and who owns it

The strongest technical section is on model routing, and it lands on a position that cuts against how most platforms are architected today.

Roughly 80 to 90% of routine ops volume should run on small language models and open-weight models, self-hosted or in a dedicated tenant. Alert triage, log queries, ticket classification, status summaries. Latency-sensitive, data-sensitive, high-volume. The remaining 10 to 20% (novel incidents, complex change-risk assessment, ambiguous multi-step planning) routes to frontier models via API.

The paper gives a three-tier breakdown: SLMs like Phi and Mistral-7B at 60-70% of volume, mid-size open-weight models at 20-30%, frontier models at 10-20%.

Then the part worth arguing about:

The routing itself has to be platform-owned. A neutral third-party router cannot know that a particular alert is really about a novel dependency failure, or that a particular remediation candidate needs deeper validation. Routing decisions are context-informed, and the context lives in the platform. This is not plumbing. It is a first-class capability.

That is a direct shot at the model-gateway-as-a-separate-product category. If routing quality depends on knowing what the task actually is, and task context lives in the ops platform, then a generic router optimising for cost per token is optimising the wrong thing.

The vendor landscape

This is the section people will actually screenshot. The paper sorts the market into four architectural approaches and is unusually blunt about the trade-offs in each.

Observability platform extensions: Datadog Bits AI, Dynatrace Davis AI, Splunk AI, Grafana Assistant. Zero deployment friction if you already run the stack. But: "strong at correlation and postmortem generation, weak at autonomous multi-step action," and lock-in now extends from your telemetry to your agent layer. Verdict: fine as a starter tier, not the answer.

Hyperscaler-native agents: AWS DevOps Agent (GA March 2026), Azure SRE Agent, Google Cloud Gemini for SRE. Deep IAM integration, no separate procurement. But primary optimisation is always the home cloud, and model choice is constrained to the provider's stack. Verdict: "locking into a hyperscaler agent means locking into the hyperscaler for the life of the platform."

Open-source agent projects: K8sGPT, kagent, HolmesGPT. Free to try, full source access, good for engineering-led evaluation. But the build-and-maintain burden is real and internal forks fall behind within a quarter. Verdict: pilots and learning, not the production destination for regulated workloads.

Specialist agentic-native platforms, and this is the category the paper recommends:

Truly AI-native architecture, built agent-first from day one, not bolted onto an observability or cloud console. Specialists understand agentic nuances at depth. Vendor-neutral across clouds and observability providers, which minimizes lock-in. Specialization drives faster capability evolution.

Best suited for: enterprises that want autonomous multi-step action, need multi-cloud and multi-observability neutrality, care about long-term flexibility, and are prepared to invest in a proper implementation.

The named vendors in that category: NudgeBee, Resolve.ai, Traversal, NeuBird AI, Cleric, Komodor Klaudia.

The paper then profiles several of them by what they lead on, which is more useful than a magic quadrant because it assumes you will shortlist two or three rather than pick one:

• Resolve.ai: autonomous incident resolution. Dynamic self-learning knowledge graph targeting 80% autonomous resolution. Best fit for teams prioritising autonomous resolution over other agent classes.
• NudgeBee: a unified multi-agent platform running three specialist agents. Knowledge graph, memory and service graph as first-class objects in the context layer. Supports BYOC, self-hosted and cloud deployment. Best fit for enterprises wanting unified coverage with deployment flexibility.
• Traversal: causal machine learning for root cause analysis, reasoning about dependencies rather than correlations alone. Best fit for complex cross-service dependency graphs.
• NeuBird AI: breadth of observability integrations. Reads in place from Datadog, Splunk, New Relic, Prometheus, CloudWatch and Azure Monitor without data migration. Best fit for heterogeneous telemetry stacks you do not want to re-platform.
• Komodor Klaudia: deep Kubernetes specialisation with cluster-aware reasoning. Best fit for container-centric operations.

His closing note on the category is the practical one: shortlist across all four categories, not within one. Comparing a hyperscaler agent against a specialist during procurement forces you to confront trade-offs you would otherwise never surface.

The class everyone underestimates

The paper splits agentic ops into three agent classes (AI-SRE for incidents, AI-Ops for automation, AI-Cost Ops for FinOps) and argues the middle one is where most of the unclaimed value sits.

Incidents are where every team starts, because incidents are loud. But the actual drag is the long tail: certificate rotation, configuration drift cleanup, environment refreshes, backup verification, dependency updates, cross-account log routing. Individually trivial, collectively enormous. The paper puts long-tail automation at $2M+ per year at typical enterprise scale and developer self-service query deflection at roughly 25% of L1 volume.

Related, and the sharpest single line in the document, from Section 2.2:

Traditional AIOps stops at visibility. Alert correlation surfaces the right incident. Anomaly detection points at the right dashboard. A cost dashboard tells you spend is high. A scanner tells you a container has a CVE. What happens next is manual, and this is where most operational value is lost.

The proposed fix is execution with a human gate: agents draft the Terraform change and open the pull request, agents propose the CI/CD fix through the normal PR flow, agents post 47 fixes with one-click apply and a rollback link instead of a report saying you have 47 drift issues.

Ten guidelines and eight anti-patterns

Section 4 is the operational core. Abbreviated:

1. Narrow and diverse scope. One incident use case, one cost use case, one automation use case beats fifteen ticket types from the same category. RAND found vague success criteria in 73% of failed projects.
2. Multi-functional platforms over single agents. Every siloed agent creates integration debt and duplicate identity management.
3. Insist on a real context layer. 60-70% of operational judgment should flow through knowledge graph and memory, not the LLM directly.
4. Start semi-autonomous. Expand only after the eval harness clears 80% for a task class.
5. Route by task class, and the platform owns routing.
6. Hybrid models: SLMs for the majority, frontier for the tail.
7. Budget for field-deployed engineers. Under-scoping integration capacity is the most common cause of stalled PoCs.
8. Change management is org design, not tooling. Gartner names "expected too much, too fast" as the root cause of 57% of I&O AI failures.
9. Build the evaluation harness in Week 1, not Week 12. 50% accuracy in PoC, 80% before pilot, 90% for production.
10. Start fast, start small, but start.

The maturity model attaches hard gates to those numbers: Crawl at 50%+ accuracy, Walk at 80%+ with zero SLA regression, Run at 90%+ with a tested rollback. The paper is explicit that skipping the Crawl stage is the most common failure.

The anti-patterns section is where the field experience shows. The best one:

If the oversight pod is doing L1 work in disguise, the platform is not really operating. The retained team supervises the agents, tunes the models, and handles exceptions. It does not do the ticket work.

And the tell he gives for spotting it: the retained team's weekly reports start focusing on ticket volume rather than agent performance, false-positive rate, and eval-harness delta. Anyone who has watched a managed-services transition go sideways will recognise that immediately.

Where we would push back

Section 9 models a 30-person cloud/SRE/support team with $30M of underlying cloud spend and comes out at $102M gross value over six years, $11M total cost, $91M net, payback inside Year 1, NPV around $65M.

The number is doing a lot of work, and one line is doing most of it. Cloud cost optimisation contributes $51M of the $102M: $9M a year, every year, for six years, against a $30M spend. That is a sustained 30% capture rate held flat for six years, in an environment where the easy wins are gone after year two and the underlying spend is presumed not to grow.

We would take the labour-side lines more seriously than the cloud-savings line. Direct ticket-work savings at $31M and long-tail automation at $19.5M are grounded in a defensible model of hours and coverage ramp. The cloud number is the one a CFO will take apart first.

To be fair to the paper, it flags this itself in Section 11, in a table on separating signal from noise in vendor claims. The first row: trust a reproducible benchmark on your own data, discount any MTTR percentage quoted without a denominator or baseline. Apply that rule to Section 9 and you get the right posture. Use the model's structure, replace its assumptions with yours.

What to actually take from it

Two tools in here are worth lifting on their own.

The vendor scorecard (Section 10). Eleven weighted dimensions: multi-functional coverage at 15%, context layer depth at 15%, multi-cloud and model-agnostic at 10%, BYOC or self-hosted at 10%, governance, auditability, ecosystem integrations, extensibility, interoperability, FDE support, cost transparency. Score 1-5, weighted sum divided by 5 gives a fit percentage. Above 80% is a pilot candidate, 60-80% needs customisation, below 60% is high implementation risk.

The signal-vs-noise table (Section 11). Nine paired rows for use during vendor pitches. Trust: reproducible benchmarks on your data, a documented eval harness with pass/fail criteria, audit trails exposed live during the demo, named references willing to take a call, per-agent per-task cost metering in the product. Discount: MTTR percentages with no baseline, "95% accuracy" with no base rate, "10x productivity" with no task-level breakdown, "trusted by Fortune 500" with no specifics, blended pricing that hides token cost inside software cost.

His rule of thumb: when a vendor answers your question by handing you their evaluation harness and a customer contact, that is signal. When they answer with a slide, treat it as noise until you can verify.

Read the whole thing. It is 15 pages and there is no filler in it.

Download the full paper (PDF) · Original post and discussion on LinkedIn · Author's AWS Hero profile

Published on gogoai.dev with the author's permission. Views expressed in the paper are the author's own and do not represent the official position of his employer.