与 Steven Sinofsky 谈企业软件的新规则

There are many things that made software sticky, but a lot of it had to do with the way a human interacts. In an agentic world, do you actually need that? The data, the logic, everything stored below it is really where the value is.

There’s this wild underestimation that you could vibe-code your way into enterprise software. Larry Ellison at Oracle went on a rant about how enterprise software was so stupid because everybody customized it. The minute you automate the most mundane thing and think you have it all squared away, whole new things appear.

The misconception right now is that you can just have a PostgreSQL database and APIs, and then, bam, you can replace SAP. That’s absolutely not true. The piece around the logic and everything else that’s encapsulated in SAP is way more important than the fact that this data just happens to be in this database.

One of the things that happens in technology shifts is that nobody understands exponential when it’s happening. The biggest opportunity right now is

Welcome to the a16z podcast. I’m here with Seema Amble, a partner here on the enterprise team, and Steven Sinofsky, who is a board partner at a16z, as well as a former member of Microsoft and friend of the firm.

We’re here today to talk about a piece that Seema wrote about a month ago called “Is Software Losing Its Head?” I’ll let Seema talk about it in her own words, but this piece was written a couple of months ago. Salesforce announced that they would be going headless, and today we’re here to discuss what that means for the future of SaaS products and for software more generally.

Seema, can you walk me through what headless software means and explain what changes it introduces?

Headless software isn’t a new term, but I think it has really risen in the public domain as a topic of interest. One of the interesting news points has been Salesforce making this announcement. They were launching Headless 360, which was, in classic Salesforce fashion, a marketing announcement more than anything else, but it does capture—or acknowledge—what’s happening.

Traditional software had been built around humans accessing it, and the workflow was to capture data. We could talk more about what that meant in an agentic world: Do you actually need that? The UI doesn’t matter because the agent isn’t accessing the software via the UI. We could unpack whether the UI matters or not, but the idea of being headless is that the data, the logic, everything stored below it is really where the value is—not just the workflow software that’s being tracked at the top.

Got it. This was announced a couple of months ago. In the past couple of months, what have we seen? You wrote in the piece that, at the beginning, you were being a little bit funny and asking whether this was really even that big of an announcement—whether it was more of a rebrand of APIs that Salesforce had already made available.

Does this feel like a significant change, or is it more of a branding exercise? What have we seen in the past couple of months as we’ve been able to observe what changes have really happened?

I’ll separate it into the Salesforce context and then the broader context, which I think is more interesting. In the Salesforce context, it’s probably not that interesting. I think Salesforce was rightfully acknowledging a shift that’s happening in the market. From what I could tell, nothing actually changed. Their Headless 360 product was the same APIs that had always been exposed, now rebranded as their 360 product.

APIs have existed for a long time. But I think the broader trend here is that Salesforce, among others, is thinking about how to build for the agentic world. If an agent needs to access the data in a CRM like Salesforce, are they doing it via the UI, or are they using the API? Salesforce is saying, “We know what is changing: Agents need to access the data. Let’s offer a headless version for them to interact with the data instead of going through the UI.”

That said, again, I don’t think anything actually changed in the Salesforce context. But Salesforce is in the old world.

Another example is Notion, which has a headless product. I think that makes even more sense because many users of Salesforce are probably less technically adept and less likely to be building their own agents, although there are many, many more people doing that with Salesforce. Notion users tend, all things being equal, to be more tech-savvy and more agentic as builders.

I think Notion is one of many other companies that are also trying to figure out what it is they offer and what APIs they expose. I think Steven will talk more about MCP. A lot of this is also getting caught up in nomenclature: What are we calling things? The broader trend around how agents access systems of record is the bigger point.

Yeah. From my understanding, this could also apply to something as simple as a chatbot. It’s not necessarily just an API or an MCP server. Salesforce acquired Slack a couple of years ago, and it could be something as simple as interacting with a CRM via a chatbot.

Totally. I think I read somewhere that there’s been a 300% increase in Slack agent usage, which is essentially saying that you don’t need to log into the Salesforce UI to get the data, or whatever data it is.

These are all agentic ways of accessing it, rather than a human needing to log in and enter the data or, from a read perspective, go back and see, “Here’s the opportunity. Here’s what happened,” and look at it themselves. That interface is less relevant.

Yeah. Steven, do you have anything to add here on the definitional territory that we’re covering right now, or on this discussion?

Well, sure. We’re in definitional hell right now, where part of a new wave of technology is that you make up a lot of new words for things you did before. That’s just a natural part of technology evolution.

I actually think it’s super important. First, you have an agent, which, as far as I can tell right now, is also a new word for a program that takes a very long time to run and might not finish. That’s just the best branding ever: A program that takes a really long time, which we used to call a bug, is now the coolest new feature ever, and it’s called an agent.

In seriousness, the most interesting way to think about what you’re really talking about doing differently between an agent and an API is: What are you actually doing? What is the agent itself doing?

