What Integration Patterns Work for Agentforce with Existing Salesforce Orgs?

TL;DR

• Agentforce does not ask you to replace your existing Salesforce integrations. It adds agents on top of the Flows, Apex, External Services and MuleSoft APIs you already run.
• Salesforce describes three ways to connect agents to outside systems: traditional APIs, MCP servers and agent-to-agent (A2A) delegation.
• Pick per system: reuse stable APIs, use MCP where a server exists or reuse is high, and use A2A when a specialized agent should own the work.

Most Salesforce orgs that adopt Agentforce are not starting fresh. They have years of Flows, Apex callouts, Named Credentials and middleware already doing real work. The good news is that agents are designed to use those investments. The real question for platform leads and architects is which integration pattern fits each outside system, so your digital workers can act without creating new technical debt.

Salesforce lays out the options in its own guide, Choose the Right Agentforce Integration Pattern: API, MCP, or A2A. Here is a practical reading of it for an existing org.

The Three Patterns at a Glance

Pattern	Fits when	Reuse	Governance
Traditional API (External Services, Apex, Flow, Named Credentials)	The API already exists, data is sensitive or bulk, reuse is low	Low to medium	Your existing Salesforce controls
MCP server	The outside system already offers an MCP server, or a new one will be reused widely	High	API Catalog allowlists plus the Agentforce Registry
A2A	A specialized agent already exists, or one agent is carrying too many jobs	High	Agent Cards, OAuth 2.0 and permissions

Pattern 1: Traditional APIs

Many orgs already have External Services registered, Apex callouts or MuleSoft APIs in place. Agentforce can call these as custom agent actions, usually through an invocable Flow or Apex method.

Use it when:

• The API is already in production and trusted.
• You need bulk processing, complex transformations or access to sensitive data.
• Few other agents will need the same capability.

In practice:

• Register the API’s OpenAPI schema through External Services so its operations can become agent actions.
• Wrap multi-step logic in a Flow or Apex the agent calls, rather than asking the agent to chain raw calls.
• Keep using your existing Named Credentials and permission sets.

This is often the fastest route to production for teams that already invested in integration.

Pattern 2: MCP Servers

The Model Context Protocol is an open standard that lets agents discover and call tools in other systems. Salesforce says Agentforce includes a native MCP client. Admins connect MCP servers and allowlist specific tools in API Catalog, and agent builders add the approved tools from the Agentforce Registry. Nothing is exposed to an agent until an admin approves it.

Use it when:

• The outside system, or MuleSoft, already provides an MCP server that does what you need.
• A new server would be reused by several agents.
• You want tools discovered and governed in one place instead of wired one by one.

Worth knowing:

• MuleSoft can expose existing integrations as MCP servers, so your current APIs can join this pattern without a rewrite.
• Salesforce also lets you build custom Salesforce-hosted MCP servers in API Catalog that make Apex, Flows and even your Agentforce agents available to outside MCP clients.

Pattern 3: A2A Delegation

Sometimes the right move is not another tool but another agent. With A2A, your agent finds a specialized agent through its Agent Card, connects over OAuth 2.0 and hands it part of the job. Salesforce notes this helps when one agent carries so many topics and tools that its reasoning slows down or gets less accurate.

Use it when:

• The outside system already offers a capable agent for the task.
• You want focused agents for distinct domains instead of one agent that does everything.

Check the current availability of A2A features in your org before you design around them, since agent-to-agent support is newer than the API and MCP patterns.

A Decision Path for Existing Orgs

1. Inventory first. List every outside system the agent must reach, and note whether it offers an MCP server, an agent or only REST or SOAP APIs.
2. Reuse what works. If a stable External Service or MuleSoft API exists, expose it to the agent before building anything new.
3. Use MCP where it pays off. Keep one-off integrations on APIs, and move high-reuse capabilities to MCP.
4. Delegate specialized work. Use A2A when another agent should own a domain.
5. Govern in one place. Approve tools in API Catalog, set permissions for each integration user and keep the Trust Layer and guardrails in front of every action.

A Worked Example

A service agent needs a credit risk score from an outside provider.

• API path: an External Service or Apex callout, exposed as an agent action through a Flow.
• MCP path: connect the provider’s MCP server (or a MuleSoft one), allowlist the scoring tool and add it to the agent.
• A2A path: if the provider offers its own risk agent, your agent hands it the sub-task.

The choice depends on what the provider offers and how many other agents will need the same score.

Common Mistakes

• Building a new MCP server for a one-time call that an existing API already handles.
• Giving one agent every tool in the org instead of splitting the work.
• Skipping permission review for integration users because “it is only the agent”.
• Testing only the happy path, with no checks for bad inputs or prompt injection.

Where Funnelists Fits

Funnelists builds custom AI apps on Salesforce, including the integrations behind them, and we have built Agentforce into our SF Support Portal Template and SF Custom Portal Template, along with example agents. On an integration project, we would start with what your org already has and add new patterns only where they earn their place.

If you are mapping integrations for an Agentforce rollout, book an intro call to talk through your systems.