The Fallacy of Autonomous AI: Why Enterprise Value Lives in the Middle

In executive forums and vendor keynotes, the dominant narrative remains the same: fully autonomous, self-governing AI agents that will run end-to-end business functions with minimal human involvement. The vision is compelling. The economics and operating realities of most enterprises, however, make the near-term pursuit of that vision one of the higher-risk capital allocation choices currently available.

Early production evidence shows that organizations fail with agentic AI less because models lack raw capability and more because their process foundations, integration surfaces, data quality, identity and authorization models, and control systems cannot safely support the autonomy they attempt to deploy. Value is not binary between a conversational interface and a fully autonomous workforce. It sits in the middle of the spectrum—in bounded, goal-oriented agents applied to well-defined, high-volume Standard Operating Procedures (SOPs).

Where Delivery Organizations Misalign

Three persistent misalignments currently dilute returns:

Business leadership is drawn to the right-hand side of the spectrum - multi-agent coordination, autonomous objective setting, and dynamic self-governance. These capabilities sit beyond current enterprise readiness for the majority of processes. Without deterministic foundations, such initiatives routinely remain high-cost proofs of concept that cannot be scaled under acceptable risk and audit conditions.

IT and technology leadership frequently anchors on the left - broad deployment of conversational assistants and copilots. These improve individual productivity but leave transactional systems, exception handling, and cross-system orchestration largely untouched. The result is diminishing returns once basic knowledge-work assistance is in place.

Engineering and architecture teams often design complex multi-agent frameworks, long-term memory structures, and non-deterministic loops before the underlying business processes have been standardized and instrumented. The outcome is unpredictable tool-call behavior, elevated latency, rapid token cost growth, and limited operational yield.

A Structured Maturity Progression

Organizations extract the highest near-term economic yield by progressing deliberately across a maturity spectrum rather than attempting large jumps. The progression is not linear, and readiness must be demonstrated at each stage through explicit metric thresholds rather than qualitative judgment alone.

Stage 1 – Minimal Reactive Search (Guided). Rule-based logic, deterministic decision trees, and structured knowledge retrieval. Prerequisite: clean operational taxonomies, API endpoint governance, and data hygiene.

Stage 2 – Emerging Conversational Assistant (Guided). Context-aware language models providing synthesis, multi-turn assistance, and draft outputs. These should be treated as advisory. Outputs require human review before any system of record is updated.

Stage 3 – Basic Goal-Oriented Agent (Enterprise Value Zone). Agents that perform task decomposition, structured tool use (APIs, queries, enterprise search), and multi-step execution against bounded SOPs. This is where the majority of near-term enterprise investment should concentrate. Focus areas are high-volume, relatively standardized processes with clear success criteria and limited exception paths.

Readiness criteria for Stage 3 (tied to metrics):

1. Task Completion Rate (TCR) sustained above the human baseline for the target SOP.
2. Human Intervention Index (HII) below a defined threshold that still delivers net capacity gain.
3. Tool-Call Precision above 90 % with drift held inside acceptable bounds.
4. Cost-Per-Resolved-Workflow (CPRW) demonstrating clear advantage versus manual or traditional automation.
5. Hallucination & Policy Breach Rate at or below the organization’s residual risk tolerance, with automatic escalation active.

Stage 4 – Intermediate Continuous Improver. Introduction of closed-loop feedback, limited self-correction within pre-approved boundaries, and longer-term contextual memory. Human-in-the-loop evaluation remains mandatory for edge cases and policy boundaries. Progression requires the Stage 3 metrics to hold under increasing volume and complexity.

Stage 5 – Advanced Strategic Automatic Agent (Cautionary Horizon). Multi-agent coordination, autonomous objective setting, and dynamic self-governance. This remains an R&D and controlled-pilot domain. Entry requires the full Stage 3–4 metric set to demonstrate sustained performance inside human operational error rates, plus robust real-time circuit breakers, full decision provenance, and continuous policy auditability.

Aligning the Maturity Spectrum with a Multi-Year Delivery Path

