I want to start with a sentence I’ve been saying in investment committee meetings a lot lately: being an AI company is not a thesis. It’s a description. And there’s a meaningful difference between the two. The number of founders currently describing themselves as AI companies is roughly equal to the number of founders who described themselves as cloud companies in 2010 or mobile companies in 2012. Most of those companies weren’t cloud businesses they were businesses that used cloud infrastructure. The distinction sounds pedantic until you’re the investor who backed the wrong one.

The question I’m asking of every AI startup I see right now isn’t “are you using AI?” everyone is. The question is: what would break if you took the AI out? If the answer is “not much,” you probably have an AI feature, not an AI business. And AI features, however impressive they look in a demo, are not venture-backable at meaningful valuations. Here’s what is.

The central failure: feature mistaken for business

The most common pattern I see in AI startups that don’t deserve the capital they’re raising is what I’ve started calling the feature-to-business confusion. The company has identified something genuinely useful that AI can do summarize contracts, draft emails, analyze images, answer customer questions. They’ve wrapped it in a product. They have early users. The demo is clean. And they have absolutely no clarity on how this becomes a durable business rather than a capability that a larger platform ships as a toggle in six months.

The path from AI feature to AI business requires answering a question that most founders are actively avoiding: why can’t the person who currently does this job, or the platform currently used to do it, simply add this capability and make my company irrelevant? If you can’t answer that question with specificity not “we’ll have more data” or “we’ll move faster,” but a concrete, defensible reason why your position compounds rather than commoditizes you haven’t built a business yet. You’ve built a proof of concept for someone else’s roadmap.

I see this most acutely in horizontal AI tools. An AI writing assistant, an AI research tool, an AI scheduling product these are valuable to users. They’re also exactly the kind of features that Microsoft, Google, Notion, and Salesforce ship as quarterly updates. The companies that survive and compound in this space aren’t the ones with the best model they’re the ones that built something structural underneath the model that couldn’t be replicated in a product update. Usually, that structural thing is one or more of the five things I’m about to describe.

What one: vertical domain depth not AI expertise, workflow expertise

The AI companies I’m most excited about in 2026 are not the ones that know AI best. They’re the ones that know a specific workflow, in a specific industry, at a level of depth that no general-purpose AI company has or will develop anytime soon. The difference is subtle but consequential.

A founder who has spent ten years as a radiologist before building an AI diagnostic tool doesn’t just know what the model should output they know which errors are catastrophic versus correctable, which edge cases occur in a real clinical setting that never appear in training data, which compliance requirements govern how output can be used, and which part of the radiologist’s workflow is the actual bottleneck. That knowledge doesn’t live in a paper. It doesn’t live in a dataset. It lives in the person who lived it. And it’s the reason their model makes different and better decisions than a general-purpose model applied to the same problem by a team that learned about radiology last year.

Vertical domain depth creates defensibility not primarily through IP but through decision quality. A model trained with the right data, tuned by people who understand the domain deeply, producing outputs that practitioners actually trust that’s a different product than a capable model pointed at a new vertical. The gap between them is months of compounding domain learning that can’t be shortcut. When I’m evaluating an AI startup, one of the first things I ask is: does this team know the workflow they’re automating at the level of someone who’s done it, not just studied it? The answer to that question tells me more about the company’s ceiling than almost anything in the deck.

What two: team composition the pairing that actually works

There’s a team composition pattern that shows up consistently in the AI companies I’ve watched succeed, and it’s not what most people expect. It isn’t two AI researchers who figured out a domain problem. It isn’t a domain expert who learned to prompt well. It’s a genuine partnership between someone who understands the technology at a level that allows real architectural decisions, and someone who understands the domain at a level that allows the technology to be pointed at the right problems.

The reason this pairing matters so much is that the failure modes of each half alone are significant. An AI engineer without domain depth builds impressive capability that solves the wrong problem or solves the right problem in a way that practitioners can’t trust or deploy in their actual environment. A domain expert without real AI depth becomes dependent on third-party models in ways that limit the company’s ability to differentiate on anything technical. Together, the pairing creates something genuinely hard to replicate: a team that knows exactly what needs to be built and has the capability to build it at a level that generic approaches can’t match.

I’ve also learned to pay attention to how the two halves of this pairing actually work together not just whether they exist on the cap table. The best partnerships have a shared language that developed before the company did, usually from prior work together or from a shared experience in the problem domain. The ones that struggle often have a dynamic where one side is translating for the other, rather than genuinely co-creating. That translation overhead shows up eventually in product decisions, in hiring choices, in how the company communicates with customers. It’s visible if you look for it.

What three: proprietary data the moat that actually holds

I’ll say something that might be obvious but that I think founders underestimate as a strategic priority: data is the one moat in AI that the largest players cannot easily buy or build. Compute, they have. Model capability, they have. Distribution, they have. But the specific, structured, high-quality dataset that captures a particular workflow, in a particular domain, labeled and curated by people who understand what the labels mean that they don’t have. And getting it requires either years of deployment or a relationship with the source that isn’t available to a general-purpose platform.

What I look for isn’t just “we have data” that’s too generic to be useful. I look for companies that have a flywheel: deploying the model generates interactions, interactions generate feedback, feedback improves the model, a better model attracts more users, more users generate more interactions. Each turn of that flywheel increases the gap between this company’s model and anything a competitor could build from publicly available data. That flywheel is a real moat. A static dataset, however large, is not because a sufficiently resourced competitor can eventually acquire or generate comparable static data.

