'Agents eat SaaS' is a clean thesis. Most enterprises can't build a clean thesis.
The "agents eat SaaS" thesis emerged from venture-class commentary through 2024-2025 and crystallized in trade-press coverage by Q4 2025. The argument: AI lowers software-build costs enough that enterprises self-build the workflows currently served by point-solution SaaS vendors, and the SaaS category compresses as a result. The thesis is clean.
The evidence on whether enterprises can execute it is messier.
A long Hacker News thread in late 2025 dissected the practitioner-class experience of enterprise-AI deployment. The consensus across senior-engineer and engineering-manager commentary: most enterprises lack the internal capability to build even simple agents, let alone complex workflow-replacement systems. The build-cost lowering is real; the build-capability gap is also real. The combination produces a different disruption shape than the venture-class thesis assumes.
_The disruption runs through AI-native products, not through enterprise self-build._
Hold the venture-thesis and the practitioner-evidence in view together and the synthesis becomes operator-class clear. "Agents eat SaaS" requires the customer to be able to build agents. The customer-class that can do this includes hyperscalers, frontier-tech-companies, top-decile financial services and engineering-led enterprises — roughly the F500 software-engineering-mature subset. The customer-class that cannot includes most middle-market enterprises, regulated-industry incumbents, and the long tail of organizations whose engineering capacity is calibrated to integration-and-maintenance rather than build-from-scratch agentic deployment.
The SaaS subcategories actually exposed to disruption are therefore the ones serving the build-capable customer class. The subcategories whose customers can't build are exposed to the AI-native-vendor substitution route, not to the customer-self-build route.
The subcategories most exposed to "agents eat SaaS" are general-purpose-tooling categories that build-capable customers will replace with internal builds. Notion-class wikis. Generic project-management. CRM at high-engineering enterprises. Customer-support tooling at engineering-led companies. Each is a category where the build-capable customer subset has the engineering capacity to self-build a workflow that replaces the SaaS vendor. The subcategories will compress through 2026-2028 as the build-capable customers cycle off the SaaS contracts. The compression is real but bounded — it doesn't reach the build-incapable customer base.
The subcategories most resistant to disruption are categories with embedded decision-making expertise that's hard to replicate without domain knowledge. Healthcare-claims-management software (decades of payer-policy-encoded rules). Tax-preparation software (decades of regulatory-code-encoded knowledge). Insurance-underwriting software (actuarial expertise embedded in the product). Industrial-process-control software (operational know-how encoded in the workflow). Each carries embedded operator-level expertise that the customer can't trivially rebuild even with AI assistance. These categories are more durable than the "agents eat SaaS" thesis allows. Operators in these categories have structural moat against the customer-self-build threat.
The actual disruption mechanism in the middle is AI-native-vendor substitution, not customer-self-build. A new category of AI-native vendors emerges, builds workflow products with AI baked in from the substrate up, and competes against legacy SaaS vendors on capability and integration. The build-incapable customer doesn't self-build; they switch from legacy SaaS to AI-native vendor. The disruption shape is vendor-versus-vendor competition with AI-native substrates winning on capability differentiation. This is the same arc that played out in mobile-versus-desktop, cloud-versus-on-premises, SaaS-versus-installed-software — the disruption ran through new vendor substitution, not through customer self-build.
The same shape generalizes to "X eats Y" theses across multiple categories. The pattern is consistent: the thesis gets mis-stated as "customers self-build because the cost of building dropped"; the actual mechanism is "new vendors with the new substrate displace incumbent vendors." The customer's role is buyer-side selection, not builder-side execution. The thesis's predictive power improves substantially when the disruption mechanism is correctly named.
Cut through the thesis-vs-evidence framing and the durable read sharpens. "Agents eat SaaS" is operationally correct in directional shape and operationally wrong in mechanism, the build-capability gap is the binding constraint that the thesis doesn't engage with, and the disruption strategy through 2026-2028 is to build AI-native substitution products rather than to bet on customer-self-build adoption rates. Operators building AI-native vendor products in disruption-exposed categories are positioned for the substitution wave. Operators waiting for customer-self-build adoption are waiting for an event that won't reach the volume the thesis projects.
"Agents eat SaaS" is a clean thesis. Most enterprises can't build a clean thesis. The cleanness of the thesis runs into the messiness of the customer-class composition. The disruption arrives anyway, through a different mechanism than the thesis named. AI-native vendors do the eating. Build-capable customers self-build at the margins. The middle-market and the regulated-industry customer base cycles through vendor substitution rather than self-build. That mix is the operator read on which categories actually compress and how fast.
—TJ