Author: Seema Amble

Translation: Deep Tide TechFlow

Deep Tide Intro: Salesforce announced the launch of "headless products," essentially repackaging APIs. But this exposes a sharper question: when Agents no longer need a UI and can directly call APIs, what's left for traditional SaaS companies that are merely database + a set of business logic? What justifies their billion-dollar valuations? a16z breaks down the reconfiguration of the moat for systems of record (SoR) in the AI era: UI stickiness disappears, muscle memory becomes obsolete, but compliance, cross-system connectivity, and unwritten operational logic become more critical.

Is software losing its "head"?

Last month, Salesforce announced the opening of APIs and the launch of a headless product, essentially betting that in the Agent era, its value lies in the data layer, not the UI. This is a clever repositioning. (Although it's worth noting that there doesn't seem to be much technical change: Salesforce's API, marketed now as a "headless product," has essentially existed for many years. In other words, this is a classic Salesforce-style marketing release.) The idea behind this new product is that Agents can access data directly from systems of record without having to interact with a UI designed for humans.

This release raises a more interesting question: If you strip away the UI and expose the database, what is actually left? How is this different from a Postgres database, a well-designed data schema, plus an API? Do the classic elements that made systems of record durable still exist, or is a new set of standards emerging? In the SaaS era, systems of record had their defensiveness because humans lived in the interface. In the Agent era, that advantage weakens. Defensible layers shift down to data models, permissions, workflow logic, and compliance, while shifting up to network, proprietary data generation, and real-world execution.

When software sheds its head, where does defensiveness shift to?

UI was once the product

Systems of record are the authoritative truth source in a business data domain. They are where the official versions of customer relationships, employee records, or financial transactions reside, and they are the systems that other tools read from and write to. CRM is the system of record for revenue. HRIS is the system of record for personnel. ERP is the system of record for funds. What makes them powerful is not just data storage, but that they become the shared reality on which the entire organization operates.

For the past two decades, Salesforce sold a way for sales leaders to manage their teams. Dashboards, pipeline views, forecasting tools, and activity streams were really what people were buying. Their business model was built on selling seats to users, providing access to those features. The underlying database, while critical, was merely a side note.

This means that UI drove stickiness. It enforced data norms. It created a shared vocabulary: leads, opportunities, customers. It compelled thousands of sales representatives to input data they otherwise wouldn’t have. The UI has always been the mechanism for maintaining data coherence. This product is so sticky that many sales leaders insist on bringing Salesforce to new jobs, not because the UI is easy to use, but because it has become muscle memory.

Agents begin to disrupt this model. They can read and write the underlying data directly, rather than through UI interactions, sparking a wave of new tools and workarounds that completely bypass the interface (Salesforce is not the only example: we recently wrote about how SAP sees an entire ecosystem thriving around it that is friendly to AI). Computer-using Agents also render traditional human factors—like preferences, training, and undocumented context—obsolete over time. In other words, the requirements for becoming a durable system of record are evolving.

The historical scorecard

Before asking what the Agent era will change, it's worth precisely stating what initially drove the stickiness of systems of record. The first few factors truly focus on how humans interact with software and their preferences. Software stickiness is largely due to UI, habits, human workflows, and embedded processes.

How frequently is it accessed? CRM is used daily by GTM teams and others. This frequency makes it critical infrastructure, and the human layer built upon it—like rituals, muscle memory, and management rhythms developed over years—tends to be the hardest to migrate since it is often not even recognized as something that needs to be migrated.

Is it read-only or read-write? A sticky system of record is a read-write system of record. For example, CRM is not just a write-only archive; it is constantly read. Every call on every record, every updated stage, every created task is input by someone (who likely cares about what they are doing). This bidirectional flow means that any alternative must handle real-time operational data, not just historical exports. There is no safe switching moment, meaning that once a business is on board with a specific vendor, it tends to stick with that vendor. On the other hand, applicant tracking systems (ATS) are often write-only, and there is little reason to return to the data once hiring is completed.

What is the level of internal or external dependency? The core question is how many internal systems, team processes, or external stakeholders rely on this system of record. Internal connectivity refers to the other software or workflows downstream. External connectivity refers to external parties like auditors, accountants, or regulators that need direct access to the data (like ERP). The higher the connectivity on either dimension, the more that needs to be untangled during migration.

How critical is the data from a compliance perspective? The core question here is simple: is this system crucial for compliance? Compliance-critical systems like payroll, ERP, and HR data require a legally defensible source of truth, strict administrator access controls, and direct involvement from auditors and regulators in any migration. This makes them significantly stickier. Sales data and customer support tools like Zendesk are on the other end: you care about continuity and context, but if the data moves or someone gets access, there is no regulatory risk.

Not all systems of record have the same switching costs. When scoring CRM and applicant tracking systems (ATS) along those same dimensions, the gaps are evident. ATS is a workflow tool for a bounded process: hiring. Once a candidate is hired or rejected, that record is basically a single write. Integrations are narrower. The user base is small and concentrated.

ERP is at the other extreme: the ledger is the audit trail, your accountants, auditors, and regulators become direct stakeholders in any migration. Swapping out an ATS is painful but manageable. Replacing a CRM is open-heart surgery. Replacing an ERP is open-heart surgery while the patient runs a marathon.

Traditionally, systems of record have not leveraged moats such as proprietary data or network effects; workflows themselves created enough moats. If anything, consumer-facing businesses combined tools and networks; historically, systems of record software has not done so.

Proprietary data - While many systems of record collect customer data, they do not do much with that data (and often cannot in contracts). So while CRMs have rich datasets that could generate insights across customers, they have never done so in a meaningful way (despite some attempts, like Salesforce’s Einstein).

Network effects - The holy grail should have been network effects. CRMs became more valuable as software sellers could find buyers. Like data, network effects have been at best weak for historical systems of record.

So if the UI disappears—Agents arrive—what is left?

Agents do not need a browser. They need APIs, context, instructions, and capabilities to take action. Two things make this possible at scale: LLMs have become capable enough to reason. Thus, Agents can now read context, plan, choose tools, execute actions, and review outputs, with most tasks requiring no human intervention. Meanwhile, MCP has standardized tool access, providing a universal interface for Agents to call external capabilities. An Agent with MCP access can perform human users’ tasks at scale in milliseconds without needing a browser. With the right context, computer-using Agents should be able to navigate existing software interfaces even without APIs.

Simply put, software buyers now have three paths:

1) Existing system + Agent. Use existing vendors' CLIs and APIs—either via their native Agent products (Salesforce’s Agentforce, SAP’s Joule) or build their own Agent on top of it. (For now, not considering whether APIs are fully available, and that headless operations are not as simple as they seem.)