The agentic spectrum does not exist in isolation. It maps directly onto the critical path most organizations must follow to convert generative and agentic AI investment into durable impact. Early production programs that skip foundation work—process standardization, stable integration contracts, identity models for non-human actors, and evaluation harnesses—consistently stall at the pilot stage regardless of model capability.

A practical three-year sequence looks like this:

Year 1 (Foundation). Establish process visibility for priority SOPs, clean integration surfaces, baseline operational metrics (TCR, HII, CPRW), and the control framework. Deploy Stage 1–2 capabilities where they reduce knowledge-work friction. Avoid large multi-agent builds.

Year 2 (Targeted Deployment). Concentrate investment in Stage 3 Basic Goal-Oriented Agents on a small number of high-volume, well-bounded workflows. Gate expansion on sustained metric performance (TCR above human baseline, HII declining, CPRW advantage, breach rate inside tolerance). This is the primary value-creation window for most enterprises.

Year 3 (Selective Scale and Controlled Horizon Work). Expand proven Stage 3 agents across additional process families. Begin limited Stage 4 continuous-improvement loops only where the Stage 3 metrics remain stable under volume. Keep Stage 5 activity inside explicit R&D or tightly governed pilots with full circuit breakers and provenance

Enterprise Prerequisites Before Agent Deployment

Process slicing alone is insufficient in most large organizations. Tribal knowledge, inconsistent execution, legacy system interfaces, and data quality issues routinely constrain agent performance more than model capability. Before significant agent investment, organizations should establish process visibility, stable schema-constrained integration contracts, identity and least-privilege models that extend to non-human actors, and baseline operational metrics against which agent performance can be compared. Agents should augment or orchestrate existing automation and workflow platforms rather than be positioned as a wholesale replacement.

Four-Phase Delivery Lifecycle

A disciplined delivery sequence reduces the risk of unbounded pilots. Each phase includes explicit metric gates before progression.

Phase 1 – Process Slicing and Pattern Identification. Deconstruct target workflows into discrete, repeatable SOPs. Isolate sub-steps that are deterministic or tightly bounded. Establish baseline TCR, HII, and cycle-time measures.

Phase 2 – Bounded Tool Provisioning. Provide agents with structured, schema-validated tool interfaces. Default to read-only access. Restrict write or action permissions to the narrowest scope required. Measure initial Tool-Call Precision and establish drift monitoring.

Phase 3 – Telemetry and Human-in-the-Loop Intercepts. Instrument prompts, reasoning traces, tool calls, latency, and token consumption. Implement automatic escalation when an agent exceeds iteration limits, confidence thresholds, or policy boundaries. Track HII and Hallucination & Policy Breach Rate in real time.

Phase 4 – Progressive Autonomy and Gatekeeping. Expand the autonomous execution window only after TCR, HII, CPRW, and breach-rate metrics demonstrate sustained advantage over the human or traditional automation baseline. Maintain explicit gates and rollback criteria tied to these measures.

Governance, Controls, and Operating Metrics

Vanity engagement metrics provide limited insight. Governance should rest on operational, risk, and economic measures, overlaid with authorization, auditability, and evaluation controls. The five core metrics—Task Completion Rate, Human Intervention Index, Tool-Call Precision & Drift, Cost-Per-Resolved-Workflow, and Hallucination & Policy Breach Rate—serve both as performance indicators and as the quantitative basis for readiness gates between maturity stages. Authorization is enforced at the tool and action level. Full decision provenance and immutable logging support auditability. Evaluation gates covering quality, safety, and compliance precede any expansion of autonomy.

Strategic Path Forward

Enterprise advantage with agentic AI will not come from being first to declare autonomous systems. It will come from disciplined architectural and operating-model execution that concentrates investment where foundations can support reliable performance, measured by explicit thresholds on the operational metrics above.

Organizations should stop treating AI as a binary choice between a conversational interface and an autonomous workforce. The highest near-term return lies in Basic Goal-Oriented Agents applied to repeatable, bounded workflows. This requires clean integration contracts, operational telemetry, progressive autonomy gates tied to TCR, HII, precision, CPRW, and breach-rate performance, and a control framework that treats non-human actors with the same rigor applied to human ones. Autonomy should be earned through demonstrated metric performance rather than assumed through model capability.

