Salesforce Agent Fabric: The Complete 2026 Guide

Salesforce said the quiet part out loud in 2026: fully autonomous agents broke in production. Not in a lab, not in a demo — in real orgs, where one agent called another agent, which called an LLM, which decided to issue a refund nobody approved. The promise of "set the agent loose and let it reason" collided with the reality that enterprises run money, contracts, and regulated data through these systems. You cannot let two language models negotiate a refund between themselves and hope for the best.

Agent Fabric is the answer. It is a multi-vendor governance and orchestration control plane that sits above your agents — every agent, not just Agentforce — and enforces policy at the exact points where autonomy becomes dangerous. It went GA in May 2026. If you have already deployed agents from more than one vendor, or you plan to, Agent Fabric is the layer that keeps that sprawl from becoming an incident.

This guide walks through all five components, the thesis that ties them together — Guided Determinism — and the concrete steps you should take in your org now.

The Problem Agent Fabric Solves

By 2026 most enterprises were not running one agent. They were running [Agentforce for service](/terms/agentforce-for-service), Microsoft Copilot for productivity, Amazon Bedrock agents for a data pipeline, and a Google Vertex agent some team stood up without telling IT. Each vendor brought its own identity model, its own LLM billing, its own logging — or no logging at all. There was no single place to answer basic questions: Which agents can touch customer PII? What did this agent spend last month? Who approved that agent calling an external tool?

That is agent sprawl, and it is a governance vacuum. Agent Fabric fills it by inserting a control plane between the agents (the hosts) and everything they reach: data sources, tools, and other agents. The host can be Agentforce, Bedrock, Vertex, or Copilot. The fabric does not care. It governs the traffic regardless of who built the agent.

Five components do the work. AI Gateway governs LLM calls. MCP Bridge governs tool connections. Trusted Agent Identity authenticates every invocation. Agent Broker orchestrates across vendors. Agent Script declares the deterministic rules. Together they implement one idea — Guided Determinism — which we get to after the parts.

AI Gateway: One Policy Layer for Every LLM Call

Every LLM call your agents make should pass through one chokepoint, and AI Gateway is it. Without a gateway, each agent talks directly to whatever model it was wired to, and you have no centralized control over cost, content, or compliance. The gateway centralizes all of it.

It enforces centralized LLM policy — which models are allowed, for which teams, under what conditions. It does token accounting, so you finally know how many tokens each agent burns. It performs PII redaction on the way out, stripping sensitive fields before a prompt ever leaves your trust boundary, the same principle behind the Einstein Trust Layer but applied to arbitrary external models. It applies per-team quotas, so the marketing team's runaway agent cannot starve the service team's budget. And it writes a complete audit log of every call.

The piece architects underrate is LLM Governance for cost-per-business-unit. Token accounting tells you what was spent; LLM Governance attributes that spend to a business unit, so finance can charge the sales org for the sales agents and the service org for the service agents. When agent costs scale into real money, that attribution stops being a nice-to-have and becomes the only way to defend the budget.

MCP Bridge: Model Context Protocol, Governed

The Model Context Protocol became the lingua franca for connecting agents to tools, but raw MCP is a trust problem. An MCP server is just an endpoint an agent can call, and nothing about the bare protocol tells you whether that agent is allowed to call it, what it can do once connected, or whether the data flowing both ways is safe.

MCP Bridge turns MCP into a governed enterprise pattern. It adds trusted authentication so only verified agents connect, and scoped permissions so a connected agent gets exactly the access it needs and nothing more. Critically, it runs the Trust Layer in both directions — inspecting and redacting data the agent sends to the tool and data the tool returns to the agent. A poisoned response from an external MCP server gets caught on the way back, not after it has already steered the agent's next action.

MCP Bridge also handles automated discovery via Agent Scanners. Scanners crawl your environment and surface the MCP endpoints and agents already in use — including the ones nobody registered. This is how you find the shadow Vertex agent. You cannot govern what you cannot see, and the scanner is what makes the inventory possible.

Trusted Agent Identity: Authentication for Every Invocation

Human users have identity. Agents, historically, did not — they borrowed a service account or an API key and operated as an anonymous blob of automation. Trusted Agent Identity fixes that by giving each agent a verifiable identity per invocation. Every time an agent acts, the fabric knows precisely which agent it was, who owns it, and what it is permitted to do.

The feature that earns its keep is mobile step-up authentication for high-risk actions. When an agent attempts something genuinely consequential — a refund above a configured threshold, a contract change, a production data export — the fabric pauses and pushes a step-up challenge to a human's phone. The agent cannot proceed until a person approves. This is the human-in-the-loop control made concrete: not a vague policy document, but a hard gate wired to the action that matters. Define your thresholds carefully, because they are the difference between an agent that helpfully drafts a refund and one that silently issues ten thousand of them.

