What Should Stay Stable as AI Keeps Changing?

Organizations are beginning to redesign work around AI while the technology itself remains unusually unsettled. Stanford’s 2026 AI Index reports that AI use has reached 88 percent of surveyed organizations, while deployment of AI agents remains in the single digits across most business functions. Capability is improving quickly, but many of the organizational patterns for using it are still forming. The combination creates a practical design problem: an organization can make expensive changes around an implementation that may look materially different before the operating model built around it has settled.

The question is not whether organizations should change as AI becomes more capable. Some changes will be substantial enough to alter roles, authority, workflow, governance, and even what work is necessary. The more useful question is where those changes should be anchored. When work is designed too closely around today’s model, product, interface, or agent pattern, ordinary technology improvement can create repeated pressure to redesign the organization around each new implementation.

A more durable level may be the capability the technology is expected to provide. I use the term AI capability classes for purposes that remain recognizable even while the implementations underneath them change. This is a hypothesis about organizational design, not an established AI operating model, so the argument should not depend on assuming that mature AI use cases already exist. Earlier technology transitions provide useful comparators for why separating a durable purpose from a changing implementation can matter.

Stable Purpose, Changing Implementations

Transportation makes the distinction visible without requiring the implementations to look alike. A motorcycle, freight train, cargo ship, helicopter, and submarine are radically different systems. They operate in different environments, carry different loads, face different constraints, and depend on different infrastructure, yet they still serve a recognizable higher-level purpose: moving people or things from one place to another.

Recognizing the common purpose does not make the implementations interchangeable. A freight train cannot replace a motorcycle, and a submarine is useful under conditions where neither would make sense. The point is almost the opposite: the more specialized the implementations become, the more useful it is to distinguish the enduring purpose from the particular system that provides it. We can reason about transportation as a stable capability while still selecting very different modes for different conditions.

AI capability classes would apply the same distinction at an organizational level. Future AI systems may become increasingly specialized by domain, task, risk, interface, autonomy, or computational architecture. The relevant question is whether some purposes remain recognizable enough that people can organize work around them without assuming that the systems providing those capabilities will look alike or remain technically similar.

Containerization adds a second lesson. Before standardized containers became widespread, cargo was handled repeatedly as it moved among ships, docks, railroads, and trucks, which meant that different transport systems had to deal directly with the form in which the goods arrived. Standardized containers changed that relationship by giving the transport network a dependable unit that could move between modes.

The transition was neither automatic nor painless. It required new ships, cranes, port infrastructure, labor arrangements, investment, and eventually international standards. OECD histories describe how incompatible early container systems gave way to standards covering dimensions and fittings, allowing containers to move more reliably across road, rail, and sea. ISO 668 still defines the external dimensions and ratings for major classes of freight containers.

Once the interface became dependable, trucks, trains, ships, cranes, routing systems, and ports could continue to evolve without requiring cargo to be repackaged around every change in transport technology. What remained stable was not the machinery but the boundary through which the larger system interacted with it. That reduced the amount of change that had to propagate whenever one part of the transport system improved.

The same design instinct appears inside computing. Transportation shows why a higher-level purpose can survive radical specialization, while containerization shows how a stable interface can limit the amount of change that propagates through a larger system. Computing has repeatedly used similar boundaries to let one layer evolve without forcing every layer above it to change at the same rate.

In 1972, computer scientist David Parnas argued that the way a system is decomposed affects both its flexibility and its comprehensibility. The information-hiding approach associated with that work separates what another part of the system needs to know from implementation details that can change behind an interface. The internals are not expected to remain static; the design objective is to keep change localized when the surrounding system does not need to know about it.

The Internet provides another example. TCP was designed as a reliable transport protocol above lower-level networks, and early specifications explicitly anticipated that it should operate across a wide range of communication systems. Applications could therefore depend on a recognizable transport capability without being redesigned around every change in the physical network carrying the packets. The lower layers continued to evolve while the abstraction above them remained useful.

