Coding agents have given every executive the same dream: custom software. Why buy a ten-year-old out-of-the-box application when your teams can build their own, designed specifically for your business?

But for business software of any scale or consequence, vibe coding from scratch is doomed for failure.

We see the future of enterprise software as the rise of the AI-native primitives: domain-specific building blocks, from data models to workflow engines to UI components, that can be composed into production-grade applications. 

Two years ago, we wrote about Composable Software: platforms and infrastructure for customers to design, implement, and modify their own workflow software. We continue to believe in this vision, and now think the opportunity is even broader: these primitives can be used by agents to build software for customers at unprecedented scale.

Agents can’t vibe-code good enterprise software

It’s easy for agents to build a good prototype from scratch, but practically impossible for it to build good enterprise software. Why? 

Most people are bad at product. One of the first lessons any product manager learns is that users often don’t know what they want. It’s hard to go past feature requests to understand an underlying job to be done, balance tradeoffs, or redesign a workflow from the ground up. If every employee acts as their own PM, we’ll end up with a lot of poor, disjointed experiences.

AI’s assumptions are often wrong. When you describe an application with just a few lines of text, coding agents fill in the gaps based on general norms. That might work okay for a simple web app but not for enterprise software. A finance team might vibe-code a customer refund tool, only to realize later it has no logging of approvals. An ops team might build an inventory tracking app that works great at one store, but breaks soon after because the data model never anticipated multiple locations. 

The maintenance burden increases exponentially. A proliferation of vibe-coded applications means a proliferation of maintenance work that gets harder and harder to manage. The problems compound as you try to scale or integrate systems; a marketing, sales, and finance team might each vibe-code an app with a slightly different definition of a customer or contract. 

Security and governance are nearly impossible. If every application is built from scratch, it’s very hard to get visibility into what everyone is doing, let alone govern implementations or enforce access controls. Vibe-coded apps could easily store Personally Identifiable Information in plaintext without a team ever realizing.

But they can assemble good software using excellent primitives

There is a better approach. Give coding agents better primitives: building blocks (tooling, infrastructure, and abstractions) that agents can assemble to make production applications. 

Businesses still have customization: they can set up workflows fit to their operations and UIs that match their preferences. But instead of building from scratch, primitives help agents build things the right way.

For decades, we've had Software Development Kits (SDKs) that provide functions and documentation to help developers build apps. But SDKs are designed for expert humans: they expose basic capabilities and assume the architect has good judgment about how to design the final system. Stripe's SDK lets you create a charge, but you still have to decide how to handle failed payments, design refund workflows, manage subscriptions, and enforce business-specific rules like spend limits.

Agent-native primitives will be different. Instead of providing flexible tools and trusting the builder's expertise, they encode domain knowledge, constraints, and best practices directly into the building blocks, so a coding agent can assemble production-grade software without needing to be a domain expert.

Compared to traditional SDKs, agent-native primitives have:

1. Embedded invariants: The primitive won't let you build it wrong. An agent-native inventory primitive isn’t just a database table. It enforces that stock counts can't go negative, makes sure transfers between locations are atomic, and handles unit conversions correctly. The agent never has to know these rules exist; they're simply baked in.
2. Opinionated composition: The primitives know how they fit together. Rather than exposing independent functions the agent has to orchestrate, agent-native primitives declare their relationships and valid composition patterns. A procurement module knows its outputs will feed into an inventory module, which connects to a fulfillment component, so agents can assemble a working pipeline like a supply chain expert.
3. Machine-readable intent: The primitives provide context about why they exist, not just how to call them. An SDK documents function signatures. An agent-native primitive explains that the workflow exists because a business needs to review any commitment above a dollar threshold, and that executed contracts must be immutable; this gives agents context to make the right architectural decisions.

Won’t foundation models figure this out?

If the next generation of foundation models become experts in enterprise architecture, sales, finance, and security, why would we need domain knowledge baked into primitives at all?

Developers today could write everything in C, or in machine code, but they don't. They use Rails, React, and Terraform because encoding best practices into reusable abstractions is always more efficient than re-deriving them, no matter how talented the engineer.

