TL;DR
- Salesforce’s planned acquisition of Fin signals a shift from AI agents that answer questions to agents that resolve real work.
- Once agents start acting inside enterprise systems, the hard part becomes context: workflows, permissions, data, dependencies, and business logic.
- The next phase of enterprise AI will be defined by whose agents understand how their business actually runs.
*****
Salesforce’s acquisition of Fin is almost silly-easy to read on paper as just another move in the AI arms race.
A major enterprise software company buys a fast-growing AI agent company, folds it into a larger platform, and uses the deal to sharpen its story around autonomous work.
I wouldn’t say that that interpretation is wrong, but I would say it is probably too short-sighted.
What we really see
The more interesting part here is that the enterprise AI market is moving quickly from agents that can answer questions to agents that are expected to resolve real-world problems.
If that shift sounds subtle, fine, let’s talk about the difference: stakes. They are higher.
A system that just answers a question can be evaluated on a litany of low-stakes qualities: usefulness, tone, speed.
A system that resolves a problem has to be evaluated on something much more difficult: whether it understood the business, the user, the context and reality itself well enough to take the right action.
Customer service is a natural place for this transition to happen first. The use case is fairly familiar, certainly measurable, and about as costly as it gets. Support teams have queues, cases, channels, escalation paths, SLAs… lots of hard numbers. If an AI agent can reduce handle time, improve response quality, and resolve a meaningful share of volume without human intervention, the value is dead simple. It’s a natural place to begin (and largely why a great many “Jobs in danger of AI displacement” rubrics put Customer Service at the top of their lists).
That is also why the Fin acquisition matters. It’s a bet that AI agents are no longer just a better front door for support. They are becoming part of the operating model.
Get it right or pay the price
A support agent that only drafts a response is one thing. A support agent that actually resolves an issue is another.
Resolution may require checking entitlement rules, reading account history, interpreting contract terms, updating a CRM record, triggering a workflow, issuing a credit, escalating to the right team, deciding that a policy exception applies, among other countless edge cases. You get my drift here: the agent is no longer just generating language. It is changing the state of the business.
Ah but the conversation gets more complicated than that.
For a while, much of the AI discussion has treated autonomy as the breakthrough. The more an agent can do on its own, the more valuable it becomes. In the abstract, that is largely true. But in an enterprise environment, autonomy without sufficient context is actually quite risky.
The reason is simple: businesses don’t actually run on clean abstractions. They run on accumulated decisions.
Useful Reality v. Unuseful Unreality
A field exists because someone needed to track something. A workflow fires because a team once had to prevent a particular failure. A validation rule was created after some edge case caused enough pain to become process. A permission set reflects not only security policy, but politics, history, ownership, and trust. An exception for one customer may be invisible to most of the company and absolutely essential to keeping the relationship intact.
Over time, all of those decisions become the system. Some of them remain useful to reality. Some do not and become drag. Some are redundant, outdated, or actively harmful. But from the outside, they often look the same.
This is the uncomfortable truth behind enterprise AI: the hard part is not always getting an agent to act. Increasingly, the hard part is making sure it understands the environment it is acting inside, that it reflects the reality of your business, not a generic one.
AI can certainly hallucinate, misunderstand a customer, or provide a bad answer. Those failures happen and of course are quite important. But a more subtle failure is an agent that gives an answer that is technically correct while missing the operational context that makes it wrong for this customer or that moment.
It updates the right field, but does not know what depends on that field downstream. It follows the standard policy, but misses the enterprise exception. It resolves the case, but creates a reporting inconsistency for RevOps. It moves quickly, confidently, and mostly correctly… except for the part of the business it could not see.
That is the real context gap
And that gap is not just a documentation problem.
Documentation matters, but documentation is usually a snapshot. The business, which operates in real time, is not. Systems change constantly. Metadata changes. Workflows change. Integrations change. Teams ship fixes, add fields, retire processes, create new segments, expand into new markets, and route around old constraints. Even when documentation exists, it often lags behind the operating reality.
This is why enterprise complexity is such a stubborn problem for AI. Complexity is often discussed as though it were inherently bad, something to be removed so the business can become simple again. But much of that complexity exists because the business needed to adapt, and that adaptation allowed for growth. Complexity reflects new customers, new geographies, new products, new compliance needs, new channels, new data, and new ways of working.
The problem is not that complexity exists. The problem is that companies lose the context behind it. Keep the reality, ditch the extra stuff.
Humans already feel this every time a seemingly simple change turns into a week of archaeology. Before touching a field, someone has to ask where it is used, what automation depends on it, who owns it, whether it feeds a dashboard, whether it syncs to another system, whether an integration will fail, and whether the person who created it still works at the company. The work slows down not because teams are timid, but because the system has become difficult to reason about.
Agents will inherit that same problem
And will encounter/multiply it at machine speed.
That is what makes the Fin deal much more than a customer service story. It is a signal about where enterprise AI is heading. Packaged agents will become easier to deploy. As that happens, the differentiator will be whether those agents have enough live context to act safely inside the business.
This also explains why so much of the enterprise AI stack is converging around data, metadata, governance, integration, and observability. These literally allow autonomous systems to operate in environments where the answer is not sitting neatly in one knowledge base, one application, or one workflow.
An agent can only be as useful as its understanding of the system around it. In a small, simple environment, that understanding may be relatively easy to assemble. In a large enterprise, it has to span applications, data models, permissions, automations, business logic, and dependencies that were never designed with AI in mind.
That does not mean agents cannot work in the enterprise. It means the next phase of adoption will be less about demos and more about operational readiness.
In the end, I think it’ll be proven soon enough that Salesforce acquiring Fin validates the demand for agents that can resolve real work.
But it also makes the next bottleneck much, much clearer: The market can (and will) buy more agents. It can package them better, deploy them faster, and measure them more aggressively. What it cannot at all do is give those agents a reliable understanding of the business they are supposed to operate inside. And without that, AI will always feel a bit off — and the success mode just a bit out of reach.
