Over the last decade, much of my work with The Business Engineer has involved a form of compression: taking the enormous complexity of a business and identifying the underlying mechanisms that explain how it works.
Business models, financial structures, technological architectures, organizational incentives. Each offers a way to make that complexity intelligible. A useful model preserves the relationships that matter, allowing us to reason about a business without having to reconstruct every detail of it.
As I’ve become more involved in enterprise AI, I’ve found myself returning to a related question: how much of the expertise required to operate a business can we capture, abstract, and make reproducible?
I increasingly believe this is one of the most useful ways to understand both the evolution of AI and the economic frontier ahead of it.
In a 2023 conversation with Jensen Huang, Ilya Sutskever put the underlying idea succinctly:
“Compression has the property that it discovers the secrets in the data.”
There is a precise relationship between prediction and compression. A system that learns to predict data effectively has captured regularities that allow it to represent that data more efficiently. In language, those regularities can extend into the concepts, relationships, and structures expressed through words. Researchers have demonstrated this connection directly by using language models as powerful compressors.
That gives us a useful starting point for understanding what has happened over the last few years.
From compressing information to developing capability
Large-scale pretraining allowed models to learn reusable representations from vast collections of text. The result was a remarkable breadth of capability: systems that could answer questions, translate, explain concepts, and adapt to tasks from a handful of examples. Much of what previously required searching through information became accessible through a single interface.
That breadth included specialist material. But learning from the knowledge available in a training corpus leaves a further challenge: applying it appropriately to a particular request, situation, or objective.
Post-training helped shape that capability into more useful behavior. Demonstrations and human feedback taught models to follow instructions more effectively and produce responses better aligned with what users wanted. The significance was that capability could be refined through examples and judgments about what good performance looked like.
Chain-of-thought techniques showed that generating intermediate steps could improve performance on problems requiring several stages of reasoning. Further work on reasoning models combined reinforcement learning with test-time compute, allowing systems to spend more computational effort working through a problem before producing an answer. These approaches overlap: training can improve the strategies a model uses, while additional computation at inference gives it more room to apply them.
Continual learning takes the question further: can a system retain what it learns from new experience and use it to improve future performance? This remains an active research frontier. Acquiring new knowledge while preserving existing capabilities is difficult, and retaining information within a conversation is different from developing durable competence across successive experiences.
These developments form a cumulative progression, with different methods addressing different parts of the problem. Pretraining builds broad representations. Post-training shapes behavior. Reasoning techniques and additional computation help apply capability to harder problems. Continual learning aims to make experience accumulate.
My reading of that progression is that we are moving toward an increasingly consequential question: can AI acquire and reproduce the distinctions that make an experienced specialist valuable?
That is where the enterprise opportunity becomes much more interesting.
The Embedding Lifecycle is Part of The Enterprise Embedding Series!
The economic frontier is deep expertise
The standard for useful AI changes as we move deeper into a business.
Broad competence is valuable when the work involves explaining a concept, drafting a document, or organizing information. In a critical operating process, the system may need to recognize an unusual case, identify an omission, reconcile conflicting evidence, and determine whether a decision falls within its authority.
The benchmark becomes the judgment of someone who has spent years working in that particular domain.
I believe AI’s deeper penetration into the economy will depend heavily on our ability to make scarce expert judgment reproducible within clearly defined areas of work.
Consider specialist insurance underwriting.
An experienced underwriter must interpret policy wording, assess complex risks, understand how an exposure affects a portfolio, and make decisions within particular authority limits. Their work connects technical knowledge with the insurer’s commercial objectives, existing commitments, and appetite for risk. The Chartered Insurance Institute’s competency framework reflects precisely this combination of interpretation, pricing, portfolio management, and decision authority.
Imagine two submissions that appear similar on their headline characteristics. An experienced underwriter might notice that an exclusion is worded differently, that a missing piece of information deserves further investigation, or that an otherwise acceptable risk would add too much exposure to something the insurer already covers.
The decisive expertise lies in recognizing which distinction changes the decision.
Some of that knowledge can be expressed as a rule. Some can be demonstrated through cases. Some emerges only when the expert is challenged with a difficult example and asked what additional evidence would change their assessment.
This is the level of capability I mean when I talk about compressing domain expertise.
The ambition is to capture enough of the structure behind those judgments that a system can apply it to new cases, recognize its limits, and improve through feedback. Within a sufficiently narrow domain, that could make parts of an expert’s work available far beyond the number of cases they can personally handle.
The economic significance is considerable: expertise that is expensive to develop and concentrated in a small number of people could become a capability that an organization can reuse and scale.
What has to survive the compression
There is a difficulty here that the compression metaphor helps expose.
A useful abstraction must preserve the distinctions that matter to the decision. In specialist work, those distinctions may sit in precisely the details that a generic summary would discard.
The unusual clause. The missing document. The exception to an otherwise reliable rule. The combination of individually ordinary facts that becomes significant when considered together.
The test of whether we have captured expertise is whether the system preserves the distinctions that change the outcome.
This also means expert practice needs to be examined critically. Experience can contain valuable judgment alongside outdated assumptions, inconsistent habits, and decisions that were never properly tested. Making expertise explicit gives us an opportunity to evaluate it.
At the enterprise level, I therefore use compression in a broader engineering sense. The representation of expertise may be distributed across a model, documented decision criteria, carefully selected cases, access to relevant evidence, and tools that allow the system to investigate or act.
Some knowledge may be learned through training. Other knowledge may need to remain explicit because it changes frequently, belongs to a particular organization, or must be inspected and approved.
The objective is to create a reusable capability whose performance can be assessed.
That requires more than collecting an expert’s explanations. We need to observe the cases they encounter, the evidence they seek, the alternatives they reject, the exceptions they recognize, and the conditions under which they defer to someone else. We also need ways to establish whether those decisions were sound.
This is where the connection to continual learning becomes especially consequential. A deployed system needs a disciplined way to turn new experience into better future performance. That involves deciding which feedback is reliable, which lessons should generalize, and which apparent improvements might weaken performance elsewhere.
In domains such as underwriting, even that feedback can be difficult to interpret. A decision’s consequences may emerge over a long period, and a favorable outcome in an individual case does not, by itself, establish that the original judgment was good.
The learning process therefore becomes part of the operating design.
Where Business Engineering comes in
This is the problem I want Business Engineering to address.
My earlier work focused on modeling businesses so we could understand how they create value, compete, and evolve. The next step is to model the expertise through which businesses actually operate, with enough precision that parts of it can be executed by AI systems.
That makes the business process a crucial unit of analysis.
A process gives expertise somewhere to operate. It connects a judgment to the evidence available, the action permitted, the person accountable, and the economic result being sought.
An underwriting recommendation, for example, acquires operational meaning through the surrounding process: what information has been checked, which terms can be offered, what requires referral, and who can commit the insurer.
The same relationship appears in procurement, financial operations, and other specialized enterprise functions. The capability becomes useful through its connection to the conditions under which a business can rely on it.
The challenge is to turn accumulated expertise into a capability that can be taught, tested, deployed, and continuously improved.
That is why I have been working on formalizing The Business Engineering Body of Knowledge.
I see a need for a systematic discipline that connects the economics of a process with the knowledge required to perform it, the means of representing that knowledge, and the operating conditions under which AI can take responsibility for parts of the work.
Expertise is one of the hardest remaining frontiers in enterprise AI. Its capture must develop alongside the systems, authority, evaluation, and incentives that allow it to produce useful results.
This gives the enterprise AI lifecycle a much more substantive purpose.
Each stage should resolve part of that translation: identifying where scarce judgment creates value; understanding how it is exercised; representing it in a usable form; testing it against meaningful cases; establishing the scope of delegated work; and learning from what happens after deployment.
The sequence matters because these decisions depend on one another. We can only evaluate a system properly once we understand what competent performance requires. We can only expand its responsibility once we have evidence about where its judgment holds and where it breaks down.
The ten-step lifecycle that follows gives this work a practical structure.
We will examine it through a composite example: a mid-sized European manufacturer of industrial pumps and valves redesigning its supplier invoice approval process. Beneath the familiar paperwork, we will encounter the judgments that make the process work: interpreting contractual terms, reconciling partial deliveries, investigating discrepancies, handling disputed quality, and deciding when an apparently valid payment requires further scrutiny.
The figures are illustrative. The purpose is to follow how expertise moves from people and established practices into an operational capability that can be evaluated and improved.
That, to me, is the deeper opportunity for Business Engineering in the AI era: making the knowledge a business depends on increasingly reproducible, while preserving the judgment that makes it valuable.
The Embedding Lifecycle is Part of The Enterprise Embedding Series!