Is it looking something up? That’s a pretty lightweight thing that all systems are good at. In fact, many of the newly announced headless agent APIs are just lookup. You basically have a new interface to the old way of looking something up, which is a lot more forgiving and involves a lot less UI goo and stuff like that.

Then there’s, “I want to do something,” and that’s where you get into very interesting issues. If you do something, you have to be impersonating a specific person. You have to have that person’s credentials. Is it another paid seat? Is it the same paid seat? You have all these interesting enterprise software issues that come up if you actually want to cause a change to a system of record.

Then there’s the third thing, which is analysis. Analysis is more than looking something up. It’s actually looking up a bunch of things. It often involves multiple systems, and that seems very well tuned to an agent because you’re not time-bound. You can spend energy, iterate, route it to different models, get different answers back, and compare them.

But it’s also where hallucination is a huge issue, because if you’re going to analyze something, you need a way to verify that every step of that analysis was correct. I think it’s super interesting and important when you look at headless and agents, which are conflated. You have to figure out what you’re talking about because we’re at different places in the evolution, the learning curve, and the deployment of agents relative to that 3-way matrix.

Yeah. I think this is a good lead-up into a follow-up question: Historically, what has made software sticky, and how are agents starting to disrupt that? I’ll leave that to either of you to answer. Maybe you can both debate about that.

I’d say there are many things that made software sticky, but a lot of it had to do with the way a human interacts with it. The UI was sticky because of the number of times you had to read and write, the frequency of access, the downstream workflows, all of the undocumented SOPs, or standard operating procedures—all the stuff that happened around the software that got ingrained in muscle memory and process—and then external parties, et cetera.

So, a CRM may be sticky because a sales rep needs to go in and out of it all the time. They’re used to interacting with Salesforce. A lot of times, when new VPs of sales come into our companies, they mandate that Salesforce is there because they’re used to using it, and their teams are used to using it.

Finance may rely on the Salesforce output for billing, and upstream marketing is going to rely on it as well. There are these dependencies, and they all drive stickiness. But I think the other piece, too, is that you need one single source of truth, right? You need to know whether an account is closed, who is working on it, and all of that needs to be logged in one place. If you go from CRM to, say, an ERP or payroll, that absolutely has legal and compliance reasons why you can’t have numbers that aren’t being tracked as cleanly and correctly as an auditor might like, for example.

So, anyways, this all drove stickiness and durability because you were used to using Salesforce, the whole ecosystem was using Salesforce, and it was the default option. Maybe there were 1 or 2 others in the market. Historically, those were some of the things that were driving stickiness.

Yeah. I mean, those are all exactly right. I think it’s important to also consider that the stickiest thing you could do is actually collect money from a customer. If you’re collecting money, it turns out it’s really, really hard for them to stop sending you money, and it’s really hard for them to figure out what to do if they stop sending you money. It sounds really trite, but the stickiest software is software that’s getting used somewhere.

Then, when you dig in and try to come up with reasons, it just depends on who you talk to in a company. You talk to the HIPAA compliance people in some company, and they’re going to tell you, “This is the software you have to use because it’s the most bestest HIPAA-compliant software.” If you talk to the administrators, you’re going to hear about onboarding new users. If you talk to the users, you’re going to hear about muscle memory and keystrokes, or labor unions, or whatever.

You really want to get the software sold, and that’s your fastest path to sticky. After that, it’s sort of a winner’s tale about what caused it to be sticky. In fact, the best thing about sticky is that if you’re the rep for a company that you’ve sold something to and the company is threatening you—“Hey, we’re going to replace you”—you’re just going to listen to them, and you’re going to find what’s sticky. If that works 3 or 4 times across different accounts, then you’ve just told the tale of what made the product sticky. It doesn’t matter what the PMs or what anybody else thought of.

It could be some crazy, arcane thing. I have stories of lots of sticky software and lots of arcane things. Anyone who’s ever tried to displace Microsoft Outlook for email very quickly learned about delegate access, having calendars owned by multiple people, and all of this crazy stuff.

I can tell you there was no meeting where we said, “Okay, let’s figure out how to make the calendar the sticky part of Outlook and make sure we handle recurring meeting exception handling well.” Then you go and find out that General Motors isn’t going to displace 600,000 seats because of the calendar, or some crazy thing like that. It’s really amazing in enterprise software what causes stickiness and how you can actually capitalize on it when somebody threatens to take you out of the enterprise.

I think there’s a really good point there in 2 ways. Inertia is a really powerful force.

And then I think the other thing is, yeah, nobody, when they’re building the software, is thinking about the rubric we put together and ticking off all these features that are going to do all these things. But I think the practical reality is also that as software extends its tentacles across an organization and gets ingrained in people using it, and they’ve been paying for it for a long time, it just seeps into how people are doing things. That’s hard to rip out.

