Editor’s Note: Over the past two decades, the moat of SaaS has largely been built on the UI—dashboards, fields, approval workflows, and user habits have not only served as interfaces but also shaped how organizations operate and structure their data. As AI can now directly read data, invoke tools, and execute workflows, the stickiness formed by human muscle memory is weakening, and the UI is no longer necessarily the core interface of enterprise software.
This does not mean the record-keeping system has lost its value, but rather that its defense is shifting: from UI and usage habits to data models, permission systems, compliance responsibilities, business logic, execution闭环, and multi-party collaboration networks. The software with true competitive advantages in the future may no longer be mere databases that record human work, but action systems capable of capturing context, initiating tasks, coordinating agents, and continuously generating new data during execution.
As software moves toward headless, the core challenge for enterprise software shifts: value is no longer just about who owns the data, but who can organize action around the data.
The following is the original text:
Last month, Salesforce announced it would open its API and launch a headless product. Essentially, this means Salesforce is betting that in the agent era, its core value will no longer come primarily from the UI, but from the data layer. It’s a fairly smart repositioning.
However, it should be noted that, from a technical standpoint, this release appears to bring little substantive change. The APIs Salesforce is now rebranding as “headless products” have largely existed for many years. In other words, this is more of a typical Salesforce-style marketing launch.
The core idea behind this new product is that Agents can directly access data in the record system without needing to interact through a UI designed for humans. Traditional UIs were intended to help human users track processes, manage tasks, and advance workflows; however, once Agents are involved, the necessity of this interface layer begins to diminish.
What’s truly worth discussing about this release isn’t just what Salesforce launched as a new product, but the more fundamental question it raises: if you strip away the UI and only expose the underlying database, what remains of a record system? How different is it from a Postgres database, a well-designed data schema, and a set of APIs?
More specifically, do the classic factors that once ensured the long-term resilience of record-keeping systems still hold true, or have new competitive standards emerged?
In the SaaS era, record systems gained moats because human users lived within their interfaces for extended periods. These interfaces embedded operational habits, organizational workflows, and data accumulation, creating high switching costs. But in the Agent era, this advantage is eroding. The truly defensible layers are now 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 was once the product itself.
A System of Record (SoR) refers to the authoritative source of truth for a specific category of business data. It is the central system where the official versions of data such as customer relationships, employee records, or financial transactions are stored, and from which other tools read and write data. CRM is the system of record for revenue-related data, HRIS is the system of record for personnel-related data, and ERP is the system of record for financial and monetary data.
The power of these systems lies not just in their ability to store data, but in that they ultimately become the single source of truth upon which the entire organization relies.
Over the past two decades, what Salesforce has sold to its customers is actually a set of tools to help sales leaders manage their teams—dashboards, sales pipeline views, forecasting tools, and dynamic feeds are the real products being purchased. Its business model is built on selling seats, which essentially provide access to these features. While the underlying database is crucial, it functions more like an invisible infrastructure within the product experience.
In other words, it is the UI that truly drives user retention.
The UI enforces data standards and shapes a common language: leads, opportunities, customer accounts. It compels tens of thousands of sales representatives to consistently enter data they might otherwise avoid. In the past, the UI was the very mechanism that ensured data consistency and usability. Salesforce’s remarkable stickiness—why so many sales leaders insist on bringing it to their new companies even after switching jobs—is not due to its interface being particularly elegant, but because it has become muscle memory.
But agents are beginning to disrupt this model. Instead of interacting with software through a UI, they can now directly read and write underlying data. This has given rise to a new wave of tools and alternatives that bypass traditional interfaces. Salesforce is not the only example: we recently discussed how an entire ecosystem more suited for AI access is emerging around SAP.
Meanwhile, agents capable of operating computers will cause traditional human-level factors—such as preferences, training, and undocumented context—to gradually become less important over time. In other words, the conditions required to become a persistent record system are changing.
Previous rating criteria
Before discussing what will change in the Agent era, it is necessary to return more precisely to a fundamental question: What exactly made record-keeping systems sticky in the past?
The first few factors are primarily related to how humans use software and their personal preferences. Software is difficult to replace largely because of its UI, usage habits, human workflows, and institutional arrangements already embedded in organizational processes.
First, how frequently is it accessed?
The CRM is used daily by the GTM team and many other departments. It is this high frequency of use that makes it critical infrastructure. Yet the human layer built on top of it—such as team meetings, operational habits, and management rhythms formed over years of organizational inertia—is often the hardest part to migrate. The reason is that it frequently isn’t even recognized as “something that needs to be migrated.”
Second, is it write-only, or read and write?
A truly sticky record system is typically a bidirectional read-write system. Take CRM as an example—it is not merely a write-only archival system, but one that is continuously read. Every phone call log, every stage update, and every task created is entered by a user, and that user typically cares about how this data will be used afterward.
This two-way flow means that any alternative must be able to handle real-time operational data, not just export historical data. There is almost no absolutely safe moment to switch during migration. Therefore, once a company goes live, it often remains within the original vendor’s ecosystem long-term.
In contrast, applicant tracking systems (ATS) are typically closer to a "write-only" system; once candidates are hired or rejected, there are relatively few reasons for companies to revisit this data.
Third, how many undocumented SOPs are there?
The most critical business context is often not documented in any wiki, but rather embedded in workflow rules built up over years by administrators and system integrators.
For example, in a sales system, these undocumented contexts might include: enterprise transactions over $100,000 require VP approval; transactions in the EMEA region must undergo privacy review; discounts for strategic customers can only bypass financial approval at the end of the quarter.
These contexts often determine whether a task can be advanced promptly or completed without violating critical processes. Migrating a system means reconfiguring every automated rule; otherwise, the company may directly lose part of its organizational memory.
Fourth, how complex are the internal or external dependencies?
The core issue is: How many internal systems, team processes, or external stakeholders rely on this record-keeping system?
Internal connectivity refers to how many downstream software systems or workflows depend on it. External connectivity refers to whether external parties, such as auditors, accountants, or regulators, need direct access to its data. ERP is a classic example.
Whether internal or external, the higher the connectivity, the more complex the relationships that need to be disassembled and rebuilt during migration.
Fifth, how critical is data from a compliance perspective?
The core issue here is simple: Is this system compliance-critical?
Compliance-critical systems such as payroll, ERP, and HR data must provide a legally defensible source of truth and enforce strict administrative access controls. Any migration may require direct involvement from auditors and regulators, making their stickiness significantly stronger.
Sales data and customer support tools like Zendesk sit at the other end. While businesses certainly care about continuity and context, data migration or unauthorized access typically does not immediately trigger regulatory risks.
Not all record systems have the same level of switching costs. Comparing CRM and ATS under the same dimension highlights the obvious difference.
ATS is a workflow tool designed for limited processes, centered around recruitment. Once a candidate is hired or rejected, the related records are mostly written once and archived. Its integration scope is narrower, and its user base is smaller and more focused.
ERP, on the other hand, sits at the other extreme. The general ledger itself is an audit trail, making accountants, auditors, and regulators direct stakeholders in the migration process.
Replacing ATS is painful but still manageable. Replacing CRM is like performing open-heart surgery. Replacing ERP is like performing open-heart surgery on a patient while they’re running a marathon.
Traditionally, systems of record have not truly leveraged moats such as proprietary data or network effects; typically, the workflow itself has been sufficient to create barriers. To some extent, combining tools with networks has been more characteristic of consumer-facing businesses; historical systems of record have not taken this path.
Proprietary data. While many record systems have accumulated vast amounts of customer data, they have not truly leveraged it deeply, and in many cases, contractual terms prohibit them from doing so. As a result, despite CRM systems possessing rich datasets that could theoretically aggregate data across customers to generate cross-customer insights, they have never achieved this in any truly meaningful way. Of course, products like Salesforce Einstein have made some attempts.
Network effects. For a record-keeping system, the ideal moat should be network effects: for example, a CRM becomes more valuable as software sellers can find buyers within it. But, like data, historically, network effects for record-keeping systems have been weak—or even virtually nonexistent.
If the UI disappears, what remains of the software after the Agent arrives?
An agent does not require a browser. It needs an API, context, instructions, and the ability to execute actions. Two factors enable this to scale: first, LLMs now possess sufficient reasoning capability, allowing agents to read context, formulate plans, select tools, execute actions, and reflect on outcomes—eliminating the need for human intervention in most tasks; second, MCP standardizes tool access, providing agents with a universal interface to invoke external capabilities.
An agent with MCP access can perform, in milliseconds and at scale, actions that previously required human users on the platform, without needing a browser. With sufficient context, an agent capable of operating a computer can even directly interact with existing software interfaces, not necessarily requiring an API.
Simply put, software buyers now have three options:
First, continue using the existing system and overlay an Agent on top of it.
Use them via the existing system's CLI and API, either by leveraging the vendor's native Agent products, such as Salesforce's Agentforce or SAP's Joule, or by building your own Agent on top. For now, assume that the APIs are complete and functional, and temporarily ignore the potential operational complexities introduced by "headless" implementation.
Second, build a completely independent record-keeping system.
Enterprises can build their own data models, operational logic, permission systems, audit trails, and system integrations, as well as their own Agent stack from scratch. This path will likely leverage third-party Agent development tools and database tools.
Third, purchase AI-native alternatives.
Enterprises can also purchase next-generation software designed from the ground up for the Agent era. These products emphasize machine readability and treat Agent orchestration as a first-class capability, rather than tacking on AI functionality to legacy systems. Such products may also be headless.
So, what elements from the previous rating criteria will be retained?
Factors driven by human behavior and preferences, such as visit frequency and read-write bidirectional attributes tied to human muscle memory, will gradually diminish. Agents may reduce the value of "muscle memory" as a moat, but they will not eliminate the moats created by operational logic and business context. In a sense, they may make these logics even more important, as agents must rely on clear rules, permissions, and process definitions to execute tasks safely.
Undocumented SOPs remain important in the short term.
The institutional logic embedded in workflow rules within an organization is precisely what an Agent needs to correctly execute tasks on your behalf. This is also the most difficult part to reconstruct. At least for now, it cannot be cleanly exported, especially when certain processes still require human involvement. However, capturing context is becoming increasingly easier; as Agents take over more manual labor, the importance of this factor will gradually diminish.
Connectivity remains difficult to untangle and will extend even deeper.
The meaning of connectivity is changing. It is no longer just about complementing human work, but about maintaining connections between traditionally siloed functions and software.
A CRM agent needs to connect data and context across different stages such as sales, billing, and customer success. If your platform also serves as a node for transactions between multiple external organizations—such as buyers, sellers, and partners all interacting through it—the dependencies will become even more complex.
When existing vendors layer on agents, it can be difficult to achieve seamless collaboration between the fundamental objects and logic of different underlying software; enterprises relying solely on a single self-built database and a set of agents will face similar challenges.
Compliance-critical data remains important.
Data involving regulatory authorities, regulatory risks, or legal risks still requires a single, trusted source of factual information. If customers already trust existing products, their likelihood of switching systems decreases.
For example, with payroll and accounting data, the Agent may indeed need access to this information, but enterprises are generally unlikely to choose to build and maintain such systems internally over the long term.
In a fully agent-driven world, one of the hardest problems to solve is: which agents are authorized to do what? Whom do they represent? And how are these actions audited? If a record system can serve as the identity and permission layer for interactions between agents, it gains a truly irreplaceable structural role. The barrier here is not just what data it holds, but what trust architecture it enforces.
Looking ahead, a new set of factors will become increasingly important for AI-native startups in determining whether they can build defensibility.
First, how difficult is it to rebuild this record system?
Data will become more important at several levels.
First, in the short term, the key lies in how easy or difficult it is to extract and reconstruct the underlying data of the record system. AI is making this easier, and a suite of tools is helping users accomplish this type of migration and reconstruction.
In the short term, existing vendors can and likely will make this more difficult: they can make APIs difficult to use, limited, incomplete, economically unviable, or even withhold them entirely. However, as extraction tools continue to improve—especially as agents capable of operating computers become more advanced—data reconstruction will become increasingly easier.
Meanwhile, the new company is also rebuilding a richer set of data from emails, phone calls, voice agents, and internal documents. AI has reduced the cost of rebuilding a record system by 80%. What distinguishes a useful entry point from a true replacement is the remaining 20%: edge cases, approval workflows, compliance requirements, and processes under unusual scenarios.
Second, does it possess truly meaningful proprietary data?
Second, the data itself will become more valuable.
Truly defensive data is not the data you import, but the data your product uniquely enables to be generated. We often refer to “data moats”: this data is either proprietary, subject to regulatory constraints, or requires continuous updating. A software provider that invests heavily in collecting authoritative and comprehensive data holds a clear advantage over generic providers or competitors lacking such data.
Another important aspect of the data is whether it depends on actions generated within the product.
The best companies don’t just store data entered from elsewhere—they continuously generate new data trails because they are embedded within the process, such as observed behaviors, response rates, time patterns, process outcomes, industry benchmarks, anomaly patterns, and agent execution traces.
The key is: data is context today.
Third, do you understand the action layer?
In the old world, storing records was sufficient. But in the new world, agents will take action directly, and defense will shift toward products that can form a closed loop: taking action, capturing outcomes, and using feedback to optimize future decisions.
For ERP systems, this may include approving expenses, triggering payroll disbursements, reconciling invoices, and sending notifications. Products that can close the loop are more defensible because they embed execution processes rather than merely observing them. They generate unique data that improves over time with usage and become harder to replace because their removal would disrupt workflows.
Of course, as more context is accumulated and edge cases are handled more thoroughly, the value here will continue to increase.
Fourth, does it include real-world execution steps?
Some business models are connected to real-world operations that cannot be fully automated. The most obvious example is companies with operational networks, such as DoorDash. Historically, they did not belong to record systems, but they are highly instructive here.
More broadly, any company that can extend the software loop to services, fulfillment, logistics, on-site operations, or payments possesses a different kind of defensibility than pure SaaS. These companies don’t just store records or recommend actions; they dispatch personnel, move goods, or complete specific services.
For entrepreneurs, this means opportunities may arise in markets where software is increasingly capable of making decisions and agents are better at coordinating processes, but the last mile still requires real-world execution. For example, vertical software tied to on-site services is a typical direction.
Fifth, is there a network effect?
Historically, most record-keeping 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 could become significantly stronger.
If a system facilitates repeated interactions among multiple parties—such as buyers and sellers, employers and employees, companies and auditors, suppliers and customers, or payers and service providers—each additional participant can increase the network's value for the next participant.
One approach is shared workflow collaboration: the product becomes the venue where both parties in the process conduct transactions, exchange context, and handle exceptions.
Another approach is benchmarking with intelligence: the system can present industry norms, anomalies, and actionable recommendations based on patterns observed in the network, further reinforcing the data value mentioned earlier.
The third approach is trust and standardization: once counterparties begin relying on the same system to complete approvals, handoffs, compliance, or payments, the product is no longer just a database—it becomes the collaborative infrastructure of the market itself, making it much 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 capabilities of different buy-side organizations still vary significantly. In particular, within vertical industries and among functional buyers that historically lacked strong internal engineering resources, the likelihood of them building, maintaining, and continuously improving their own databases, workflow logic, Agent stacks, and governance layers remains low.
Cost is equally important here. While DIY may theoretically reduce software licensing fees, it often shifts expenses to implementation, maintenance, and internal complexity.
This means there are still real opportunities in categories that are operationally complex but suffer from insufficient technological supply, such as manufacturing, construction back-office operations, industrial processes, field service workflows, and accounting.
Other factors are equally important and will gradually become basic requirements for software.
For example, the ontology needs to change. Many ideas about "building your own database" underestimate the value inherent in the object model itself. Existing software is built for dashboards, reports, and human users, capturing objects within workflows—such as opportunities, tickets, and candidates.
But the schema of the Agent era needs to capture reasoning, actions, state tracking, exception handling, task delegation, and cross-system collaboration. Native object models may no longer be opportunities, tickets, and candidates, but rather tasks, intentions, threads, strategies, or outcomes.
Similarly, the permission system also needs to be updated. It is no longer just about managing human users, but also about managing Agents. This includes: who can do what, through which Agent, under what policies, what approvals are required, what audit trails should be left, and how to perform rollbacks and handle exceptions.
Of course, all of this comes down to costs, such as how much it costs to build and maintain Agents and databases, and how high API access costs are. This brings us back to several core questions: how difficult is data reconstruction, how many dependencies are involved, and how deeply the system is embedded.
So, what’s the conclusion?
As existing software vendors move toward headless architectures, they are implicitly betting that the data layer will remain the primary source of value. In certain categories, particularly those heavily regulated like financial services, this bet may still hold for some time, and the headless transition may proceed more slowly.
But for software entrepreneurs, as established vendors begin to de-interface, the questions of how to compete with them and how to build software with long-term defensibility are changing.
The next-generation record systems are already taking on different forms: they are no longer merely data warehouses for recording human work, but are becoming more agent-like—capable of capturing context, proactively initiating tasks, and logging the data trails generated during execution.
Going further, the most interesting companies will extend into the real-world execution layer: they will coordinate on-site staff, logistics providers, service teams, and physical assets, or act as intermediaries between multiple parties, enabling multi-party collaboration.
These companies will blend multiple business models from the old world. Meanwhile, the core of traditional record systems—data—will gradually recede into the background, becoming the foundational layer that supports the entire system.
Click to learn about the open positions at BlockBeats
Welcome to the official BlockBeats community:
Telegram subscription group: https://t.me/theblockbeats
Telegram group: https://t.me/BlockBeats_App
Official Twitter account: https://twitter.com/BlockBeatsAsia