SaaS, the laws of gravity & context-as-a-service
All SaaS companies worth their salt (Posthog, Basecamp, Intercom etc) are racing to launch CLIs and adopt a more “headless composability” approach, where agents can do more and more of the heavy-lifting work inside these products, simply by interacting with APIs, CLIs, and SDKs. I’ve written about this trend a few times before, and suffice to say, I think this is a smart and logical strategy.
But there is a big open question which is: where does the value accrue if the agent starts to do more of the work?
Put another way, if an agent is doing most of the work, how should I value, or how much should I pay the SaaS tool the agent is using? Who is more valuable, the agent or the SaaS product? Will I (or should I) spend more money on agent tokens, or SaaS licenses?
The answer to this question depends on whether the underlying system is horizontal or vertical.
On one hand, people continue to underestimate just how many SaaS tools the average company is using, and the fact that the vast majority of these aren’t rich systems of context. They’re purely horizontal “tools”. Not systems, tools. They are CRUD apps. Databases with a UI on top. There is a whole segment of SaaS which is basically a spreadsheet running as commercial SaaS.
In this segment, it is actually a lot less clear who creates the value if things go “agentic”. These are systems of convention, for want of a better term. The “rules” of the software aren’t in the code; they are in the heads of the humans using them. If you move a Trello card from “In Progress” to “Done,” the software doesn’t know if the work is actually finished, it just follows the convention you’ve defined.
Because the software is logic-agnostic, the agent (and the model) has to do all the reasoning. If you use Claude Code to manage your project in a generic CRUD tool, the agent is providing the “brain” while the SaaS is just providing the “filing cabinet.” In this world, the value shifts heavily toward the agent. Why pay a premium for a filing cabinet when the agent is doing most of the hard work anyway? In that world, the SaaS license is the commodity, and the valuable spend will move to the agent/tokens.
On the other end of this spectrum are vertical systems. These are “systems of context”, where highly-valuable domain experience and expertise is (or at least, can be) actually encoded into the core primitives of the product. Clear operational rules, guidelines, and playbooks that determine how work must be done.
In these tools, agents are guided by the platform, and not the other way around. An agent adheres to the “laws of gravity” defined by the system rather than trying to reason its way forward.
Rippling is the obvious example here. Rippling has the richest context about employees in an organization. It’s not just the data, it’s actually the encoded domain knowledge. There are clear rules and primitives, at the level of code, which determine things like spending limits for corporate cards, approval flows for paid time off, and organisational reporting lines, just to name a few. Rippling has, very cleverly, architected its platform around modular and composable components and apps, a unified data infrastructure and most importantly, all of the business and operational logic too, from permissions to processes.
For a long time, the meme was “you won’t vibe code your payroll system,” and I think that’s accurate, but it misses the nuance. With a payroll system as rigid and robust as Rippling’s, you will trust an agent to run it. You can trust the agent because the underlying system of context provides the structural integrity. The agent doesn’t have to guess, it can activating pre-built workflows and playbooks.
In this world, the system, the SaaS platform, is providing the context and guardrails, and thus remains the high-value asset in this stack. You are actually paying for the structural integrity of the constraints. That’s where the value accrues. Agents are the commodity, the system is the valuable bit.
So, what matters most in this new world? How should we think about building software? Here’s a simple 3-step set of questions I’m asking myself (and our team), as we build things now.
Can the system force the agent into pre-built workflows?
Are there codified “laws of gravity” that prevent an agent from breaking rules?
Does the system maintain a source of truth that an agent cannot hallucinate away?
