The Three Forces Framework is defined as follows: the AI startups that build lasting, compounding competitive advantage do so by combining Domain Expertise (the moat that survives the next model release), Clarity (the bottleneck that determines whether speed helps or hurts), and AI-Native Velocity (the multiplier that separates companies operating at Level 4 from those still using AI as a chat tool). When all three align, each sprint produces data that trains better models that deepen the moat - the flywheel becomes self-reinforcing, and a competitor starting today cannot catch up.
We first articulated this framework internally, then refined it through our work as investors and operators. We now apply it in every Tech Due Diligence we run, every AI Transformation Sprint we deliver, and every product we build in our own Venture Studio. The pattern holds with unusual consistency.
What follows is the full framework - not as a checklist, but as a set of interlocking ideas that explain why some AI startups become genuinely hard to compete with and most do not.
Why most AI startups look strong in a pitch and fail in production
AI startup failurepitch vs productionmissing forceAI competitive advantage
There is a fundamental asymmetry in how AI startups are evaluated versus how they actually perform. In a pitch, the AI demo is compelling. The founder is smart. The market is large. The team moved fast from idea to prototype. All of this is real, and none of it predicts whether the company will still be growing in two years.
The 2026 AI landscape is littered with companies that looked exceptional at the pitch stage and stalled in production. The common thread is not a lack of technical capability - it is a missing structural property. They had velocity but not clarity, so they shipped the wrong things fast. Or they had clarity but not domain expertise, so they were commoditised by the next model release. Or they had domain expertise and clarity but were running their team like a pre-AI company, so they were outpaced by leaner competitors who were not.
The failure mode in each case is different. That is why “the team is strong” and “the technology works” are necessary but not sufficient evaluations. You need to know which of the three forces is missing - or whether any of them exist at all.
Force 1: Domain Expertise - the moat that survives the next model release
domain expertisedata moatvertical AIAI startup moatbehavioural moat
The most dangerous question you can ask about an AI startup is this one: if OpenAI, Anthropic, or Google released a vertical product in your exact market tomorrow, what would you have that they do not?
If the answer is “our technology” or “our architecture” or “our prompt engineering”, the company does not have a moat. It has a head start. Those are different things, and the difference becomes visible very quickly.
Domain expertise is the only moat that becomes more valuable, not less, as base model capability improves. It shows up in three forms:
- Data moat. Proprietary training data, interaction logs, or feedback loops that are structurally unavailable to competitors. A platform that has processed ten years of clinical trial outcomes has data that cannot be replicated. A company that has handled millions of transactions in a specific regulated market has compliance and edge-case knowledge that a general model does not.
- Behavioural moat. Deep understanding of how users in a specific domain actually behave - not how they say they behave in a product research call, but how they interact with the product under pressure, under time constraints, with incomplete information. This understanding, embedded in product decisions, creates an interface and workflow that a generalist builder cannot reverse-engineer from the outside.
- Workflow moat. Knowledge of the end-to-end workflow in a specific domain, including the parts that are informal, undocumented, and politically complex. Knowing not just what the process is but why it works the way it does - and which parts of it are genuinely painful and which are painful by tradition - is the kind of knowledge that takes years to acquire and cannot be extracted by a language model scraping the internet.
In our Tech Due Diligences, we assess domain expertise as a specific dimension separate from team quality. A team of brilliant generalists building in a vertical they do not deeply understand is a different risk profile from a team of domain experts who learned to build. The latter consistently outperforms the former when the market matures and competition intensifies.
AI writes the code. It cannot replace knowing your industry. The founders who win in vertical AI are not the best engineers. They are the ones who understand their domain well enough to know what to build and who for, before a single line of code is written.
The best founders we back and work with are domain experts who learned to build, not engineers who learned a domain. The difference in conviction, in customer empathy, and in product instinct is visible from the first conversation.
Force 2: Clarity - the bottleneck that determines whether speed helps or hurts
founder clarityICP definitionFounder's Prompt Biasscope disciplineproduct direction
In the pre-AI era, execution was the bottleneck. Ideas were cheap; the hard part was building the thing. That constraint is gone. A two-person AI-native team can ship a working product in a week. The bottleneck has moved - entirely and permanently - to clarity.
Speed without direction is just failing faster.
Clarity, in this context, is not a vague virtue. It is a specific, measurable property of a founding team. A company has clarity when it can answer three questions without hedging:
- Who, exactly, is the customer? Not a market segment. A specific person, in a specific context, with a specific problem that is painful enough to pay to solve.
- What problem are we solving, and why does solving it matter?Not “we help teams be more productive.” The specific, articulated mechanism by which the product creates value - and the evidence that this mechanism is real.
- What are we explicitly not building? Clarity about scope is as important as clarity about direction. The failure mode of fast-moving AI teams is not slowness; it is zero-friction scope creep. When building costs almost nothing, the discipline to say no becomes the scarcest resource.
We call this discipline “the Founder's Prompt Bias” - the implicit mental models that shape what gets built without ever being made explicit. Most founders carry deep assumptions about who their customer is and what they want. These assumptions are often correct at the seed stage and wrong at the growth stage. The founders who build durable companies make these assumptions explicit, test them continuously, and update them when the data says they should. The ones who do not build fast in the wrong direction and wonder why growth stalls despite strong execution.
In a Tech Due Diligence, we look for two specific signals of clarity. The first is whether the team can describe their ICP in one sentence without qualifiers. The second is whether their product roadmap is driven by evidence from that ICP or by the founder's intuition about what is interesting to build. Both matter. The combination is rare.
The practical consequence is that clarity is now the primary investment a founder can make before writing any code. Customer discovery, hypothesis sharpening, and ICP definition are not soft activities that happen before “real work.” In an AI-native context, they are the highest-leverage engineering work you will do, because everything that follows is cheaper and faster than it has ever been - and the cost of building the wrong thing is therefore higher relative to building the right thing.
Force 3: AI-Native Velocity - the multiplier that compounds
AI-Native VelocityLevel 4 AI MaturityAgent PodsCompany BrainAI agent playbook
The third force is what separates companies that move quickly from companies that move at a structurally different speed. AI-Native Velocity is not about using AI tools. It is about how the organisation itself is designed - whether AI agents are incidental additions to an existing workflow or foundational components of how the company operates.
We assess this using the same four-level framework we apply in every Tech Due Diligence. Most companies we see are at Level 2: they use AI tools unevenly, without a shared playbook, without measurement, and without agents operating autonomously in production. Roughly 60% of companies we assessed in 2025 sit here.
Level 4 companies - where AI agents are first-class members of the organisation, with defined roles, escalation paths, and a persistent knowledge layer that every agent queries at runtime - operate at a 5.7× revenue-per-employee advantage over comparable companies at Level 2. The gap is not incremental. It is exponential. And it compounds every week, because agents at Level 4 are improving continuously through automated feedback loops, not just being used to do individual tasks faster.
What Level 4 actually looks like in practice:
- A shared AI Agent Playbook, versioned in git, that every engineer follows - not individual tool preferences left to personal discretion
- A Company Brain: a persistent knowledge layer that every agent queries at the start of every session, so context does not need to be reconstructed each time
- Agent Pods organised by business function - a Dev Pod, a Product Pod, a GTM Pod - each with defined responsibilities, escalation paths, and performance criteria
- Full observability over every agent run via tools like Langfuse: traces, latency, cost, and quality scores, so the team can improve agent behaviour the same way they would debug production code
- Autonomous execution: agents running on schedule without being prompted, handling recurring work end-to-end while humans focus on judgment and strategy
The gap between Level 2 and Level 4 is not a tools gap. Every company has access to the same models. The gap is architectural. It is the decision to build the infrastructure - the Company Brain, the Playbook, the Pods - that allows AI to compound rather than plateau.
Tools plateau. Agents compound. A Level 4 team does not just use AI to go faster. It builds a system that gets smarter every week, regardless of whether any human is paying attention to it.
When all three align: the compounding flywheel
AI flywheelcompounding competitive advantageself-reinforcing moatAI-native operations
The reason the Three Forces framework is useful - rather than just a list of good things to have - is that the forces are not independent. They interact. When all three are present, they create a flywheel that is structurally self-reinforcing.
Domain expertise determines what to build. Clarity determines what to build now, and what to leave for later. AI-Native Velocity determines how fast the right things get built and improved. But the compounding happens in the feedback loops between them.
A company with genuine domain expertise builds with clarity about what their customers actually need, not what looks impressive. That clarity produces a product that generates high-quality interaction data, because it is solving the right problem for the right people. That data, fed back into the Company Brain and the agent feedback loops, improves the agents' performance on the exact tasks that matter to that customer segment. Which deepens the behavioural moat. Which widens the domain advantage.
A competitor starting today does not just face a better product. They face a system that is actively compounding, with a data moat they cannot replicate, a workflow moat they cannot reverse-engineer, and an AI-native infrastructure that is already months ahead of theirs. The flywheel, once turning, requires a structural advantage to stop - not just better execution.
The Three Forces at a glance
Three Forces FrameworkAI startup evaluationdomain expertise clarity velocity
| Force | What it is | Moat type | Missing = |
|---|
| Domain Expertise | Proprietary knowledge that survives the next model release | Data moat, behavioural moat, workflow moat | Commoditisation risk |
| Clarity | Precise definition of who you build for and why | ICP focus, scope discipline, Founder's Prompt Bias awareness | Fast failure in the wrong direction |
| AI-Native Velocity | Organisational design that lets AI compound rather than plateau | Agent Pods, Company Brain, shared Playbook | Ground lost every quarter to leaner competitors |
What happens when one force is missing
AI wrapper riskcommoditisationfast failurescope creepAI laggards
The diagnostic value of the framework is clearest when you look at what happens when each force is absent.
Missing domain expertise: commoditisation risk.A company with clarity and AI-native velocity but no deep domain expertise is building something that a better-funded competitor with domain knowledge can replicate. Worse, it is building something that the base models themselves will catch up to. We see this most often in “AI wrapper” companies - products that take a general capability from an LLM provider and add a thin interface. When the next model release includes that capability natively, the wrapper has no residual value.
Missing clarity: fast failure. A company with domain expertise and AI-native velocity but no clarity moves very fast in multiple directions simultaneously. The product grows in features but not in coherence. Customer acquisition costs rise because the ICP is unclear. Retention suffers because different customer segments need different things and the product tries to serve all of them. Every sprint produces output, but the output does not accumulate into a compounding position. We see this in technically excellent teams who cannot explain their product to a non-technical customer in a single sentence.
Missing AI-native velocity: ground lost every quarter. A company with domain expertise and clarity but no AI-native velocity is, in most markets, losing ground every quarter to competitors who have all three. Their release cadence is slower. Their cost per feature shipped is higher. Their ability to run product experiments is constrained by engineering capacity in a way that their competitors are not. The gap widens regardless of how good their domain knowledge is or how clear their strategy is, because execution speed has become a structural component of competitive advantage.
What we look for in Tech DD and Venture Studio work
tech due diligenceAI maturity assessmentinvestor scorecardDD signals
In every Tech Due Diligence we run, we now score all three forces explicitly. The questions we ask and the signals we look for:
Domain Expertise:
- Can the founder describe a customer problem that is invisible to anyone without direct experience in this domain?
- Does the product contain decisions that only make sense if you deeply understand how this specific industry works?
- Does the company own proprietary data, interaction logs, or feedback that a competitor could not acquire by hiring engineers?
- What happens to the company's competitive position if the next major model release includes native capability in this area?
Clarity:
- Can the founder describe the ICP in one sentence, without qualifiers, and have the product team confirm that description without hesitation?
- What was the last significant thing the team decided not to build, and why?
- Is the roadmap driven by evidence from customer conversations, or by the founder's intuition about what is technically interesting?
- How does the team handle scope pressure from customers who want features outside the core use case?
AI-Native Velocity:
- Does the team have a shared AI Agent Playbook, versioned and followed by everyone, or is AI tool usage left to individual discretion?
- Are there agents running in production autonomously, not pilots, not experiments, but live systems handling real work without human initiation?
- Does the team have a Company Brain - a persistent knowledge layer that agents query at runtime?
- Can the team measure AI impact in numbers, not feelings? If they cannot, they are almost certainly at Level 2 or below.
A company that scores well on all three is a different risk profile from one that scores well on two. The third missing force is not a minor weakness - it is the constraint that limits everything else.
The window is still open, but it is closing
AI leaders vs laggardsPwC 7.2×McKinsey 74%AI competitive window
The Three Forces are not static. They are time-sensitive.
Domain expertise, by definition, takes time and lived experience to build. You cannot accelerate it by hiring more engineers. The founders who have it today have often spent years in the industry before building their company - which means the next cohort of domain-expert founders is already forming.
Clarity is a decision, and decisions can be made quickly. But the cost of not having clarity compounds over time. Every sprint without clear ICP definition builds features that will need to be removed or ignored later.
AI-Native Velocity has a specific characteristic that makes it particularly time-sensitive: it compounds. A company that builds the infrastructure for Level 4 operations today - the Company Brain, the Agent Playbook, the observability layer - is not just moving faster today. It is building a system that will be measurably smarter in six months, and dramatically smarter in two years. A competitor starting that journey six months later does not just start behind. They start behind a target that is actively moving away from them.
PwC research puts the revenue differential between AI leaders and laggards at 7.2×. McKinsey data shows 74% of AI-era value will be captured by 20% of companies. In our own portfolio and DD work, we see the same concentration beginning to emerge. The window to join that 20% is real, and it is not permanently open.
How we apply this framework
Three Forces diagnosticAI Transformation SprintAI Venture Studiofractional CTO
We use the Three Forces Framework in three contexts: as an evaluation lens in Tech Due Diligences, as a design framework for companies in our AI Venture Studio, and as a diagnostic for AI Transformation engagements where a company is strong on one or two forces but missing the third.
For the AI Maturity dimension specifically - how to assess and improve AI-Native Velocity - we have published a detailed framework in The 4 Levels of AI Maturity We See in Every Tech Due Diligence. For the clarity and customer discovery process - how to develop and maintain Force 2 under the conditions of AI-enabled speed - the full methodology is in The AI-Native Startup Playbook. For the full Tech DD methodology - how we structure assessments, what we score, and what we look for beyond the Three Forces - the complete framework is in The Tech Due Diligence Manifesto.
If you are an investor evaluating an AI startup, the Three Forces are a more predictive frame than team quality alone or technology sophistication alone. If you are a founder, they are a diagnostic: which of the three forces is your constraint right now, and what would it take to strengthen it?
We start every engagement - whether a Tech DD, a Venture Studio sprint, or an AI Transformation - with this diagnostic. It rarely takes more than two conversations to know which force is the bottleneck. The answer shapes everything that follows.
Frequently asked questions
AI startup FAQThree Forces FAQdomain expertise AIAI-Native Velocity
What is the Three Forces Framework?+
The Three Forces Framework is a strategic model for evaluating AI startups, defined as the combination of Domain Expertise (the proprietary moat that survives model releases), Clarity (the ability to define precisely who you are building for and why), and AI-Native Velocity (the organisational design that allows AI to compound rather than plateau). When all three are present, they create a self-reinforcing flywheel. Missing any one of them makes the other two insufficient.
What is the most important of the Three Forces?+
No single force is more important - they are interdependent. Domain Expertise without Clarity produces a company moving fast in the wrong direction. Clarity without AI-Native Velocity loses ground every quarter. AI-Native Velocity without Domain Expertise gets commoditised when the next model ships. The constraint that matters most in any given company is whichever force is weakest.
What is AI-Native Velocity?+
AI-Native Velocity is the degree to which an organisation's structure - its workflows, agent architecture, knowledge layer, and shared playbook - is designed to let AI compound rather than just accelerate individual tasks. Companies at Level 4 AI Maturity, with Agent Pods, a Company Brain, and a versioned AI Playbook, operate at a 5.7x revenue-per-employee advantage over comparable Level 2 companies. The gap is architectural, not a matter of which tools the team uses.
What is the Founder's Prompt Bias?+
The Founder's Prompt Bias describes the implicit mental models founders carry about who their customer is and what they want - models that shape what gets built without ever being made explicit. It is Force 2 (Clarity) applied to the founding team: the failure to examine and continuously test the assumptions behind the product direction. Founders who surface and challenge these assumptions consistently outperform those who do not, particularly as the company scales past its original ICP.
How do you assess the Three Forces in a Tech Due Diligence?+
We score all three forces explicitly in every Tech Due Diligence. For Domain Expertise: can the founder articulate a problem invisible to non-domain experts, and does the company own proprietary data or feedback loops? For Clarity: can the ICP be described in one sentence with no qualifiers? For AI-Native Velocity: are agents running autonomously in production - not pilots, live systems - and can the team measure AI impact in numbers rather than feelings? The full assessment methodology is documented in The Tech Due Diligence Manifesto.
Above The Clouds runs Tech Due Diligences and AI Transformation Sprints across Europe. We score Domain Expertise, Clarity, and AI-Native Velocity as a core part of every engagement. Get in touch to discuss your company or portfolio.