Salesforce was introduced as a CRM for people working in a browser and connected to ERP, service, and marketing systems over the years. Now agents are joining as new consumers: Agentforce on the inside, external agents on the outside. This article describes three generations of Salesforce integration, what changes when the consumer is an agent, the role MuleSoft plays as the layer in between, and what a realistic four-step path looks like.
Most Salesforce environments have grown in layers. First came the CRM, introduced for sales and operated by people in a browser. Then it was connected to the ERP so that customers and orders would not have to be maintained twice. Later, service, marketing, a ticketing system, document management, and a dozen smaller applications were added, each with its own interface.
This architecture has a common denominator: there is a person at the end of every integration. Data is synchronized so that a sales representative can see in the CRM what has happened in the ERP. The interface, permissions, and response times are all designed for human use.
Now a new consumer is joining. Agentforce works within Salesforce and needs access to data outside it. External agents, whether in Slack, the ERP, or a custom application, want to access Salesforce and take action there. Both change the architectural requirements more fundamentally than may first appear. CRM integration becomes the starting point for the agentic enterprise.
Three Generations of Salesforce Integration
When assessing your own environment, you will usually recognize one of three generations, often with several existing side by side.
| Generation | Pattern | Consumer | Typical weakness |
|---|---|---|---|
| Point-to-point | Direct connections, overnight batch synchronization, scripts, and middleware jobs | People in a browser | Every new connection is a separate project; changes cause unexpected failures |
| API-led | Reusable System, Process, and Experience APIs, for example with MuleSoft | People in a browser, mobile apps, portals | Agents lack context, action descriptions, and fine-grained permissions |
| Agentic | APIs with meaning and action semantics; agents as consumers and actors | Agents inside and outside Salesforce, alongside people | Still emerging; governance and operations are not yet established |
The transition from the first to the second generation took many companies years. The result was interfaces that could be reused, withstand change, and be monitored centrally. The best practices for integrating MuleSoft and Salesforce that have proved effective are well documented.
The good news: if you have reached the second generation, you have the foundation for the third. The APIs exist. What is missing is the layer that makes them understandable and safe for agents.
What Changes When the Consumer Is an Agent
A person using a Salesforce interface brings a great deal of knowledge that is not described in any API. They know that a discount above ten percent requires approval. They know that a customer with an open escalation should not receive a sales call right now. They know which fields matter and which ones nobody maintains. An agent knows none of this unless someone tells it.
This leads to five concrete differences:
- Context rather than fields. An agent does not need a list of fields, but a description of what an object means and how it relates to others. An opportunity is only useful to it if it knows which corporate group the customer belongs to, which quote is outstanding, and who is responsible.
- Actions with semantics. An API endpoint that updates a record says nothing about whether the action can be reversed, what side effects it has, or whether it requires approval. For an agent, precisely this information is crucial. The requirements agents place on enterprise APIs go well beyond what an OpenAPI specification describes.
- Permissions per agent. An agent is not a user with a profile. It acts on behalf of different users, in different contexts, with different rights. Authorization must come from the context, rather than from a service account that is allowed to do everything.
- Response time and volume. An agent may call ten APIs in succession during a single operation. What is acceptable for a person making one click adds up to delays that make the agent's process unusable. At the same time, agents generate far more calls, with consequences for API limits and costs.
- Repeatability. An agent that receives no confirmation tries again. An API that turns this into two orders is not suitable for agents, even if it has worked for people for years.
None of these points requires discarding the existing integration. All five require adding a layer above it that gives agents what people bring with them.
Salesforce as a Source, a Target, and an Actor
In an agentic architecture, Salesforce takes on three roles simultaneously. This is new, because in integration it has almost always been only a source or a target until now.
As a source, Salesforce provides customer context to agents working elsewhere: an agent in the service system that wants to know whether the customer is strategically important; an agent in the ERP that checks whether an order belongs to a won opportunity; an assistant in Slack that makes CRM context available directly in day-to-day work.
As a target, Salesforce receives actions from agents: an agent creates an opportunity, updates a status, or creates a task for the account manager. This is where questions about authorization, idempotency, and approval are most urgent. We have already described what happens when Salesforce is no longer confined to the browser.
As an actor, Salesforce operates its own agents through Agentforce, which need to reach beyond the platform to access other systems. An Agentforce agent handling a service request needs delivery status from the ERP, contract data from document management, and perhaps a credit check from an external service. These requests are subject to the same requirements as those made by external agents, just in the opposite direction. Whether the investment pays off is a question of the business case for Agentforce, but the architecture required is the same either way.
The Layer in Between: Integration, Context, Governance
The answer to all three roles is not a new product, but a layer between Salesforce, the other enterprise systems, and the agents. It has three responsibilities.
| Responsibility | What it provides | Tools and building blocks |
|---|---|---|
| Integration | Consistent, secure access to all systems, regardless of whether the caller is a person or an agent | API-led architecture, MuleSoft as the integration platform, policies for limits, retries, and idempotency |
| Context | Business objects, relationships, and rules that agents can understand | A semantic layer above the System APIs; tool descriptions that explain meaning and side effects |
| Governance | Who may do what, with which approval, and how it remains traceable | Permissions per agent and context, approval steps, centralized logging, monitoring of all agent calls |
MuleSoft plays a particular role in this layer because it already supports integration in many Salesforce environments. The System APIs built there for people and applications are the starting point. What is added is a description of these APIs as tools for agents and centralized control over which agent may use which tools. The way MuleSoft Agent Fabric approaches this orchestration shows where the platform is heading.
What matters is that all three responsibilities sit in one place. If Agentforce gets its own connections to the ERP, external agents get their own connections to Salesforce, and each agent brings its own rules, the first generation's point-to-point environment emerges all over again, only with agents instead of scripts. The lesson from twenty years of integration still applies: a shared layer takes more effort at the beginning and costs less every year after that.
Agents do not turn integration into a different discipline. They reveal where integration has previously relied on human knowledge.
A Realistic Path in Four Steps
Moving to an agentic architecture is not a major project if it builds on API-led integration. Four steps have proved effective.
| Step | What it involves | Outcome |
|---|---|---|
| 1. Take stock | Identify existing integrations and APIs, who consumes them, and where agents are already accessing systems, perhaps without anyone calling it that | An overview of gaps and uncontrolled access |
| 2. Make APIs suitable for agents | For the System APIs agents need: descriptions that explain meaning, identification of side effects, idempotency for write calls, and authorization derived from context | A set of tools agents can use safely |
| 3. One end-to-end process | A specific workflow, such as quote to order, with an agent using Salesforce and the ERP, including defined approval steps | Proof in production that the layer works |
| 4. Governance and operations | Monitoring of all agent calls, metrics per agent and tool, and a process for introducing new agents and tools | A foundation for adding further agents without uncontrolled proliferation |
The third step is the most important. A process running in production shows more than any architecture diagram. It reveals where permissions are too broad, where an API is too slow, and where the agent needs context nobody has described. These findings feed back into the layer before the second and third agents are added. Everything involved in bringing an agent from pilot to production applies here in full.
What Companies Should Review Now
| Area | Key question |
|---|---|
| Generation | Which generation has your Salesforce integration reached, and where do point-to-point connections still exist? |
| Agent access | Are agents already accessing Salesforce, for example through user accounts or scripts, and is that access controlled? |
| Agentforce | Which systems outside Salesforce does an Agentforce agent need, and how does it reach them? |
| API descriptions | Are the System APIs described so that an agent understands what they do, what side effects they have, and when to use them? |
| Permissions | Do agents act in a user's context or through a service account with more permissions than any person? |
| Idempotency | Can write calls to Salesforce and the ERP be repeated safely? |
| Monitoring | Is there one place where all agent calls across all systems are visible? |
Conclusion
For years, Salesforce was the center of customer relationships and the target of many integrations. With agents, it becomes something else: a node in a network of systems in which people and agents read, write, and act alongside each other. The integration built for that environment remains the foundation. But it needs a layer above it that gives agents context, action semantics, and boundaries.
If you operate an API-led architecture with MuleSoft, you have already covered most of the ground. What is missing is less about technology than about descriptions, control, and a first process that demonstrates it works. If you are still relying on point-to-point connections, you should not begin the transition solely for agents, but you should keep agents in mind.
The agentic enterprise does not emerge simply by deploying an agent. It emerges through an architecture in which agents can work as reliably as the people for whom Salesforce and system integration were originally built.