How we think about the stack
Notes on enterprise AI infrastructure, developer primitives, and what we're watching.
Recent Writing
Three pieces
The missing primitives: why most enterprise AI projects stall at the plumbing
The pattern we keep seeing: an enterprise team runs a proof-of-concept with an LLM integration. It works in the demo. They try to ship it to production. It falls apart at the data layer.
This isn't a model problem. The models are good. The problem is that the infrastructure layer around the models — the plumbing that gets data to the model, routes the output to the right place, handles failures gracefully, and produces a record of what happened — was never designed for AI workloads.
The three gaps we see most often
Orchestration. AI workflows are not stateless. A customer-service AI that escalates to a human mid-conversation, waits for the human's response, and then resumes requires durable state management. Most teams try to implement this on top of Lambda functions and SQS queues and spend months debugging race conditions. The right primitive is a step-function engine that treats AI-in-the-loop workflows as first-class citizens.
Data plumbing. The most useful AI applications are the ones with access to real-time, accurate, contextualized data. But most enterprise data is in Postgres, behind a REST API that was designed for a different purpose, or in a data warehouse that's 24 hours stale. Change-data-capture, streaming pipelines, and semantic caching are the infrastructure that turns the data layer into something AI can work with in real time.
Observability. When an AI-powered workflow produces the wrong output, how do you debug it? The tooling that exists for traditional software — APM dashboards, log aggregation, distributed tracing — was not designed for probabilistic systems. You need something that records the prompt, the model parameters, the output, and the downstream effect — and surfaces patterns across thousands of calls. This is a new category.
Why this creates a durable investment opportunity
Infrastructure primitives are sticky. Once an engineering team builds their orchestration layer on a particular tool, the cost of migrating is proportional to the amount of workflow logic they've encoded into it. The companies that solve this layer correctly — not as a feature of a broader platform, but as the focused primitive — will be extremely hard to dislodge as the ecosystem matures.
We backed Inngest and Portkey.ai because we believe orchestration and observability are the two most underdeveloped layers in the enterprise AI stack. Both companies are building the primitive, not the application on top of it. That's where we want to be.
CDC as competitive advantage: what Sequin taught us about data infrastructure bets
When we first looked at Sequin, the honest reaction from two of our three partners was: "is this a big enough problem?" Change-data-capture — the technical approach of capturing every database mutation and streaming it to downstream consumers — is a solved problem in large enterprise contexts. Debezium exists. Kafka exists. The tooling is mature.
The case for Sequin wasn't that CDC hadn't been done. It was that CDC hadn't been made accessible to the companies that needed it most: smaller engineering teams building AI-native products on Postgres who couldn't staff the Kafka deployment, couldn't afford the operational overhead, and were trying to get real-time data into their AI pipelines without building a second full-time infrastructure role.
The distribution gap in infrastructure
There's a consistent pattern in developer infrastructure: a technology gets validated at the hyperscaler level, proves its value, and then sits inaccessible to the next tier of companies for five to ten years because the implementation complexity requires a team that only exists at hyperscaler or large-scale web platform scale.
Postgres WAL-based CDC is a version of this pattern. The technology works. The problem is that deploying it requires understanding PostgreSQL internals, configuring replication slots, managing backpressure, and handling schema migrations in the change stream — work that is tractable for a senior platform engineer but brutal for a team of five trying to ship a product.
Sequin wraps all of this into an API-first, Postgres-native interface that strips out the complexity while keeping the correctness guarantees. That's not a new technology — it's a distribution innovation on top of a proven technology. Those bets are often more durable than pure technology bets, because the distribution gap is structural, not temporary.
Why the data stream is the application layer
Here's the thesis that drove our conviction on Sequin: the company that owns the change stream owns the application layer. If your CDC tool is the first thing that sees every database mutation — before it goes to search, before it goes to the AI pipeline, before it goes to the event queue — you're in a position to add value at every one of those routing decisions.
That's data gravity. As the routing logic compounds over time, the cost of migrating away grows. The CDC layer becomes more central, not less, as the data architecture matures. That's the kind of moat that matters in infrastructure.
Seed-stage AI: why we lead when it doesn't look fundable yet
There's a common piece of fundraising advice that circulates in investor communities: "wait for the signal." Wait for revenue traction. Wait for a lead customer. Wait for the market to validate the category. Then write the check.
We think this advice is correct for most investors and wrong for us.
The window we operate in is narrow. It exists between "too early for market proof" — the point at which a company has a product but not enough customers to validate the thesis — and "too late for our check size" — the point at which the Series A is priced at $20M+ and the round is ten times oversubscribed. That window is typically 12–18 months. Most institutional investors miss it by waiting.
What conviction looks like before signal
We've written pre-signal checks six times in the last three years. In each case, the conviction didn't come from the metrics — it came from the founder's specific understanding of a specific problem.
When we backed Portkey.ai, the LLM observability category had one or two other entrants and no clear winner. The metrics were early-stage by definition. But the founding team had spent a year trying to instrument their previous product's LLM calls, knew in precise detail what the tooling should look like, and had a point of view about the right architecture that was different from anyone else in the space.
That founder-category fit — the signal that the people building this thing have felt the problem in their bones, not researched their way into it — is higher-fidelity information than a revenue chart at the Seed stage. A revenue chart tells you the market exists. The founder's depth of knowledge tells you this team can build the right solution for it.
The cost of waiting
Infrastructure categories typically produce one or two dominant players. The window in which a new fund can lead at reasonable valuation is short. The funds that wait for signal end up either missing the category entirely or paying Series A prices for a Seed-stage position.
Our fund sizes are calibrated for this: small enough to lead early at check sizes that matter to the company, large enough to maintain meaningful ownership through a follow-on. That mandate is only coherent if we're willing to write the first check before the market agrees with us. We are. That's the job.