When the Use Case Is the Wrong Abstraction

OBSERVED

I was reading Phil Fersht’s notes from a conversation with Marc Warner under the provocation “Stop Building AI Use-Case Lists”, and almost immediately I found myself wandering away from the article itself. I was nodding, but not because I was encountering an entirely new argument. It felt more like someone had entered a room I have been walking around for years and switched on another light, illuminating a pattern that was already there but had not yet been named cleanly enough.

The phrase stop building AI use-case lists lands because the use-case list has always bothered me. We inherit the enterprise exactly as it exists—Sales, Marketing, Finance, HR, Supply Chain, IT, Legal—and then ask every department where AI might help. Marketing produces twelve opportunities, Finance nine, HR seven; somebody arranges them on an impact-versus-feasibility matrix, a steering committee selects the top ten, pilots begin, productivity numbers appear, and eventually the organization declares that transformation is underway.

The question that refuses to leave me is what exactly has been transformed. We may have made the inherited machine faster without asking whether it remains the right machine. Departments, workflows, applications, approval chains and management layers are not natural facts of organizational life; they are historical responses to an earlier set of constraints, created when information was scarce, communication expensive, computation limited and human judgment could only be coordinated through hierarchy.

What becomes interesting, therefore, is not simply where AI can be inserted. The deeper inquiry begins when we ask what happens to the architecture of the institution when the constraints that produced that architecture begin to disappear.

THE WRONG UNIT OF ANALYSIS

AI is not interesting merely because it can write an email faster, summarize a contract, generate software or prepare a report. Those capabilities can produce substantial value, but they remain improvements to activities whose existence we have already accepted. AI becomes more consequential when the distance between intent and execution begins to collapse and the enterprise can move from observing reality to taking governed action with radically less mediation.

A person can increasingly describe what they want and software begins to appear. A business leader can express an outcome and systems can reason about possible ways to achieve it. A machine can sense a change in its environment, interpret what that change means, evaluate responses and, under bounded authority, initiate action. What is being compressed is therefore not merely labor but a chain that has always existed inside the enterprise.

Historically, this loop was distributed across people, meetings, documents, applications, committees, reports and organizational layers. The enterprise did not lack intelligence, decision-making or action; it lacked a way to connect them without enormous amounts of coordination machinery. AI begins to compress that machinery, and once that happens the old question of where AI belongs starts yielding to a more consequential question about what organizational machinery remains necessary at all.

That is where Warner’s argument begins for me, but it is not where the thought stops.

MANAGEMENT LATENCY

Starting with business strategy rather than AI use cases is already an important improvement. If reducing working capital, improving customer retention, accelerating product development or increasing manufacturing yield matters strategically, begin there and ask where intelligence materially changes the economics or probability of achieving that outcome. This immediately removes a surprising amount of activity masquerading as transformation.

Even there, however, I want to go one level deeper. Why does strategy stop where execution begins? We have historically separated strategy from operations because organizations needed hierarchy to translate one into the other: boards establish direction, executives turn direction into priorities, functions turn priorities into plans, managers convert plans into tasks, people execute those tasks, systems record what happened, and reports eventually travel upward so management can interpret the result and adjust the plan.

The amount of latency embedded in that architecture is enormous, but familiarity makes it appear inevitable. A meaningful portion of what we call management may actually be compensation for information and coordination latency: organizations required layers of human mediation because they could not continuously understand their own state, reason across fragmented context or safely translate intent into action. Management performs many irreducibly human functions, but not every layer of managerial coordination is irreducibly human.

If an enterprise can increasingly sense what is happening, understand its state, reason about desired outcomes, evaluate constraints, recommend or execute actions, observe consequences and learn, then management latency becomes an architectural variable. Planning cycles become contestable, the boundary between strategy and operations becomes less obvious, and the distance between deciding and doing begins to collapse.