The same logic applies to agents. Even a model that deeply understands procurement workflows will build faster, more reliably, and more consistently when it's composing tested, constrained building blocks than generating thousands of lines of custom logic from scratch.

Primitives are also a critical place to enforce business context. You could tell an agent that refunds over $5,000 require VP approval, but nothing stops it from skipping that step. When that rule lives in a primitive, it's not a suggestion the agent might overlook; it can be enforced as a hard constraint. This is especially valuable in enterprises with hundreds of interrelated rules, policies, and edge cases; prompts just won’t cut it. 

Primitives in action: Doss

Theory portfolio company Doss is building exactly this kind of primitives-first software platform for enterprise operations. Today’s operational software (ERPs and adjacent products) is rigid out of the box; any change requires painful manual customization. 

Doss is taking a different approach: building next-generation software primitives designed for AI consumers, so that coding agents (initially Doss’ own; some day their customers’) can safely build, deploy, maintain, and modify mission-critical operational applications.

Their platform includes all of the components described above:

1. Domain-aware data model. Instead of a generic database, Doss' data layer is built around the core concepts of operations — it understands what inventory, purchase orders, and BOMs actually are, enforces their constraints and relationships, and supports complex enterprise-scale queries. A coding agent working with this layer doesn't need to design a schema from scratch or guess how warehouses relate to SKUs; the semantics are already captured.
2. Workflow primitives. Doss provides composable building blocks for creating operational automations — procurement cycles, fulfillment processes, approval chains — that encode the decision-making logic and exception-handling patterns an experienced operator would know. An agent assembling a three-way matching workflow inherits years of procurement expertise it could never derive from a blank prompt.
3. Application and UI primitives. Rather than generic UI components, Doss' interface layer is designed around its underlying data and workflow primitives. Components understand what a warehouse dashboard, an inventory transfer form, or a receiving inspection workflow should look like and how users expect to interact with them — so the agent makes zero design decisions about layout, drill-downs, or interaction patterns it would otherwise get wrong.
4. DevOps infrastructure. Doss provides the deployment, testing, and evaluation infrastructure that lets agents autonomously build, validate, and ship changes — with guardrails to ensure updates don't break production, rollback systems when they do, and observability tooling to monitor what's running. This is the layer that vibe-coded apps universally lack, and it's what makes the difference between a demo and a system of record.

We think this pattern will define the next era of enterprise software: thick middle-layer platforms that encode domain knowledge, workflow logic, and business context for agents to build applications that behave like real enterprise products. SaaS as we know it may be dying. But the companies building these primitives will be among the most important software businesses of the next decade.

If you’re thinking about primitives like these, I’d love to hear from you: at@theoryvc.com.

What technology discontinuities birth new companies that define a generation of software?

At Theory Ventures, we’ve spent a lot of time on that question. We are concentrated, thesis-driven investors. We care about real technical shifts, durable platforms, and the kinds of products that emerge when the stack changes underneath them.

But markets are shaped just as much by decay as by invention. Businesses are full of detritus as innovation leaves behind abandoned architectures, bitter lessons, and best-practiced techniques. If you want to understand what matters next, it is no longer enough to study what is being born;

You also have to study what is dying.

The industry is extraordinarily good at tracking emergence, and surprisingly bad at tracking obsolescence.

As I walk through the valley of the shadow of death, I fear no bubble. I take a look at the moats and realize there’s nothing left.

Today, Theory Ventures is proud to announce R.I.P. grep, our system for understanding the dead and dying.

‍

What’s dead can never die

Every cycle leaves behind an elephant graveyard of abandoned ideas – and despite real value created within businesses and markets – the populist tech community deems them unworthy. 

AI has produced an especially oversold cemetery.

• RAG is dead.
• Prompt engineering is dead.
• Evals are dead.
• Grep is dead.

and even,

• SaaS is dead.

This is not noise. This is data.

R.I.P. grep is Theory’s platform for tracking declarations of purported technological death. R.I.P. grep indexes the internet’s ongoing effort to bury things. It tracks claims that a technology, pattern, category, or market narrative has become obsolete, irrelevant, commoditized, or mildly irritating to an influencer.

Anyone can track launches. Anyone can track funding rounds. Anyone can build a dashboard of growth metrics. 