2) Completely DIY systems of record. Build your own data model, operational logic, permissions, audit trails, integrations, etc., from scratch, along with your own Agent (perhaps leveraging third-party Agents built and database tools).

3) Purchase AI-native alternatives. Buy the next generation of software built from the ground up for the Agent era, designed to be machine-readable, with Agent orchestration as a first-class feature rather than an add-on. This could be headless.

So, what remains on the old scorecard? Elements driven by human behavior and preferences have faded, such as access frequency or read versus read-write, which are related to human muscle memory. Agents may kill muscle memory as a moat, but they will not kill operational logic and context as a moat. If anything, they make that logic more important, as Agents need explicit rules, permissions, and process definitions to act safely.

Unwritten SOPs remain significant in the short term. The institutional logic encoded in your workflow rules is precisely what Agents need to operate correctly on your behalf. This is also the hardest thing to reconstruct. It can't be exported cleanly, especially when some parts of the process still involve human participation. However, capturing context is becoming easier, and as Agents replace more labor, this becomes less relevant.

Connectivity remains difficult to untangle and extends further. Connectivity factors have changed. It is no longer about keeping pace with humans; it's more about maintaining connectivity between traditionally isolated functions and software. A CRM Agent needs to stitch together data and context from sales, billing, and customer success. If your platform also serves as a node for Agents from multiple external organizations conducting transactions—buyers, sellers, partners—the dependencies deepen. An existing vendor with Agents will face greater challenges when working across various underlying software primitives, as will DIY databases and a set of Agents.

Compliance-critical data remains important. Data that is subject to regulatory scrutiny or legal risk needs a single trusted source of data. If clients trust their existing products, they are less likely to switch. Take payroll and accounting data as examples—Agents may want access to this data, but you are unlikely to build and maintain it internally. One of the hardest issues to solve in a fully Agent-driven world is: which Agents are authorized to do what on behalf of whom, with what level of auditability? A system of record that becomes an identity and permissions layer for interactions between Agents has a structurally irreplaceable role, not because of the data it holds, but because of the trust architecture it executes.

Looking to the future, a set of increasingly relevant factors to drive the defensibility of AI-native startups becomes important:

How difficult is it to rebuild systems of record? - Data will become important in several ways. First, in the short term, the ease of extracting and rebuilding the underlying data of systems of record. AI is making this easier through many tools. In the short term, existing vendors can and will make this harder by making APIs painful, limited, incomplete, or economically unattractive, if they even offer APIs at all. But as extraction tools improve, especially with advancements in computer-using Agents, they will make this easier. At the same time, of course, new companies are reconstructing richer datasets from emails, phone calls, voice Agents, and internal documents. AI is reducing the cost of rebuilding systems of record by 80%. The remaining 20%, consisting of exceptions, approvals, compliance requirements, and edge-case workflows, is still what differentiates useful wedges from true alternatives.