This is what I mean by the Converged Enterprise. It is not another IT reference architecture. It is the possibility that things we historically separated—strategy, operations, technology, data, governance and increasingly agency—begin converging into a common operating fabric because the economic reasons for keeping them apart are changing.

BITS, ATOMS AND COORDINATION

Warner’s distinction between bits and atoms is directionally right. Banking, insurance, software, professional services and other information-intensive industries clearly sit directly in AI’s path because information is both their raw material and a large part of their value-creation mechanism. When intelligence becomes cheaper and more abundant, their economics can change quickly.

The distinction nevertheless feels incomplete because physical industries contain enormous informational coordination layers. Agriculture is atoms: soil, seed, water, fertilizer, weather, tractors, plants and animals remain stubbornly physical, and no amount of prompting will cause a tomato to materialize. Yet nearly every important economic decision around those atoms is informational.

Farmers decide what to plant, when to plant, how much water to apply, whether disease is developing, when to harvest, where to sell, whether to store, how to transport, how to finance inventory, how to insure risk and how to respond to demand. Processors, distributors, retailers, lenders, insurers and agronomists make adjacent decisions whose quality depends upon fragments of the same physical reality.

This is why I keep thinking Physical AI is being defined too narrowly. The phrase often brings humanoids, robots, drones and autonomous machines to mind, and those technologies certainly matter. A more useful definition may be intelligence crossing the membrane between informational and physical systems: sensing physical state, reasoning about it, taking action upon it and learning from the consequence.

Agriculture, energy, manufacturing, logistics, healthcare and construction may move more slowly than pure information industries because reality imposes friction. Their eventual transformation, however, could be deeper precisely because intelligence changes how physical systems are coordinated rather than merely how documents are produced.

That connects directly to Wellzai in my head. Perhaps the opportunity is not another farm application and may not even be adequately described as “AI for agriculture.” Agriculture and food suffer from extraordinary coordination failure: farmers, input providers, agronomists, lenders, insurers, processors, distributors, retailers and consumers participate in one economic system, but the system does not reason as a system because information, incentives, trust and coordination mechanisms remain fragmented.

The venture thesis changes when we see the problem this way. The opportunity becomes economic coordination rather than isolated automation.

BUILDING CHANGES THE QUESTION

Warner also argues that every CEO should personally build something with AI. I agree, although perhaps for a somewhat different reason. Experiencing how quickly intent can become software changes a leader’s sense of what is possible, but the more important effect is that building changes the quality of the questions being asked.

A technological regime cannot be fully understood from PowerPoint. Abstraction protects us from contradiction, whereas building forces contact with reality and immediately reveals what the model understands, where it fails, which context it lacks, where data quality matters, where permissions become consequential, where humans must intervene, where reliability collapses and where the economics stop making sense.

This sounds increasingly like Subzero → 451. An idea at Subzero is not a startup waiting for a pitch deck; it is something that should remain cold long enough that we do not destroy it with premature certainty. We examine it, live with it, connect it to other ideas and allow contradictions to remain unresolved long enough for something more interesting to emerge.

Eventually preservation is not enough. The temperature has to rise, and at 451 the idea must survive contact with reality. Building is one of the mechanisms through which that temperature rises, which may be why I keep building systems rather than merely writing about them.

ADAM, Pola, Nitya, Kriyas, Musewoods and the Governed Data Foundry may look like separate creations from outside. Increasingly, they feel like different probes into the same underlying question: what does an institution require when intelligence, authority, evidence and action begin operating as a connected system?

WHAT STOPPED ME: AUTHORITY

The argument becomes more consequential when it reaches AI safety. I agree that we should avoid both complacency and hysteria, but the word safety increasingly feels too broad because it collapses several fundamentally different control problems into one category.

When an AI provides information, the primary concern may be correctness. When it recommends a decision, evidence, explainability and accountability matter. When it makes a decision, authority enters the picture; when it takes an action, consequences matter; and when it delegates work to another agent, provenance and chains of authority become critical.