Yeah. You even talk about this in your PC mode, where there are all of these invisible, tacit understandings about how to use different products or things that are embedded both within the software and within the people using them. It does become hard after a while to extricate yourself from whatever ecosystem you happen to be in.

In fact, Steven, I think you’ve even said the SaaS apocalypse is overblown. You’ve written an essay called “The Death of Software? Nah.,” where you emphatically rejected this idea. Maybe you want to recount that piece a little bit for us.

Well, I mean, Seema co-wrote a post on SAP, which is sort of the ultimate example of sticky software. The only software that’s stickier than SAP is behind the scenes, and it’s the software that insurance companies wrote. They wrote all this software 50 years ago or 75 years ago, and if you ever try to replace it, there’s no replacing it. Whenever jokes come up about businesses that are looking for COBOL programmers, it’s to go and work on the insurance software that exists in every state in the union.

In many ways, what you’re seeing with one of the biggest successes to date in Stripe has been somebody actually going in and, for the first time in 2 generations, coding up the software to collect money from people. That itself had previously been an unsolved problem on the scale of insurance because nobody put together the tax laws for every country, every jurisdiction, every locality, every border crossing, every currency exchange. It’s mind-blowing.

Now that is the stickiest. That is not going anywhere, ever. It’ll be like we’ll be doing this podcast with our great-grandchildren 100 years from now, talking about how sticky that experience was. Just like I told you: You didn’t know this, but the software that runs Allstate is older than me, and it’s not going anywhere.

That’s because these examples are ones that codified an external force, and that external force was the regulatory body that they embraced. The seminal example is SAP: It just codified a company. If you take SAP out of a large automobile manufacturer, there’s no automobile manufacturer left. Or Walmart—the company just evaporates because the company is defined not just by purchasing the software, not even just by using it, but by how it codified the business rules into that product.

I think it’s a good point to double-click on because I think a misconception right now is that you can just have a Postgres database and APIs and then, bam, replace SAP. That’s absolutely not true. I think partly—I don’t know if you want to elaborate on this, Steven; I’m happy to—but I think the logic and everything else that is captured in SAP is way more important than the fact that this data just happens to be in this database.

There’s a reason why SAP takes multiple years to implement and get up and running. It’s not because the system integrators are slow—part of it is—but because it’s customized to the way that a business actually operates. I think that’s an important part of why you can’t just abstract away the software completely and turn it into a database plus APIs.

Yeah. This is just so important because this is one of the things where startups look at enterprise software and think about it in terms of startup scale. They take something mundane like expense reporting and say, “Okay, well, we have 40 people, and 1 person could figure out expense reports for 40 people. You could hire a human and be done with it.”

You come back from a trip, dump the receipts in a bucket, and 1 human rifles through them, and the expense-reporting problem goes away. Or you say, “Forget the human. We’ll just all take pictures of our receipts, OCR them, categorize them, and the whole thing will go away.”

That’s fine until you have 100,000 people in 20 countries with different national laws and policies about business expenses. Then you overlay corporate policies, and the whole thing just becomes complicated. Your business is codified that way, and you can’t replace it.

Back in the late 1990s, Larry Ellison at Oracle—who is now sort of the godfather of enterprise software—went on a multiyear rant about how enterprise software was so stupid because everybody customized it. He had this saying that businesses should just stick with the 80% solution and use whatever works 80% of the time.

Most enterprise people were like, “A, you’re just talking your book because your software only does 80% of what I need. But B, that’s just not how it works.” If you take the top 10 companies in autos, putting aside EV versus gas or whatever, they all just make cars, which is a lot of known technology with assembly lines and workers.

What differentiates the companies is how they operate and the internal processes they use to decide what car to make, how many more materials to buy, what currencies to hedge, how many people to hire, and when to introduce a new product line.

All of that is enterprise resource planning. And how is all of that done? It's all in SAP. So those companies are effectively run by people sitting in conference rooms looking at SAP screens, and the differences between Ford and Toyota and General Motors and Daimler are not just that they're looking at the same screen. It's that they chose which screens to look at, which customizations to make in those screens, and then they go and buy steel and aluminum and wire and dashboards and radios from all the same places.

I just think that people wildly underestimate the level of sophistication that customers apply to this software. Back when we were first starting to get Excel used in companies, you'll laugh at this. We used to do these little visits, and we'd go visit bankers. So we're sitting in Goldman Sachs and we're telling them that Excel is better than Lotus 1-2-3. That's super old. You don't even know what 1-2-3 is. I know. Trust me, it's old.

The guy at Goldman looked at us and said, “I don't think you understand. We make more money from Excel than you do.” And we're just sitting there like, “What is he talking about?” It made no sense to us. Then we started to think about it, and it's like, well, we sell Excel to Morgan Stanley and JPMorgan Chase and everybody else. What Goldman was saying was that their application of Excel was so differentiated. That wasn't just people typing. They built add-ins, they wrote all this code, and they defined their workflows. There's this wild underestimation that you could vibe-code your way into enterprise software.

