Operating Model Debt Is the Constraint on Enterprise AI

Technology has become one of the primary ways a business senses, decides, operates, and competes. That raises a question most leaders are not asking: whether the business itself is built to move at the speed its technology now makes possible. For most, it is not. Modern tools, AI, and engineering practices are running on decision structures, funding models, and approval cycles built for a slower era, and that mismatch creates friction.

The numbers say the same thing. Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Every one of those causes traces back to the operating model: how work is funded, how value is defined, and how risk is governed. Plenty of leaders would point to talent, data quality, or security posture as the real constraints. But to find the real constraint, look at what determines whether those investments pay off. Across businesses, from private equity portfolio companies to enterprises just getting started, I’ve seen the payoff come down to how work gets funded, prioritized, and approved. The operating model sets the pace for everything. And when that pace falls behind what the technology makes possible, a gap opens.

That gap is what I call operating model debt: the friction between modern capability and legacy decision-making. It is easy to miss, because each piece looks reasonable on its own. Together they slow the work and shrink the return on the modern tools sitting on top. Even now, the way many enterprises make decisions reflects how they worked ten or fifteen years ago.

A quick self-test for operating model debt:

• Can your CFO name your AI cost per unit of shipped work?
• Does an engineer need a steering committee to try a new tool?
• Do you know your rollback rate on AI-assisted releases?
• Can every team explain what AI is currently costing them?
• What does good and cost-efficient look like for a particular use case(s)?
• What benchmark(s) do we have for agentic processes and workflows?

If the honest answer to two or more of those is no (or I am not aware), that is operating model debt at work.

The way through is to run business and technology as one system. When strategy, product thinking, engineering execution, data, security, finance, and governance move in a single operating rhythm, technology stops being a cost center and becomes a business acceleration system. AI raises the stakes on getting this right, because it accelerates value creation and mistakes at the same time.

A Fortune 100 technology company we worked with had already rolled out modern engineering tools but was not seeing the productivity and business outcomes it expected. We established a new software engineering model, delivering improvements of 40–50% in delivery velocity, 30–40% in engineering decision-making, and 25–30% in operational throughput.

AI can accelerate almost any task in software engineering, but human judgment decides whether the work is worth doing, whether it is safe to release, and whether it serves the business outcome. The tension surfaces the moment an organization confuses AI output with engineering accountability, and that line has to be clear.

This is why roles are changing. The developer, architect, product owner, and engineering leader are all moving toward judgment as the premium skill: asking the right questions, decomposing problems well, validating outputs, reading context, and managing risk. The new primary skill is knowing what “good” looks like, for the enterprise, its customers, and its own teams. Used well, AI raises the value of that judgment, because the cost of getting it wrong now scales as fast as the benefit.

This is the reason agentic AI for enterprise pays off only when speed comes with control. The discipline is to wrap governance, software quality engineering, and clear review patterns around AI-assisted delivery, so cycle time compresses while accountability stays human. That kind of thinking went into building AAVA™, the Ascendion platform that puts it into practice at scale, so teams can move quickly and still answer for what ships.

I’m seeing this in a U.S. healthcare payer, a regulated environment where more than 650 agents run in production every day, taking on scale and repetition, with people staying in the loop on the decisions that carry real consequences. That balance is what lets the system serve 39 million Americans reliably.

The enterprises that pull ahead treat transformation as a matter of discipline across leadership, operating models, and execution. In my experience, they tend to do three things well:

• Connect the transformation to a clear business outcome. They adopt AI for a concrete reason: to improve modernization speed, reduce defects, or raise release confidence.
• Build the conditions for scale from the outset. Governance, security, funding, metrics, talent enablement, and executive sponsorship are designed in from the beginning, along with the controls this moment requires: token and cost discipline, agent audit trails, model-risk review, and human sign-off gates on anything that ships.
• Measure value relentlessly. Let me repeat that, because it is the part most often skipped: they measure value relentlessly. They know whether AI and engineering modernization are genuinely improving throughput, quality, cost, compliance, and business impact.

Ambition is common. What separates these organizations is execution architecture, the ability to turn strategy into something governed, repeatable, and measurable, then deliver it at scale. Pilots create learning, and operating models create scale. Transformation fails when activity becomes the measure of success and the real business outcomes go unmeasured.

For developers, I would submit that this shift elevates their role when it is handled well. The strongest engineers are becoming AI-amplified problem solvers who understand code, context, and systems, and tie all three back to business value.

If an engineer is already in the workforce, the move is to treat AI as an amplifier while keeping ownership of judgment. They need to deepen the skills that AI cannot replace: architecture, security, testing, observability, domain knowledge, and product thinking. If an engineer is just starting out, the fundamentals still matter, and may actually matter more than before. Because they cannot validate what they do not understand, the early work is to learn how systems work and how to guide AI responsibly.

Over the next five years, the most valuable engineers will be defined less by how much code they write and more by how well they frame problems, design systems, validate AI-generated work, manage complexity, control cost, and connect technical decisions to business outcomes. AI exposes weak engineering practices faster, and it makes strong engineers stronger. The ones who combine technical depth, business fluency, and AI orchestration will become some of the most valuable talent in the enterprise.

When I walk into an engineering organization, readiness shows up quickly, in two places.

The first is clarity. When leaders can explain the business outcomes they need, the constraints they face, the systems that matter most, the risks they must manage, and the metrics that define success, that organization is usually ready to move. It may still carry technical debt and aging platforms, and that is fine. But clarity at the top cannot be faked.

The second is discipline, in several forms: cost discipline, token discipline, and rollout discipline. Ready organizations already have a foundation in place, with governance, architecture ownership, engineering standards, DevSecOps practices, quality expectations, and executive accountability. The absence of those signals tells its own story. When every team is testing AI on its own and no one can explain what AI is costing, that organization is still in the experimentation stage, where scale stays out of reach until the basics are in place.

The encouraging part is that readiness can be built. The key is to start with the operating model and let the toolset follow. Clarity is the first signal of readiness, and good governance is what makes speed safe.