I flew up to Manhattan to find out whether Agent Fabric and Data 360 hand me a control plane I own or a very elegant lease. The honest answer is neither, because neither was quite the right question.

In The API Catalog Is the Tool Catalog I carried four questions into the room. Is Agent Fabric control or just visibility. Whose runtime is the control plane. Who owns the context the agents reason over, and what does it cost to leave. And does an API access boundary travel with an outbound agent call. Time on the floor at Connect:AI convinced me the question I should have asked was a different one. Not which vendor wins the control plane, but whether anyone does.

They do not. The most likely future is not MuleSoft winning the control plane or Microsoft winning it. It is the two coexisting: Azure AI Foundry as the place models and agents run, and MuleSoft Agent Fabric as the cross-vendor layer that governs and brokers them. Foundry and Fabric, not Foundry or Fabric. That is a read of where the public roadmaps point, not a vendor commitment. The four questions are how I got there.

Control, Not Just Visibility

I went in skeptical, because vendors keep blurring this line, and I came out moved. Agent Fabric has more real control than I expected, not just a very good dashboard.

The levers are concrete. The Omni Gateway does semantic routing and policy enforcement on agent traffic, not just logging. There is an Agent Kill Switch as a named intervention mechanism, which is the thing you actually want at two in the morning: cut an agent off, do not just watch it. Trusted Agent Identity rides on Gateway Federation. That is enforcement living in the path of the call, the test I set in the thesis post, and it passed more of it than I assumed.

Then the headline quietly walked itself back. The pitch was autonomous agents, and what shipped leans on deterministic scripting, because, as the independent analysts put it, autonomous agents are not predictable enough for production yet. Determinism is the admission under the feature. On the floor, practitioners said agent identity is still not fully defined. So the enforcement is real, and it is not yet enough to run unattended against a ledger. Control, with an asterisk I am not allowed to ignore. It is the kind of containment I watched Microsoft build into the OS in the Build verdict, arriving here from the integration seat.

A Runtime You Can Still Own

This was the question I cared about most, and the one that turned the post toward coexistence.

The fear was that adopting Agent Fabric would quietly relocate my agent governance into Salesforce and re-lock the moat there. Gateway Federation is built to do the opposite. It lets one policy catalog govern gateways you already run, Kong, Apigee, your own, without rerouting traffic through anyone. Governance by attachment, not runtime captivity, the same shape that made governance or containment resolve better than I feared. You can own more of the plane than the demo implies.

The catch is that the marketed breadth runs ahead of the shipping connectors. The hard question, the one no keynote answers, is whether policy semantics translate cleanly across gateways with different runtime models, different identity systems, and different policy primitives. A federation that lists five gateways on a slide is not a federation that enforces the same rule identically on all five.

The realistic posture is federated, and the most probable shape is Foundry’s runtime sitting under Fabric’s policy plane. The direction points there. It has not arrived. The Omni Gateway federation story names Azure in its set, and the AI Gateway routes across model providers, but the coverage is partial. It does not yet reach Foundry’s full model catalog, and Anthropic’s models on Azure are still on the roadmap, a few months out, which is the same gap I flagged from another angle in Beyond the Rebrand. So I am revising my earlier read that Foundry was not a routing target, but only halfway. It is becoming one, slowly, and the Anthropic seam is exactly where announced runs ahead of available. Confirm the specific connectors with your vendor before you design on them.

When the Second Lake Doesn’t Pay

The third question was who owns the context the agents reason over and what it costs to leave. The more you look at Data 360, the sharper question is whether you should stand up the second platform at all.

Start with what is true. Zero Copy is a real engineering win, and Data 360 and Microsoft Fabric interoperate through it. Microsoft Fabric sits in Salesforce’s Zero-Copy Partner Network, so the two reference each other without duplicating data. That is the part the pitch leads with, and it is the part that should make you cautious, not comfortable.

A data platform is never just storage. It is a semantic model, a governance plane, a consumption meter, and a learning tax, the same tax I argued in the investment post. If you already run a unified lake, and OneLake is one copy for the whole tenant by design, the honest question is what a second platform buys you that a zero-copy reference into the first one cannot. I made the copy-versus-reference case in The Zero-Copy Promise. It bites harder here, because the second thing you are asked to keep is not a table, it is a whole platform.