I was at a dinner last night, and there was someone there who was the head of RevOps at a—I don't know—maybe growth-stage startup. His task—this is a 1,000-plus-person company—was to rebuild their Salesforce instance internally. I think he was like, “Well, we know all the fields; we can import all the data,” and I was like, “That's not really the part that's tough, right? It's, well, how are you deciding what gets captured, how the whole organization lines up around it, and then who's going to maintain this over time?” I think that's a piece that just falls off.

You can vibe-code a CRM. We've all vibe-coded projects that have already gone stale and that we haven't touched again because it's painful. It takes time and needs to adapt to the business.

And Seema, you've also written about how there's an entire ecosystem of startups now that are just building on top of SAP and building around all of the headache-inducing stuff while still using SAP. So, to both of your points earlier, these legacy SaaS systems are so deeply embedded that the newer insurgents are just coming and building on top of and around them rather than trying to rip them out and get people to migrate completely.

A lot of what we're seeing AI being used for today is: How do you make it—I think the word is often used—conversational? How do you pull the information out and actually make it more usable? How do you retrieve the information from SAP without needing to run a SQL query and get all the information or look at a bunch of screens? If I want to connect to Steven's point around analyzing 3 different sets of tables in different geographies, can I quickly query that in a natural-language way? Can I get reports automatically generated that are customized to me without needing to go back through the SAP customization process?

I think that usability layer is indicative of what's happening now with software in general, which is that accessing the UI is optional. Going back to the Slack bots point, you want the information delivered to you rather than needing to go to the UI. But the data and the business logic inside—whether it's SAP or something else that's replacing it—still need to exist one way or another.

Mhm. That's an incredibly important point for folks to take away: the biggest thing about enterprise software is that it almost always does what somebody wants it to do. They just don't know how to make it do that. There's no report that SAP can't generate—no graph, no chart, no analysis, or whatever—but you just can't figure it out. Or maybe it's configured so you don't have permissions or something.

The way to think of it is that in enterprise software, the 2 most frequently used features exist in no enterprise software natively: export to Excel and export as CSV and/or PDF—you pick. So, in all enterprise software, the first thing they have to do when they show up and do that first demo is answer the question that the customer asks: “Does it export to Excel? Does it export to CSV or PDF?” Because then you know you have an escape valve to do the thing that you couldn't do before in analysis.

What's so cool about where we are today is that now, with language models, you have this incredible way to actually consume those in a much easier way than you could before. If you think about PDFs, the old way used to be, “Okay, I want to figure out exception handling—some report that my system emits, declined expense reports or whatever—but I want to do it over some weird time period or across different currencies that it doesn't handle, or some weirdness that you can't figure out in the UI.” So now you can export them all, take these 20 PDFs, put them in a model, and do a bunch of analysis that you couldn't do before—or, if you did, it was all copy and paste, this mundane thing—and turn it into something that Seema wrote about: these ad hoc business processes are the ones that really become the most interesting.

They're interesting because that's how a business runs, but they're also interesting because those are the next products. Those are the next companies that people start. CRM used to just be a spreadsheet. If you were in a business and were an account manager and kept track of your accounts, you just kept track of them in Excel, and then a company got started to do that. It wasn't SaaS. It wasn't Salesforce first. It was the predecessor called Siebel. Then people were like, “Oh, we should make a whole company that does this.”

And that's what some of these apps are that you're seeing, using language models and interfaces that are chat to SAP or to Salesforce. They're just trying to take advantage of what the LLMs are really good at, which is synthesizing and orchestrating unstructured information.

Yeah. I think we also forget that Salesforce is really an enforcement mechanism for the go-to-market team. It's like, okay, are you collecting all of the information that you need to? Of course, we can talk about Salesforce hygiene as a separate point, but do you have all the information you need? Is the human doing the work of getting the data to then capture the state of the business?

Which—okay, but I think if we now switch to the agent world—and again, we can talk about what agent means—imagine there's an agent that needs to do outbound calling or outbound messaging. They want to be able to retrieve that information. They don't really care about how the fields are organized or how many clicks it takes, but they do still need to access that information.

But then the second piece they need is this context thing. We've talked a lot—I feel like the internet has talked a lot—about context graphs over the last 6 months, but what is that? That's all the exceptions: What do you do? How do you handle certain cases? It's the edge cases, the permissioning, and all the policies that are not necessarily in the fields of Salesforce.

For the agent to then go back to this 80/20 thing, the agent can extract all the information and send an outbound email based on the information that's in the CRM about the person and their persona and what they do and all that. But then, okay, how do you deal with one case versus another and how they respond? It's like, oh, well, normally if it's a person who's in Asia, we respond this way, but if it's a person in the US, we respond this other way. That's not captured in Salesforce, but that was in someone's head. And so that's the context that's really important now for agents to be able to act on behalf of this data.

