Tools, not Vertical Agents

Best paired with Schlep as a Service.

The 2023-2025 reaction to AI was to lean in hard by building AI into the product. Originally derided as LLM wrappers, the current (more accurate) term for that business model is vertical AI agent. The vertical AI agent is an amazing business when executed correctly. But for many existing SaaS incumbents, it’s not a realistic outcome, and going for it risks losing the moat.

In the age of AI the war chant is: “Move up the value chain, deliver outcomes not software, cut into labour budgets, do knowledge work, get on the token path, expand the TAM!”. It’s natural for a successful SaaS company to want to swing for the vertical agent outcome, because pulling it off entails continued and accelerating growth.

The problem with the vertical agent model is the vertical part. Think about the position of most SaaS inside a business. Each one executes a tiny slither of that business’s activity. Human knowledge workers are fundamentally horizontal. Humans get the full picture across email clients, editors, spreadsheets and dozens of different SaaS tools.

In 2026, Claude and ChatGPT started getting the horizontal picture too. Out of all the agents, they are in the best position to execute the knowledge work. Conventional wisdom says this is how the labs eat your business model. The conclusion being, hold onto your proprietary data as a moat, build your own agent using that context (and maybe even train).

While that advice may be helpful for some businesses, the “data moat” argument is just wrong for most SaaS. Firstly that data isn’t really yours, it’s your customers. More importantly, it’s not enough data. No matter how good your product is, your vertical SaaS does not have enough context. Even in the much lauded “system of record” the value is not in hoarding the context, but the fact that it contains an accurate, working, useful representation of a particular vertical of the business. In most cases, the correct strategy is to eagerly make this accessible to the horizontal agents. In other words, become an AI tool.

If you make your SaaS an agent friendly tool, it is simply not in the interest of the labs to replicate it. The years of painful integrations that move at human speed, and the thousands of iterations that made it the best in class at its vertical slice. It took years to build your schlep moat, and you’re underrating just how hard it is for your customers to build something as good.

Databricks is a great example of a business that naturally became an AI tool. I’ve fantasized about building a more agent friendly Databricks competitor. Last time I used it, debugging and tuning Databricks jobs with Claude was a real pain in the ass. But their cloud computing platform is excellent and battle tested, it’s already in the enterprise, and they’re a cashflow machine. They don’t even need a great developer experience anymore, agents will deal with it, as long databricks make all relevant tasks possible via MCP, CLI or API. Even if they bumble their way there, they’ll crush me, their schlep moat is too great.

Fortunately, many SaaS incumbents are doing the opposite, trying to become the agent the white collar professional uses. They’re explicitly hoarding their functionality for their agent or UI, and either over-charging for, or outright blocking, programmatic access. Resisting becoming an AI tool is the quickest way to drain your schlep moat. If everything else can be accessed by a horizontal agent, your product becomes the bottleneck, and an immediate priority to get rid of. This opens the door for challengers.

Seat based Counter Positioning

Databricks, Stripe and Twilio are all businesses that are well-poised for the agentic transition, because they already have usage-based pricing models. Usage based pricing is usually discussed in terms of consuming tokens as a vertical agent, but I mean it in the more traditional sense1 (e.g. per API call, per CPU, per GB).

This is a difficult transition for seat based SaaS incumbents, for multiple reasons. Pricing changes are a one way door, customers find them confusing, and there is genuine downward pressure on prices due to the cost of producing software going down. SaaS incumbents built their teams when engineers hand wrote the code, they are well over-staffed, accustomed to continuous revenue growth and will find it very challenging to nerf their own revenue with a cheaper usage based model.

Then there is the allure of becoming the vertical AI agent. To the incumbents, that is perhaps the only path that doesn’t require an initial drop in revenue.2 It’s natural to want continuous growth, but as discussed it’s unlikely and expensive. Context engineering and writing good evals at scale requires expensive talent. Also, tokens have poor margins.

This is doubly delicious for startups challenging incumbents. Not only do we have traditional counter positioning, but the incumbents are distracted and wasting money on an expensive quest they will likely fail. While they’re spending time on that, small startups can come in and start building the schlep moat, starting with the most useful functionality and making it agent operable.

2026 is the time to execute this strategy. While programmers have all transitioned to working via a horizontal agent, much of the white collar workforce is just starting to try out Claude Cowork and codex / GPT work. The pain of an agent-unfriendly SaaS is about to become real, and being forced to use an incumbent second rate agent/UI via computer use is going to infuriate the incumbent’s customers.

The irony is that the potential growth from being used by agents is so much higher than any seat based model ever had. Focus on building an AI tool. Keep your code deterministic and boring. No token bills, no GPUs, no expensive talent. Let the labs and other companies spend billions to make agents better at using your tools. Schlep your way to becoming Claude’s chosen AI tool, before the incumbents understand where their true value lies.

Footnotes

  1. That said it is totally reasonable to have AI / sub agents (with token based pricing) as part of your product. Using agents inside your tool is not the sin, the sin is thinking that your agent is the front end to the human knowledge worker. Sorry but it’s Claude, not your shitty agent. ↩

  2. In the short to medium term at least. In the long term, being exposed to the explosion of agents is an excellent position for growth. ↩