Next Wednesday I walk into the TDX 2026 keynote hall expecting a specific pitch. I think Salesforce is going to put Agentforce 360 and Slack on a single slide and call it the agent stack. I’ll be sitting there with an Azure investment I’m not walking away from — compute, inference, identity, and the LLM gateway all already running somewhere Salesforce doesn’t control.

The question I’m bringing isn’t “Salesforce or Microsoft.” I mapped the six-layer AGaaS stack last week precisely so I could walk into rooms like this one and ask a more interesting question: which Salesforce layers are load-bearing for me, and which are scaffolding I can skip?

The Two Pitches I Expect at TDX

The maximalist pitch is the one I expect on the keynote slides. Agentforce 360 as the agent runtime. Slack as the conversational surface. Atlas as the reasoning engine. Data Cloud as the grounding layer. MuleSoft Agent Fabric as the integration plane. One contract, one console, one roadmap, one throat to choke. If it lands the way I think it will, it’s a genuinely coherent story — coherent enough that a lot of architects will walk out of the keynote having pre-negotiated the compromise in their heads before they ever see the quote.

The unstated alternative is the one I’m curious whether Salesforce will acknowledge — the layers they don’t want to unbundle but legally have to sell you anyway. Core CRM. Data Cloud with Zero Copy. MuleSoft as a plain integration layer. Flow and Apex for deterministic automation. You can buy every one of those layers and put the agent brain in Azure. The maximalist pitch is a bundle. The alternative is a platform.

What I want to figure out at TDX is which layers have real lock-in gravity and which are commodity you can route around.

What Salesforce Appears to Be Building

Three things matter for this analysis based on what’s publicly available, and they sit in different maturity lanes. TDX will either confirm or complicate this read.

Atlas and Agentforce 360 are tightly coupled. Atlas is the reasoning engine — Salesforce’s own engineering writeup describes an asynchronous, event-driven architecture with a Planner, Action Selector, Tool Execution Engine, Memory Module, and Reflection Module. It’s a real piece of engineering, not marketing. The problem for an opt-out strategy is that Atlas is not a standalone service you can call. If you want Atlas, you are buying Agentforce seats. The BYO-LLM support is real — Azure OpenAI is a first-class provider alongside Bedrock, Vertex, and OpenAI — but inference still routes through the Salesforce Models API and the Einstein Trust Layer. You keep your Azure endpoint; Salesforce keeps the runtime.

Slack looks like it’s no longer just messaging. In the 2026 story, Slack appears to be the conversational surface for Agentforce — the UI layer where humans hand tasks to agents and agents report back. If that’s the direction, it’s where the lock-in thickens quietly. Every team that adopts Slack-as-agent-UI is one more team whose muscle memory is tied to a Salesforce-owned surface. The unit economics stop being Slack seats and start being agent-interaction volume. That would be a different contract. I want to see how they frame this on stage.

MuleSoft Agent Fabric is more mature than I expected. As of October 2025, Agent Registry, Agent Broker, and Agent Visualizer are generally available. Flex Gateway now natively supports both the Model Context Protocol and the Agent2Agent Protocol, with policy enforcement for token limits, content safety, and agent identity. The architect deep dive positions it as a unified control plane for LLM traffic, MCP tool access, and A2A communication. This is the layer the rest of the post has to take seriously.

The Opt-Out Architecture

Here’s what I think you can buy on the Salesforce side without touching Agentforce or Slack — the hypothesis I’m taking into TDX to pressure-test.

Core CRM and Data Cloud stay where they are. That’s non-negotiable for most shops already on the platform, and nothing in the opt-out story asks you to move it. Zero Copy is the piece that makes the Azure-side story work: the Zero Copy Partner Network now covers Snowflake, Databricks, BigQuery, and bidirectional Microsoft Fabric integration. Your analytics workloads can see Salesforce data where the data already lives, on Apache Iceberg tables, without round-tripping through the Salesforce APIs. Flow and Apex handle deterministic automation. MuleSoft stays as a plain integration layer if you already own it.

On the Azure side, the stack assembles cleanly. Azure AI Foundry Agent Service is generally available with Entra RBAC, private networking, MCP server support, and multi-provider BYO-model with automatic failover. Azure OpenAI provides the inference. Semantic Kernel handles orchestration for anything multi-agent. Azure API Management’s AI gateway is the LLM governance layer — llm-token-limit, llm-emit-metric, llm-content-safety, and semantic caching are all GA, working across Foundry models, third-party providers, and self-hosted models alike. Entra is the identity plane. Copilot Studio is an optional conversational surface if you don’t want Slack.