Oh, that's super. For Salesforce in particular, that's incredibly important because I've never met a salesperson, an account manager, or an account executive who thinks that the default is the right answer for anything with their account. And no—even if they get the Japanese language right, “Oh, it's spring and the birds are chirping, but you're overdue on your payment; your license count is wrong”—even if you do that correctly, the rep is going to want to handle it in their specific way.

I think this notion of exception handling is just the root of the challenge with agents, which is that almost everything interesting in an enterprise is an exception.

Yes. Yep, like that. People are all about exception handling. Basically, spend 15 minutes at McDonald's and watch people start at the kiosk and give up, and then go watch what they really want. They're like, “Well, I wanted a McFlurry, but I wanted 2 flavors and to mix them together, and that's not in the kiosk.” And it's always the exceptions.

And everything about automation in the enterprise is handling exceptions. It just is. It's the strangest thing. Enterprise pricing is a great example: How much is it per seat? Well, you have to call us. You call, then you talk, and then it's still an exception.

Yeah, that's exactly right. These exceptions aren't captured anywhere right now. Now, I think if there's a voice agent doing, let's say, compliance-check calls for freight, as one of our portfolio companies does, they're now collecting the exceptions through their voice agent and getting some of that context. Or, if we're looking—we can talk about computer-using agents—if you're observing humans, how they're clicking through software and responding to things, we now have the ability not only to record data or interactions but then process that by LLMs. Then you're able to start collecting some of this context, but there's a lot there.

As Steven was saying, all the interesting work is around the exceptions. It's not like, okay, 3 days later, we've got it all—we've got all the context—because sales cycles take a long time. Each exception isn't handled with a frequency that gets you the data immediately, right? You have to feel comfortable; you have to get to that point where you're like, okay, we've observed enough interactions to actually capture and understand the exceptions. Then, on the sales side, the buyer trusts that this piece of software has actually captured all the context to handle them.

Well, let me just add to that, building on that, because I think it helps us go back to this notion of headless and what both the challenges and the opportunities are. Of course, if you're an engineer—with almost everyone talking about what's going on in the world of AI today—you think headless and API, an agent API, are just interchangeable. So you think, "Oh, well, it's code; I can write the business process down." The problem you hit right at the beginning is that if you're not an engineer, you can't even explain the process that you use to resolve a customer issue.

In fact, it's very interesting to watch Amazon really do some of the best work on this because they really don't want to have humans. You can't call Amazon for anything; it's just hopeless. What they're doing is learning with everybody the best way to automate something, and it's their religion. It's their core principle: You just decide in favor of the customer.

They sent the wrong thing? You go to the chatbot, tell them, and the chatbot understands that you got the wrong thing and just sends you a new one. I think that's so interesting compared to old-school exception handling. Then they use the data to improve the internal shipping, handling, and warehouse process—maybe it's the product description, a zillion other things, or reviews.

I find that's what's so interesting about the capabilities of AI: It's driving a different definition and different behavior at companies about how to handle exceptions. When we get through the 1.0 version of this, we're going to get to a new version where people are comfortable letting AI do or decide things because they realize it's adding a level of predictability and repeatability to their enterprise.

It is. It's funny to think that maybe customer service gets worse in the short term because things stop getting decided by default in favor of the customer. Suddenly, you actually have to defend your case again instead of being reshipped the Sensodyne toothpaste you feel like you were owed.

More generally, it sounds like you're both saying that automating the long tail is still the hardest thing about all of this. Is that true, or would you say there are other hard things that developers and founders also need to think about?

I think that's part of it. I think there are a lot of other things around permissioning, and you could probably lump it into the long tail. Permissioning is part of this, right? As you give people—or give it—API access, which cases can people extract data? When can they write versus read? That all needs to be figured out over time as well, as do interactions between agents.

If you go back to the idea of a system of record, ideally there's one central repository of data that is the source of truth. But now, if you have multiple people accessing and writing to it, who gets to access it and when? These are additional problems that need to be solved—solvable problems, but they will take time.

Well, one of the things that happens in technology shifts is—you know the thing about nobody understanding exponential when it's happening—so you have to be very careful not to extrapolate linearly when something exponential is happening.

The same thing happens with productivity, or an analogous thing happens with productivity: People look at the existing body of work that happens today and say, "Okay, how do we make that easier?" Then all of a sudden there's all this fear that we're going to automate everything away, that everything is just going to become an API, which developers and engineers say, "Oh, that will be easy," and then we'll be in this nirvana world where everything is automated, easy, and predictable. But they forget that productivity drives new scenarios.

So the minute that you can get something easier with automation and can actually automate it—which I do think is happening right now with agents and language models—we're going to dream up a whole bunch of new stuff to do. I just mentioned this loop Amazon must be in on customer service. They got rid of all the phone people and the phone experience that would be miserable: doing a return, the challenge-response and the fighting, asking, "Can I return this? Do I have to package it up? Or will you just ignore it, like toothpaste?" They don't want it back.