What Data 360 genuinely adds is native Salesforce customer-data harmonization, identity resolution, and activation into Agentforce. Real value, and it earns its place to the degree your customer data and your agent activation are Salesforce-centric. If they are, the second platform pays for itself. If they are not, one lake referenced by zero copy is usually enough, and the cost of the second is hard to justify to anyone holding the budget. This is the one layer where the blend’s “and” gives way to “pick one.” Which one depends on how Salesforce-centric the estate already is. Either way, own the semantic layer you most depend on in plain text you control, the way I argued in Architecture Is the Prompt, so the choice stays yours.

The Boundary That Doesn’t Travel

The last question is the trust boundary, and it has the least comfortable answer. The boundary does not travel cleanly with the call. Not yet.

A2A is a wire format. Conformance makes agents interoperable; it does not make governance or identity propagate. My API, exposed through the fabric, has an access policy. An agent calls it, then hands off to another agent, maybe a partner’s over A2A. What became clear is that the downstream agent tends to inherit the trust the first agent established, instead of the original access boundary travelling with the request. The practitioners’ admission that identity is still not fully defined is the same gap, said out loud.

The same seam keeps turning up in a new place. It is the human-versus-agent identity gap from Who Issued the Agent?, where the identity planes simply do not talk. It is the discovery asymmetry from Who Scans Whom, where each platform catalogs the other but neither grants reciprocal trust. Vendor-neutral workload identity exists, SPIFFE-style, and as I said before, it is available and it is not free. Until propagation is solved, the trust boundary is the thing that breaks first in any multi-agent chain. It breaks precisely at the seam between two vendors, which is the strongest evidence that no single vendor owns this plane.

Why Coexistence, Not Conquest

Put the four verdicts next to each other and the pattern is hard to miss. Three refuse a clean single owner. Control is real but partial. Runtime is federated, not captured. The trust boundary fails at the vendor seam. Only the fourth, the data layer, points the other way, toward consolidation: a second lake rarely justifies its cost. Coexist on the control plane, consolidate on data.

The market pushes the same direction. MCP and A2A have moved from differentiator to table stakes, a shift I traced in The Agent Control Plane War. When the protocols are commodity, interoperability is the ground state, and interoperability favors coexistence over conquest. Nobody owns a plane that every competitor can already speak into.

So the prediction, grounded in what shipped. Azure AI Foundry as the runtime where models and agents execute, and MuleSoft Agent Fabric, the Omni Gateway and the scanners and the registry, as the cross-vendor governance layer over it. Foundry and Fabric, not Foundry or Fabric. The data layer is where you resist running two of everything. The governance layer is where you accept you will run across more than one vendor whether you planned to or not.

What I Cannot Promise

The honest part, by tradition. The prediction rests on pieces that are still half-built. Clean Azure federation, identity that propagates across an A2A handoff, policy semantics that translate across gateways with different runtime models. Every one is announced more confidently than it is shipped.

The vendor’s own boilerplate says as much, cautioning that announcements may reference features still in development and that you should buy on what is released. I am betting on the direction, not the dates. If propagation never gets solved, the coexistence I am describing stays a diagram, and the seams between the vendors stay the dangerous part of the estate. That is the risk anyone designing on this carries, eyes open.

The Verdict, in One Line

The thesis post asked whether the control plane on top of the catalog stays yours. It is not a single plane, and it does not have a single owner. What you get is a federation you have to govern, and the real work is making the seams hold. Coexist where the protocols force you to. Consolidate where a second platform cannot pay. The vendors will own their layers. The architecture that lasts belongs to whoever owns the seams between them.

---

If this resonated, the companion read is The API Catalog Is the Tool Catalog. That post carried the four questions into the room. This one carries the verdict out.

If you are designing across Foundry and Fabric, or making the same coexist-or-consolidate call and landing somewhere different, I want to compare notes. Find me on X @orestesgarcia or LinkedIn /in/setsero.