When an agent controls machinery, allocates capital, approves a transaction, rejects a customer, changes a production schedule or enters into a commitment, “AI safety” is no longer an adequate description of the system that must surround it. The deeper problem is governed authority, because intelligence and legitimate authority are different properties.

Human institutions already understand this distinction. A brilliant analyst may know exactly which acquisition a company should make but cannot wire $500 million merely because her reasoning is correct. A physician may reach the correct diagnosis while remaining inside a defined scope of practice, and a procurement manager may identify the optimal supplier while possessing purchasing authority only up to a specified threshold.

Autonomous systems should not somehow escape the same institutional logic merely because their reasoning is computational. Every consequential agent action may ultimately need to answer who authorized it, what was delegated, under which policy, within what boundaries, based on what evidence, for how long, whether that authority could be revoked, what consequence followed and who remained accountable.

Those questions cannot remain only in governance documents. They have to become runtime infrastructure.

Seen through this lens, Pola begins to look different to me. Traditional IAM largely asks: Who are you, and what resource can you access? An agentic enterprise has to answer a harder question: What are you authorized to decide and do, on whose behalf, under what conditions, using what evidence, with what economic and operational consequences?

That is not simply an additional permission flag on an access-control system. It is a different control problem.

THE UNIT OF ENTERPRISE COMPUTATION

This is also why discussion about agents replacing applications can feel superficial. I do not particularly care whether applications disappear; they may in some domains and may not in others. That is an implementation consequence rather than the most interesting architectural question.

The question I keep returning to is what becomes the unit of enterprise computation. For decades the application was the unit: CRM, ERP, HCM and SCM each contained a bounded region of enterprise activity, while workflows later emerged to coordinate work across application boundaries.

In an agentic enterprise, perhaps the more useful primitive is the consequential decision and resulting state transition.

Something about the world is true. New evidence arrives and the enterprise interprets it; a decision becomes necessary, authority is evaluated, an action occurs, enterprise state changes, and evidence of what happened is retained so that the institution can learn.

If this becomes the primitive, applications become containers around fragments of a larger decision-and-action system rather than the conceptual center of enterprise architecture. That is a much larger transition than making ERP “AI-enabled.”

THE DECISION GRAPH KEEPS REAPPEARING

I can see the same pattern in the enterprise-revenue thesis that has been occupying me. We spent twenty years automating selling: CRM records seller activity, sales-engagement systems automate outreach, revenue-intelligence systems analyze conversations, generative AI writes emails and prepares account briefs, and now agents are beginning to prospect.

Yet those systems still do not fundamentally model what must happen for the buyer to decide. An enterprise purchase is not an activity funnel; it is a distributed organizational decision involving people, authority, motivations, constraints, budgets, politics, evidence, timing, dependencies and risk.

Once again, the inherited process becomes the distraction. The seller is trying to cause an organizational commitment, and if that is the desired state transition, perhaps the real object is the Decision Graph rather than the CRM activity stream.

The recurring pattern is becoming difficult for me to ignore: do not begin by automating inherited activity; first understand the underlying decision and reconstruct the system around it. Quantiply was ultimately about decisions rather than data. The Governed Data Foundry is about trustworthy evidence for decisions rather than pipelines, Pola is about authority surrounding decisions and actions, ADAM increasingly feels like reasoning over state and context, Wellzai is becoming economic coordination rather than agriculture intelligence, and the Converged Enterprise is about removing boundaries that prevent an institution from continuously sensing, deciding and acting.

These may have been the same question appearing in different domains.

SUBTRACTION BEFORE INVENTION

There is one point in Warner’s argument I want to push further: start with the business you already run. I agree completely if this means reinvention must begin with actual economics, customers, employees, technologies, obligations and constraints rather than an imaginary future-state architecture.

The danger begins when “start with the business you already run” quietly becomes “preserve the business you already run.” The existing enterprise is the starting state, not necessarily the destination, and transformation programs often fail because they ask how a powerful new capability can be introduced while disturbing the inherited operating model as little as possible.