That's a pioneering invention by Amazon: If somebody gets the wrong consumable, we just don't want it. They've opened it or used part of it; it's cheaper just to have them throw it away. Well, that never happened before. You used to have to actually bring spoiled food to the supermarket and show it to them.

So they've fixed that level of productivity, but now there's this backend that's just out there constantly figuring out how to make sure it doesn't happen again. Now they need a new level of analysis, a new set of tools. The long tail got no shorter; it just got longer in a different way.

Yes. I think people forget that that's how innovation works: constant reinvention. It's a growing pie, not a static pie. All the negativity around AI comes from thinking that the work to be done is this fixed thing that takes n people and m amount of software, and we're just going to replace n people with m plus 5, and then we're done. There are no jobs anymore; there's just an agent running. That's just never going to happen.

Legal is a great example of this. People do contracts, and they think that the law is going to help contracts get done quicker without lawyers. Except I can assure you contracts will get longer and more sophisticated and encompass way more sets of scenarios than a person ever could. And that's going to create a whole—

More litigation around it. And that creates a whole ecosystem. Look, there's the now-apocryphal, semi-apocryphal famous example of radiology, which is a correlation, not causation, but radiologists all love AI, and now we're having a radiologist shortage. It's not—there are a lot of reasons. It's complicated, but it just shows that the innovation wasn't static and the market for the demand wasn't static.

I think a lot of what happens at the enterprise level is that the minute you automate the most mundane thing and think you have it all squared away, whole new things appear. Expense reporting is a really good example. First there's nothing, then people figure out how to do spreadsheets, and then people figure out, "Oh, now we have a whole system. We can analyze it."

There's always another layer of analysis on top.

Always there. But the analysis then drives new processes and new behaviors that themselves differentiate companies. Business travel, to stick with that example, is a huge sink in most companies. It's just a giant expense hole that they wish they could shrink.

But once they can tie it to how things perform in their company, then it's more than just expense moderation.

It's actually figuring out performance optimization. Figuring that whole thing out becomes a different kind of job than just booking travel and analyzing expenses. It becomes this whole remote-work optimization tool, and then it's a different thing.

I think the other interesting thing—not to dwell or spend too much time on business travel—is that it also ties the physical and digital worlds together. There are always things that humans will be doing. Maybe it's not back-office TPS reports, but salespeople will be closing deals; there will be human interaction to close deals. People will be getting on planes as a result, and maybe they aren't spending as much time entering data into Salesforce or doing things along the way, but there will be humans doing online- and offline-world work. I think there will always be data exhaust from things to capture, optimization that needs to happen, and that isn't going away either.

Yeah. Well, I think open-source software development is actually a really good example of this, because the hardest thing in software development is that you have to be finished at some point so that everybody knows this is a stable release and can go build on it. The art of finishing is this long tail of not changing the code. And there's no API for that.

Developers don't hesitate to think there should be an API for that. They could think of a way to automate it with voting and a discussion that has sentiment analysis or whatever, but you still need a bunch of people to concur over a decision to fix or not fix something. And yet those same people will just say some other business process, like closing the books for earnings, should just be an API.

It's literally the same mental model. There's a bunch of stuff, and we're deciding when to close the books and what sales to account for, when, and where. It's fixing a bug, and there's a story around it, a narrative, and we have to explain it to our boss. If something goes wrong, we need a trail that explains who did what.

So much of what a business really is is just the people deciding things. All that software does is uplevel and abstract what they decide, how they decide it, and what tools they use.

The other sort of follow-up to Seema's point is that it's the best case for just recording everything you do, to capture if people are going and flying and closing deals in person. Make sure the software or the LLM can capture everything that happens at all times. Obviously, I'm not advocating for a full panopticon, but—

Synthetic gathering.

Exactly. Exactly. Whether it's recording conversations or taking emails and written artifacts and ingesting them, this is the way that the world is moving. So, yeah.

Yeah. Well, it's also to your earlier point: expertise exists in this cloud in an organization, and it is the untapped resource of the modern era. Aaron Levie at Box has done the most eloquent job of repeatedly explaining the assets that exist in all of these Word and Excel documents strewn throughout a company.

It's actually very, very hard to understand which documents are important and which ones to believe. Part of being in a company and having a culture is really knowing the answer to that. It's super interesting to watch the customers at Box use Box to actually answer those questions: Which are the sales PowerPoint presentations that are actually working? Which are the spreadsheets and the models that people actually rely on?

I think AI is the first thing to come along that really taps into that unstructured information in a company.

Before we wrap up, it might be good to visit the more immediate history and then the more faraway history of what headless software even is. Steven, I know you wrote a piece last year in reaction to the rise of MCP servers. In that piece, you also related it to the early Microsoft litigation that the Justice Department levied against them, and part of the argument was that Microsoft had a lot of products that could be categorized as middleware.

I'm just curious: In all of these different software waves that you've witnessed, in what ways is history rhyming and repeating? Maybe not on the litigation side, but on the product level. That part will continue, too?

