Thesis
Why AI is the foundation, not a layer
We believe the strongest AI businesses are designed around AI from the first day, rather than adding it on top of a finished product. A layer improves a process; a foundation changes which processes are worth running at all.
What a layer looks like
A layer is easy to recognize. The company has a working product, a team organized around it, and a roadmap. Someone proposes adding AI, and a small group builds a feature: a summary, a suggestion, a search box. It ships, usage is modest, and the company reports progress. Nothing underneath has changed. The data was never collected to train or evaluate anything, the workflow still assumes a person does each step, and the team measuring success is the same team that built the original product.
That path is reasonable, and often the right first step. But it has a ceiling, and the ceiling is set by the parts nobody touched.
What a foundation looks like
In a foundation, the design questions come in a different order. What decisions does this business make repeatedly? Which can a system make reliably, and which need a person? What data would we need to improve those decisions, and how do we capture it as a side effect of doing the work? Only then does the team design the product.
The result is a different shape of company. Data capture is part of the product, not an analytics project. Review and escalation are designed as features. The cost model assumes that a growing share of work needs no human touch, and that compute, not payroll, becomes the main variable cost.
Why we believe the difference compounds
There are three reasons we think this matters over a long horizon.
- Data accumulates where it was designed to. A company that captures outcomes and corrections from day one has a growing evaluation set and a clear view of where the system fails. A company that retrofits capture starts from zero, usually under time pressure.
- Workflows improve in small steps. When review is built in, each correction is a lesson. When review is informal, the same fixes are repeated by different people.
- Teams learn to ask the right question. In a foundation company, "can the system do this step?" is asked about every process. In a layered company it is asked about the one feature someone owns.
None of this is automatic. A company designed around AI can still make poor product choices. We are describing a starting position, not an outcome.
Signs you may be building a layer
Use this as a quick checklist. Several yes answers do not mean the company is in trouble, but they suggest where to look.
- The AI feature can be switched off without changing how the team works.
- Nobody can say which data is captured to improve the system.
- Success is measured by feature usage rather than by cost, speed or quality of the underlying work.
- The people doing the work were not involved in designing the AI step.
- Headcount plans for next year assume the same ratio of staff to customers as this year.
- The model vendor can be named, but a switching plan cannot.
Can an established business rebuild on a new base?
Often, in stages, and usually in one workflow first. Pick a process that is high volume, has a clear definition of a good outcome, and has people who want it improved. Redesign it end to end, including data capture and review. Measure it honestly. Then use what you learn to decide where else the approach fits. For owners considering this path, our page for companies explains how we think about it, and our approach sets out how we work with operating teams.
What changes in the team
Foundation companies tend to organize around the loop, not the function. Product managers, engineers, operators and data owners sit close to the same workflow and share the same measures. There is usually a person responsible for evaluation: someone who keeps the test cases, watches for drift and can say, with evidence, whether last week's change helped. In layered companies this role is often missing, because the AI feature is treated as finished once shipped.
A short illustration
Hypothetical example, for illustration only. A regional insurer adds a summarization tool to its claims system. Adjusters like it, and handling time falls a little. A second insurer redesigns claims intake so that the system reads documents, proposes a decision with its reasoning, and sends only uncertain cases to an adjuster, whose corrections are stored for later evaluation. The first insurer has improved a step. The second has changed the process, and has begun to build the data that will let it keep improving.
The first insurer made a reasonable choice. It is simply on a different path, with a lower ceiling.
What we look for
In a founding team, we look for evidence that they started from the work, not from the technology: a specific decision, a specific customer, a specific cost. In an established company, we look for an owner with authority over the workflow, not only over the AI project. In both cases we ask the same plain question: if the AI disappeared tomorrow, what part of the business would no longer make sense? The answer tells us whether we are looking at a foundation or a layer.
This article is for general information only and is not investment, legal, tax or accounting advice.
FAQ
Frequently asked questions
Is adding AI to an existing product a mistake?
No. It is often a sensible first step. The risk is stopping there and calling the job done, when the workflow, data and team design still assume the old way of working.
What is the cost of treating AI as a layer?
Usually a ceiling. Gains stay small because the surrounding process, data and incentives were built for people doing every step.
Does this apply to small companies?
Yes, and sometimes most clearly there, because a small company can design its workflow around a system before habits harden.
Contact
Building, running or selling an AI-native business?
Tell us a little about it. We aim to reply within two business days.