In the fall of 2021, I spent three months talking to engineering teams at fifty companies building on top of language models and other ML systems. I asked each of them the same question: what breaks first when you try to take something from experiment to production? The answers were remarkably consistent. Not the model. The infrastructure around it.
Feature pipelines that work in notebooks and fail at two in the morning. Vector similarity search that's fast enough in a demo and collapses under real query load. Model serving frameworks that require a platform team to operate. Workflow orchestration that treats failure as an exception rather than the default. These are infrastructure problems, and they are largely unsolved at Seed stage, where the companies that will eventually define the AI application stack are being founded right now.
The model is not the moat
There is a tendency in the current moment to treat the foundation model as the durable value in an AI system. This is wrong, and it will become more obviously wrong over the next several years. Foundation models are being commoditized faster than almost anyone in the industry anticipated. The value in an AI application is not the model choice — it's everything that runs around it: the data quality, the retrieval architecture, the feature freshness, the serving latency, the observability surface.
If you've spent time building real production ML systems, this is obvious. The 18 months of engineering work that go into deploying a model reliably — the data pipelines, the feature stores, the A/B testing infrastructure, the monitoring — that's where the work is. The model selection is a three-hour decision.
Four specific gaps
Based on my conversations, four infrastructure gaps appear repeatedly in teams building AI applications at anything above toy scale:
Context retrieval at production latency. Language models need context to be useful. Retrieval-augmented generation is a promising pattern, but the retrieval layer — embedding storage, similarity search, filtering — is not production-grade for most teams. The tools that exist are research-grade or enterprise-priced. There's a missing middle: open-source, developer-friendly, performant at billions of vectors.
Feature freshness. The features a model was trained on are often different from the features it sees at serving time. This training-serving skew is a first-class failure mode for production ML systems and virtually every team building at scale has encountered it. Feature stores exist, but they're predominantly either hand-rolled infrastructure or expensive enterprise products. A developer-native feature platform is missing.
Observable, recoverable pipelines. Data and ML pipelines fail. The question isn't whether they'll fail but whether the failure is visible and recoverable. Most orchestration tools treat failure as an edge case. The right design treats failure as the default and builds observability and recovery as core primitives.
Analytical queries everywhere. AI applications generate data. They also consume data. The ability to run complex analytical queries against local or remote data — without spinning up a cluster, without waiting for a data warehouse job — is a missing primitive. Processing power has outpaced the client-server database model for many workloads.
Why Seed is the right entry point
The companies solving these problems are being founded now. They're open-source projects with small communities, a handful of GitHub stars, and a handful of production deployments. They don't have revenue models yet. Most institutional investors won't touch them for another eighteen months.
That is precisely when the investment is most valuable and most difficult. It requires technical conviction — the ability to evaluate architecture, API design, community trajectory, and ecosystem fit before the market has formed an opinion. It requires operator judgment: understanding what it actually takes to run these systems in production, because the founders are often building them for the first time and will make architectural decisions that are very hard to undo.
This is what Flintrock Capital was built to do. We are not waiting for traction metrics. We are evaluating technical architecture and writing checks before others will.