Yes. It's super interesting. I love Seema to opine on where she sees things going with startups in this regard as well, so I'll go quick.

The real thing with MCP is that so much of what we're seeing now is driven by an engineering view of what would make for a good software architecture, and very little of it is being driven by seamlessly using the physical reality of the world. Of course, if you're an engineer, you'd love for every tool you want to use to have a very clean API, preferably a command-line interface that pipes text in and out. That would be perfect, but it turns out not to be how the world wants to work. There are many reasons why it doesn't want to work that way. Seema touched on many of them, like security and compliance, and things like that.

The reality is that no software wants to be disintermediated by some other layer above it. Nobody wants to just be put in a corner and told, “Your job is to just store this SQL format for expense reports and do nothing more. We're going to use you only for that, and, by the way, we're piping you through to some other tool to analyze expense reports.” That's not a growing business; that's a decaying business.

This whole notion that everybody is going to be perfectly content to be abstracted by some benign layer in the middle just doesn't really work that way. Customers actually do not want to assemble their scenario from a bunch of different providers, because your system will only be as stable as the most unstable part of that. If the expense-report company goes out of business, you're completely out of luck.

You want your expense-report company to be thriving and doing more stuff, even though in your head you're thinking, “I wish they would just stop. I don't want any more from them. It's getting complicated. They just did a UI reworking that's driving me crazy.”

The flip side is that those companies aren't just going to sit there and decay. They're going to look to the left and look to the right, and they're just going to do the stuff that they see people using with their product. SAP, the example Seema used—we're seeing this whole ecosystem grow up, and SAP is just going to do those things. That's the norm now. Not all of them, and most of them, they're not going to do very well.

In fact, just before this, I was talking to somebody, and we reminded them that in most giant enterprise companies, they view just a tie with some competitor as a win, because they'll just bundle it into their existing thing and give it away. This middleware layer is always, always very unstable. It looks great in a network-hierarchy diagram of the OSI levels of networking, but it's just never that stable.

Yeah. I think there are 2 things I'll add. One is the practical realities. Even going back to the Salesforce example, or Workday: Workday has had APIs that you could work with. But can you really extract all of the data out of Workday in a clean way and just operate without using Workday? No.

Workday makes it extremely difficult to actually get access to the documentation and work with the API, and they don't expose all the endpoints. To use the API example, this is analogous to what we're seeing now: It makes it a dumb database, right? They're not incentivized to do that.

I think what we're seeing is that there are 3 paths in front of you if you're a consumer or a business that's looking to buy software. One is that you take Salesforce and either turn on Agentforce or build all your agents on top of it, and then treat Salesforce as just the back end.

Some of that will work, but some of that will also not work, because Salesforce doesn't want that to be the case. They don't want to be just the data in the background, right? I think there will be mixed results around that, and I'm not bullish on the incumbent software building great agents on top.

There's option 2, which is that you just totally DIY it. You have the most control in that situation. However, based on everything we just talked about, that's really hard, right? You have to rebuild true enterprise software. For a startup, building or rebuilding a CRM is much easier than rebuilding a CRM for a Fortune 500 business.

It's a lot of business logic to capture, and you're also trying to do open-heart surgery while the patient is alive, right? Or whatever analogy you want to use.

Well, hopefully they're alive, but—

Yeah. Yeah. Yes, yes, yes. Of course, they're alive. I mean, you're taking the engine out midflight, or whatever you want to say as the analogy.

That’s really hard, and you have to get the practical realities of permissioning and collaboration and all that right.

Then there’s a 3rd option, and I think this is why we continue to do what we do in investing in AI software: there is a reason that agents can continue to be built, and the data can be sucked in and built in the background. A lot of what we’re seeing right now is things that are working alongside SAP, or a layer of visibility on top that is enhancing the experience and allowing the business user to then run agents on top of the existing data they have, while also not throwing out all of the logic they’ve had in the background.

Then I think they can also create a new system of record. Voice agents are collecting new data, recordings are collecting new data, and transcription and ingestion of documents are pulling in all of that documentation. Maybe one day these AI startups will replace the systems of record in the back end, but they’re doing so in a systematic way, observing how the business is operating.

I guess to close this out, Seema, you sort of just touched on this: where are we really seeing the biggest opportunities for startups right now?

A lot of this is what I was just saying. It’s doing the things that the incumbents are not doing right now, which is going from a layer of collection of data into, “How do we take action on top of it?” Take the CRM example. It’s not just logging all of the call information; now I’m providing the intelligence back around, “How do I prioritize leads? Which accounts should we work on? Which have risk of churn?” Flagging all of that and then sending the outbound.

Part of that is creating this agentic loop, where the agent sends the outbound, sees the response, and you’re understanding, A, what works and what didn’t and how people responded, and B, you’re also collecting benchmark data on, “This type of response is most effective in these cases. In Asia, we should be using this type of language or opening versus in Europe,” and so on. You’re now agentically collecting all of that, and that’s an interesting data exhaust.

