MuleSoft for Agentforce

An agent that can only read Salesforce records is a search box with better manners. The moment it has to do something real — check inventory in the order platform, refund against the billing engine, look up a shipment in the carrier’s system — it needs to reach a system that lives outside your org. Salesforce gives you several ways to build that reach, and most teams default to the one closest to hand: an Apex callout, wrapped as an action, per system, per agent. It works. It also means the same order API gets integrated three times by three teams, each with its own auth handling, its own error paths, and its own hand-written description for the reasoning engine to read.

That’s the N×M problem the Model Context Protocol was designed to kill, pointed at a different layer. MuleSoft’s answer — Topic Center and the API Catalog — is to let you publish an API once, at the integration layer, as a set of agent-ready actions, and then have any Agentforce agent in the org pick it up as a governed capability. This post is what those two features actually are, the exact path a Mule API travels to become an Agentforce action, how this compares to the other ways to give an agent an action, and where the security lives — because an agent calling a live external system is a very different risk from one reading a record.

Where a MuleSoft action fits among the alternatives

Before the build, the honest map. Agentforce can take an action through several surfaces, and MuleSoft is one of them, not the answer to everything:

Flow actions — declarative, in-org logic and record operations. The right default when the work stays inside Salesforce.
Apex actions — pro-code, for a risk calculation, a proprietary callout, or multi-object logic clicks can’t express. Powerful, but it’s code your team owns and maintains, per org.
External Services / OpenAPI — import a clean OpenAPI spec and get low-code actions fast. The quickest path for a single, well-behaved API, but it chokes on large or loose specs and gives you no API-management layer underneath.
MCP — when the external system already speaks the Model Context Protocol, or you need multi-turn tool context in a session.
MuleSoft API-led actions (Topic Center + API Catalog) — when you want governed, reusable integration across an estate of systems, including the legacy and at-scale ones, with policy and identity applied consistently.

Salesforce’s own guidance frames the choice as: the right pattern depends on what the external system already supports and how much reuse you need. Use Flow and Apex for in-org logic. Use External Services for one quick, clean API. Reach for MuleSoft when you already run — or want to run — a managed API estate, and you’d rather integrate the order system once and have every current and future agent reuse it than wire it up again each time. The trade-off is footprint: this is the heaviest option, and for a long-tail SaaS connection you’ll touch once, it’s overkill. The value shows up when the same APIs are consumed by many agents under one policy plane.

An Apex action is a capability one team built for one agent. A published MuleSoft topic is a capability the whole org inherits, governed the same way every time. The difference isn’t the callout — it’s who has to build it again next quarter.

Topic Center: authoring actions at the API layer

Here’s the shift Topic Center makes. In the Apex-action model, the metadata that decides whether an agent uses your action correctly — the description the reasoning engine reads — lives next to the code, authored by whoever wrote the method. Topic Center moves that authoring to Anypoint Code Builder, where the API is designed, and bakes it into the API specification itself.

A topic, in both the MuleSoft and the Agentforce sense, is a bundle of actions (tasks the agent can perform, each backed by an API operation) and instructions (natural-language guidance telling the agent how and when to use each one). The point of authoring it in Topic Center is that the topic you define at the API layer becomes an Agentforce topic once it’s synced across — same conceptual object, authored by the integration team that actually understands the API, reused by every agent.

Mechanically, you work in an OpenAPI 3 spec. You enable the API project for agent topics and actions, then annotate the operations you want to expose. The load-bearing annotation is:

paths:
  /orders/{orderId}/status:
    get:
      operationId: getOrderStatus
      summary: Retrieve the current fulfilment status of an order
      description: >
        Returns the current status, carrier, and estimated delivery date for a
        single order, given its order id. Use when a customer asks where their
        order is or whether it has shipped.
      x-sfdc:
        agent:
          action:
            publishAsAgentAction: true
      parameters:
        - name: orderId
          in: path
          required: true
          schema: { type: string }
      responses:
        '200':
          description: Order status found
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/OrderStatus'

That publishAsAgentAction: true flag is what marks the operation for Agentforce, but it comes with requirements the platform enforces, and they trip people up. When an operation is published as an agent action it must have at least one input (a parameter or request body), at least one 2xx response, an operationId, and a description longer than ten characters — and its payload media type must be application/json, with no headers on the responses. Miss any of these and enablement fails or the action registers in a shape the agent can’t use.