Cloud computing moved a similar boundary upward. NIST defines Infrastructure as a Service as the ability to provision processing, storage, networks, and other fundamental computing resources without requiring the consumer to manage the underlying cloud infrastructure. Servers, storage devices, virtualization technologies, and data-center machinery can change substantially while the customer continues to ask for recognizable capabilities such as compute, storage, and networking.

Cloud adoption itself often required major organizational and architectural change, so the comparison should not be pushed too far. Abstraction does not eliminate transformation. It can, however, create a boundary after which routine improvement underneath that boundary no longer requires an equivalent redesign above it. That narrower pattern is the one worth carrying into the AI question.

What That Might Mean for AI

AI products are currently described largely through implementation language: model names, copilots, agents, assistants, orchestration patterns, retrieval systems, and rapidly changing product categories. Those distinctions matter technically, but they may be too volatile to serve as the primary layer around which organizations design durable work.

A capability class instead describes what the organization expects intelligent systems to help accomplish. To be useful as a design layer, the purpose should remain recognizable across multiple implementations, including systems that become highly specialized for different domains or conditions. Roles, processes, governance, and authority could then be designed around what the capability is expected to contribute without assuming that the technology underneath it will remain fixed or become uniform.

The taxonomy is deliberately provisional. Four classes currently seem useful enough to test: knowledge management, environmental and market signal monitoring, reasoning support, and opportunity identification. They are not claims that AI has already matured into four settled enterprise categories; they are candidate organizational design layers whose durability still has to be demonstrated.

Knowledge management

Organizations already accumulate knowledge across documents, systems, conversations, decisions, specialists, and years of experience. The recurring problem is not simply producing more information but making relevant knowledge available in the situation where it matters. AI may contribute through retrieval, synthesis, connection, preservation, and contextual access, but the organizational purpose is broader than any one search product, model, or retrieval architecture.

If knowledge access becomes the design target, onboarding, decision history, expertise preservation, investigation, and reuse can be designed around an expectation that the supporting technology will continue to evolve. A future system may connect context far more effectively than today’s tools without changing the underlying need to bring relevant organizational knowledge into the work at the right time and with enough context to be useful.

Environmental and market signal monitoring

Organizations operate amid changing customer behavior, competitive moves, regulation, technical developments, operational anomalies, supplier conditions, and market signals. The tools used to monitor those environments will change, but the organizational need is more durable: notice material change soon enough to understand what it may mean and decide whether a response is warranted.

Designing around that capability could allow sensing technology to become broader, faster, and more sophisticated without forcing the surrounding organization to rediscover the purpose of monitoring every time the implementation improves. The implementation details can change while questions of autonomy, human attention, evidence, and escalation remain explicit design choices rather than accidental consequences of a particular tool.

Reasoning support

Reasoning cuts across nearly every form of knowledge work. People frame situations, interpret evidence, compare explanations, question assumptions, explore consequences, and make judgments under uncertainty. AI can support portions of that work without owning the final judgment, which makes the durable capability something broader than a ‘chatbot’ or a ‘reasoning model’: assistance that helps people build a better representation of the situation and make more warranted decisions.

That capability could become substantially more powerful while remaining human-augmenting. Later systems may ask better questions, connect more evidence, identify conflicts earlier, or recognize when a premise should be reopened. If the organization has already designed appropriate human authority, specialist boundaries, and review around reasoning support, many of those improvements could strengthen the work without requiring the entire operating model to be rebuilt.

Opportunity identification

Opportunity identification differs from simply making existing work faster. Organizations can miss possibilities because knowledge is distributed across functions and because existing products, technologies, and processes accumulate assumptions about what they are for. A market signal may take on different significance when it is connected with an internal capability, a customer problem, a regulatory change, or an economic shift that sits somewhere else in the organization.

AI may eventually become increasingly useful at making those relationships visible, but the organizational capability is the ability to surface possibilities worth investigating rather than the use of a particular model to generate ideas. Human judgment would still determine which possibilities deserve development, which constraints are real, and what would have to become true before a promising possibility could justify commitment.

Designing Around Capabilities Rather Than Implementations