The 3rd area I’d flag, too, is that we talked about the physical realities, but another part of physical realities is that a lot of the vertical software that builds for the physical world is a really interesting set of data that’s hard to capture and has historically been hard to capture. You’ll have to continue to pull together things that agents can operate on in software, but also what humans are doing out in the field and what machines are doing out in the field, and pull that back in. Construction, manufacturing, all of that.

The universal truth for enterprise software is that the most difficult thing to do, which happens to be the dumbest, is to attempt to compete head-on with an existing category. By head-on, I mean not just the same category, but doing it the same way.

The biggest opportunity right now is always, always to look at the existing mental map of enterprise categories and be in between 2 established players. The thing that established players won’t do during a massive technology shift is disturb their existing product line and go-to-market. They absolutely will just bolt AI onto their existing product. They won’t get rid of it, stop working on it, or do anything to break it. They’re just going to try to weather this technology storm by powering through it.

Your opportunity in a startup is to look at 2 big players who are bolting AI onto the side and exposing some existing API as an agent or whatever, and just aim for the middle. Do things in the new way. By not attacking head-on, you don’t show up at every single customer and have them say, “Well, you need to do these 8,000 things before you even enter the door.”

Instead, you have an equally difficult question, but one you’re in control of: “Why do you even exist?” That’s your own question. You don’t have to answer to a 20-year-old framework that was created to answer a bunch of questions that aren’t even relevant anymore.

The best example of this is HTTP and HTML. Client-server existed, but the reason those took over was not because they did all the things that client-server did. In fact, they did none of them, but they implemented that concept in an entirely new way. The web exists in spite of the fact that legacy vendors had $1 trillion invested in how client-server should work.

Well, I would say the other piece, too, is that it’s not just between 2 legacy vendors. I think now there’s a layer of translation between 2 different functions within an organization, too.

Oh yeah. Yeah, for sure.

Software has always sold to, “Oh, I’m selling into just the sales team or the finance team,” but then there are these handoffs, which is now the context on bills and deals. That actually also presents an interesting opportunity.

The last question I have is for Steven. Network effects are this thing we always talk about on the consumer side, and they’re a great source of defensibility. No enterprise software business, as far as I can tell, has successfully implemented network effects, but you could argue that they’re a good source of durability over time. I think Salesforce has tried this in a couple of ways in the past, but do you think enterprise software will start entering the field of network effects? Are we going to have both buyers and sellers on our CRM and therefore be able to mediate these transactions? I’m curious to get your take on that.

Certainly, network effects outside of a company are extremely difficult for a bunch of compliance and security reasons. But the biggest network effect in enterprise software is inside of a company.

We’re seeing that happen now with just chat. All of a sudden, you’re seeing this dynamic that almost felt like the good old days, when some very motivated person—most people who work in enterprises, it turns out, are not super interested in making their job better. They actually just want to go to work, get paid, and go home. They don’t come to work every day going, “How can I make my job better? How could I streamline my task?” They just want to not mess it up. That is a lot of the world.

There’s a small set of people, like those bankers at Goldman Sachs, who were saying, “How do I do more deals faster, better, with more clever models?” They were using Excel when the other bankers were using Lotus 1-2-3.

There’s actually an old commercial for Excel floating around on the internet—a launch TV ad from the late 1980s, where the first Excel spreadsheets were being used. It’s a person sitting there with this monstrous laptop that weighed like 12 pounds in an elevator, trying to use it. I’m laughing because, of course, they were trying not to run out of battery life during the elevator ride, which was invariably the case.

All of a sudden, this crowded elevator of people in 1980s ties and wearing 1980s glasses is looking at the spreadsheet and going, “What are you doing? How are you doing that?” They’re getting all excited. Fast-forward to 2025, and that’s exactly what happened with chat.

In fact, I had a friend at SAP who was writing an SAP white paper about something, and I just asked them, “Tell me what questions you’re trying to answer.” I did the prompt and sent them back a white paper. I’m positive I kicked off some sort of viral loop—not technically a viral loop, but some sort of network-effect viral loop—inside her team, because all of a sudden people are seeing how to make their job better, it’s accessible to them, and they’re doing it.

To your point, Elena, this idea of a tool that enables 2 functions to talk together that couldn’t before is golden. That’s exactly what enterprise software integration is, except that’s all manual, brute-force, hire-Accenture kind of stuff.

If you have products that bridge this, and you can develop software that leverages AI to bring together parts of an organization that don’t normally communicate, that’s a whole new category. Figma did a bunch of this with design and product development. We’ve seen that with things like IT budgeting, where IT and finance would end up with tools that helped them both do forecasting, and the cloud enabled that.

I think that’s a huge opportunity.

Nice. Well, I think that’s also an amazing note to end on. Thank you so much, Steven, for joining us here.

Thanks, Seema.

Yeah. And thank you.

And thank you, Seema.