Software System Reconstruction in the Age of Agents: When the User Interface Is No Longer a Moat, Where Does the Value of Software Flow?

Today I studied an in-depth long-form piece from a16z about Salesforce launching a no-interface product.

On the surface, it discusses whether software will lose its front end, but the author actually uses this topic to deconstruct the underlying logic of enterprise software systems, connecting the old logic of enterprise software, the new logic after AI intervention, and the changes in future product forms.

A few points I found particularly insightful:

• In the past, much of the stickiness of SaaS didn’t just come from data, but also from the interface, usage habits, and a set of operational rules not documented anywhere.

• In the age of AI Agents, the true moat of software may shift from the UI to the underlying data model, permission system, workflow logic, and the ability to truly enter the business execution loop.

• The article provides a very detailed comparison of CRM, ATS, and ERP, offering nuanced analysis of user stickiness, core competitiveness, and migration difficulty for different products.

• I also agree with the author’s judgment: the opportunity for AI-native software is not just to wrap an Agent around the old system, but to rethink what a software system should be in the new era.

Our company is also focusing on enterprise AI transformation-related businesses, including enterprise knowledge bases, vertical AI tool development, business process restructuring, and AI Agent application design. We have already established deep partnerships with multiple enterprises in industries such as e-commerce and new energy. If you have relevant needs, please scan the QR code below to talk to me.

Original link: https://a16z.com/is-software-losing-its-head/

Last month, Salesforce announced it would open its API and launch a no-interface product. Essentially, it’s betting that in the Agent era, Salesforce’s value will no longer come primarily from the user interface, but from the data layer. This is a clever repositioning. Of course, it should be noted that from a technical perspective, the actual changes seem minimal. The APIs that Salesforce is now marketing as a no-interface product have mostly existed for years. In other words, this is more like a typical Salesforce-style market launch.

The thinking behind this new product: Agents can directly access data in the system of record without needing to interact with the human-oriented interface used for tracking workflows.

This announcement raises a more interesting question: If you remove the interface and only expose the database, what remains? What is the essential difference between it and a Postgres database, a well-designed schema, and an API?

Will the classic factors that gave systems of record long-term defensiveness continue to exist, or are new criteria forming? In the SaaS era, systems of record were defensive because human users lived inside their interfaces for extended periods.

In the Agent era, this advantage will be diminished. The truly moated layer will shift downward to the data model, permissions, workflow logic, and compliance capabilities, and upward to network effects, proprietary data generation, and real-world execution capabilities.

When software becomes interface-less, where exactly does its moat transfer?

The Interface Was Once the Product Itself

A system of record is the authoritative source of truth for a specific type of business data. It’s where the official version of customer relationships, employee records, or financial transactions lives, and where other tools read data from and write data back.

CRM is the system of record for revenue-related data, HRIS for people data, and ERP for financial data. They are powerful not just because they store data, but because they become the foundational reality that the entire organization relies on to operate collectively.

Over the past two decades, Salesforce essentially sold a way for sales leaders to manage their teams. Dashboards, pipeline views, forecasting tools, and activity feeds were what users actually purchased. Its business model was built on selling access to these features per seat. The underlying database was of course important, but in user perception, it was secondary.

That is, what really drove user stickiness was the interface. The interface enforced data discipline, created a common vocabulary (e.g., lead, opportunity, account), and induced thousands of salespeople to enter data they otherwise wouldn’t. The interface was the key mechanism for maintaining data consistency. The product was so sticky that many sales leaders insisted on taking Salesforce with them when they changed jobs—not because the interface was great, but because it had become muscle memory.

Agents are beginning to disrupt this model. They no longer interact through the interface; they can read and write directly to the underlying data. This has also spawned a wave of new tools and workarounds that bypass traditional interfaces.

Salesforce is not the only example; we recently wrote about an entire ecosystem rapidly growing around SAP that is AI-friendly. Agents that can operate computers will also gradually erode human-level factors such as preferences, training, and undocumented context over time. In other words, the conditions required to be a long-term stable system of record are changing.

Historical Evaluation Criteria

Before discussing what changes the Agent era will bring, it’s necessary to accurately clarify why a system of record was sticky in the past. The initial factors were largely centered around how humans interact with software and the preferences of human users. The stickiness of software came largely from the interface, habits, human workflows, and processes embedded within the organization.

• How frequently is it accessed?

CRM is used daily by GTM teams and many other stakeholders. High-frequency use makes it critical infrastructure. The human layer built on top—ritualized processes, muscle memory, management rhythms accumulated over years—is often the hardest to migrate because many people don’t even realize these things need to be migrated.

• Is it a write-only system or a readable/writable system?

A sticky system of record is usually readable and writable. Take CRM: it’s not a write-only archive; it’s continuously read. Every call log, stage update, and task creation is input by someone, and that person usually cares about what they are doing. This two-way flow means any replacement system must handle real-time operational data, not just an export of historical data. There’s no absolutely safe switchover point, so once a company goes live, they typically stay with the incumbent vendor.

In contrast, an Applicant Tracking System (ATS) is often closer to a write-only system. Once a candidate is hired or rejected, there is limited reason to revisit that data.

• How much undocumented standard operating procedure (SOP) exists?

Critical business context is usually not in any ready-made knowledge base but is encoded in workflow rules built by administrators and system integrators over years. For example, in sales scenarios, undocumented context might include: enterprise deals over $100K need VP approval, EMEA deals require privacy review, strategic customer discounts can bypass financial approval only at quarter-end.