The integration seam between the two sides is where the architecture earns its keep. Three options, in ascending governance weight. Direct REST and Bulk API calls with an Entra-federated connected app is the cheapest path — identity is the hard part, and this is where the agent impersonation problem stops being theoretical. MuleSoft-fronted access is cleaner if you already run MuleSoft, because OAuth, mTLS, and runbooks are already solved. Zero Copy sidesteps the API layer entirely for analytics workloads, which matters when your agent is doing aggregation rather than transactional writes.

This is the same six-layer lens from the four-layer regulated AI stack work, collapsed and mapped to the vendor split. The seam isn’t a single protocol. It’s three, chosen per workload.

The MuleSoft Honest Take

I came into this analysis not sold on Agent Fabric. I’m coming out of it with a sharper position: keep it if you have it, don’t buy it for agents alone.

Where Agent Fabric and Flex Gateway earn their keep is the same place every mature integration platform earns its keep — you already run MuleSoft. You have the federated API catalog. OAuth and mTLS are already solved. Your governance runbooks exist. Your on-call rotation knows the product. In that world, Agent Fabric is a low-friction upgrade that exposes your existing API estate as MCP servers, brokers A2A traffic across teams, and puts LLM gateway policies in the same pane of glass your API team already uses. That’s genuinely useful. Flex Gateway’s MCP and A2A support is native, not a port, and the protocol choice matches what the rest of the industry is converging on.

Where it doesn’t earn its keep is in a shop with no existing MuleSoft footprint. Starting MuleSoft for the agent layer is a very large bill to solve a problem Azure APIM plus Entra plus a thin MCP shim can handle for a fraction of the cost. APIM’s LLM policies are not a lightweight alternative — the token-limit policy precalculates prompt tokens server-side, enforces per-consumer TPM caps, and works against models hosted in Foundry, third-party inference providers, or self-hosted open-weight models. That’s the same scope Flex Gateway covers, minus the A2A broker and the MuleSoft runbooks you’d have to build from scratch anyway.

The heuristic is simple. If you already have MuleSoft, let it do A2A, MCP, and LLM gateway duty for the Salesforce-facing half of your estate. If you don’t, don’t buy it to get those things. The governance value of a managed integration platform is proportional to the existing integration estate it governs. A new MuleSoft footprint with no legacy APIs under it is a governance console with nothing to govern.

The Honest Admission

Opting out costs you things. The Einstein Trust Layer’s data masking, toxicity detection, and audit trail are harder to replicate on the Azure side — you can build equivalents with APIM content-safety policies, Purview, and Foundry evaluations, but it’s a build, not a purchase. Agentforce ships with prebuilt skills for Sales, Service, and Marketing; every one of those you’d need to rebuild on the Azure side adds weeks. When Salesforce ships a new native agent feature, you are by definition behind until you rebuild it on your stack. And there’s the split-brain operational cost I wrote about in the architect’s dilemma — two governance consoles, two audit trails, two on-call rotations, two contract negotiations. That cost is real and it doesn’t go away with architecture cleverness.

You’d be trading roadmap alignment for portability. That’s the bet I’m evaluating, and TDX is where I expect to learn whether it’s a reasonable one.

What I’m Curious About at TDX

Four things I want to find out on the floor. Whether BYO-LLM latency on Azure OpenAI is production-viable under the Models API detour, or whether it’s technically supported but operationally discouraged. Whether Flex Gateway’s MCP and A2A support is as mature in a live demo as the docs suggest. Whether Atlas will ever be exposed as a service you can call without Agentforce seats — I doubt it, but it’s the right question to ask. And whether Zero Copy adds new bidirectional targets that make the Azure-hosted agent path cleaner.

This is the first dispatch in what I expect will be a series as TDX unfolds. The hypothesis going in: opting out isn’t a rejection of Salesforce — it’s a bet that the agent layer will be more portable than any single vendor’s 2026 roadmap. TDX is where I find out how hard they’re going to fight that bet.

Sources

Salesforce: TDX 2026 Admin Guide · Salesforce Engineering: Inside the Atlas Reasoning Engine · Agentforce Developer Guide: Supported Models · Salesforce: Einstein Trust Layer · MuleSoft Agent Fabric · MuleSoft Docs: Flex Gateway for Agents (MCP + A2A) · Salesforce Architects: MuleSoft Agent Fabric Deep Dive · Salesforce: Zero Copy Partner Network · Microsoft: New Capabilities in Azure AI Foundry Agent Service · Microsoft Learn: Azure APIM AI Gateway Capabilities · Microsoft Learn: APIM llm-token-limit Policy

---

The AGaaS infrastructure stack this post builds on is in Agent as a Service Is Real. The vendor-governance split is in The Architect’s Dilemma.

Find me on X or LinkedIn. I write about what happens when AI infrastructure meets regulated reality.