But who is recording these crucial markets’ death knells?

Where is the system-of-record for the moment (or moments!) a category crosses over from frontier to commodity to punchline?

That is the value R.I.P.-grep provides.

‍

The dead outnumber the living

To understand the value of these data, let’s look at RAG.

RAG is extremely dead – everyone knows that LLM’s don’t need high quality context from disparate systems or sources, and even if they do, context windows are near infinite. This is borne out by the data: 

and even though it has died 12 times, this time is definitely for real. It’s probably good to avoid this category as an investor and instead focus on Anthropic secondaries.

Similarly, vibe-coding is dead, and despite token-flexing dominating the feed, vibe-coding’s death is on the rise.

Coding agents' ubiquity is sure to crash now that vibe-coding is in the grave, so we know we should focus on fully agentic software. 

Somewhat paradoxically, MCP is also recently dead (the funeral is today):

Which leaves agents securely using enterprise data in a tricky situation, but I’m sure we’ll figure it out.

Last but not least, evals are dead. We know this one has seen a lot of flip-flopping from the influencers, but the data doesn’t lie. 

‍

With R.I.P. grep, we will continue to monitor the situation.

Theory Ventures concentrates on companies living in the future.

‍

We led Doss’ Series A one year ago because we shared Wiley Jones and Arnav Mishra’s vision of a new way to build enterprise software. Today, we’re thrilled to join their $55 million Series B financing led by Madrona and Premji Invest, along with participation from Intuit Ventures.

For decades, enterprises have been stuck with core systems of record that can’t evolve with the business. They’re forced into expensive custom development projects, manual process workarounds, and paralysis whenever considering a migration/upgrade. 

Doss envisioned something entirely different: powerful, flexible, composable infrastructure & application primitives that can be assembled (by humans or AI) to fit the complexities of dynamic real-world businesses. 

Over the past year, the business has accelerated even faster than we anticipated. In 2025, Doss >10x'd revenue and grew from 10 to over 70 customers, including brands like Eight Sleep and Verve Coffee. The platform now processes 8.6 billion workflow events per day, up from 30,000 just a year prior. And the team has scaled from 16 to over 50, adding veterans who built data platforms at Google, Meta, Scale AI, and Uber, and who scaled ERP businesses at NetSuite, Odoo, and Coupa.

The vision for the company hasn’t changed since our first meeting, but its realization has accelerated dramatically. Here are 3 reasons we’re excited to double down on Doss, from Partner Andy Triedman’s recent interview with Doss CEO Wiley Jones. 

‍

1. GTM & upmarket acceleration

Buying an ERP is a risky investment: about 50% of implementations fail entirely, and that can cost an exec their job. Historically, that’s made it hard for startups to enter the market. But Doss has inverted the risk calculus: its customers see that the “safe” choice of a legacy provider is likely to break under operational strain, while Doss is a more certain path to reaching an operating system that can support their business. They’ve moved upmarket more quickly than expected, helping complex customers like Verve Coffee and Eight Sleep rearchitect their entire stack onto Doss’ modern, flexible operations cloud. 

Video

‍

2. Partnerships with leading finance & accounting platforms

Today’s legacy ERP platforms force buyers into a consolidated, monolithic stack combining finance and operations. But these two functions have very different needs. Finance is all about conformity: every transaction needs to be processed according to consistent accounting standards. Operations, on the other hand, is all about configurability: every business operates entirely differently, and needs a platform that can be flexible to their workflows. To give its customers the best of both worlds, Doss has partnered with the leading finance & accounting products – both incumbent (Intuit) and startups (Rillet & Campfire) which will accelerate the next phase of growth.

Video

‍

3. The missing infrastructure layer for AI-built enterprise software

AI coding agents have made it clear that every business should expect custom-made, self-updating software. But no enterprise will want to vibe-code their core systems of record. Nor will they be able to achieve their goal if they limit their AI agents to legacy platforms’ decades-old developer tooling. Doss is building the substrate needed for AI-generated enterprise apps: its composable data model and workflow engine give AI agents well-defined building blocks to construct and modify system-critical workflows, rather than generating fragile application code from scratch.

Video