Salesforce
Artificial Intelligence
The Agentforce Decision Most Leaders Will Underestimate
Article
Arnab Mukherjee
5
min read
The performance of an enterprise AI agent depends on more than the quality of its underlying model. Once an agent is expected to execute business processes rather than simply generate responses, its effectiveness becomes dependent on a wider architecture: the systems it can access, the tools it can invoke, the permissions governing those interactions, and the way complex work is distributed across agents.
This makes integration architecture central to Agentforce discussion. Salesforce currently distinguishes between three patterns for extending Agentforce beyond the Salesforce platform:
Traditional APIs
Model Context Protocol (MCP)
Agent2Agent (A2A)
These patterns are sometimes discussed as successive generations of integration. In practice, they address different requirements and are likely to coexist within the same enterprise architecture.
The relevant architectural question is therefore not which pattern replaces the others. It is where each pattern provides the appropriate level of control, interoperability, and specialisation.
APIs remain the foundation for controlled execution
Traditional APIs remain appropriate where integrations involve sensitive data, high transaction volumes, low-latency requirements, or established enterprise interfaces.
Salesforce identifies APIs as the established standard for system-to-system data exchange and recommends them particularly where organisations require:
high-volume or bulk processing
low-latency transactions
controlled access to sensitive systems
reuse of existing enterprise integrations
predictable execution against well-defined interfaces
This distinction matters because most enterprises are not beginning their Agentforce programs with an empty integration landscape. Salesforce environments are already connected to ERP platforms, payment services, data platforms, identity systems, underwriting applications, order-management systems, and proprietary applications.
For these systems, an agent does not necessarily require a new integration method. Existing APIs may continue to provide the most appropriate execution layer.
There is, however, an additional requirement when APIs are used by agents. Salesforce notes that interfaces such as REST APIs or Bulk API do not automatically become agent actions. Flow, Apex, or other orchestration logic may still be required to define inputs, process outputs, and make the capability usable by Agentforce. This creates an important distinction between system connectivity and agent-ready connectivity.
An API can make a system accessible without necessarily making its capabilities easy for an agent to discover, interpret, and select.
MCP addresses the discoverability problem
Model Context Protocol operates at a different layer of the integration architecture.
Salesforce describes MCP as an open standard through which external systems can expose tools and contextual information to AI agents in a consistent format. An MCP server can describe:
the tools available
what each tool does
the required inputs
the expected schemas
instructions governing how the capability should be used
In a conventional API integration, developers generally know the endpoint in advance and configure the logic required to invoke it. With MCP, an external system can expose a catalog of capabilities that an agent can interpret and use through a standardized interface.
An ERP environment, for example, could expose tools for inventory checks, order submission, returns processing, or shipment status. Rather than configuring each capability independently for every agent, those tools can become reusable across several agent experiences. This becomes increasingly relevant as the number of agent use cases grows.
Salesforce therefore recommends considering MCP when an external system already provides an MCP server, when MuleSoft can expose existing integrations through MCP Bridge, or when the expected reuse justifies building a dedicated MCP layer.
For a narrow integration used by one agent, that additional abstraction may offer limited value. For a capability expected to serve many agents, the economics are different.
A2A changes the unit of integration
Agent2Agent (A2A) addresses a different problem: how much responsibility should one agent carry? Salesforce guidance notes that continually adding tools, topics, and responsibilities to a single agent increases the context it must evaluate and can affect reasoning performance.
Instead of one general-purpose agent carrying every instruction and tool, an organization can distribute work across agents with narrower responsibilities:
a customer-service agent can identify intent and manage the interaction
a returns agent can evaluate eligibility and return policies
a billing agent can investigate payment or invoice issues
a lending agent can operate within its own domain rules and controls
The coordinating agent does not need to contain the complete expertise of every specialist. It needs to recognise when another agent is better suited to complete a task. Salesforce's agentic architecture guidance describes A2A as a pattern that enables agents to collaborate and delegate domain-specific work across agent boundaries.
This creates a useful distinction:
MCP connects an agent to tools
A2A connects an agent to other agents
The difference is architectural. MCP extends capability while A2A distributes responsibility.
Enterprise architecture will require all three
API, MCP, and A2A should therefore not be treated as competing standards. An enterprise workflow could legitimately use all three.
A customer-facing Agentforce agent handling a service request. The process might involve:
The primary agent identifies the customer's intent.
A2A delegates a specialist task to another agent.
The specialist agent identifies the tools required through MCP.
Those tools execute transactions against established enterprise APIs.
Each layer solves a different problem.
The three patterns can operate within the same architecture rather than as separate alternatives. A2A distributes work across agents, MCP exposes reusable tools, and APIs provide the execution layer into enterprise systems.
The choice between them therefore depends less on technical preference and more on the role each integration needs to perform. The table below summarizes that distinction.
Salesforce similarly recommends evaluating each integration pattern according to the characteristics of the external system and validating the design against actual performance and scalability requirements.
From agent capability to agent architecture
As Agentforce deployments move beyond isolated pilots, the quality of the surrounding architecture becomes increasingly important.
The question is no longer simply whether an agent can understand a request or generate an appropriate answer. Organisations must determine whether the agent can reliably:
reach the required enterprise systems
identify the correct tools
operate within appropriate permissions
delegate work when specialist expertise is required
execute consistently at enterprise scale
That changes the focus of the Agentforce decision.
The most consequential design choice may not be the model behind the agent. It may be the architecture connecting reasoning to tools, tools to systems, and agents to one another.
That is the distinction between an agent that performs well in a controlled demonstration and an agent system designed for real enterprise operations.
