Hexaware Positioned as a Visionary in the 2026 Gartner® Magic Quadrant™ for Custom Software Development Services
Hexaware Positioned as a Visionary in the 2026 Gartner® Magic Quadrant™ for Custom Software Development Services
Gartner, Magic Quadrant for Custom Software Development Services, By Jaideep Thyagarajan, Ryan McKinney, Nathan Davie, 7 October 2026. Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates. Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Hexaware.
Blog
Share on
Reimagined ITOps is a weekly series about what IT operations becomes when AI stops assisting and starts operating. This is article 4 of Season 1. Stay with it.
Every agentic operations maturity model published this year is a staircase. Ours is a staircase too.
The ladders arrived in volume in 2026. L0 to L5. Observe, draft, bounded execute. Assisted, conditional, full. They disagree about the rungs and agree about the shape.
Meanwhile, almost nobody has climbed them. By our own directional estimate, fewer than 5% of enterprises are even entering autonomous operations, and none is fully there. Independent data points the same way: Deloitte’s survey this year found that 1% of organizations say agentic AI is fully integrated as a key part of their operations. Whatever is stopping them, it is not a shortage of ladders.
My claim: context is neither a rung on the staircase nor a gate in front of it. It is the floor the staircase stands on; it has to deepen at every level, and almost nobody funds it that way.
We call ours the Enterprise Context Foundation. Six domains: configuration items, applications, business services, ownership, topology, and artifacts, meaning the runbooks, SOPs, and knowledge where resolution actually lives. It sits under all five stages of our maturity model, and it is deliberately not one of them.

Fig 1: No signal, no safe action
Put context on the staircase as step 1, and you have told the organization that context is a phase. Phases finish.
So a discovery program runs, closes, reports a completeness figure, and begins decaying the next morning, because the estate changed that morning. Two years later, the configuration data is a liability nobody owns, and every automation quietly routes around it.
The deeper problem is that each stage consumes a different depth of context, not more of the same context.
A reasoning recommendation needs enough context to be right. A governed autonomous action needs enough context to be right, to be safe, to be verified after it lands, and to be reversed when verification fails.
That last requirement is where programs discover the floor is thin. Verification is not confirming the command ran. It is confirming the condition cleared, and you cannot confirm a condition you have no signal for.
Which is why we hold it as a principle rather than a stage: no signal, no safe action. Autonomy without context is not autonomy. It is unsupervised guessing with production credentials.
The other half of the market made the opposite error this year. Clean your data first. Data quality overtook AI initiatives as the top-ranked concern among data leaders, and readiness checklists multiplied in its wake.
I have some sympathy for this position. It is more honest than pretending context does not matter. But as a gate, it cannot be passed, because nobody has ever finished a configuration database, and a gate you cannot pass becomes a reason never to start.
It also asks the wrong question. Readiness is not how clean the records are. Readiness is what an agent can reliably do with them without a human standing by to explain what the fields mean.
Here is the concession this series owes. Messy context genuinely does limit what you can automate, and it limits some classes of demand far more than others. Cleanliness is necessary. It is not sufficient, and the reasons are structural rather than technical. That finding deserves its own article later in the season.
The workable position is neither gate nor phase. Pour the floor to the depth the next stage requires, under the specific towers you intend to climb, then pour more. Depth is assessed per domain and per queue, never declared estate-wide, which is the same discipline as measuring automation potential on your own tickets instead of estimating it.
This is the failure I see most often in context work that is genuinely well funded.
A configuration database with accurate rows and no relationships is inert. What makes context actionable is the graph: what depends on what, who owns it, which change last touched it, which business service it serves, and what it costs when it stops.
Most estates have the nouns. Very few have the verbs.
Those edges are exactly what an agent traverses to form a hypothesis. “This change modified that component” and “that runbook resolves this incident type” are the sentences a reasoning system reasons over, and neither is a field in a row.
The same gap shows up in knowledge. A knowledge article existing for a fault is not the fault having a resolution, and a resolution field reading “fixed, closing” contains no resolution. Attribute presence is not the property it stands for. Any readiness score built from field completeness is scoring paperwork.
First, shift-left stops being a training problem. Organizations move work from L3 to L2 to L1 while leaving the context needed to do that work at L3, and then read the resulting drop in quality as a skills gap. Work shifts left only as far as context does. That makes shift-left an architecture decision with a budget line, not a curriculum.
Second, the maturity conversation changes shape. The useful question is not which stage we are at. It is how deep the floor is under the stage we are trying to reach, in this tower, for this class of demand.
Third, and this is the uncomfortable one: context has no stage to be funded in. It is not a rung, so it gets no phase gate, no named owner, and no standing budget. One observability writer this year called it the foundation nobody funds, which is accurate and worse than it sounds, because every program that does get funded quietly assumes it.
If one operational change comes out of this article, make it a line item. Context depth, owned by a named person, funded continuously, reviewed against what the next stage actually requires.
Look at whatever maturity slide your organization is using right now and find where context sits on it. If it is a step, ask what happens to that step in year 3. If it is a prerequisite, ask who is allowed to declare it finished.
So my question: in your estate, does anyone own context depth as a standing responsibility with a budget, or does it only get attention when an automation program trips over it?
Next week: your estate is not at one maturity stage. It is at five at once, one per tower, and the top one means preempting the predictable rather than predicting everything.
Sanjesh Rao leads product strategy and innovation for Hexaware’s Agentic ITOps platform.
Because each stage consumes a different depth of context rather than more of the same context. A reasoning recommendation needs enough context to be right. A governed autonomous action needs enough context to be right, safe, verified after it lands, and reversed when verification fails. Drawn as a step, context becomes a phase that finishes and then decays.
Treating clean data as a gate does not work because no one has ever finished a configuration database, and a gate that cannot be passed becomes a reason not to start. The workable position is to build context to the depth the next stage requires, under the specific towers you intend to climb. Messy context limits what can be automated, so cleanliness is necessary but not sufficient.
Relationships, not rows. A configuration database with accurate records and no relationships is inert. What makes context actionable is the graph: what depends on what, who owns it, which change last touched it, which business service it serves, and what it costs when it stops. Those edges are what an agent traverses to form a hypothesis, and a readiness score built from field completeness measures none of them.