SaaS Might be Dead, But Primitives Aren’t

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.