The related question I always ask: who owns the relationship with the data source? A company that has exclusive data partnerships, or that has built deep integrations with the systems that generate the data, or whose product is the system that generates the data, is in a structurally different position than a company that accessed data through a one-time licensing agreement. Exclusivity and depth of access matter as much as volume.

What four: distribution and go-to-market built in not bolted on

The AI company failure I see almost as often as the feature-to-business confusion is the distribution failure: a genuinely impressive AI product that has no clear, defensible path to the customers it needs. The founders built something real. They just haven’t figured out or in some cases haven’t seriously thought about how they’re going to sell it at scale, to whom, through what channel, with what sales motion, at what price point.

Distribution in AI isn’t just sales and marketing. It’s structural. The companies I back have distribution built into the product architecture, not planned for after product-market fit. That might mean a bottoms-up motion where the product is free to use and pays for itself through team adoption. It might mean a partnerships channel where the go-to-market is embedded in the workflow of a distribution partner who already has the customer relationship. It might mean a founder who has spent twenty years in the target industry and has the trust and access to land the first hundred enterprise customers without a traditional sales organization. The form varies. What doesn’t vary is that the distribution advantage is specific, defensible, and available to this team in a way that isn’t equally available to every other team building in the same space.

One of the clearest signals I’ve learned to read in AI pitches: founders who treat go-to-market as a problem to be solved after the next funding round. If the plan is “build the product, find PMF, then figure out how to sell it at scale,” the company is probably eighteen months away from discovering that the sales motion they imagined doesn’t work for the customer they built for. Distribution is not a downstream problem. It’s a design constraint that should be shaping product decisions from day one.

What five: genuine AI IP owning something technical, not renting it

I want to be precise about this one, because the conversation about AI IP gets muddled quickly. I am not saying a company needs to have trained its own foundation model to be venture-backable. The era of every AI startup needing its own LLM is over, and founders who are still building that way unless they have a very specific reason are making an expensive mistake. Foundation models are infrastructure. You don’t build your own cloud.

What I am saying is that there needs to be something technically defensible in the stack that isn’t just “we call the OpenAI API.” That might be a fine-tuned model trained on proprietary domain data that performs meaningfully better on the specific task than any general-purpose model. It might be a novel architecture for multi-agent coordination that solves a problem general-purpose orchestration frameworks don’t handle well. It might be a proprietary inference optimization that reduces latency or cost in a way that matters for the use case. It might be a training pipeline that converts domain feedback into model improvement faster than anything available off-the-shelf.

The test I apply: if OpenAI or Anthropic released a new model tomorrow that was 30% more capable, would it make this company more valuable or less valuable? If the answer is “less valuable” because the company’s positioning depends on a capability gap that a better foundation model closes that’s a problem. If the answer is “more valuable” because better foundation models are raw material that this company knows how to use better than anyone else, on top of a differentiated stack that’s a company worth looking at.

How these five things fit together

I want to be honest: I’ve never backed an AI company that had all five of these things perfectly in place at the seed stage. That would be asking for a fully formed business to exist before a business has been built. What I look for is a team that has a genuine answer on three or four of them, a clear-eyed understanding of where the gaps are, and a plausible roadmap for closing them with the capital they’re raising.

The combination I find most compelling: vertical domain depth plus the right team composition, with a data flywheel starting to turn and a go-to-market motion that’s already generating signal. That combination tells me the company is building something structural not just something that works in a demo. The IP and the technical defensibility often follow from that foundation, rather than preceding it.

What I won’t back, regardless of how good the demo is, is a company that can’t answer the question I started with: what would break if you took the AI out? Because if the AI is the whole thing if the product is the model and the model isn’t theirs and the workflow isn’t theirs and the customers don’t have any particular reason to stay then what you have is a proof of concept for the category, not a company. Proofs of concept don’t compound. Companies do.

The question to ask yourself before you pitch

If you’re an AI founder preparing to raise, I’d ask you to sit with five questions before you walk into a room with someone like me.

Can you describe your company without the word “AI” in a way that makes it sound interesting? If not, you may be leaning on the category to do work that the business itself should be doing.

What would a major foundation model release change about your competitive position? If the honest answer is “a lot,” that’s important to understand before an investor surfaces it in diligence.

Does your team include someone who has genuinely lived in the domain you’re disrupting not just studied it, but made decisions in it, felt the consequences of those decisions, and built relationships with the people whose workflow you’re changing? If not, what’s your plan for getting that depth?

Where does your data come from, who else has access to it, and what happens to your model quality if that access changes? If the data source is publicly available or easily replicated, that’s a risk worth surfacing honestly rather than hoping an investor doesn’t ask.

And finally: do you have a distribution path that’s specific to your team and your relationships or is your go-to-market “we’ll hire a sales team when we raise”? The former is a thesis. The latter is a hope.

The founders who can walk through all five of those questions clearly, honestly, and without deflecting even when the answers aren’t perfect are the ones I want to back. Not because they’ve solved everything. Because they understand their own business well enough to build it. That’s rarer than it should be, and it’s exactly the thing no amount of AI can substitute for.