a16z: When UI is no longer the product, what remains of the software's moat?

Editor’s note: Over the past twenty years, the moat of SaaS has largely been built on UI. Dashboards, fields, approval flows, and user habits are not just operational interfaces but also shape organizational workflows and data order. When AI can directly read data, call tools, and execute processes, the stickiness formed by human muscle memory begins to weaken, and UI is no longer necessarily the core interface of enterprise software.

This does not mean that record systems lose their value, but rather that their defensive advantage is shifting: from UI and usage habits to data models, permission systems, compliance responsibilities, business logic, closed-loop execution, and multi-party collaboration networks. The truly barrier-creating software in the future may no longer be just a database recording human work but an action system capable of capturing context, initiating tasks, coordinating intelligent agents, and continuously generating new data during execution.

As software moves toward headless (de-interface), the core issues of enterprise software also change: value is no longer just about who owns the data, but who can organize actions around the data.

The following is the original text:

Last month, Salesforce announced it would open up its API and launched a headless product. Essentially, this means Salesforce is betting: in the Agent era, its core value is no longer primarily derived from UI but from the data layer. This is a quite clever repositioning.

However, it’s also worth noting that from a technical perspective, this release doesn’t seem to bring many substantive changes. The API that Salesforce now rebrands as a “headless product” has, in large part, existed for years. In other words, this is more like a typical Salesforce marketing release.

The core idea of this new product is that agents can directly access data in the record system without interacting through UI designed for humans. Traditional UI’s role is to help human users track processes, manage tasks, and push workflows; but after the intervention of agents, the necessity of this interface layer begins to decline.

What’s truly worth discussing about this release is not just what new product Salesforce has launched, but a deeper question it raises: if UI is stripped away and only the underlying database is exposed, what remains of a record system? How different is it from a Postgres database, a well-designed data schema, and a set of APIs?

Furthermore, do the classic factors that once made record systems defensively strong still hold? Or have new standards of competition emerged?

In the SaaS era, record systems have a moat because human users have long lived within their interfaces. These interfaces carry operational habits, organizational processes, and data sedimentation, which also create high switching costs. But in the Agent era, this advantage is being eroded. The layers that provide real defensibility are shifting downward into data models, permission systems, workflow logic, and compliance capabilities; and upward into network effects, proprietary data generation, and real-world execution capabilities.

As software moves toward headless, where will the moat shift to?

UI once was the product itself

A System of Record (SoR) refers to an authoritative source of certain business data. It is where official versions of customer relationships, employee records, or financial transactions reside, and it is the core system that other tools read from and write back to. CRM is the record system for revenue-related data, HRIS for personnel data, and ERP for financial and accounting data.

The strength of these systems is not just because they store data, but because they ultimately become the “real version” that the entire organization depends on to operate.

Over the past twenty years, what Salesforce sold to customers was essentially a way to help sales leaders manage their teams. Dashboards, sales pipeline views, forecasting tools, and dynamic information flows are the actual products purchased. Its business model is built on selling seats to users, which in essence grants access to these functions. The underlying database is crucial but functions more like an implicit infrastructure within the product experience.

In other words, the real driver of user stickiness is UI.

UI constrains data standards and shapes a common language: leads, opportunities, customer accounts. It enables thousands of sales reps to continuously input data they might not otherwise want to enter. Historically, UI was the mechanism to maintain data consistency and usability. Salesforce’s high stickiness, to the point that many sales leaders insist on bringing Salesforce to new companies after switching jobs, is not because of its interface’s excellence but because it has become a form of muscle memory.

But agents are beginning to disrupt this model. They no longer need to interact via UI but can directly read and write to the underlying data. This has also spawned a batch of new tools and alternatives that bypass traditional interfaces. Salesforce is not the only example: recently, we discussed how an entire ecosystem around SAP is growing, better suited for AI calls.

Meanwhile, agents capable of operating computers will make traditional human factors—preferences, training, undocumented context—less important over time. In other words, the conditions for becoming a durable record system are changing.

Past scoring standards

Before discussing what changes might occur in the Agent era, it’s necessary to revisit a more precise question: what exactly made record systems sticky in the past?