This context often determines whether something can be done in time or whether it violates important practices. Migration means reverse-engineering every automation rule, or directly losing the institutional memory that is indispensable in practice.

• Does this system have many internal or external dependencies?

The core question is how many internal systems, team processes, or external stakeholders depend on this system of record. Internal connectivity refers to other software or workflows downstream. External connectivity refers to external parties that need direct data access, like auditors, accountants, or regulators—ERP is a classic example. Whether internal or external, the higher the connectivity, the more pieces need to be untangled during migration.

• How critical is the data for compliance?

The core question here is simple: Is this system compliance-critical? Systems like payroll, ERP, and HR data require a legally defensible source of truth, strict administrator access controls, and direct involvement of auditors and regulators during migration. This significantly increases stickiness.

Sales data and tools like Zendesk (customer support) are at the other end. You care about continuity and context, but if data is migrated or someone gains access, it usually doesn’t immediately trigger regulatory exposure.

Not all systems of record have the same switching costs. Using the same set of dimensions to compare CRM and ATS shows stark differences. ATS is a workflow tool serving the well-defined process of hiring. Once a candidate is hired or rejected, the record becomes largely a one-time write. Its integrations are narrower, and its user base is smaller and more focused.

ERP is at the opposite extreme: the general ledger is an audit trail itself, your accountants, auditors, and regulators become direct stakeholders in any migration. Replacing an ATS is painful but tolerable. Replacing CRM is like open-heart surgery. Replacing ERP is like performing open-heart surgery while the patient is running a marathon 🤣.

Stickiness and migration difficulty vary for ATS, CRM, and ERP

Stickiness and migration difficulty vary for ATS, CRM, and ERP

Traditionally, systems of record did not really leverage moat-creating factors like proprietary data or network effects, because the workflow itself was usually enough to form a moat. To some extent, consumer internet businesses are better at combining tools and networks, whereas historical systems of record often did not achieve this.

• Proprietary Data

Many systems of record collect customer data but have not truly utilized it—often contractually they cannot. Therefore, even though CRM has rich data and could theoretically aggregate data across customers to generate cross-customer insights, they have not meaningfully done so in the past. Of course, there have been attempts, like Salesforce’s Einstein.

• Network Effects

The ideal state is network effects. For example, CRM becomes more valuable because software sellers can find buyers. But similarly to data, historically, network effects in systems of record have been at most weak.

For software systems like systems of record, what truly matters

For software systems like systems of record, what truly matters

If the Interface Disappears and Agents Arrive, What Remains?

Agents don’t need a browser. They need APIs, context, instructions, and the ability to execute actions. Two things enable this capability at scale.

First, LLMs are now powerful enough to reason. Therefore, an Agent can read context, make plans, choose tools, execute actions, and check outputs—and for most tasks, no human involvement is needed.

Second, MCP standardizes tool access, allowing Agents to call external capabilities through a common interface. An Agent with MCP access can, at millisecond scale, do what a human user does on a platform—without a browser. Given sufficient context, an Agent capable of operating a computer should even be able to directly navigate existing software interfaces, without necessarily needing an API.

In simple terms, software buyers now have three paths:

Path 1: Continue using existing systems and overlay Agents on top. Use the existing system’s CLI and API, either through the original vendor’s Agent product (e.g., Salesforce Agentforce, SAP Joule) or build your own Agents on top. Assume for now that the API is fully available and that going interface-less is not as operationally complex as it might seem.

Path 2: Build a completely in-house system of record. Build your own data model, operational logic, permissions, audit trails, integrations, etc., and build your own Agents from scratch—likely using third-party Agent-building tools and database tools.

Path 3: Purchase AI-native replacement products. Buy next-generation software designed from the ground up for the Agent era—built for machine readability, treating Agent orchestration as a first-class feature rather than a bolt-on. Such products may also be interface-less.

So, which of the old evaluation criteria remain valid?

Factors driven by human behavior and preferences will gradually fade, such as frequency of access and readability/writability tied to human muscle memory. Agents may eliminate human muscle memory as a moat, but they will not eliminate operational logic and context as a moat. Quite the opposite—they make these logics more important, because Agents need explicit rules, permissions, and process definitions to execute actions safely.

In the short term, undocumented stuff remains important. The institutional logic encoded in workflow rules is exactly what Agents need to depend on. It is also the hardest to rebuild. Currently, this content cannot be cleanly exported, especially when some process steps still involve humans. However, capturing context is becoming easier. As Agents replace more human labor, the importance of this factor will decline.

Connectivity remains hard to untangle and expands in scope. The connectivity factor will shift. It is no longer just to serve human users, but to maintain connections between traditionally siloed functions and software. A CRM Agent needs to string together data and context across sales, billing, and customer success. If your platform is also a node where Agents from multiple external organizations transact (e.g., interaction nodes between buyers, sellers, and partners), dependencies deepen further. Overlaying Agents on existing systems makes it harder to collaborate across different underlying software primitives; building your own database and Agent combination also faces this problem.

Compliance-critical data remains important. Data subject to regulators, or with regulatory and legal risk, requires a single, trustworthy source of truth. If customers trust the existing product, they are unlikely to switch lightly. For example, payroll and accounting data—Agents may want to access this data, but you are unlikely to want to build and maintain the entire system in-house. In a fully Agentized world, one of the hardest problems is:

Which Agents are authorized to do what? On behalf of whom? How is auditability ensured? If a system of record becomes the identity and permission layer in Agent-to-Agent interactions, it will have a truly hard-to-replace structural role. It would be difficult to replace, not because it holds data, but because it executes a trust architecture.

The End.

———— A Bowl of Beef Noodles