Briefing · September 16, 2026
Agentic AI Is Scaling. The Work Underneath It Isn't.
Enterprises are deploying AI agents faster than they redesign the work structures those agents break — and that gap is where value goes to die.

Most executives deploying agentic AI are making a category error: they treat it as a faster version of automation, bolt it onto existing workflows, and declare transformation underway. The evidence says otherwise. According to McKinsey (2025-07-01), many enterprises are scaling AI agents faster than they are redesigning the work underneath — and that sequencing mistake is precisely why most deployments fail to create lasting value.
Agentic artificial intelligence (agentic AI) is worth defining plainly, because the field-specific term gets thrown around loosely: unlike a conventional AI model that responds to a single prompt, an agentic AI system pursues multi-step goals autonomously, delegating subtasks, calling external tools, and making real-time decisions without a human in the loop for each action. The distinction matters because agentic systems don't just accelerate existing processes — they alter who (or what) holds accountability for outcomes, and that change has organizational consequences that most change-management playbooks were never designed to handle.
Why Are Most Agentic AI Deployments Stalling?
The failure mode is structural, not technical. Organizations stand up agents to handle customer triage, code review, procurement workflows, or internal knowledge retrieval — and then discover that the surrounding work architecture was built on human judgment calls that never got documented. The agent hits an edge case, no escalation path exists, and either a human patches it ad hoc or the process quietly degrades. McKinsey (2025-07-01) is explicit: a detailed blueprint must support the rollout and lay the groundwork for work redesign simultaneously. Sequence matters. Agents deployed before process re-architecture don't create value — they calcify bad processes at machine speed.
The software development context makes this concrete. GitLab (2025-01-01) describes a fundamental economic shift: large language models (LLMs) can now produce useful code reliably enough, and cheaply enough, to change the economics of software development — engineers are no longer just asking for suggestions but giving agents real work and measuring how far they can take it. That's not a productivity story. It's an accountability story. When code is abundant, the scarce resource is judgment about which code to ship, which debt to accept, and who owns the decision when an agent's output breaks something downstream.
What Does "Responsibility Work" Mean When Agents Do the Information Work?
Tim O'Reilly, writing in Substack (2025-07-01), frames the underlying dynamic with unusual precision: information work is actually responsibility work wearing an information costume. The jobs that feel like they're about processing, summarizing, or generating content are, at their core, about exercising judgment and bearing accountability for outcomes. If agentic AI strips out the information layer, what remains is raw accountability — and most org charts, compensation structures, and performance systems have no architecture for pricing that accountability explicitly.
This is the strategic question that no vendor roadmap answers: once an AI agent handles 70% of a knowledge worker's information-processing tasks, what is the remaining 30% worth, to whom, and how is it measured? The answer is not obvious, and the organizations that figure it out first will have a structural advantage that compounds over time — not because their agents are better, but because their accountability architecture is cleaner.
Is Your Organization Redesigning Work or Just Deploying Faster?
The practical test is straightforward. Pick any agentic AI deployment currently in production or pilot at your organization. Ask three questions: Who is accountable when the agent makes a consequential error? Does that accountability structure exist in writing, in a role, with a named person? And was the surrounding workflow redesigned before the agent went live, or after the first incident?
If the answers are "unclear," "no," and "after" — respectively — you are in the majority, and you are building technical debt of a new and more expensive kind. McKinsey (2025-07-01) is explicit that the blueprint must precede the scaling, not trail it.
The board conversation worth having is not about which agents to deploy or which vendors to evaluate. It is about whether your organization has a coherent theory of accountability for the work that agents cannot do — and whether that theory is reflected in how roles are designed, how performance is evaluated, and how escalation paths are built. Agents are already faster than your change management. The only durable competitive move is to close that gap deliberately, before an incident forces you to close it expensively.
Created with AI assistance. Editorial oversight: Juergen Ritzek. See our AI disclosure.