The distinction becomes clearer in an ordinary product organization. Its strategy process might assume that people will have increasingly strong support for accessing organizational knowledge, monitoring customers and markets, reasoning about priorities, and surfacing emerging opportunities. Product leaders would still determine what deserves attention, evaluate tradeoffs, decide what to build, and remain accountable for the commitments that follow.

The systems providing those capabilities could change materially. One generation might rely heavily on retrieval and summarization; another might connect product telemetry, competitive information, customer behavior, technical dependencies, and internal expertise with much greater sophistication; a later system might perform more of that work continuously or proactively. If the surrounding organization is designed around the capability and authority relationship rather than the product label, those improvements have somewhere to go without automatically changing the purpose of the work above them.

That is the organizational analogue of a stable technical interface: the layer above depends on what the capability can reliably provide while remaining insulated from implementation details that do not need to propagate upward. The boundary will never be perfect, and some improvements will be important enough to cross it, but the design objective is to avoid unnecessary coupling between a fast-changing technology layer and a slower-changing operating model.

Stability Does Not Mean Standing Still

Technology history also provides a reason not to take the argument too far. New technology can require real organizational change. Research by Timothy Bresnahan, Erik Brynjolfsson, and Lorin Hitt found complementarities among information technology, workplace reorganization, and new products and services at the firm level, supporting the broader point that technology can create more value when the organization changes with it rather than simply inserting a new tool into existing work.

AI is unlikely to be an exception. A genuinely new capability may eliminate some work, create other work, change the distribution of expertise, alter evidence requirements, or move a task across an authority boundary. Regulation may change what can be delegated, and increasing autonomy may require different controls and accountability. When the capability changes what the organization can or should do, redesign is warranted.

The proposition here is narrower: ordinary improvement in an expected capability should not automatically trigger another operating-model redesign. Organizations pay for unnecessary change through integration work, documentation, retraining, governance updates, disruption, and temporary productivity loss. A more durable design should distinguish improvement within a known capability from the arrival of a materially different capability that genuinely changes the work.

A More Durable Starting Point

Much of the AI-transformation conversation begins with the technology and works backward: what can this model do, where can this agent be deployed, and which workflow should change? That sequence is useful for experimentation, but it may be a weak foundation for durable organizational design precisely because the implementation is the part of the system changing fastest.

A capability-first approach reverses the order. It begins with the work the organization needs to accomplish, identifies intelligent capabilities likely to remain valuable even as implementations change, and then determines how those capabilities should interact with people, information, specialist expertise, governance, and authority. Technologies can then be selected, improved, or replaced within that design without assuming that every change below the boundary requires the organization above it to be redesigned.

The transportation analogy provides the simplest conceptual test: one durable purpose can be served by highly specialized implementations. Containerization, modular software, layered network protocols, and cloud infrastructure provide more concrete technology comparators for how stable interfaces or capability boundaries can absorb change underneath them. None of those histories proves that AI will settle into the same pattern, but together they make the organizational hypothesis plausible enough to test: work may become more durable when it is anchored to recognizable intelligent capabilities rather than to whichever implementation happens to be current.

Knowledge management, signal monitoring, reasoning support, and opportunity identification are only an initial proposal for where those boundaries might sit. The more durable objective is to design around what the organization needs intelligent systems to help accomplish, while allowing normal technological improvement to strengthen those capabilities without repeatedly forcing the organization to rebuild itself around the latest implementation.

Selected sources and further reading

Stanford HAI, The 2026 AI Index Report - Current AI capability and organizational-adoption context.

OECD, Containerships - the engines of globalization and trade - History of container standardization and intermodal transport.

ISO 668:2020, Series 1 freight containers - Classification, dimensions and ratings - Current standardized external dimensions and ratings for freight containers.

David L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules - Foundational modularity and system-flexibility comparator.

RFC 761, DoD Standard Transmission Control Protocol - Early layered-network specification designed to operate over diverse underlying communication systems.

NIST SP 800-145, The NIST Definition of Cloud Computing - Cloud service models and the abstraction between consumers and underlying infrastructure.

Bresnahan, Brynjolfsson, and Hitt, Information Technology, Workplace Organization, and the Demand for Skilled Labor - Firm-level evidence on complementarities among IT, workplace reorganization, and new products and services.