The middle of the spectrum is not a compromise. It is the zone in which most enterprises can currently convert AI investment into measurable operational and economic outcomes. The organizations that treat the maturity spectrum and the multi-year critical path as two views of the same operating model—rather than as separate technology and strategy exercises—are the ones currently converting agentic investment into durable results.

HTH...

A Tech Artist 🎨

Enterprise Network Modernization, Part 1: Draw the Map Before You Buy the Boxes

Ask five people in the same company what “network modernization” means and you will get five answers, each one shaped by the last vendor presentation that person sat through. One will say SD-WAN. Another will say SASE, or zero trust. The data centre folks will talk about AI fabrics and 800G optics. The cloud team will tell you the network is somebody else's problem now, it lives inside a VPC. And someone from finance will ask why all this costs so much and whether we can just rent it.

None of them is wrong, which is exactly the problem. Everybody is describing one piece and nobody is holding the whole thing. So the roadmap turns into a shopping list, the shopping list turns into a set of projects, and a few years later nobody can quite say who asked for what, why, or whether anything actually got better.

I wrote about the same itch for security a while back (The Enterprise Security Meta Model). Same spaghetti, different kitchen. This post is the networking version, and then a second part on something that bothers me even more: once you have the map, where do you get the evidence to decide anything?

If you are an executive, the map and the evidence section are the parts to read, and you can skim the technical asides. If you run or design networks, the asides are for you, and I would like to hear where you disagree.

Why I start with a map

Without a shared map, three things tend to happen.

First, overlap. Two teams quietly buy the same capability under different names. The firewall team and the WAN team both end up with a cloud security service, each with its own policy engine, each convinced theirs is the strategic one.

Second, gaps. Something important has no owner, and it is usually the thing that sits between two teams. Who owns the path from a branch office to a SaaS application? Ask three people, get three answers, and a fourth who says “it depends”.

Third, sequencing mistakes. Agentic operations get funded before anyone trusts the telemetry. Segmentation projects start before anyone knows what talks to what. You can guess how those go.

There is a second reason, and it is less obvious. Categories keep moving. Gartner published a Magic Quadrant for Single-Vendor SASE in mid-2024. A year later the same space was being evaluated as SASE platforms, and the 2026 edition is dated July. The technology did not change overnight. The label did. If your strategy is organized around somebody else's category names, it ages with their marketing calendar. I would rather own the map and then lay the analyst categories on top of it.

The map

Two questions organize the whole thing. Where does the traffic live? And what governs it? The first gives four domains. The second gives three planes. Under both sits a physical foundation that nobody wants to talk about and everybody depends on. 

That is 24 topics plus the foundation. It is not a magic number, it is just where I ended up after moving things around many times.

The one rule that makes it work: every topic has exactly one home, and the home is decided by who owns the buying decision, not by what the product brochure says. Consultants call this mutually exclusive and collectively exhaustive. I just call it not double-counting.

So SASE platforms sit under WAN, because that is where the traffic path gets bought, even though half of what they do is security. Quantum-safe appears once, under security. Segmentation appears once, under security, even though it gets enforced in campus switches, in DC fabrics and in cloud constructs. The moment you let a topic appear in two boxes, the map turns into a pile of overlapping boxes, and a pile is not a map.

Where the traffic lives

Data center. This is where the money and the heat are. Enterprise DC fabric is the familiar leaf-spine, EVPN-VXLAN world that carries the applications you already run. AI fabric is a different animal: the back-end network that ties GPUs together, with a few enormous, synchronized, loss-sensitive flows instead of lots of small ones, and the Ethernet or InfiniBand debate that comes with it. My view, and it is only a view, is that most enterprises are not building GPU clusters. They are renting capacity or calling APIs, and for them the AI question is less about 800G switches and more about connectivity, data movement and security around that rented capacity. Whether you need the AI fabric topic as a priority depends on which of those two worlds you actually live in. Edge or micro-DC is compute pushed closer to where data gets created, such as stores, plants and branches. The network question there is mostly about how many of them you will end up with and who is going to run them.

