Skip to main content

The Compound Advantage: Why AI Foundations Beat AI Projects

The most important concept in enterprise AI is compound value, not the model. The thesis, the evidence, and how to build for it.
25 April 2024·7 min read
Isaac Rolfe
Isaac Rolfe
Managing Director
There's a fundamental divide forming in enterprise AI. On one side: organisations treating each AI capability as a separate project. On the other: organisations building foundations that make each new capability faster, cheaper, and more powerful than the last. The second group is winning, and the gap is compounding.

What You Need to Know

  • Compound AI value is the most important concept in enterprise AI strategy. Each capability you build should make the next one faster and cheaper. If it doesn't, you're building projects, not a platform.
  • The foundation approach costs ~30% more on capability #1. By capability #4, it saves ~50% on total investment and ~40% on total time. The math is unambiguous.
  • The compound advantage isn't just financial. It's organisational. Teams that build on foundations develop expertise faster, governance matures faster, and adoption accelerates because each new capability integrates with what people already know.
  • Most enterprises are still in "project mode," building standalone AI tools that share nothing. Every one of these projects is a missed opportunity to build shared infrastructure.
  • The transition from projects to platform is the single most impactful strategic decision in enterprise AI.
faster delivery by the fourth AI capability when building on a shared foundation
Source: RIVER Group, enterprise engagement data, 2023-2024
50%
total investment savings by capability #4 compared to standalone project approach
Source: RIVER Group, enterprise engagement data, 2023-2024

The Compound Thesis

Every enterprise AI capability has two components:
  1. Unique value: the specific thing this capability does (claims intelligence, fraud detection, customer communication)
  2. Foundation value: the shared infrastructure this capability builds or extends (data pipelines, knowledge bases, integration patterns, governance)
In a project model, you capture only #1. In a foundation model, you capture both, and #2 compounds.
Here's what that looks like in practice:
Capability 1 (claims intelligence) builds: document processing pipeline + knowledge base + integration framework + governance patterns. Unique value: faster claims processing. Foundation value: infrastructure for everything that follows.
Capability 2 (fraud detection) reuses 60% of the foundation. Builds: anomaly detection + investigation workflows. The document processing pipeline already exists. The knowledge base already contains policy information. Integration patterns are established.
Capability 3 (customer communication) reuses 75%. The knowledge base, integration framework, and governance are all in place. New: generation models and compliance checking for outbound communication.
Capability 4 (risk assessment) reuses 85%. Almost everything is built. The mature data pipeline, rich knowledge base, and proven governance framework make this a 4-week sprint instead of a 14-week project.
Foundation Reuse Compounds With Each Capability
Source: RIVER Group, enterprise engagement data, 2023-2024
This is compound value. Each capability is cheaper and faster because it inherits the infrastructure of every capability before it.

Why Projects Don't Compound

The alternative (standalone projects) looks different:
Project 1 builds its own data pipeline, its own knowledge base, its own integration. 14 weeks. Project 2 builds its own data pipeline (different format), its own knowledge base (separate from project 1), its own integration (same systems, new connections). 14 weeks. Project 3 - same pattern. 14 weeks.
Three projects, 42 weeks, three separate infrastructures. On a foundation: 27 weeks, one shared infrastructure.
Standalone Projects vs Foundation Approach (3 Capabilities)
Source: RIVER Group, enterprise engagement data, 2023-2024
The project model has another problem: the systems don't learn from each other. The claims AI doesn't share insights with the fraud AI. The customer communication tool doesn't benefit from claims processing improvements. Each system is an island.
On a foundation, improvements flow across capabilities. A better document processing model improves claims, fraud, and communication simultaneously. A governance update applies everywhere. A new data source enriches every capability.

Building the Foundation

The foundation isn't a separate project. It's embedded in your first capability. The key is to design the first capability's infrastructure for reuse, not just for the immediate use case.
Practically, this means:
Document processing pipeline: build it to handle multiple document types from the start, not just the ones your first capability needs. The incremental cost of generality is small; the compound value is large.
Knowledge base: structure it with multiple domains in mind. Policy knowledge for claims also serves underwriting and compliance. Customer knowledge serves communication and service.
Integration framework: build connectors that work bidirectionally and support multiple consumers. The CRM integration for claims also serves customer communication.
Governance: design monitoring, logging, and access control for multiple capabilities from the start. Adding governance to an existing system is 5× harder than building it in.
The Foundation Test
After building your first capability, ask: "How long would it take to build a second, different capability on this infrastructure?" If the answer is "nearly as long as the first," you built a project, not a foundation. If the answer is "significantly faster," you're compounding.

The Strategic Implications

For boards: AI investment should be evaluated as a programme, not as individual projects. The ROI of capability #1 is modest. The ROI of capabilities #1-4 on a shared foundation is transformational.
For CIOs/CTOs: The architecture decision between projects and platforms is the single most important technical decision in enterprise AI. It determines whether your AI investment compounds or stays flat.
For operators: Each AI capability should feel more familiar than the last. Same interfaces, same governance, same patterns. If capability #4 feels like learning a new system, something went wrong.
For AI partners: If your AI partner isn't building shared infrastructure, if each engagement starts from scratch, you're building their revenue, not your foundation.
Is it too late to switch from projects to a platform approach?
No. You can retrofit a foundation around existing AI projects. It's more expensive than building it in from the start, but less expensive than continuing the project-by-project approach. The best time to make the switch is before your next capability build.
How much more does the foundation approach cost upfront?
Typically 20-30% more on capability #1. This premium funds the infrastructure that makes capabilities #2-N faster and cheaper. The breakeven point is usually between capabilities #2 and #3. After that, the foundation approach is strictly cheaper.
Does every enterprise need a custom AI foundation?
Every enterprise that plans to build more than one AI capability does. The "foundation" can be simple (a shared data pipeline and knowledge base) or full-scale. Scale it to your ambition.