Salesforce’s next growth opportunity just may come from customers spending less time in its interface, and having agents do more of the work.
Coming out of Dreamforce 2026, we believe that is the shift worth exploring. The progression from command lines to graphical interfaces, browsers and mobile is entering the next phase. Specifically, an agent can now generate an interface around a task, inside Claude, Slack or another client surface. The customer no longer has to start with the application’s screen. The starting point becomes a desired outcome.
But generating an interface is not the same as understanding the business. That is where our AI enterprise software framework comes in. The system of engagement (SoE) is the new client interface and connects people and agents. The system of intelligence (SoI) supplies the business context. And the system of agency (SoA) turns that understanding into action. Salesforce’s larger ambition is to connect these elements through what it calls an enterprise AI harness, comprising data, business knowledge, workflows and controls, that let models do useful work across systems. This goes well beyond answering questions. It blends deterministic software with the stochastic qualities of LLMs to completely change how organizations and professionals work.
Surveys show interest in Agentforce and Headless is nearly universal
The customer evidence from our friends at Qualitate, suggests an opportunity for Salesforce, but the data also underscores the company is in transition. Qualitate’s latest channel checks find that most organizations interviewed remain in Agentforce pilots or proofs of concept. Yet among customers who have modeled or experienced the financial impact of headless access, 75% expect Salesforce spending to increase, not decline. Working outside Salesforce’s interface could actually mean doing more work on its platform.
That creates both upside and a challenge. More consumption can generate more revenue, but it does not automatically generate more customer value. Pricing must make sense as pilots scale. And if customers increasingly work through their preferred AI environment, Salesforce must demonstrate why its business context and execution capabilities remain an essential underpinning of the customer experience. The point is, the interface can move elsewhere, meaning the next purchase may not automatically stay within Salesforce.
Welcome to Breaking Analysis #327.
In this episode, we map Salesforce’s post-Dreamforce direction into our System of Intelligence framework. We combine firsthand observations at Dreamforce with new Qualitate customer research to examine headless access, Agentforce maturity, competition from AI-native agents, and the changing relationship between pricing and business outcomes.
In this post, we not only explore the question of whether Salesforce can sell more AI – it will. The real issue is can Salesforce grow beyond its own interface by becoming the system that makes AI most useful to the business.
The system of intelligence connects AI to the physics of the business
The slide below shows the AI stack framework we have used to examine leading platforms including Snowflake, Databricks, Google, Amazon and others. Developed by George Gilbert with Geoffrey Moore and adapted to the new AI stack, the framework has evolved over the past couple of years, but its basic structure has not changed. What has changed is that the software vendor community is now rolling out products that fit into it.
The starting point is the analytic data platform, shown in orange at the bottom left – the Snowflakes and Databricks of the world. Customers have historically used these platforms to aggregate their operational data, transform it and bring it into one analytic environment. But putting the data in one platform does not eliminate the silos. The data cubes – i.e. the structures used to aggregate, slice and dice the data – remain individual silos because of how that data is modeled. On the bottom right are the traditional systems of record, including Oracle, SAP, NetSuite and Salesforce itself.
Above those foundations sits governance metadata. These are the catalogs that allow the data to start making sense to both humans and agents. The vocabulary becomes people, places and things – in other words, not just column names and table names. The data becomes understandable in terms that humans and agents can use.
The green layer is the core: the system of intelligence, which we believe is the most important piece of real estate in enterprise software for the next 15 years. This is what connects general-purpose intelligence, in the form of a large language model or an agent, to how a particular business works – the physics of that business if you will – and how its model of the business improves over time.
At the most basic level, this starts with familiar business intelligence concepts: metrics and dimensions, such as revenue and churn. But the full system of intelligence goes beyond those measures to represent business processes. For example:
- How does the organization perform quote-to-cash?
- How does it onboard a new employee?
The system of intelligence provides the map that allows agents to understand the state of the business and work within it.
The system of agency, shown at the top, plugs into that map to do work. An agent reads the state of the business, reasons about it, makes a plan and then operationalizes that plan through the system of intelligence. The workflows effectively become tools that agents can use. Alongside these layers, the system of engagement provides the human and agent experiences for interacting with insights, decisions and data.
What stood out at Dreamforce was that, for the first time, we saw a vendor explicitly connect the familiar concept of an agent harness – usually treated as a standalone piece of software – to the system of intelligence itself. For Salesforce, that brings together Data 360, Agent Fabric from MuleSoft and the Application 360 semantics. Salesforce is now describing that combination as its agent harness.
The proposition is to take whatever model the customer wants, make it useful in the context of the business, and allow its value to compound over time. That is the connection between general-purpose intelligence and the business-specific knowledge and workflows represented in our framework.
With that foundation, we can map Salesforce’s approach into the stack, starting with the system of engagement and how the application interface is changing, then bring in the customer evidence.
Introducing Qualitate – New data shows universal interest in AgentForce and Headless
Before digging into the architecture, it is worth reintroducing Qualitate, which we first brought to our audience ahead of CrowdStrike’s Fal.Con event. Founded by Sagar Kadakia, one of ETR’s early data scientists, Qualitate combines an expert network with an agentic research platform. Rather than relying on multiple-choice surveys, its agents conduct interviews in which people answer questions in their own language. The platform captures those responses, then uses AI to combine and categorize them.
We describe this as “schema on read.” Instead of forcing an expert’s experience into choice one, two, three or four – which may not accurately describe that experience – the platform lets the person explain it. The structure comes from analyzing the responses rather than requiring every answer to fit a predefined box.
The Salesforce study released alongside Dreamforce drew on 20 in-depth customer interviews, conducted within five business days. These were half-hour to hour-long conversations, so the sample is small, but the interviews provide depth beyond a conventional multiple-choice survey.
The initial findings set the context. Agentforce remains early, with most organizations still in pilots or proofs of concept, but roughly three-quarters are open to adoption and only about one-quarter are uninterested. The interviews show no evidence yet of Agentforce funding detracting from existing Salesforce budgets, and the most common allocation is 5–15% of Salesforce spending. Flex Credits are helping some customers get started, although pricing remains a discussion we will return to. [Source: Qualitate].
Agentic interfaces become the new system of engagement
The slide below maps the system of engagement in our AI stack to a novel interface model. It shows a Claude client accessing Salesforce through Headless 360 and generating an interface around the data and functions the user needs. The progression across the top underscores the shift from command line-> graphical interface->browser->mobile. The next step is an agentic UI, generated on demand rather than designed as a fixed set of application screens. The Qualitate customer research on the right helps explain the shift in more quantatative detail.
Headless 360 is, essentially, Salesforce without its user interface. Salesforce exposes functionality through MCP servers and APIs, while plugins – i.e. collections of skills – allow clients such as Claude and Slack’s Slackbot to navigate that environment. Those clients can work with the data, definitions and business context Salesforce has brought together.
The important part is that a coding agent uses that context to generate an interface specific to the work a person wants to do. After years of trying to simplify Salesforce’s interface, attract more users and expose only the functionality each person needs, that experience can now be generated on demand. It is a generative user interface with a coding agent behind the scenes.
The examples discussed at Dreamforce include Claudeforce, Slackforce through Slackbot, and Agentforce Coworker within Salesforce’s Lightning interface. These are different ways of presenting the underlying capabilities to a user. In the example on the slide above, Claude is the client, Headless 360 supplies the Salesforce context, and a coding agent builds the interface the human interacts with.
In our view, this was among the most immediately relevant, useful and impactful announcements at the conference. Salesforce is becoming a semantically harmonized data repository that can unify customer-related data and serve it in the context a user needs. The interface no longer has to be the starting point. The data, its meaning and the functions the user needs can determine the interface.
This is the result of engineering work we have been following for a couple of years. The prevailing narrative was that Salesforce’s acquisitions – e.g. Tableau, Slack and others – had left it with a collection of disconnected assets. What we saw underneath was substantial work to bring those assets together, beginning around Data Cloud, evolving into Data 360 and now surfacing in the capabilities shown at Dreamforce. The integration with Anthropic is part of that progression. Salesforce has moved from being viewed as a collection of products to being firmly in the mix in the agentic era.
The Qualitate findings indicate that customers are receptive to working beyond Salesforce’s screen. Approximately 90% of respondents to the headless question are already accessing Salesforce outside its UI or are planning or interested in doing so. In the discussion of why customers were moving headless, seven of eight cited consolidation around a preferred large language model.
The spending data from Qualitate is also important: 75% of those who had modeled or experienced the impact of headless access expected Salesforce spending to increase. [Note: That is a finding about the evaluated subset – not a statement that three-quarters of all participants had modeled the economics]. The point is, moving outside Salesforce’s interface does not necessarily mean spending less with Salesforce. We will return to that relationship when we examine pricing and consumption.
At the same time, customers and developers have established preferences for the clients and tools they use. One respondent said, “Our developers are pretty standardized on Claude Code.” Another said, “We are a Microsoft shop using a lot of GitHub Copilot.” These comments concern existing development-tool preferences, but they illustrate the affinity described in the discussions. Qualitate also found that existing Claude usage was the strongest predictor of sentiment toward Claudeforce. The point is Claude affinity is real, but it is not exclusive.
Our interpretation is that Headless 360 moves Salesforce beyond an application UI into an agentic environment – but also makes the preferred client more strategic. There is a crowded field of agents and development environments. Customers do not necessarily want to abandon the one around which they have already organized their work.
One distinction is important to the framework. Here, we are examining the system of engagement – i.e. a coding agent generates an interface for a human to use. The same Headless 360 can also expose data and workflows as context for an agent to take action, potentially with a human in the loop. That is the system of agency, which we will examine later. One creates a tailored experience for a person; the other grounds the work of an agent operating on the business.
This change in interaction already resonates with our own research experience. Within days of onboarding to the Qualitate research platform, we had launched two studies – one around ServiceNow Control Tower customers and another around CoreWeave – and were already receiving results. The process involved talking to the platform, collaborating on the structure of a study and launching it, rather than navigating a lengthy sequence of predefined steps. It is a transformative experience that involves speaking to the platform and the data becomes a practical way to get work done.
The next example brings that same generative interface model into Slack, connecting the system of engagement directly to the collaboration layer of our framework.
Slack becomes a collaboration-native system of engagement
The slide below connects the collaboration box in our AI stack to Slack as a system of engagement. The principle is the same as the previous example – i.e. Headless 360 operates in the background, while a coding agent generates the interface. The difference is that the generated experience now sits where people and agents collaborate.
In the Claude example, an individual interacts with the application and might generate an artifact to share. Here, Slackbot generates a custom interface for interacting with Salesforce data, actions and workflows inside a collaboration environment. Users can work with colleagues within the enterprise or across enterprises, and they can interact with other agents. Slack becomes a work surface for humans and agents collaborating together, rather than simply a place where an individual asks an application a question.
We believe this can make a significant difference in Salesforce’s accessibility, including for potential new users. The underlying functionality remains in Salesforce, but the experience is generated where the collaboration already happens.
The broader opportunity extends beyond Salesforce. In the example shown, the coding agent has the skills needed to navigate Headless 360. But with MCP servers and APIs connecting other applications, the same approach could generate an interface that brings together Salesforce data with SAP, NetSuite or other enterprise systems. Slack could become both a UI and a collaboration environment for those applications.
Generating the interface does not, by itself, harmonize the underlying data. That still requires work, and the user may have to bridge differences between the systems. Nevertheless, this represents a first step toward bridging the application silos we have lived with for years. The interface to the back-end systems is generated around the work, rather than requiring the user to navigate each application separately.
The headless findings on the right from Qualitate repeat the evidence from the preceding slide; they are not separate measures of Slack adoption. The customer commentary, does however connect the shift directly to Slack and its potential spending implications. One respondent explained that as representatives begin using Slack or other tools outside Salesforce’s UI, “some of those API costs or consumption costs would maybe offset some of the savings that we’re seeing on the seat-based side.” More work outside Salesforce’s screen can still mean more consumption inside its platform. We will return to what that means for spending and pricing.
The awareness findings from Qualitate require a distinction between Slack Code and the Slackbot-generated interface demonstrated above. Qualitate found that 60% of participants had not heard of Slack Code at the outset of their interviews. Conversely, 40% had some awareness. We found this finding noteworthy for an early offering, but not a measure of awareness or adoption of the newly demonstrated Slackbot experience at Dreamforce.
Seven respondents reported no interest in Slack Code because of entrenched alternatives, while one was monitoring it with some developer interest. Examples included teams standardized on Claude Code and a Microsoft shop using GitHub Copilot. These are existing development-tool preferences, not evidence that those organizations have rejected Slack as a collaboration environment. The study also notes that the interviews did not go directly to development teams, but did ask respondents about developer sentiment, which may help explain some of the limited familiarity. [Source: Qualitate].
Governance is another qualification. Some customers in the Qualitate survey find the prospect of accessing applications through these new interfaces attractive; others want more proof before becoming comfortable with it. Respondents raised concerns that MCP may not yet be enterprise-ready, along with security, data leakage and pricing opacity. These are customer concerns about readiness, not a finding that the architecture cannot work. We would expect regulated organizations, in particular, to want more evidence before expanding their use.
The significance of the demonstration is therefore not that Slack has already become the interface for every enterprise application. It is that a coding agent can generate a shared work experience over enterprise data and workflows, bringing the system of engagement into the collaboration layer. That brings us to the platform underneath – i.e. the data, semantics and workflows Salesforce must connect to make these generated experiences useful.
The enterprise agent harness connects business context to action
The slide below, drawn from Marc Benioff’s keynote, maps Salesforce’s platform to our system of intelligence. The red box highlights Customer 360 and Data 360 – i.e. the application semantics, workflows and data that support the agents and interfaces above them. This is where Salesforce is redefining the agent harness for enterprise work.
In the age of agents, both humans and agents must be able to read the data and understand what it means – i.e. the state of the business. They need that understanding to reason about possible actions and outcomes, then take action. The question is what the harness must provide to make that possible.
Much of the rapid development around agent harnesses has centered on coding agents. Two critical elements are memory and context, which, for a coding agent, come primarily from the codebase being worked on. The tools allow the agent to read and write to the file system and edit that codebase.
Salesforce’s message was that we need to rethink the harness when the agent’s job is to work inside an enterprise application. In this setting, Data 360 becomes the memory and context – i.e. the CRM data that describes customers, their profiles, and where they sit in a sales or service process. It represents the state of the business the agent needs to understand.
Customer 360 supplies the application semantics and workflows. Every agent has tools, but the tools here are business actions. Examples include issue a refund, activate a customer segment or run a particular type of campaign. Instead of editing a file, the agent is working through the enterprise’s processes.
There is no shortage of agent development kits. What distinguishes them is the harness. Grounded enterprise data and enterprise workflows are what make Agentforce useful. That is the significance of connecting the familiar harness concept to the system of intelligence we have been describing.
How data platforms fit into Salesforce
Snowflake and Databricks are not explicitly shown in this stack, but their absence from the slide does not mean customers are expected to abandon them. We have debated whether Salesforce needs to acquire a data platform, and our view has always been that partnering is the better approach. There will be overlap in the Venn diagram, but that does not make these platforms mutually exclusive.
The Qualitate customer conversations reinforce a preference we also heard at the conference: customers have standardized on Databricks, Snowflake or both, and want a customer data platform that can layer over that investment. They recognize the capabilities of their existing platforms and want to retain them. They want composability, not another requirement to replace the data foundation.
The irony is that Data 360 should fit that requirement. We believe it is best understood as a customer-process model that layers over the existing Databricks or Snowflake environment. Its Zero Copy capability allows it to point to the relevant data in those platforms. When a Data 360 query is issued, it dynamically accesses that data and brings it back, or caches it locally. The architectural idea is a value-added layer above the existing data platform, not necessarily a replacement for it.
Salesforce still has work to do to make that relationship clear and easy to implement. Part of the challenge is organizational. The technology side of the house has historically been responsible for platforms such as Snowflake and Databricks, while Salesforce has been deeply entrenched on the business side. Salesforce must earn credibility with the teams that own the existing data environment.
Composability, in this context, means customers can see and deploy a set of components that work better together on top of the technology platforms they already use. Salesforce is still working on that positioning and on making deployment straightforward enough to deliver the expected time to value.
That is important because Agentforce looks to Data 360 for its context. In the architecture we are describing, Data 360 is a prerequisite, although how much needs to be in place depends on the deployment. This has been one of the limiting factors for Agentforce – i.e. the context layer must be installed before agents can use it to do useful work.
In our assessment, that dependency means Agentforce’s immediately addressable market, at any given time, is bounded by the customers with Data 360 installed. Making that foundation easier to deploy – and easier to understand as a complement to existing platforms – is therefore central to expanding the opportunity.
The next step is to examine how this enterprise harness brings knowledge and workflows together across the functional silos that have traditionally shaped enterprise software.
Deterministic applications do not make a deterministic enterprise
The slide below shifts from the platform architecture to the organization it must serve. Enterprises were built around people specialized into functions and departments, with applications, processes, screens, permissions and workflows reflecting those divisions. The enterprise AI harness and system of intelligence are intended to bring knowledge and workflows across those functional silos.
Getting there can be a heavier lift, depending on how much of the capability an organization wants to use. The Qualitate research includes reports of difficult implementations and hallucinations in Agentforce pilots. We expect the hallucination issues to improve over time, but they remain a concern for some customers today.
This brings us to an important insight from our late colleague David Floyer, who did some of his best work in retirement and whom we miss dearly. We often discuss bringing deterministic and probabilistic software together: one operates through highly structured rules, while the other estimates based on probabilities. But Floyer challenged the assumption underlying that distinction. Determinism in many organizations is, in fact, illusory.
An organization might have determinism within its HR system, its CRM, its logistics application and its financial system. But bringing those systems together does not necessarily produce a deterministic result across the business.
The reason is that people have historically been the bridge between the silos. Parts of processes such as procure-to-pay or order-to-cash may be hard-coded into applications, but people connect the work across those applications and departments. However deterministic the individual systems may be, that human bridge makes the overall process non-deterministic.
We hear considerable emphasis on the non-deterministic nature of agents. Floyer’s point was that the enterprise processes into which those agents are being introduced were not necessarily deterministic to begin with. The structure existed within the applications; people supplied the connections between them.
That is where the enterprise AI harness and the system of intelligence come in. The intent is to harmonize data across departments and applications and inject process knowledge into workflows. Breaking down the silos means bringing together knowledge and processes that previously depended on people to bridge the gaps.
The next step is to examine how the harness brings that knowledge and those workflows together, connecting the intelligence of the model to the way the business actually operates.
Connecting applications is not enough: Agents need a harmonized map of the business
The slide below makes the distinction between connecting enterprise systems and giving agents the knowledge to work across them. The upper-left graphic shows the connections; the lower-right graphic positions the AI harness between the models and the business. Connectivity alone is not enough. Agents need a harmonized map of the business, its data and its workflows.
Why can’t an agent simply connect through MCP servers or direct APIs to all the enterprise’s applications and go to work? Because an agent needs an even more explicit map than a human does. It must understand that customer 103 in one system is the same as Acme in another. The way revenue is calculated in one application must map to how it is calculated elsewhere.
That requires a layer above the silos. As we discussed in the previous section, humans have historically been the bridge between those systems, making the overall process non-deterministic even when individual applications follow deterministic rules. The enterprise harness starts to put more explicit structure around those connections.
This is the first time we have seen a vendor (Salesforce) describe the harness not simply in terms of an individual agent’s memory and tools, but in terms of how the enterprise works: its state and its workflows. The aim is to create deterministic bridges across the silos. Those bridges do not dictate everything that must happen. They establish guardrails around what an agent must do or must not do, along with controls on its actions.
That distinction is important as agents move beyond basic tasks. Practitioners deploying AI describe it as increasingly good at mundane data-entry work. Higher levels of agency, involving more complex workflows, remain more challenging. This is where we have expected Salesforce to have an advantage because of its underlying application logic and process knowledge.
We expected Salesforce to be among the first big winners with agents. The platform has harmonized semantics for how customer data is defined and the processes through which it moves across the organization. But having that foundation did not eliminate the gaps in flow definitions and the metadata describing how things work.
Those gaps were acceptable when a human was looking at a screen. The person could interpret what was missing and bridge the gap. An agent needs those definitions to be explicit enough to make decisions without that ambiguity. Cleaning up the underlying flows and metadata required considerably more work than the existence of an integrated platform might suggest.
This brings us back to the Claudeforce and Slackbot experiences. It is much easier to generate an interface for one person working with a small set of back-end functions than to have an agent execute work across an entire collection of workflows. In the first case, the agent generates the experience through which a human interacts with the application. In the second, the agent must understand and act across the processes themselves.
That is why we believe the generative user interface has greater near-term relevance for Salesforce customers than end-to-end workflows and outcomes executed by agents. The enterprise harness is important to the broader opportunity, but the work required to make those workflows unambiguous helps explain why generated interfaces can deliver value sooner.
With that distinction established, we can turn from the system of engagement to the system of agency – and how Salesforce is packaging role-specific agents to do the work.
Role-specific agents accelerate time-to-value…Agent traces drive improvement
The slide below moves up our framework to the system of agency. Salesforce positions Agentforce as its digital workforce, above Customer 360 and Data 360, with AIforce providing the interface layer at the top. The objective is faster time to value – i.e. give customers role-specific agents rather than require them to custom-build each one.
This connects to the system of intelligence we have been describing. The task is not only to harmonize data, but also to capture the enterprise’s tacit knowledge through workflows and potentially develop new ways of working. A critical part of that is the closed loop between the emerging client surface and the back-end system of intelligence. The back end learns from the front end, including the reasoning traces of humans and handling exceptions. In our framework, that learning is what allows governed data to incorporate the tacit knowledge needed to support confident action.
There are plenty of agent builders. The Qualitate research includes an organization already using AWS Bedrock for agentic development and other tools. But building an agent is only part of the job. The agent must be governed and operate within a trusted control framework. That is the broader requirement Salesforce is addressing.
The agents shown on the slide above package capabilities around specific roles: Piper for inbound pipeline generation, Hunter for outbound sales, Casey Help for Service Cloud, and Paige for IT service management and HR. The idea is that customers do not have to enter Agentforce and build each of these from scratch. The work shifts toward configuration. In other words, ensure enough back-end knowledge is in place, then tune what the agent does.
More model choice is another important part of the approach. Customers can choose Claude or OpenAI, but Salesforce also introduced its own reasoning model. As described at Dreamforce, Salesforce took an NVIDIA open-weight model (Nemotron) and post-trained it on the Salesforce environment so it could reason through and interact with that environment. While reports from practitioners indicate Nemotron is less functional than the leading OSS models, it’s only a matter of time in our view before Nvidia closes that gap.
This gets back to an idea we have discussed before: a mid-sized model, post-trained on a specific environment, can be more cost-efficient and performant for work within that environment. We expect a family of models: frontier models for the hardest reasoning, with a Salesforce-native model available for everyday work. The point is not that every task needs the largest general-purpose model, but that the model can be matched to the work it needs to perform.
There is also an important layer that is not visible on this slide – the fabric coming into place for discovering, orchestrating, governing and observing agents. Observation is particularly important because the objective is for agents to learn from the outcomes of their actions.
That means going back through the agent traces – the reasoning traces and the tool calls – to examine which led to successful outcomes. Those findings can then be used to improve the agent, whether through better prompts, better-constructed context or, eventually, fine-tuning the model itself.
This is a new type of analytics. The observability data provides the “breadcrumbs” for understanding how an agent performed its work and how that work can improve. It connects the actions an agent takes to the outcomes it produces, feeding the learning loop rather than ending with the completed task.
In the consumer online era, user clicks fed the matching and recommendation engines of companies such as Google and Facebook. Those signals helped the systems improve. In the agentic enterprise, agent traces become the signals that help make agents smarter. Role-specific packaging is intended to shorten the path to initial value; learning from outcomes is how that value can improve over time.
The next example takes that time-to-value objective into customer service, where Salesforce is also pursuing a standalone agent approach.
Fin offers a faster start without the full enterprise harness
Just this month, Salesforce closed the acquisition of Fin, for which it paid $3.6B. The slide below positions Fin as a standalone customer-agent offering to counter Sierra and other alternatives competing on ease of setup. The goal is to let customers get something running quickly without first putting the entire enterprise harness in place.
This is the other side of the platform discussion. The enterprise harness brings together Data Cloud and Customer 360 to provide business context and workflows. But the requirement to install Data Cloud can be too heavy a lift for some customers trying to get started with Agentforce. That dependency is why we have described the immediately addressable market for the platform-led Agentforce approach as the Data Cloud installed base.
Not every customer needs that full environment to begin a proof of concept or pilot. Some need access to only a couple of Salesforce objects and a limited amount of data, whether from Salesforce, Databricks or Snowflake. Fin is the answer for customers who want that narrower starting point, with the kind of quick setup offered by Sierra or Decagon.
The experience we saw at the Salesforce Dreamforce booth centered on scripts, a natural-language development environment and straightforward connections to a few API endpoints. The interaction is similar to connecting ChatGPT or Claude to a tool. Rather than installing the whole platform, the customer connects the capabilities needed for the task and gets started.
We believe that is a compelling offering for organizations that want an agent working with their Salesforce environment but are not ready for the heavier implementation. The distinction is between deploying the full enterprise harness and getting a specific agent use case up and running. Fin gives Salesforce an answer to customers who prioritize the latter.
There is also a notable competitive connection. Bret Taylor served as Salesforce’s chief product officer, chief operating officer and eventually co-CEO before co-founding Sierra, while also becoming the chairman of the board at OpenAI. Salesforce is now competing with its Fin alternative on the practical question of how quickly a customer can get started. Qualitate customer data suggests alternatives like Decagon and Sierra, while having momentum in the market, continue to face the classic enterprise software sales challenges of long sales cycles and proof of enterprise-grade capabilities. Salesforce, with Fin, can potentially attract skeptics that want a safe, integrated, “good enough” alternative.
Ease of setup is one part of the value proposition. The next question is how customers pay for the work, and how pricing and spending evolve as those initial pilots scale.
Pricing shifts toward outcomes, but the growth model remains unsettled
The slide below brings the architecture back to the business model. BCG’s pricing framework describes a progression from charging for resources and agents to charging for completed work and financial outcomes. We use it as a maturity model, not as a representation of Salesforce’s pricing mix. The Qualitate findings on the right test where customer spending stands today and what could change as usage scales.
Software companies have historically been good at preserving their revenue through changes in pricing models. From core counts and on-premises licensing to SaaS seats and consumption, vendors find ways to preserve the value they capture. Salesforce is experimenting with several approaches, including seat pricing, consumption, outcomes and what we would call gain sharing, taking a portion of the financial benefit created.
The full range of contract options is not easy to find in one place. Enterprise license agreements can also sound like all-you-can-eat arrangements in the marketing, but procurement teams will encounter restrictions. Flexibility in how customers buy does not necessarily mean simplicity in understanding what they will ultimately pay.
We are still predominantly on the left side of BCG’s framework. Resource-based pricing meters inputs such as token consumption. Agent-based pricing charges for the number or type of agents deployed, serving as a proxy for seats. Interaction-based pricing measures conversations or other activities – the approach used in Agentforce’s original conversation-based pricing. Qualitate customer survey data indicated some negativity toward chat interaction-based pricing.
Moving to the right, outcome-based pricing charges for completed jobs, such as resolving a customer help request. Financial outcome pricing goes further, capturing some of the upside through cost savings or increased revenue. That is closer to value-based pricing, where the vendor shares in the value created.
The farther right the model moves, the harder it becomes to implement. The measurement capabilities are not all in place, and customers and vendors may not agree on how to measure financial outcomes – or whether they want to share them. Salesforce is trying to meet customers where they are with different options. What stood out to us at Dreamforce was the inclusion of pricing tied to completed jobs or resolutions, an approach Sierra had offered from the outset.
But there is a business issue this framework does not resolve. The assumed relationship is that the vendor supplies the agent, the agent consumes its data and process model, and the vendor charges for that work. What happens when the agent belongs to someone else?
A customer could access Salesforce through Headless 360 while building its agent with Databricks or Snowflake. In that arrangement, Salesforce is not necessarily supplying the agent. Does it capture value from the broader work being performed, or does it become one data feed among many? The pricing categories explain different ways to charge, but they do not settle that question.
Startups and the schema-on-read approaches we have discussed add another uncertainty. A customer deeply embedded in Salesforce, with its workflows and processes running there, is unlikely to move away easily. But a customer using Salesforce primarily as a system of record, without that deeper workflow investment, may be more open to accessing the data and recreating equivalent functionality elsewhere.
The “SaaSpocalypse” is not binary. Different portions of the software industry will feel these pressures differently. Salesforce’s position depends in part on whether it is supplying the business logic and workflows through which work gets done, or primarily storing the records that another platform uses.
The Qualitate research provides an early view of the economics. Customers are divided on Flex Credits: roughly half see easier access, while half see more complexity. The positive view is more common among lighter Agentforce users, who can start small rather than make a large commitment. Other customers say that more pricing options make future costs harder to forecast. Flex Credits can ease entry without resolving predictability at scale. [Source: Qualitate].
Among the 18 respondents in the Qualitate survey represented in the budget-allocation question, 5–15% of Salesforce spending was the most common allocation to Agentforce. Separately, none of the 14 respondents to the funding question reported shifting existing Salesforce budget to fund it. Funding came from new allocations, non-Salesforce budgets or a combination of the two. These are distinct findings: the allocation describes Agentforce’s share of spending, while the funding question indicates that customers were not yet taking money from their existing Salesforce purchases.
The spending expectations in the Qualitate data are also noteworthy. Of those who had modeled or experienced the impact of headless access, 75% expected higher Salesforce spending. Separately, the report says 44% planned spending increases after Agentforce adoption. These findings concern different questions and respondent groups; they should not be treated as interchangeable measures.
Procurement will be watching how those expectations develop. Small pilots have made funding manageable, but some customers anticipate reallocating budgets as adoption scales. We will need to see whether higher AI consumption remains incremental to Salesforce or is offset by lower spending on existing products, fewer seats or retired features. The absence of cannibalization in early funding decisions does not settle the economics of scaled deployment.
Our overall assessment is that Salesforce has told a compelling story and brought together the pieces to show where the industry is going. This is more than a raw data platform with an agent-building tool that queries disparate databases without understanding how the data maps across systems. Salesforce has been doing the engineering work to make enterprise data understandable and to give agents the workflows needed to act across those silos.
There is still work to do. Salesforce must earn credibility with the technology side of the house and make the product “just work” in the Steve Jobs sense. The aspiration is not to hand customers a collection of piece parts. The platform may be composable, but those components should work together without placing the integration burden on the customer.
Salesforce now has to deliver that experience and convince customers to trust it. The next test is whether its platform, pricing flexibility and expanding consumption translate into consistent, sustainable growth. Growing beyond its own interface is a credible opportunity. Turning that opportunity into a durable business model remains the work ahead.
Action item: Prove the value before scaling the spend
We believe Salesforce customers should start with a clearly defined sales or service task and make broader adoption contingent on measurable business value. A generated interface or role-specific agent can be the starting point, but a successful demonstration is not proof that an agent is ready to execute an end-to-end workflow. Business and technology teams should establish what data and process knowledge the task requires, where human judgment remains necessary, and how results and exceptions will be reviewed. Procurement should model implementation, licensing, API and consumption costs at expected usage – not just pilot volumes. The Qualitate interviews reinforce the importance of that exercise. Additional API and consumption charges could offset seat savings. Customers should then measure useful work completed, time saved and total cost against the existing process, using agent traces and human corrections to guide improvements. The expansion decision should rest on whether the system delivers more trusted work at a cost the business can justify and control, not on how many agents are deployed or how much they consume.
