Speak to the average employee of a frontier AI lab and they’ll tell you: “the AI application layer is toast”. Listen to the average Fortune 500 CEO and you’ll hear: “we’re building as much as possible in-house – why would I buy software?”
There are complex incentives driving both narratives and both underestimate the need for specialist AI solutions. But the fact remains that every AI startup now faces the same question from investors and customers: how defensible are you?
The defensible space for AI startups is tasks that frontier labs can’t solve and that end-users can’t configure their way to. Here’s a framework for figuring out whether that’s the space in which you’re building.
AI startups are being squeezed from two sides
All economically valuable tasks that AI could automate
Frontier labs: Every major model release automates tasks that previously required a product to be built around them. Marketing copy creation, code generation, document analysis – these and other use cases have seen a number of recent startups rise to fame, only to be made redundant a few months later.
End-user configuration: Enterprises are increasingly building their own internal tools on top of frontier models, using products like Claude Code or agent builders. A competent internal team can now wire up a model to internal data and ship workflow-specific software surprisingly quickly.
If either side can reach your product’s value, you are running on borrowed time.
What needs to be true for AI to automate a given task?
AI models have made enormous leaps in well-defined problem areas, but the majority of economically valuable tasks are not part of the training data set. All players – frontier models, enterprises and AI startups – are sprinting to close the gap.
Here’s how:
Every task AI performs – whether it’s processing an invoice or advising on a drug development programme – requires four things:
Four things that need to be true for AI to automate a given task.
Knowledge: Does the AI know what to do and how to do it? This covers both the structure of the work (what are the steps, how is the task scoped) and the domain expertise required to execute it (what rules apply, what constraints matter, what does an experienced practitioner know that’s never been written down).
Data: Can the AI reliably access the right data for the task, from various systems and tables in the organisation? And does it have the data context to understand what this data means and how to disambiguate inconsistencies?
Evaluation: Does the AI know what good looks like? And is there a feedback mechanism in place that measures performance and enables the AI to get better over time?
Action: Can the AI take actions in the organisation’s tools and systems? And is it allowed to?
Any solution must achieve all four to automate a task. Depending on the task, that requires more or less specialisation.
The tasks only specialist AI solutions can automate
Using this framework, we built a simple matrix to assess an AI startup’s technical defensibility.
Founders should only pursue problem spaces where neither frontier labs nor self-built solutions can achieve the four requirements – Knowledge, Data, Evaluation and Action.
A simple matrix to assess an AI startup’s technical defensibility.
Knowledge
Focus on tacit knowledge that experts can’t easily break down and that doesn’t exist in documents.
Frontier lab solves it: If the task relies on published knowledge and general reasoning, training data covers it. “Build me a marketing plan” works out of the box because the model has ingested thousands of marketing plans.
End-user configures it: Company-specific workflows can easily be defined through prompts and agent builders, but only if the expertise is written down. Well-defined pricing policies, brand guidelines, product specs and standard operating procedures can be fed in by customers themselves.
Specialist needed: Tasks that rely on tacit knowledge that experts can’t easily break down and that doesn’t exist in documents. To go from tacit knowledge to a structured environment for an AI agent to operate in requires decomposing expert behaviour into discrete tasks, defining what information the AI needs at each step, designing how the system handles uncertainty and failure, and building the feedback loops that let it improve. Frontier labs can’t do this for every conceivable problem space, and domain experts don’t have the product skills to do so themselves. The process has to be reverse-engineered by startups who understand both the domain and the technology.
Defensibility test: Is the domain knowledge needed for your AI on the web? Do your end-users have well-defined SOPs, or does structuring the work require a mixture of domain expertise and product thinking they don’t have?
Data
Focus on data that cannot be shared with frontier models or that is generated by your own product.
Frontier lab solves it: Tasks that rely on synthesising public data – e.g. pulling insights from PubMed – and tasks where raw access to internal data without a formal context layer is “good enough”, for example because error tolerance is high enough that imperfect understanding doesn’t matter.
End-user configures it: Most organisations have a limited semantic layer (containing definitions like “when we say ‘active user’ we mean someone who logged in within 30 days”) that are used by human data teams to field business queries. Some simple tasks can be automated in-house with AI using that semantic layer. There is an opportunity here to help businesses build a deep, dynamically updating context layer for the 99% of data that isn’t treated by today’s semantic layers – solving this will expand the addressable problem space for in-house solutions.
Specialist needed: But some data simply cannot be shared with frontier models – whether because it contains IP, because of regulation or because it is multi-party data. More importantly, in many high-value problem areas, the information AI needs to make good decisions has never been recorded. How long does each step in a capital project actually take versus plan? What evidence did a drug development team consult when making a go/no-go decision? This data emerges only when the specialist builds the product that creates it. The workflow is the data collection mechanism.
Defensibility test: Is your data advantage based on customers choosing to share hyper-sensitive data with you? Does your product generate new data that didn’t exist before?
Evaluation
Focus on judgment-based tasks where “good” is contested and feedback takes years.
Frontier lab solves it: If the task success definition is the same for every competitor in a given problem space, frontier models can build RLHF eval cycles for it. Financial modelling doesn’t differ enough from company to company to require specialist solutions.
End-user configures it: For tasks with company-specific success definitions, if the task is routine, then most knowledge workers can define what they want well enough to evaluate straightforward outputs and set up basic feedback. Did the invoice match the purchase order? Yes/no. Does the email draft contain the key action points mentioned in the call transcript? Yes/no. Etc.
Specialist needed: Tasks that are non-routine and judgement-based are harder to evaluate. What does optimal look like for complex resource optimisation or investment selection? End-users often can’t easily define these criteria because they are contested and/or have very long feedback cycles. Specialists with access to cross-industry benchmarks and multi-year experience are at an advantage.
Defensibility test: Is it difficult to define “success” for your problem domain? Does your problem domain have long feedback cycles?
Action
Focus on high-stakes workflows in regulated environments where compliance won’t approve an in-house build.
Frontier lab solves it: Tasks that can be executed through general tool use via MCP, where the end-user has authority to delegate those tasks. “Draft a follow-up email to everyone I spoke to today.”
End-user configures it: Tasks that are executed in internal tools, access to which is governed centrally.
Specialist needed: Tasks where compliance would not be comfortable with an in-house build, due to governance, traceability, reversibility, near-zero error tolerance, regulatory constraints and/or a preference for outsourcing risk. Tasks that require deep integrations into legacy or proprietary systems where the API doesn’t exist.
Defensibility test: Does your product focus on high-stakes workflows in regulated environments? Does your product rely on deep integrations with legacy or proprietary software?
So what?
This framework covers one axis of defensibility: whether the task itself requires a specialist or whether frontier labs and end-user configuration will get there first.
It doesn’t address whether a given specialist solution is defensible against direct competitors. Network effects, switching costs, data flywheels – these still matter enormously. But they’re table stakes. The new question is whether you’re solving a problem that only a specialist can solve. That’s what we’ve tried to address here.
Our bet is that there is a large, valuable space between “the squeeze” from frontier labs and customers.
Map your product against all four requirements. Does your startup…
- Structure tacit knowledge into AI-ready environments
- Work with data that can’t be shared with frontier models, or generate proprietary data through the product itself
- Build evaluation infrastructure for judgement-based tasks, and
- Earn the right to act in high-stakes, regulated settings?
If you are in the specialist zone on more than two, we’d love to hear from you.