Notice that description field, and how much heavier it is than a normal API summary. That’s deliberate, and it’s the same lesson as custom Apex actions: the description is the part the reasoning engine reads to decide whether this operation is the tool for what the user asked. “Returns order status” is a worse action than the version above, which tells the agent both what it returns and when to reach for it. The instruction text you attach to the topic does the same job at the bundle level. You’re not documenting the API for a human developer anymore; you’re programming the agent’s tool selection in prose.

Once the spec is enabled and annotated, you run it through governance and publish it to Anypoint Exchange, tagged so Salesforce can find it. That tag — sf-api-catalog — plus an active managed endpoint in API Manager is what makes the API eligible to sync. An API that isn’t actually managed and running won’t appear on the Salesforce side.

The API Catalog: from Exchange to an agent action

The API Catalog is the Salesforce-side surface that unifies APIs from MuleSoft, Salesforce, and Heroku into one place an admin can manage and hand to an agent. This is where the integration artifact becomes an org capability.

The flow, end to end:

Sync. In Salesforce Setup, open API Catalog and start the sync. This imports the tagged, managed APIs from Exchange — and, importantly, it auto-generates the plumbing for each: Named Credentials, External Services, and Apex classes. You don’t hand-write the callout wrapper; the sync produces it.
Activate. Select an imported API and activate its actions, supplying a connection description and the destination URL. This is the step that turns API operations into invocable Agent Actions.
Grant access. The generated actions and credentials are gated by permissions. Assign the relevant permission sets to the users — and the agent’s running user — who need them.
Assign to the agent. In Agent Builder, add the activated topic and its actions to the agent, then test that it actually invokes them on the right utterances.

The result is that “look up an order’s status” is now a topic any agent in the org can be given, backed by a governed Mule API, with the callout, credential, and external-service scaffolding created for you. Add a second agent next quarter and you assign the same topic instead of rebuilding the integration. That reuse — one governed definition, many consumers — is the entire argument for doing it this way instead of one Apex callout per agent.

Where the governance actually lives

An agent that can read a record is bounded by sharing. An agent that can call your billing API can act, and that raises the stakes on exactly which identity is making the call and what it’s allowed to do. Two layers matter here.

On the Salesforce side, the running user is the boundary. Every Agentforce agent executes as a defined running user, and actions inherit the permissions of that user and of the Apex, Flow, or credential they reference. If the agent user can’t use the Named Credential the sync generated, the action silently fails — and if it can use far more than the one API this agent needs, you’ve handed a reasoning loop more reach than the use case justifies. Scope it tightly. The generated credential itself comes in two flavors worth understanding: a named principal shares one credential so the agent acts on the system’s behalf, while a user principal carries per-user credentials so the agent acts as the end user. Which one you pick decides whose permissions the downstream system enforces, and it’s a decision to make deliberately, not accept by default. This is the same least-privilege discipline we argue for in the agent security guide — the blast radius of an action is set by the identity behind it.

On the MuleSoft side, the API is governed the way any managed API is. Because these actions run through APIs managed in API Manager and Flex Gateway, the controls you already apply to an API estate apply here too: authentication and authorization policies, rate limiting (including SLA-based tiers), threat protection, and audit logging. An agent hammering an operation in a reasoning loop is exactly the traffic a rate-limit policy exists to contain. The API-management layer that felt like overhead when a human app was the only consumer earns its place the moment an autonomous agent is the caller.

The practical failure mode to plan around isn’t exotic. The single most common reason a Mule API works in a test client but fails as an agent action is a loose OpenAPI contract — generic object types Salesforce can’t map to action inputs, missing descriptions, a response the schema doesn’t pin down, the wrong media type. The fix is unglamorous: flat, strictly-typed request and response shapes, real descriptions on every operation and parameter, and a thin wrapper API in front of any backend that returns something messy. A clean contract is not a nicety here; it’s the interface the agent reasons over.

Agent Fabric: governing the mesh, not building the action

It’s easy to conflate two MuleSoft-for-Agentforce stories, so draw the line clearly. Topic Center and the API Catalog are how you turn your APIs into agent actions. MuleSoft Agent Fabric, announced September 26, 2025, is a different product with a different job: an enterprise agent control plane to discover, govern, orchestrate, and observe agents — including Agentforce agents alongside those on Amazon Bedrock, Google Vertex AI, and Microsoft Copilot Studio — plus the MCP and A2A endpoints they call.

