THE AUTOCATALYTIC ENTERPRISE SERIES · PART 1
This series examines how enterprises build capabilities that make subsequent innovation easier. This article explores how one AI implementation can improve the organization’s ability to deliver the next. Each essay can be read independently.
TL;DR
A successful AI project can improve a business process while leaving the organization to repeat much of the implementation work on its next project. Capability begins to compound when later teams can use and improve what earlier implementations established: access to business information, connections to operating systems, evaluation methods, controls and operational experience. Executives should examine that inheritance alongside the immediate return. The practical question is what the last AI investment has made possible for the next one.
Executive action
At your next AI portfolio review, select two successive implementations. Ask the second team what it inherited from the first, what that inheritance enabled and what still had to be rebuilt. Then establish whether the second implementation contributed anything the first team—or a third—can now use.
Why the next AI project starts over
The first AI project works. Employees use it, the business sees a benefit, and leadership approves further investment.
The next team begins with a different use case and a familiar list of problems. It needs access to enterprise information. It needs to establish what the system is allowed to see and do. It needs a way to evaluate its results, handle exceptions and determine who takes responsibility when something goes wrong.
The first team encountered many of these questions. Some of its answers ought to be useful.
But the relevant knowledge is distributed across application code, project documentation, access approvals and the experience of the people who built it. Working out which parts apply to the new implementation takes time. Adapting them takes more. The second team makes its own arrangements and moves ahead.
Both applications may deliver an acceptable return. Yet the enterprise has paid twice to acquire some of the same capabilities.
In the previous essay, The Autocatalytic Enterprise, I proposed that innovation becomes autocatalytic when the products of innovation increase the system’s capacity to produce subsequent innovations.
AI implementation gives us a practical place to examine that proposition. We can follow what one project creates, see whether another project benefits and ask whether the resulting work improves what is available to everyone else.
What compounds is the enterprise’s capability to implement useful AI.
That distinction matters because some improvements arrive from outside the organization. A provider releases a more capable model. Inference becomes cheaper. A software product gains a feature that previously required custom development. The enterprise benefits from progress it did not have to produce.
There is a further source of improvement within its control: what it learns and builds through implementation, and how effectively it carries that work forward.
What the first implementation actually creates
Consider a company introducing an AI assistant to help customer-service staff answer questions about orders.
The visible application may appear straightforward. An employee asks a question, and the assistant retrieves information and prepares an answer.
Making that answer dependable involves considerably more.
The application must identify the right customer, retrieve the correct order and interpret its status. It must distinguish information an employee is entitled to see from information they are not. It needs to recognize when the available records are incomplete or contradictory.
The team also needs a way to determine whether the assistant is performing well enough for use. That requires representative questions, expected answers or assessment criteria, and examples of situations in which the system should acknowledge uncertainty or hand the issue to a person.
Once the assistant is operating, someone must investigate failures, manage changes and decide whether a new model or a revised connection to an order system has altered its behavior.
Suppose the implementation succeeds. Staff spend less time searching across systems and can answer customers more effectively.
The project has also produced a working relationship between AI and part of the enterprise. It has established access to business context, resolved questions of permission, developed evaluation practices and created experience of operating the application.
Those are potentially useful inheritances.
Their value to the next implementation depends on whether another team can use them.
What the second implementation can inherit
Now suppose the company wants an assistant to help staff handle returns.
Some requirements are different. The application needs to interpret return policies, assess eligibility and distinguish routine cases from exceptions. If it can initiate a return or issue a refund, it also needs authority to act and controls appropriate to the consequences.
But the team should be able to begin with some of the earlier work.
Customer identification and order retrieval are already established. Access arrangements may provide a starting point. The evaluation process may offer a useful way to organize cases, investigate errors and decide whether a change is acceptable. Monitoring and incident-handling practices may be adaptable.
None of this removes the need to evaluate the returns assistant on its own terms. Accuracy on order-status questions provides little assurance that a system will apply a return policy correctly. Permission to retrieve an order does not confer permission to refund it.
The inheritance gives the team a better starting position. Its value has to survive the work required to adapt and validate it.
Suppose the returns implementation then exposes a weakness in customer identification. The team develops a better way to handle customers with several accounts and makes that improvement available to the original assistant. It also develops a dependable process for escalating policy exceptions that another application can use.
We can now trace a relationship across the implementations. The first made parts of the second easier. The second improved a capability used by the first and created something available to a third.
That is the mechanism I mean by compounding.
The example is illustrative. In an actual enterprise, we would need evidence of those transfers and their effects. But it gives us something specific to look for beyond the number of applications deployed.
When project work becomes enterprise capability
A capability is a dependable ability to accomplish something under conditions we understand reasonably well.
For AI implementation, it includes the arrangements that let a team connect a model to the business and operate the resulting application responsibly. Software is part of that arrangement. So are knowledge, ownership, evaluation and authority.
A connection to an order system becomes useful to another team when that team can discover it, obtain appropriate access, understand its behavior and rely on someone to maintain it.
An evaluation method becomes useful when another team can apply it to its own risks and decisions. The cases themselves may need substantial revision. What transfers could be the method for constructing them, the means of running them and the discipline of investigating failures.
Operational experience becomes useful when it changes how subsequent applications are built and managed. A lesson recorded at the end of a project has limited effect if the next team encounters the same failure without knowing that anyone has seen it before.
This is where much of the implementation effort goes: making the relationship between AI and the enterprise dependable.
It is also where an organization can repeatedly lose what it has learned.
The connection to composability
In the Composable Enterprise work I began in 2013, I described matched Component Operating and Component Architecture Models. The intention was to make business and technology capabilities available for assembly and recombination through predictable interfaces and shared understanding.
AI implementation makes that architectural question particularly tangible.
An assistant needs access to what the enterprise knows and, increasingly, to what it can do. The quality of those connections affects what can be built, how reliably it operates and how much effort the next implementation requires.
The operating arrangements matter throughout. A technically reusable service can be difficult to use because no one owns its ongoing development, access requires repeated negotiation or its funding ends with the original project.
The autocatalytic question extends this foundation: does using the available capabilities produce further capabilities that improve subsequent work?
A shared platform can help. Its existence alone tells us little about whether this is happening. We need to follow its use, the improvements contributed by implementations and the effect of those improvements on later work.
Where the argument needs limits
It would be easy to turn this into a requirement that every AI project produce reusable components. That would create another source of unnecessary work.
Some applications address a narrow problem. Their value may justify a local implementation with little relevance elsewhere. Generalizing the solution could add more cost and maintenance than any plausible future use would warrant.
Even where reuse is appropriate, the boundary requires judgment.
A method for evaluating answers may transfer between applications while the underlying test cases remain specific to each one. A monitoring service may be shared while the thresholds for intervention differ. A business capability may be technically accessible but inappropriate for an agent to invoke without additional approval.
Compounding also carries the possibility of propagating mistakes. An incorrect interpretation of a policy can spread through several applications. A shared evaluation process can overlook the same class of failure everywhere it is used.
The ability to inspect, challenge and correct inherited work therefore belongs inside the implementation approach.
Nor should we expect every successive AI project to cost less or finish faster. A later project may address a more consequential decision, operate across more systems or attempt something the organization could not previously have contemplated.
The useful inquiry is what the team was able to accomplish because earlier work existed, after allowing for the cost of adapting, validating and maintaining it.
Putting it to work
Choose two AI implementations with a plausible relationship. Ideally, the second should have enough operating history for the teams to distinguish expected benefits from actual experience.
1. Identify what the first project made available.
Ask for concrete examples: a maintained connection to business information, an access arrangement, an evaluation method, an escalation process or an operational practice. Establish who owns each one and what another team would need to use it.
A list of technologies deployed will not answer this question. You are examining what the organization became able to do.
2. Ask the second team what it actually used.
Have the receiving team explain what it inherited and what that enabled. Ask what work it avoided, what uncertainty it reduced or what became feasible as a result.
Separate this account from improvements attributable to a newer model, a vendor feature or a change in project scope. Several sources of progress may be operating at once.
3. Examine the cost and limits of the inheritance.
Find out what had to be rediscovered, negotiated, adapted or rebuilt. Ask which assumptions required fresh validation and which permissions could not carry over.
If reuse was abandoned, understand why. The earlier capability may have been unsuitable. It may also have been useful in principle but too difficult to access or maintain.
4. Follow what the second implementation contributed.
Did it improve anything used by the first application? Did it create a further capability that another team has adopted?
One instance of reuse demonstrates a benefit. Contributions flowing through further implementations provide stronger evidence that the organization is developing the continuing mechanism described here.
5. Make one decision about the next investment.
The findings should lead somewhere specific. An access problem may require a change in ownership or approval. Repeated evaluation work may justify a shared method with application-specific cases. An unreliable integration may need investment before more applications depend on it.
Where there is no credible further use, preserve the local solution without creating an unnecessary enterprise obligation.
Capture the result on one page: what was inherited, what it enabled, what adaptation cost, what came back and what leadership will do next.
A further question for the AI portfolio
The immediate return from an AI application remains important. An organization needs to know whether the implementation improved the work it was intended to improve.
Alongside that assessment, leadership should be able to explain how the investment has affected its capacity to undertake further implementations.
Does the next team have better access to business context? Can it evaluate a proposed application with greater confidence? Are responsibilities clearer? Can it build on operating experience rather than acquire all of it again through failure?
Over a portfolio of investments, these differences become consequential. They affect which problems the enterprise can attempt and how much effort it takes to address them.
The evidence will be found in the relationships between implementations: what one team creates, what another can use and what their work makes available in return.
The question to carry into the next AI investment review is therefore quite practical.
What did the last project make possible?
The Autocatalytic Enterprise Series · Part 1
Previously: The Autocatalytic Enterprise — the prologue establishing how innovation can increase the capacity for subsequent innovation.
Coming next: The Capability Graph — how to understand what the enterprise can do and which capabilities can work together.