Sometimes minimizing disruption is prudent. Sometimes the disruption to the operating model is precisely where the value resides.

Perhaps two disciplines therefore have to operate simultaneously. One is deeply pragmatic: begin with real priorities, workflows and measurable economic outcomes. The other is architectural archaeology: continuously ask why the workflow, department, approval, application or role exists in the first place and which historical constraint caused it to emerge.

That makes subtraction before invention a potentially more useful starting principle for enterprise AI than maximum automation. The operating sequence begins to look less like use-case discovery and more like institutional redesign.

This sequence does not begin by asking where AI can be inserted. It begins by exposing why the present system has the shape it does.

THE AI PROGRAM OFFICE MAY BE SOMETHING ELSE

This may also be what the AI Program Office has been trying to become. Initially, an AI Program Office sounds dangerously close to another PMO, and if its purpose is merely to centralize governance around twenty-eight AI projects, we have institutionalized the use-case problem rather than solved it.

The construct only becomes interesting if it becomes the mechanism through which the enterprise continuously examines where intelligence changes the economics and architecture of work. The questions then become more consequential: which outcomes matter, where decision latency lives, where people perform coordination work because systems cannot reason, where valuable judgment remains trapped inside individuals, where controls remain manual because authority cannot safely be encoded, where context is trapped inside application boundaries and where organizational structure is compensating for missing information.

At that point, the portfolio itself starts learning. Not every experiment deserves to scale and not every process deserves AI, while sometimes the correct answer is to leave a system alone until the economics, data or control environment changes.

The objective should therefore not be maximum AI adoption. It should be increasing the institution’s ability to discover where intelligence creates durable advantage, where it does not, and why.

HUNCH: MATURITY IS THE SPEED OF LEARNING

This is why conventional AI maturity models also make me uncomfortable. Experiments become pilots, pilots become scaled deployments and eventually somebody declares that the enterprise is “AI-native,” but the model rarely makes clear what has actually matured.

Perhaps a more useful measure is how quickly and reliably the enterprise can learn from consequential action.

The same idea keeps resurfacing elsewhere in a more compact form.

The speed and integrity of that loop may ultimately matter much more than the number of agents deployed. Something else follows from it as well: the deepest competitive advantage in the next era may not be intelligence itself because intelligence is becoming cheaper and more widely available.

Models will diffuse, techniques will diffuse, agents will diffuse and coding capability will diffuse. Many forms of reasoning that appear extraordinary today will eventually become commodity infrastructure, leaving the genuinely scarce resources elsewhere: context, trusted evidence, institutional memory, authority, coordination, judgment about goals, the capacity to act in the real world and the ability to learn from consequences.

Companies may not win because they possess AI; everyone will possess AI. They may win because they construct superior systems of intelligence and action around proprietary context.

This is why data keeps returning to the story, although not in the old “data is the new oil” sense. Data sitting in a lake is nearly useless; what matters is whether an institution can transform observation into decision-grade evidence, determine what happened and what it means, establish whether it can be trusted, connect it to the decision that depends upon it, determine who may act and preserve what happened after the action was taken.

That is a very different notion of a data platform.

WHAT 451 MAY ACTUALLY BE

There is something underneath all of this that I suspect I have carried since Bell Labs and later Yahoo and PARC without fully naming it. The best institutions do not merely produce products; they produce capacity for discovery by creating environments in which meaningful questions can be pursued, disciplines can collide, systems can be built and reality can interrogate theory.

Bell Labs was not powerful because somebody maintained a telecommunications use-case spreadsheet. PARC was not powerful because somebody scored inventions on a two-by-two. Their deeper capability was institutional: they made it possible for questions to mature through investigation and construction before being prematurely forced into conventional categories.

