Why the SaaSpocalypse is fake news

Snowflake, MongoDB, and Salesforce are all ripping for the same reason: analysts are coming to terms with the fact that yes, human seats might go down, but a lot of these businesses are usage-based businesses.

If AI makes someone 10x more productive, they probably make 10x more database calls, 10x more Salesforce lookups, 10x more API calls, and 10x more "go get me the context" requests. It might even be 100x since agents often have some waste in their execution.

Using your product does not have to mean a human opening the app and clicking around. Using can just mean getting context from it. If an agent is using your tool for context and any part of your product is usage-based, congrats, you've avoided the permanent underclass.

Quick disclaimer: this is a billing-model rant, not a stock recommendation. I have no idea where these stocks go tomorrow. I do own these stocks.

I wrote about this stack in The ROI of Agentic GTM. The agent consumption path has layers: surfaces, agents, intelligence, and the data sources that get queried every time the agent needs context.

Context lives somewhere

Agents need context. Context lives somewhere. Agents query that. A lot.

Every GTM agent we've built at Vercel queries Snowflake, Salesforce, some DB like Neon, Turbopuffer, and Exa.ai for public web context. They also call out to other agents across the business for extra internal context. We pull from Slack, Zoom, Notion, and all of these have some form of usage-based billing.

At Vercel, we have an internal data agent called d0. Vercel has talked publicly about d0 answering hundreds of questions per day. That is already a different usage profile from "the BI team writes SQL when somebody asks nicely."

And a user question is not one query.

A toy version of the billing shape with AI SDK tools looks like this:

import { generateText, stepCountIs, tool } from 'ai'
import { z } from 'zod'

async function answerQuestion(question: string) {
  const { text } = await generateText({
    model: 'openai/gpt-5.5',
    system: 'Use tools for context.',
    prompt: question,
    tools: {
      querySnowflake: tool({
        description: 'Read Snowflake.',
        inputSchema: z.object({
          sql: z.string(),
        }),
        execute: async ({ sql }) => {
          return snowflake.query(sql)
        },
      }),
      askSalesAgent: tool({
        description: 'Ask the CRM agent.',
        inputSchema: z.object({
          accountId: z.string(),
          question: z.string(),
        }),
        execute: async (input) => {
          return salesAgent.ask(input)
        },
      }),
    },
    stopWhen: stepCountIs(8),
  })

  return text
}

One human asked one question. The model called querySnowflake, looked at the result, called askSalesAgent, came back with a CRM detail, called querySnowflake again, maybe retried, maybe generated a chart, maybe exported a sheet, maybe scheduled the same question to run again every Monday.

So when you hear "hundreds of questions per day," do not translate that into hundreds of database queries. Translate it into thousands, then add retries, scheduled runs, dashboards, permission checks, semantic-layer exploration, and follow-up questions.

The billable unit moved from seat to operation

The scary SaaS story was seat compression. If agents do more work, do companies need fewer human seats?

Maybe. Some companies will absolutely get hurt by that.

But Snowflake, MongoDB, and Salesforce all have meaningful usage mechanics in the business. Snowflake bills through credits. MongoDB Atlas clusters are billed hourly, with other Atlas features tied to processed or transferred data. Salesforce is explicitly pricing Agentforce with Flex Credits and conversations, and each Agentforce action draws from that credit pool.

So the investor question becomes:

If the number of humans using software goes down 20%, but the number of operations those humans and their agents trigger goes up 10x, what happens to revenue?

Snowflake is the cleanest example. A human analyst used to handwrite SQL. The query was expensive enough socially that you saved it for when you really needed it. You did not Slack the data team at midnight because you knew they would answer tomorrow, and by tomorrow maybe you forgot, or the report moved on, or the decision got made with a vibe.

Now anyone can ask the data agent. The question gets answered immediately. The agent can ask follow-ups. The agent can run the same check on a schedule. The agent can be embedded in another workflow.

The demand goes up because the friction goes down.

Build when upside is uncapped

This is how I think about build vs buy now. Dev teams already have a process for these decisions. AI changes the inputs.

It is not that hard for a CTO to shift an engineering team toward internal tooling that can hire and maintain itself. The hard part is picking the work. I only want to build software with uncapped upside.

Do not build internal software with a fixed return ceiling and unknown maintenance burden. Do not build software with unlimited downside exposure unless it is inside your company's core competency. Payment processing is the easy example. Use Stripe. Great product, obvious buy.

GTM tooling is different. If the tool only needs read-only access to existing context, you can and should vibe code the prototype. If the tool needs production write access, vibe code the prototype, prove it matters, then rebuild and harden it with actual engineering.

Reuse the foundations you already have. Every build evaluation should include a prototype because the prototype is the fastest way to price complexity, maintenance, security, upside, and downside.

That matters for SaaS stocks because "we built it ourselves" does not mean "nobody gets paid." The internally built GTM agent still reads Snowflake. It still looks up Salesforce. It still searches the customer knowledge base. It still calls the model. In a world where more companies build their own agents, the application layer can get thinner while the context layer gets hit more.

This is the split. Seat-based apps with capped value are exposed. Usage-based systems in the agent consumption path get pulled deeper into the workflow.

Why the stocks are ripping

Snowflake just reported product revenue of $1.33B, up 34% year over year, and explicitly called out AI as a tailwind to the core data platform.

Salesforce is now reporting Agentforce and Data 360 like investors should track them as first-class lines of business, with Flex Credits and Agentic Work Units giving the market a metered usage language.

MongoDB is telling enterprises it can be the operational database, search layer, memory layer, and retrieval layer for agents in production.

The stocks are ripping because investors realized there are two sets of SaaS companies now: the ones in the agent consumption path and the ones that aren't.

If you're in the path, an agent does not have to love your UI. It does not have to be a named seat. It just has to hit your system for context.

This is why the SaaSpocalypse is fake news, at least if you can get agents to query your API.