Last time the second reader read your architecture. This time it calls your APIs.

In Architecture Is the Prompt I argued that the context layer agents need was never something you had to buy. It was the architecture corpus you were always supposed to keep: the C4 model, the decision records, the principles catalog, plain text in git where you control it. The argument was about what agents read. This post is about what they do. Because the same reversal that turned compliance documentation into a prompt is about to turn the integration estate into a toolbox, and I am walking into two Salesforce events next week to find out how much of that is real.

Tuesday is the Data 360 workshop. Wednesday is MuleSoft Connect:AI. For an enterprise architect in regulated financial services, API-led connectivity is not a conference topic. It is the daily wheelhouse. So when MuleSoft says it can make a governed API estate legible to an agent, that is not a product demo. That is a claim about whether twenty years of integration discipline just became the most valuable asset an institution holds, or its largest ungoverned attack surface.

The Runtime Sequel to the Documentation Argument

The corpus argument had a clean shape. Institutions were forced into documentation rigor for two decades, resented it as a tax, and then discovered the agents needed exactly that text to reason well. The discipline turned out to be the asset.

The integration estate has the same shape. API-led connectivity, the whole system and process and experience layering, the catalog of governed interfaces with their contracts and their policies, was also framed as overhead. It was the price of not letting every team integrate point to point and call it architecture. And now the agents have arrived needing something specific from it.

An agent is only as useful as the actions it can take safely. The model can reason all day, but value shows up when it calls a real system: post a transaction, open a case, check a limit, move a record. That action surface is exactly what an API catalog is. The discipline built to keep integration sane is the thing an agent needs to do anything at all. The corpus was the prompt. The catalog is the toolbox.

What MuleSoft Is Actually Claiming

The specific claim is worth stating precisely, because the whole architecture decision turns on it. MuleSoft’s Agent Fabric says it can take any existing Mule application or API and expose it as a Model Context Protocol server with no code change. Decades of integration investment become MCP-compatible assets that agents can discover and call.

If that holds, it is a genuinely big deal. It means an institution does not rebuild its estate to make it agent-ready. The governed catalog it already keeps, with its contracts and policies, becomes the tool registry. Salesforce frames this further with support for MCP and A2A plus a fabric that is supposed to orchestrate and govern agents across ecosystems, not just Agentforce. The connector documentation describes the mechanics of making Mule apps agent-ready.

The headline writes itself: every API is now a tool. But the headline is also where I get cautious. Turning an API into a tool an autonomous agent can invoke is not a packaging change. It is a change in who calls your systems and how predictably. The governance layer, the policy and security and cost controls, stops being a fence around human-paced traffic and becomes the only thing standing between a reasoning loop and your ledger. That is the part I want to see under load, not on a slide.

The Questions I’m Bringing

I am not going to Manhattan to learn what was built. The press material already tells me that. I am going to find the constraints, the place where the current implementation breaks first, because that is what determines whether I design on this today or design a stub I replace in twelve months. Four questions, in priority order.

Is Agent Fabric Control, or Is It Visibility?

This is the same distinction I brought to Build, and it keeps mattering because vendors keep blurring it. Visibility means I can see which agents exist, what tools they hold, what they have called. That is table stakes and it ships first, because it requires no enforcement.

Control means I can revoke an agent’s access to a specific API, narrow its tool scope without redeploying it, suspend it without deleting it, and contain the blast radius when one agent misbehaves. Agent Fabric is pitched as orchestration and governance across ecosystems. The test is whether that governance is enforcement or inventory. When an agent goes wrong at two in the morning, can I cut its access to the payments API from one surface and trust that the cut is real everywhere, or do I get a very good dashboard of the damage?

Whose Runtime Is the Control Plane?

This is the question underneath the demo, and it is the one I care about most. In the Build verdict I argued the durable fight had moved from owning the harness to owning the context layer. The integration edition of that fight is about the control plane.

If Agent Fabric becomes the place where all my agents, my own and Agentforce and third party, are orchestrated and governed, then it is the most strategically located component in the estate. So does that plane attach to runtime I control, or does adopting it quietly relocate my agent governance into Salesforce and re-lock the moat there? I asked Microsoft a version of this in Governance or Containment. I am asking MuleSoft the same thing from the integration seat. The right answer is a control plane I can point at infrastructure I own. The convenient answer, for the vendor, is the other one.