Agent Broker: Orchestration Across Vendors

Agent Broker is the cross-vendor orchestration engine — the part that connects Agentforce, Bedrock, Vertex, and Copilot into a single workflow. Before Agent Broker, stitching a Bedrock agent to an Agentforce agent meant custom glue code, brittle webhooks, and no shared governance. The broker makes cross-vendor handoffs a first-class, governed operation.

You author these workflows two ways. There is a visual authoring canvas for architects and admins who want to compose flows graphically — drag a Vertex agent next to an Agentforce agent, define the handoff, set the guardrails. And there is Agent Script, the code-first path, for teams that want their orchestration in version control. The two are views of the same underlying definition, much like building automation as Flow versus Apex: pick the altitude that fits the team and the complexity. Agent Broker is in beta as of GA, which is exactly why now is the time to pick a workflow and get hands-on before it becomes the default fabric for every cross-vendor interaction.

Agent Script: Determinism You Can Commit to Git

Agent Script is an open-source language for declaring how agents hand off work. Where an LLM's reasoning is probabilistic, Agent Script is fixed: it declares handoff rules, state, and execution flow as explicit, readable code. At each transition point between agents, you can attach deterministic hooks — code that runs unconditionally, the same way, every time. The LLMs reason between the hooks; the hooks themselves never improvise.

The design decision that matters most: Agent Script lives in version control, right next to your Apex classes and your Flow XML. Your agent orchestration becomes a reviewable, diffable, deployable artifact. It goes through pull requests. It gets tested in a pipeline. It rolls back cleanly. This is the move that takes agent behavior out of a vendor console and puts it under the same engineering discipline as the rest of your codebase — which is the only way agent logic survives contact with a real release process.

A handoff declaration reads roughly like this in spirit: when the triage agent finishes, transition to the refund agent, but first run the verifyRefundLimit hook; if the hook fails, stop. The LLM never gets to talk its way past that check, because the check is code, not a prompt.

Guided Determinism: The Core Thesis

Here is the idea that ties the whole fabric together. Put deterministic code at the seams where money moves and regulated actions fire. Let LLMs reason inside their lanes between those seams.

Pure autonomy failed because it allowed probabilistic reasoning at exactly the points where you need certainty. Two agents negotiating a refund is two language models improvising a financial decision with no checkpoint. Guided Determinism inverts that: the refund amount, the approval threshold, the data-export gate — those are hooks, fixed code that executes identically every time. The agents reason about which customer, what their problem is, how to phrase the resolution. They do not reason about whether the refund clears the limit. That is decided.

This is the honest middle path between "agents can do anything" and "agents are too risky to ship." You get the flexibility of LLM reasoning for the open-ended work and the guarantees of deterministic code for the consequential work. The hard part, which the press release glosses over, is identifying your seams. Nobody can hand you the list. You have to map where your agents touch money, contracts, and regulated data — and that mapping is the real architecture work.

What to Do Now

Agent Fabric is GA, but Agent Broker is still in beta, which makes this a window, not a deadline. Here is the practical sequence.

1. Run an Agent Scanner sweep. You cannot govern what you cannot see. Run the scanner across your environment and build the real inventory of agents and MCP endpoints — including the shadow ones. This is step zero for every other decision.

2. Identify your high-risk actions. Sit down with the business and list the actions that warrant a deterministic hook and step-up auth: refunds above a threshold, contract changes, production data exports, anything regulated. These become your seams. This is the work no tool does for you.

3. Pick one cross-vendor workflow for the Agent Broker beta. Do not boil the ocean. Choose a single workflow that already crosses vendors — say, an Agentforce service agent that needs a Bedrock agent's output — and rebuild it through Agent Broker. Learn the model on something real before it is mandatory.

4. Audit your Connected App inventory. Trusted Agent Identity is only as good as the access already granted. Review every Connected App and integration that agents authenticate through, revoke what is stale, and scope what remains.

5. Add Agent Script to your version control standards. Update your team's definition of done so agent orchestration lives in the repo, goes through pull requests, and ships through the pipeline — same as Apex and Flow. Decide this now, before you have fifty agents and no convention.

The Bottom Line

Agent Fabric is Salesforce's admission that the fully autonomous agent was the wrong goal, and its bet on a better one. AI Gateway governs the LLM calls. MCP Bridge governs the tools. Trusted Agent Identity authenticates the actors. Agent Broker orchestrates across vendors. Agent Script makes the rules deterministic and committable. Guided Determinism is the thread: code at the seams, reasoning in the lanes.

The teams that win in 2026 will not be the ones with the most autonomous agents. They will be the ones who knew exactly where to put the checkpoints — and wired them in before an unsupervised agent found the gap first.

---

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.