The first factors are mainly related to how humans use software and their own preferences. The difficulty in replacing software largely depends on UI, usage habits, human workflows, and embedded organizational routines.

First, how frequently is it accessed?

CRM is used daily by GTM teams and other related departments. This high frequency makes it a critical infrastructure. The organizational inertia—such as team meetings, operational habits, management rhythms—that is built on it often takes years to change and is often the hardest part to migrate because it’s rarely recognized as something that needs to be migrated.

Second, is it read-only or read-write?

A truly sticky record system is usually a two-way read/write system. For example, CRM is not just a storage archive but is continuously read. Every call record, stage update, or task creation is input by a user, who also cares about how that data is used afterward.

This bidirectional flow means any replacement must be able to handle real-time operational data, not just export historical data. There is almost no absolute safe switch point during migration. Once a company goes live, it tends to stay long within the original vendor’s system.

In contrast, candidate tracking systems (ATS) are closer to “write-only” systems. After a candidate is hired or rejected, the reason for reusing that data is relatively limited.

Third, how much undocumented SOPs are there?

Critical business context is often not written in any wiki but is embedded in workflows and rules built over years by administrators and system integrators.

For example, in sales systems, these undocumented contexts might include: enterprise deals over $100k requiring VP approval; transactions in EMEA needing privacy review; discounts for strategic clients only bypassing finance approval at quarter-end.

These contexts often determine whether a task can be pushed forward in time or completed without violating key processes. Migrating systems means dismantling each automation rule; otherwise, part of organizational memory might be lost.

Fourth, how complex are internal or external dependencies?

The core issue is: how many internal systems, team processes, or external stakeholders depend on this record system?

Internal connectivity refers to how many downstream software or workflows depend on it. External connectivity refers to whether external entities like auditors, accountants, or regulators need direct access to the data. ERP is a typical example.

Whether internal or external, higher connectivity means more relationships need to be dismantled and rebuilt during migration.

Fifth, from a compliance perspective, how critical is the data?

The core question here is simple: does this system have compliance-critical importance?

Systems like payroll, ERP, HR data that are compliance-critical must provide a legally sound source of truth and have strict admin controls. Any migration might require direct involvement from auditors and regulators. This makes their stickiness significantly stronger.

Customer data and support tools like Zendesk are on the other end. While companies care about continuity and context, data migration or access rights usually do not immediately trigger regulatory risks.

Not all record systems have the same switching costs. Comparing CRM and ATS under the same dimension shows a clear gap.

ATS is a workflow tool serving limited processes, centered on recruitment. Once a candidate is hired or rejected, related records mostly become one-time write data. Its integration scope is narrower, and its user base smaller and more focused.

ERP, on the other hand, is at the other extreme. The general ledger itself is an audit trail, and accountants, auditors, and regulators are direct stakeholders in migration.

Replacing an ATS is painful but manageable. Replacing a CRM is like open-heart surgery. Replacing an ERP is like performing open-heart surgery on a marathon-running patient.

Traditionally, record systems did not truly leverage proprietary data or network effects as moat sources; usually, workflows alone were enough to form barriers. To some extent, combining tools with networks was more common in consumer-grade businesses; historical SoRs did not follow this path.

Proprietary data. Many record systems have accumulated large amounts of customer data but have not deeply utilized it, and often contractual terms restrict them from doing so. Therefore, despite rich datasets, CRM systems have never truly achieved meaningful cross-customer insights—though products like Salesforce Einstein have attempted some exploration.

Network effects. For record systems, the ideal moat would be network effects: for example, CRM becomes more valuable as sellers find buyers within it. But like data, network effects in record systems have historically been weak or nearly nonexistent.

If UI disappears and agents arrive, what remains of the software?

Agents do not need browsers. They require APIs, context, instructions, and the ability to perform actions. Two factors enable this at scale: first, LLMs now have enough reasoning power to read context, plan, select tools, execute actions, and review results—most tasks no longer require human intervention; second, the MCP standardizes tool access, providing a universal interface for external capabilities.

An agent with MCP access can perform in milliseconds what human users used to do on platforms, and at scale, without a browser. With sufficient context, agents capable of operating computers can even directly use existing software interfaces, not necessarily relying on APIs.

In simple terms, software buyers now have three paths:

First, continue using existing systems and overlay agents on top.
Use their CLI and APIs, either with vendor-native agents like Salesforce’s Agentforce, SAP’s Joule, or custom-built agents. This assumes APIs are complete and available, ignoring the operational complexities of headless setups for now.

Second, build a record system from scratch.
Companies can start from zero, designing their data models, workflows, permission systems, audit trails, integrations, and their own agent stacks. This path likely involves third-party agent development tools and database solutions.

Third, buy AI-native replacements.
Companies can purchase new-generation software designed from the ground up for the Agent era. These products emphasize machine readability, with agent orchestration as a core capability, not just patching AI onto old systems. They are also likely headless.

So, which elements from the old scoring standards will be retained?

Factors driven by human behavior and preferences—such as access frequency, bidirectional read/write attributes—will gradually weaken. Agents may diminish the value of “muscle memory” as a moat, but they will not eliminate the moat provided by operational logic and business context. In fact, these may become even more critical because agents need clear rules, permissions, and process definitions to execute tasks safely.

Undocumented SOPs will remain important in the short term.
The institutional logic embedded in workflow rules is what agents need to perform tasks correctly. It’s also the hardest part to rebuild. Currently, it cannot be cleanly exported, especially when some processes still require human involvement. However, capturing context is becoming easier; as agents replace more manual work, this factor’s importance will decline.

Connectivity remains difficult to dismantle and will extend deeper.
The meaning of connectivity is evolving. It’s no longer just about supporting human workflows but about maintaining links between functions and software that were previously siloed.

A CRM agent needs to connect data and context across sales, billing, customer success, and more. If your platform becomes a node for multiple external organizations to transact—buyers, sellers, partners—dependencies deepen further.

When existing vendors layer agents onto different underlying software, seamless collaboration across core objects and logic becomes challenging; similarly, companies relying solely on self-built databases and agents face similar issues.

Compliance-critical data remains vital.
Data involving regulators, compliance risks, or legal risks still needs a single, trusted source of truth. If customers trust existing products, their switching likelihood drops.

For example, payroll and accounting data may require agent access, but companies are unlikely to build and maintain such systems internally long-term.

In a fully agentized world, one of the hardest questions is: which agents are authorized to do what? Who do they act on behalf of? How are these actions audited? If a record system can serve as an identity and permission layer for agent interactions, it gains a structurally irreplaceable role. The moat here is not just data ownership but the trust architecture it embodies.

Looking ahead, for AI-native startups, a new set of factors will become increasingly important in determining their defensibility.

First, how difficult is it to rebuild this record system?

Data will become more critical at several levels.

Initially, in the short term, the key is how easily the underlying data of record systems can be extracted and reconstructed. AI is making this easier, with tools emerging to assist in migration and rebuilding.

In the short term, existing vendors might make this harder—by limiting API usability, imposing restrictions, making APIs incomplete, or even not providing APIs at all. But as extraction tools improve, especially with enhanced agent capabilities that can operate computers, data reconstruction will become increasingly feasible.

Meanwhile, new companies are reconstructing richer data from emails, calls, voice agents, and internal documents. AI reduces the cost of rebuilding 80% of a record system. The real differentiator is the remaining 20%: handling edge cases, approval workflows, compliance requirements, and edge scenarios.

Second, does the company possess truly meaningful proprietary data?

Second, data itself will become more valuable.

Data that provides defensibility is not just what you import but what your product uniquely facilitates generating. We often talk about “data moat gardens”: these are data that are proprietary, regulated, or require ongoing updates. A software vendor investing heavily in collecting authoritative and complete data will have a clear advantage over generalist or data-lacking competitors.

Data also depends on actions generated within the product.

The best companies do not just store data entered from elsewhere. They continuously generate new data traces through their processes—behavioral observations, response rates, timing patterns, workflow outcomes, industry benchmarks, anomalies, and agent execution logs.

The key point: data is now context.

Third, do you control the action layer?

In the old world, storing records was enough. In the new world, agents will take direct actions, and defensibility may shift toward products capable of closing the loop: from acting, capturing results, to using feedback to optimize future decisions.