Is there meaningful proprietary data?

Secondly, the data itself is becoming more interesting. Defensible data is not what you import, but what your product uniquely incentivizes to create. We talk about the data's walled gardens—those proprietary, regulated, or continuously updated data. Investing in software providers that collect authoritative and complete data offers advantages over generic providers or competitors lacking this data. Another dimension around data is when the data depends on internally generated behaviors. The best businesses do not merely store data input from elsewhere. They generate new data by engaging in processes, including observed behaviors, response rates, time patterns, process outcomes, benchmarks, anomaly patterns, and Agent performance trajectories. The key is that data now equals context.

Does it have an action layer?

In the old world, storing records was sufficient. In the new world, Agents take actions; defensibility may shift to products capable of operating in a closed loop—from taking action, to capturing results, to leveraging feedback to improve future decisions. For ERPs, this could involve approving expenses, triggering payroll, reconciling invoices, sending notifications, etc. Closed-loop products are more defensible as they reside within execution rather than merely observation: they generate unique data that improves with use and become harder to remove without disrupting workflows. The value here certainly increases as the collection of context grows and the edge cases processed increase.

Are there real-world execution elements?

Business models connect to real-world operations that will not fully automate. Obvious examples include companies with established operational networks, like DoorDash, which historically were not systems of record, but inspire here. More broadly, any software business extending into services, fulfillment, logistics, on-site operations, or payments possesses defensibility distinct from pure SaaS. These companies not only store records or recommend actions; they dispatch personnel, transport goods, or complete services.

For builders, this means there will still be opportunities in markets where software can increasingly decide, and Agents can increasingly coordinate, but the last mile still needs to be executed in the real world. For example, vertical software related to field services.

Are there network effects?

Historically, most record systems have weak network effects because software was primarily for internal use. But in the Agent world, if systems are embedded in multi-party workflows, network effects may become more significant. If a system mediates repeated interactions between buyers and sellers, employers and employees, companies and auditors, vendors and customers, payers and providers, then each new participant can make the network more valuable to the next participant.

One way is through shared workflow coordination: products become the place where both process sides transact, exchange context, and resolve exceptions. Another is through benchmarking and intelligence: systems can present norms, anomalies, and suggestions based on patterns observed in the network, aligning with the data points above. A third is through trust and standardization: once trading partners begin relying on the same tracks for approvals, handoffs, compliance, or payments, products become harder to replace, as they cease to be just a database but part of the infrastructure coordinating the market itself.

What is the technical capability of buyers?

In a theoretically anyone can build their own Agents world, the gap in actual building capabilities among buyers remains large. Especially in vertical end markets and functional buyers with historically weak internal engineering resources, the likelihood of them building, maintaining, and continuously improving their own databases, workflow logic, Agent stacks, and governance layers is still quite low. Costs are important here too: theoretically, DIY may reduce software licensing fees, but usually shifts spending to implementation, maintenance, and internal complexity. This means there are real opportunities in categories where operational complexity is high but technical services are lacking, such as industrial manufacturing, construction back office, field service workflows, or accounting.

There are also several other important factors that will become fundamental requirements of software. For example, the ontology needs to be different. Much of the "DIY database" thinking underestimates the value that the object model itself carries. Existing software is built for dashboards, reports, and humans capturing workflows. This includes opportunities, work orders, candidates, etc. The Agent model needs to capture reasoning, actions, state tracking, anomaly handling, delegation, and cross-system coordination. Native object models may become tasks, intents, threads, strategies, or outcomes.

Similarly, permission management needs to be updated to manage Agents, not just humans. This includes: who can do what, through which Agent, under what policies, requiring what approvals, what audit trails exist, and what rollback/anomaly handling is in place.

Of course, all of this exists against a cost backdrop (e.g., the cost of building and maintaining Agents/databases, the cost of API access), which circles back to the questions of how difficult it is to recreate data and the number of dependencies.

So where does this leave us?

As incumbents move towards headlessness, they are implicitly betting that the data layer will continue to be a source of value. In certain categories, particularly those heavily regulated like financial services, this bet may hold for a while, and headlessness may still be a long way off. For software builders, the opportunity to compete with incumbents moving towards headlessness and build durable software is changing. The next generation of systems of record is starting to look different: not merely repositories that collect data to document human work but are agentic in capturing context, initiating work, and recording data byproducts. Moreover, the most interesting businesses will extend into real-world execution, coordinating field workers, logistics providers, service teams, and physical assets, or sitting between multiple parties. They will blend old-world business models while the core of traditional systems of record—data—will become something in the background.

Many thanks to @astrange for the collaborative thoughts on this issue!