Campus and branch. The least glamorous domain and the one most of your users actually touch. Wired and wireless LAN are where Wi-Fi 7 and its predecessors live. Private 5G is for the cases where Wi-Fi is the wrong tool, such as large sites, mobility, or industrial areas. IoT and OT networking covers the devices that cannot run an agent, cannot be patched on your schedule, and were sometimes bought by a department that never told IT.

WAN and secure access. SD-WAN is the overlay that steers traffic across whatever transport you have. SASE platforms bundle that with cloud-delivered security, and the interesting argument inside most organizations is whether the network team or the security team owns the decision. Carrier WAN services are the underlay: the ISPs and telcos that carry it all, and the contracts that make switching hard. Optical or photonic transport sits below that, and it matters when you need a lot of bandwidth or predictable latency between a handful of sites. The conversation moves down the stack, and the people you need in the room change.

Multi-cloud and hybrid. Native cloud networking is every cloud's own constructs (VPCs, VNets, transit gateways), each slightly different. Multi-cloud platforms try to give you one policy and one view across them. Cloud connect, or SDCI, is the software-defined private on-ramp to those clouds. Service mesh and PaaS overlays are application-level networking inside platforms like Kubernetes, and they are usually owned by platform teams, not network teams, which is where a lot of quiet friction comes from.

What governs it

Operations and intelligence. Three items, and the order matters. Observability and digital experience is how you see. Automation and orchestration is how you act, deterministically, from a specification. Agentic NetOps is how you let software decide, and that is a different thing from automation, not a bigger version of it. Automation is governed by the spec: it either does what was written or it does not. A learned system is governed by measuring its behavior over time, with confidence levels and drift. Treat them as the same thing and you will govern one of them badly. You cannot automate what you cannot see, and you should not let an agent act on what you cannot verify.

Security and trust. Zero trust and segmentation is deciding who may talk to whom, and it is hard because it is mostly an organizational problem wearing a technical costume. Hybrid mesh firewall is the idea of consistent firewalling across on-prem, cloud and branch under one management plane. Quantum-safe is about cryptography that survives a future quantum computer, which matters now because some of what you send today will still be sensitive then. Network security basics is the unglamorous baseline controls that still need to be in place before anything fancier is worth discussing.

Consumption and sourcing. NaaS is a commercial model, not a technology. What you are really buying is a contract, so read the exit terms before you read the brochure. Managed and co-managed services answer a different question: who runs it, and who carries the pager.

Foundation. Fibre, cabling and optics. Twenty-year assets, slow to change, and the mistakes here are the most expensive to reverse.

What the map does not cover, and where it is weak

Satellite and LEO connectivity, DNS and IP address management, voice and collaboration, and whatever 6G turns out to be are not on it. Add them when they matter. The structure should make it obvious where they would go.

It is also not perfect. SASE straddles two worlds and any placement is a compromise. Edge or micro-DC could just as easily live under campus and branch. And a map is for deciding what to talk about, not for designing anything. A design still needs requirements, constraints and trade-offs, and no box on a slide replaces that.

What to do with it

Twenty-four topics cannot all be priorities, and if they are, nothing is. Pick a few. For an exercise like this, four to six is plenty.

For each candidate, five questions, in plain language:

1. What business outcome is pulling on this? If you cannot name one, stop here.
2. Where are we today, honestly?
3. What breaks, or gets expensive, if we do nothing until 2030?
4. What does it depend on? SASE depends on identity being in reasonable shape. Agentic operations depend on observability and automation. Segmentation depends on knowing what talks to what.
5. What evidence do we have, and how good is it?

The fifth one is where most plans quietly fall apart, so the rest of this post is about that.

What comes next

The map tells you what to talk about. It does not tell you what to believe. In Part 2 I cover where I look for evidence before any of these topics gets a budget, how I read analyst reports without being fooled by the top right corner, and why I rate the evidence separately from the technology.  

HTH...

A Tech Artist 🎨

From Pass-Through to Proof: Overcoming the Gartner & IDC Blind Spot in Enterprise Advisory

 