For ERP, this might include approving expenses, triggering payroll, verifying invoices, or sending notifications. Products that close the loop are more defensible because they embed execution, not just observation. They generate unique data, improve with use, and are harder to replace because removing them would break workflows.

Of course, as context accumulates and edge cases are better handled, this value will further increase.

Fourth, do they include real-world execution steps?

Some business models are connected to real-world operations, which cannot be fully automated. The clearest example is companies with operational networks, like DoorDash. They are not traditional record systems but are highly instructive.

More broadly, any company that extends software’s closed loop into services, fulfillment, logistics, on-site operations, or payments has a different kind of defensibility from pure SaaS. These companies do not just store records or recommend actions—they dispatch personnel, move goods, or deliver specific services.

For entrepreneurs, this suggests opportunities in markets where software increasingly makes decisions and agents coordinate workflows, but the last mile still requires real-world execution. For example, vertical software tied to on-site services is a promising direction.

Fifth, are there network effects?

Historically, most record systems had weak network effects because they were primarily internal software. But in the Agent era, if a system embeds multi-party workflows, network effects can become much more significant.

If a system mediates repeated interactions among multiple parties—buyers and sellers, employers and employees, companies and auditors, vendors and clients, payers and service providers—each additional participant can make the network more valuable for the next.

One approach is shared workflow collaboration: the product becomes a place for transaction, context exchange, and exception handling between process parties.

Another is benchmarking and intelligence: the system can observe patterns in the network, presenting industry norms, anomalies, and action recommendations, reinforcing the data’s value.

A third is trust and standardization: once counterparties rely on the same approval, handoff, compliance, or payment processes, the product becomes a foundational infrastructure for market coordination, making it harder to replace.

Sixth, how strong is the buyer’s technical capability?

In a world where anyone can theoretically build their own agent, the actual building capacity of different buyers varies greatly. Especially in vertical industries and among functional buyers without strong internal engineering resources, the likelihood of self-building, maintaining, and continuously improving databases, workflows, agent stacks, and governance remains low.

Cost is also a factor. DIY might reduce licensing fees but often shifts expenses to implementation, maintenance, and internal complexity.

This means real opportunities still exist in complex operations with insufficient technical supply—such as manufacturing, backend construction, industrial processes, field service workflows, and accounting.

Some other factors are equally important and will gradually become basic thresholds for software.

For example, ontologies need to evolve. Many “self-built databases” underestimate the value of their object models. Existing software is built for dashboards, reports, and human users, capturing objects like opportunities, work orders, or candidates.

But in the Agent era, schemas need to capture reasoning, actions, state tracking, exception handling, task delegation, and cross-system coordination. Native object models may shift from opportunities, work orders, and candidates to tasks, intents, threads, strategies, or outcomes.

Similarly, permission systems need updating. They no longer just manage human users but also agents. This includes: who can do what, through which agent, under what policies, with what approvals, leaving audit trails, and handling rollbacks and exceptions.

Of course, all these depend on costs—how much it costs to build and maintain agents and databases, and the API access costs. This circles back to core questions: how hard is data reconstruction, how many dependencies exist, and how deeply embedded is the system?

So, what is the conclusion?

As existing software vendors move toward headless, they are implicitly betting that the data layer will remain the core source of value. In certain categories, especially heavily regulated fields like financial services, this bet may hold for some time, and the process of headless transformation might be slower.

But for software startups, as existing vendors begin de-interfaceing, the questions of how to compete and how to build long-term defensible software are changing.

The next generation of record systems is already showing different forms: they are no longer just data warehouses for recording human work but are increasingly agent-like—able to capture context, proactively initiate work, and record data traces during execution.

Furthermore, the most interesting companies will extend into the realm of real-world execution: coordinating on-site workers, logistics providers, service teams, and physical assets, or acting as intermediaries among multiple participants.

These companies will blend various traditional business models. The core of the old record system—data—will gradually recede into the background, serving as the foundational layer supporting the entire system’s operation.

[Original link]

Click to learn about Rhythm BlockBeats’ open positions

Join Rhythm BlockBeats’ official community:

Telegram subscription group: https://t.me/theblockbeats

Telegram discussion group: https://t.me/BlockBeats_App

Twitter official account: https://twitter.com/BlockBeatsAsia