Perhaps this is part of what I have been trying to reconstruct with 451 Labs. Not innovation theater, not simply a startup studio and not another AI center of excellence, but something closer to machinery for turning uncertainty into consequential systems.

Seen together, these are beginning to look less like separate concepts and more like an operating model for creation. That may explain why Warner’s pragmatic observation about use cases triggers such a disproportionate reaction in me: beneath the simple statement sits a larger proposition that once the use case becomes contestable as an abstraction, many other inherited abstractions also become available for examination.

THE INSTITUTION BECOMES AVAILABLE FOR REDESIGN

The application may be the wrong abstraction. The workflow may be the wrong abstraction, as may the department, the annual planning cycle, layers of managerial hierarchy, the boundary between strategy and execution, the separation between technology and “the business,” and even the assumption that authority must remain permanently attached to organizational position.

Once those assumptions become contestable, the phrase AI transformation begins to sound much too small. We may actually be at the beginning of a redesign of the institution itself.

That does not mean companies become autonomous machines, nor would that necessarily be desirable. Enterprises ultimately exist to serve human purposes, and humans will continue choosing what matters, determining acceptable tradeoffs, defining values, managing exceptions and remaining accountable for consequences.

The division of labor, however, could change dramatically. Humans may increasingly provide purpose, judgment, relationships, values, exceptions and ultimate accountability, while machines provide memory, sensing, synthesis, simulation, coordination, execution and continuous monitoring.

Between the two sits the problem that keeps returning:

Authority may become one of the central design primitives of the AI-native enterprise because intelligence without legitimate authority cannot safely become consequential action.

FOLLOW THE CONSEQUENCES

When Warner argues that enterprises should stop designing the perfect AI future and begin changing the present, I agree. Start with the present, choose something that matters, build, observe and learn, but then follow the consequences honestly rather than stopping at the first productivity improvement.

If AI improves a workflow, ask whether the workflow should still exist. If it improves a department, ask whether the boundary between departments still makes sense; if an agent can make a recommendation, ask what would be required to grant it bounded authority; if automation releases capacity, ask where that capacity should move; and if productivity rises, follow the effect all the way to enterprise economics.

Eventually the inquiry reaches a much more uncomfortable question.

That is where I think the argument ultimately leads.

WHAT I MAY HAVE BEEN BUILDING

The part that caught me by surprise while thinking through all of this is how many apparently separate things begin collapsing into one body of thought. The Converged Enterprise is the institutional architecture, while the AI Program Office may be one mechanism for moving from the present operating model toward it.

Pola belongs to the authority layer. The Governed Data Foundry belongs to the evidence layer, ADAM to intelligence and reasoning, Physical AI extends the operating system into the world of atoms, and Wellzai tests the architecture against a fragmented economic system where coordination itself may be the opportunity.

Kriyas is a system for interrogating possibilities before committing to them. Subzero → 451 is the machinery through which possibilities are protected, challenged and exposed to reality, while The Clearing gives ideas enough context to reveal relationships before we force them into form.

Musewoods may therefore be something larger than a publishing system. Perhaps it is where ideas accumulate context, encounter one another and mature before we decide what they are.

A Fieldnote can preserve an observation while the thought is still moving. A Journal can continue the inquiry, a Story can eventually make developed understanding traversable, a Grove can cultivate what has become durable, and a Trailhead can invite someone else into unresolved territory.

Seen this way, these are not simply content types. They are different relationships to the life of an idea.

HUNCH

I may have been building pieces of the same machine without yet recognizing the full machine. It is not simply an AI platform, a venture studio, a publishing system or an operating model, even though each description captures part of what is being built.

The question connecting them may be larger.

AI makes that question newly investigable through working systems rather than theory alone. What I hear underneath Warner’s remarks, therefore, is less a tactical prescription for improving enterprise AI programs than the beginning of a more consequential conversation about the future architecture of the institution.

The use case may simply be the first abstraction to fall. What I want to understand next is what happens when we follow that implication all the way down.