What Traditional Analysts Miss

Traditional industry analysts prioritize market presence, revenue trajectory, and execution scale over technical depth. By evaluating products primarily through commercial readiness, logo adoption, and high-level feature checkboxes, legacy reports overlook underlying architectural mechanics. This creates a critical blind spot: market "Leaders" are often recommended based on brand stability rather than integration feasibility, frequently leading enterprises to adopt bloated, overprovisioned platforms that introduce technical debt and policy fragmentation.

What Architectural Analysts Bring

Emerging technical analysts address this deficit by evaluating solutions from the code and primitive level up. Rather than scoring marketing messaging or corporate viability, they test how an architecture actually translates into real-world capabilities—such as securing AI agents or fitting cleanly into multi-cloud environments. These briefings provide advisory teams with an objective, low-risk environment to stress-test technical trade-offs, evaluate niche versus platform strategies, and verify compatibility before making enterprise commitments.

Where Architectural Analysts Fall Short

Conversely, purely architectural evaluations lack the macro-level risk management that enterprise boards require. They do not measure financial solvency, global support infrastructure, long-term vendor viability, or broad peer-deployment history. A solution may possess an elegant architecture, but if the vendor lacks the scale or financial runway to survive an enterprise procurement cycle, recommending it introduces operational and commercial risk.

The Symbiotic Dual-Lens Framework

Neither evaluation model is sufficient on its own; true advisory leadership requires both. Traditional analysts validate market viability and governance compliance (answering “Will this vendor exist in five years?”), while architectural analysts validate technical fit and stack efficiency (answering “Will this actually work in our environment?”). Combining both frameworks bridges the gap between commercial safety and technical reality, enabling technology advisors to deliver strategies that satisfy both risk-conscious procurement teams and speed-driven technical architects.

HTH...

A Tech Artist 🎨

Problem Framing vs. Solving

 

A quick google search about "Best Books - Problem Solving" will come with 10s if not 100s of recommendations and best sellers list such as: https://www.amazon.com/Best-Sellers-Decision-Making-Problem-Solving/zgbs/books/2679

Now if you search for "Best Books - Problem Framing", you with either see the problem under the category of problem solving, maybe in few cases the books on "Systems Thinking" will appear in the search.

So while 99.99% books will teach you "problem solving", there are just handful and not well known books out there on "problem framing". You will likely come across recommendations in that category from your friends in consulting circle.

If you are ever go to one of those popular consulting schools, they taught me that brilliant people fail when they answer the wrong question.

Don’t just answer questions. Frame them. Because a brilliant answer to the wrong question is still wrong. Ask, “How do we make customer support more efficient?” and everyone races to cut headcount or automate.

You might save dollars and bleed trust. Try this instead: “What service approach builds loyalty while balancing cost?” Now you are designing for humans, not just a spreadsheet. How you frame a question shapes what you notice, what you measure and what you ship. Daniel Kahneman and Amos Tversky called this the framing effect. It’s one of the most underrated leadership skills.

I learnt the value of spending time on framing the question during my time at consulting schools.

At first it felt forced. But projects (case studies) where we invested serious time up front to define the question led to sharper insights, faster decisions and happier teams & clients.

When we didn’t take the time, chaos reigned. Put it into practice this week: 1. Question the question. ↳ What assumptions are baked in? What if you flipped it on its head? 2. Start at the finish line. ↳ Define outcome or experience you want, then trace back the decisions and actions that create it. 3. Make space for the devil’s advocate. ↳ Assign someone to challenge whether you’re even solving the right problem. If you work with data or roll out new tech, your analysis is already shaping outcomes. Make sure you’re shaping the right ones. Have you ever felt like you’ve missed the mark on the question you’re answering?

What's one question your team has been wrestling with that might need a reframe?

Further Readings:

Problem Solving & How Often People Get it All Wrong - A Brief Perspective

How context shapes our thinking

Framing, Re-Framing, and Perspective 

Think more rationally with Bayes’ rule

MECE principle

Cracked It! book launch event 

HBR - To Solve a Tough Problem, Reframe It

HTH...

A Tech Artist 🎨