Who Owns the Context the Agents Reason Over?

This is the Data 360 question, and it is the workshop I am most curious about. Data 360 is now positioned as the live context that fuels agents, with Zero Copy as the headline: your data does not move, the agents reason over it where it lives.

Zero Copy is a real engineering win and also a very good way to phrase a dependency. The data not moving is not the same as the context layer being mine. The unified profiles, the semantic model, the activation logic that makes that data useful to an agent, that is the context corpus, and in Context Engineering Is Infrastructure I argued that layer is the thing you most want to own. So the question for the workshop is concrete. If the context that makes my agents intelligent is assembled and lives in Data 360, what is the exit cost? Zero Copy on the way in is easy to celebrate. I want to understand the path on the way out.

Does the Access Boundary Travel With the Call?

The last one is the trust boundary, and it is where agentic integration gets genuinely hard. My API, exposed through Agent Fabric, has an access policy: this caller can read these fields, not those, up to this rate. Now an agent calls it. Then that agent hands off to another agent, maybe an Agentforce agent, maybe a partner’s agent over A2A.

Does my API’s access boundary travel with the call, or does the downstream agent inherit whatever trust the first agent established? If a partner agent in a multi-agent workflow ends up holding the effective permissions of my agent because the boundary did not propagate, I have not exposed an API. I have delegated my access policy to a chain I do not control. I want a session engineer to walk the failure case, not the happy path. The scenario where the boundary does not hold is the one that tells me what I can actually ship.

Why the Room Matters

The keynote will stream. The announcements will be written up within the hour. If I were going only for content available online, the trip would be ambient conference energy at travel cost, which is not an investment.

The reason to be in the room is the access that does not stream. The hallway conversation with an engineer who is not reading from a script. The Q&A where the follow-up pushes past the prepared answer into honest uncertainty. The workshop bench where you try the thing yourself and find the edge the demo was built to avoid. Press releases describe capabilities. Engineers, cornered politely, describe constraints. The constraints are what shape the next eighteen months of my architecture decisions, so the constraints are what I am flying up to collect.

This year the room is not a hope, it is a schedule. The agenda is a deliberate mix: the public sessions where the platform story gets told, and individual meetings with MuleSoft’s product and executive teams, where a follow-up question has somewhere to land. That second track is the one I care about, because the control-plane and boundary questions above are not answered from a stage. They are answered by the person who can tell me where the current implementation breaks first.

What I Cannot Promise You

The honest part, by tradition. I am writing this before I have seen any of it, so every claim above is a hypothesis I am about to test, not a verdict. The “no code change” promise in particular deserves a calibrated prior: making an API technically reachable by an agent is not the same as making it safe for one to call autonomously, and that gap is usually where the real work lives.

There is also a failure mode I worry about more than vendor lock-in. If turning an API into an agent tool is genuinely one click, then it is one click for everyone, and an estate where every API is trivially agent-ready is an estate where shadow tools multiply faster than governance can register them. The thing that makes the catalog a toolbox is the same thing that makes it a sprawl risk. A governed catalog is an asset. An ungoverned one that thinks it is governed is worse than no catalog at all.

And I will not know which of these I am holding until I have pushed on it in person. That is the whole point of going.

The Catalog Was Waiting Too

The corpus argument ended with the architecture documentation turning out to be the prompt all along. The integration argument rhymes. The catalog of governed APIs, built to keep integration disciplined and resented as overhead, turns out to be the action surface agents need to do real work. The discipline was the asset again. The only question is whether the control plane on top of it stays mine.

I will know more by Thursday. The verdict post will have the synthesis: what held up at the bench, where the boundaries broke, and whether Agent Fabric and Data 360 hand me a control plane I own or a very elegant lease. That one I write after I have been in the room.

---

If this resonated, the companion read is Architecture Is the Prompt. That post was about the context agents read. This one is about the tools they call.

If you are at MuleSoft Connect or the Data 360 workshop working through the same questions, agent governance, control planes, context ownership, I want to compare notes in the room. Find me on X @orestesgarcia or LinkedIn /in/setsero. The verdict post will be here after.