Its pieces are an Agent Registry (a catalog where any agent or tool, MCP and A2A servers included, is registered and discoverable), an Agent Broker (LLM-powered routing across agents), an Agent Visualizer (observability), and Agent Governance (built on Anypoint Flex Gateway, applying access control, rate limiting, and audit trails to every agent-to-agent and agent-to-tool interaction). A January 2026 expansion added automated scanners that discover agents across those major platforms and brought public MCP servers in the Registry to GA.

For an architect, the distinction is the useful part. The API Catalog answers “how does this agent call that system?” Agent Fabric answers “how do I see, govern, and route across all the agents and tools sprawling across my enterprise?” — the fleet-level problem we’ve written about in governing an agent fleet, now with a cross-platform control plane. They’re complementary: API-led actions expose governed capabilities; Agent Fabric governs the broader mesh those capabilities live in. Reaching for Agent Fabric to build a single action, or for the API Catalog to govern a multi-vendor agent estate, is using the wrong tool.

What to actually do

If your agent needs to touch systems outside Salesforce and those systems are already — or should be — behind managed APIs, the MuleSoft path is worth the footprint precisely because it stops you integrating the same API once per agent. Author the topic in Anypoint Code Builder against a clean OpenAPI 3 spec, spend real effort on the operation descriptions and instructions because that prose is what drives the agent’s tool selection, and hold the contract to flat, strict, well-described shapes. Publish it tagged and managed, sync it into the API Catalog, activate the actions, and gate them behind a running user scoped to exactly what this agent needs — with the named-versus-user principal choice made on purpose. Lean on the API-management layer for rate limiting and audit, because an autonomous caller is the traffic that layer was built for. And keep Agent Fabric in the right box: it governs the mesh; it doesn’t build the action.

Do that and “give the agent access to the order system” becomes a capability the whole org inherits under one policy, instead of the fourth slightly-different callout nobody wants to maintain. If you’re deciding between an Apex action, an External Services import, and a MuleSoft topic for a specific integration — or trying to get a Mule API that works everywhere else to actually register as an agent action — talk to us. Building the governed integration layer under an agent, so it can act on real systems without acting out, is exactly the work we do.

Understanding the basics

What is MuleSoft Topic Center for Agentforce?

Topic Center is a design-time capability in Anypoint Code Builder that lets you turn MuleSoft API operations into Agentforce topics and actions while you design the API. You enable an OpenAPI 3 project for agent topics and actions, annotate the operations you want to expose with x-sfdc/agent/action/publishAsAgentAction: true, and define the topic’s actions and natural-language instructions. Published to Anypoint Exchange and synced into the Salesforce API Catalog, that topic becomes an Agentforce topic any agent in the org can be assigned — so the same API is integrated once and reused across agents rather than rebuilt as a per-agent callout.

How does an API become an Agentforce action through the API Catalog?

After a topic-enabled, managed API is tagged and published to Exchange, you sync it into the API Catalog from Salesforce Setup. The sync auto-generates the Named Credentials, External Services, and Apex classes for each API. You then activate the API’s actions (supplying a connection description and destination URL), grant the relevant permission sets to users and the agent’s running user, and assign the topic and its actions to the agent in Agent Builder. At that point the API’s operations are invocable agent actions, governed by both the running user’s Salesforce permissions and the API’s MuleSoft management policies.

Is MuleSoft Agent Fabric the same as the API Catalog?

No. The API Catalog (with Topic Center) turns your MuleSoft, Salesforce, and Heroku APIs into governed Agentforce actions. Agent Fabric, announced in September 2025, is an enterprise agent control plane for discovering, governing, orchestrating, and observing agents across platforms — Agentforce, Bedrock, Vertex AI, Copilot Studio — and the MCP and A2A endpoints they use, with governance built on Anypoint Flex Gateway. They’re complementary: one exposes API-led capabilities to agents, the other governs the wider agent mesh those capabilities operate in.

Deciding how an Agentforce agent should reach the systems that run your business — Apex, External Services, MCP, or a governed MuleSoft topic — and want the identity and governance right before it can act? Talk to us — designing the integration layer under an agent so it acts safely on real systems is exactly the work we do.

MuleSoft for Agentforce: turning your APIs into governed agent actions