The architecture convinced me in the first ten minutes on the floor. The investment case took the rest of the day to come apart.

I walked into MuleSoft Connect:AI expecting to argue about the architecture, because that is usually where these things break. It did not break. The control plane story is coherent, the boxes connect, the demos work. The part everyone expects to fight over turned out to be the easy part. The expensive part was never on the slide.

What Agent Fabric Actually Gets Right

Give the architecture its due first, because it earns it. The named enemy is agent sprawl: agents multiplying across Agentforce, Bedrock, Vertex, Copilot Studio, with no central catalog, no shared governance, no single place to see what is running or what it costs. Anyone who has watched shadow IT happen knows this is real, and it is happening faster than shadow IT ever did.

Agent Fabric answers it with one control plane that does three things. It discovers agents and registers them into a single catalog, scanning the other platforms automatically. It governs them through a gateway that handles identity, policy, and a kill switch. It orchestrates them, increasingly through deterministic scripting rather than open-ended autonomy. Discover, govern, orchestrate. As a reference architecture it is hard to argue with, and I covered the competitive shape of it in The Agent Control Plane War when MuleSoft and Microsoft both shipped the same pitch in the same month.

The numbers behind the pitch are real too, even discounting the source. Salesforce’s 2026 Connectivity Benchmark surveyed 1,050 IT leaders and found organizations running an average of 12 agents, projected to climb 67 percent within two years, with 96 percent saying agent success depends on integration across systems. It is vendor-sponsored research built to make integration look like the bottleneck, so weight it accordingly. But the direction is not in dispute. The diagram scales cleanly to that future.

The question nobody costed on stage is whether the team does.

The Cost Everyone Argues About

Start with the cost you can see, because it is the one the room wants to talk about, and it deserves a fair hearing before I set it aside.

MuleSoft has never been cheap, and the bill has more lines than people expect. You license runtime capacity, historically by vCore and, for contracts signed since 2024, by Mule Flows and Mule Messages instead. You pay to manage APIs, priced by how many you put under management. You pay for gateway traffic, the requests and responses moving through it, plus data egress. And premium support is its own line, more again at the Signature tier. None of that changes whether you run on CloudHub or on your own infrastructure through Runtime Fabric, because you are paying for licensed capacity and support, not for where it runs. The AI connectors are free to obtain on the exchange and not free to run, because every agent interaction tends to fan out into multiple backend calls, and each call lands on one of those meters: more runtime consumed, more gateway traffic, more managed surface area.

Then there is the part of the spend that has nothing to do with the license. Third-party contract data puts mid-market first-year total cost in the several hundred thousand range once you add implementation, and the people line is the heavy one. Specialist DataWeave developers run well into six figures each, and system-integrator services in year one routinely land at two to three times the base platform cost. The contract benchmarks tell the same story across every iPaaS in the category.

This is the cost finance knows how to fight. It is a number in a spreadsheet, it has a vendor on the other end of it, and procurement can negotiate it down. That is exactly why it is not the one that bites. The cost that bites does not show up on any meter.

The Learning Tax

The line the whole keynote hung on was the shift “from a software mindset to an agent mindset.” That sentence is the entire investment problem hiding in a phrase. A mindset shift is not a line item. You cannot buy it, depreciate it, or put it on the contract. Your people have to acquire it, and they acquire it by spending time they were spending on something else.

Look at what a team actually has to internalize before any of this delivers value. The MCP and A2A protocol model, which is new enough that the vendors themselves were still defining it on stage. Agent Script, the deterministic scripting layer for codifying multi-agent workflows. The visual orchestration canvas with its human checkpoints. The registry and the governance model that sits on top of all of it. Each one is a real abstraction with its own mental model, and none of them is free to learn.

None of this is a MuleSoft problem. Pick Boomi, Workato, Microsoft’s Foundry, or a cloud-native build on AWS, and the names change while the shape does not. Each arrives with its own protocols, its own orchestration model, its own governance vocabulary, and each has to be learned before it pays. The tax is not levied by the vendor. It is levied by the act of adopting an unfamiliar abstraction, and every platform on the shortlist charges it.

And it compounds with variety. A team on one platform learns one model. A team spread across three vendors and a stack of technologies carries all of them at once, plus the seams between them, where the hardest learning lives. The tax is not paid once. It is paid per abstraction, and the bill grows with every vendor and tool you choose to keep. The agent sprawl a control plane promises to tame is, underneath, a learning tax that multiplied while nobody was counting.

You can see the curve in the build times. Recipe-driven platforms advertise one to two week builds against MuleSoft’s eight to ten. Part of that gap is tooling, and part of it is the depth of the model you have to hold in your head to be productive. The deeper the abstraction, the longer the climb before output. That climb is not waste. It is the price of the power the abstraction gives you. But it is a price, and it is paid in the one currency a fixed team cannot print: delivery capacity.

I made a version of this argument once already, about regulated work, in The Compliance Tax. That post was about why AI productivity in a regulated shop lands at three times, not the ten times the marketing promises, because compliance taxes every gain. This is the sibling tax. Compliance taxes your productivity. A new abstraction taxes your capacity, up front, before the productivity arrives at all.

When the Body Count Is Fixed

Every vendor ROI deck carries the same unstated assumption: that you will staff the new layer. The model quietly imagines an org that hires the agent engineers, the DataWeave specialists, the platform owners, and adds them on top of the team already doing the work.

Most enterprises are not that org. Headcount is fixed for the year, sometimes fixed for several. When the body count does not move, you do not add the new layer. You reallocate into it. Adopting the abstraction means someone stops doing their current job and starts climbing the learning curve instead, and the backlog they were burning down does not pause to wait for them.

That is the real shape of the investment, and it is why the case is hard to write honestly. The license cost is small and visible. The learning tax is large and hidden, and it lands first. One of the CIO panelists reframed the whole value question as “return on intelligence, not ROI,” which is a good line, but the intelligence has an acquisition cost, and the return only starts after the team has crossed the curve. You pay the tax against this quarter’s delivery to earn a return that shows up in some later quarter, if the team gets there.

The scale numbers make the stakes concrete. The keynote’s proof point was one customer running 420 agents on MuleSoft. A panelist quietly mentioned running closer to 1,500 across different platforms. The gap between those two numbers is the sprawl the control plane is meant to tame, and taming it at that scale is not a tooling problem you buy your way out of. It is a team that has to learn to operate a fabric, and there are only so many of them. I made the adjacent argument in The Bottleneck Was Never the Code: when the tool changes and the velocity does not, the constraint was never the thing the tool fixed.

Process Is the Problem, Not the Platform

The most honest moment of the day came from the practitioners, not the keynote. “Process is the problem to solve” was a refrain on the CIO panel. So was “DevOps and the quality of your process is the real lever.” There was heavy emphasis on InfoSec education, and a candid admission that agent identity is still not fully defined, which lines up with what the independent analysts have been saying about the gap between the announcement and the assembled, working whole.

Read that against the investment question and it gets sharper. The architecture assumes a process maturity that most fixed teams have not built yet. It assumes you already have the DevOps discipline, the identity model, the security education, the governance habits that let a control plane mean something. Building those is not a one-time setup. It is more learning tax, layered on the first one.

And if you skip it, you do not get a faster outcome. You get automated chaos, which I wrote about in Automating Chaos Produces Automated Chaos. Sol Rashidi’s 200-plus deployments put roughly 70 percent of AI failure on organizational causes, not technical ones. A control plane on top of an immature process does not fix the process. It scales it, faster, with less human in the loop to catch it. The platform is genuinely good. It is also a multiplier, and a multiplier on an unready process multiplies the wrong thing.

Sequence the Tax, Don’t Pretend It Away

You cannot avoid the learning tax. What you can control is when you pay it and where you pay it first.

Pay it where process maturity already exists. The one place an enterprise has usually built real discipline is the governed API catalog, the part of the estate that was always treated as overhead and now turns out to be the asset. That is the argument I made walking into these events in The API Catalog Is the Tool Catalog. Start there. Wrap APIs you already govern as agent tools through MCP Bridge, where the access model and the operational habits already exist, rather than standing up net-new agent sprawl and learning everything at once. Test the wrapper behavior carefully, because the analysts are right that auto-generated tools inherit every quirk of the underlying API.

Let one team cross the curve before you scale. The learning tax is paid once per person, but it compounds the other way too: the first team to internalize the model becomes the internal teachers for the next. Fund that team explicitly, protect its capacity, and treat its job as much teaching as building. That is how a fixed-headcount org absorbs an abstraction without grinding delivery to zero.

And take the quiet retreat as good news. The headline pitch was autonomous agents, and what actually shipped at GA leans on deterministic scripting, because, as one analyst put it, pure autonomous agents do not behave predictably enough for production. A deterministic, auditable workflow is easier to learn, easier to govern, and easier to trust than open-ended autonomy. For a team paying a learning tax, a smaller, more predictable surface to learn is a feature, not a climbdown.

Then write the honest ROI model. Put a line in it for capacity lost to learning. Return on intelligence is real, but only if you budget the cost of acquiring the intelligence, and most cases do not.

What I Am Not Saying

I am not saying do not adopt it. Agent sprawl is a real problem, a control plane is the right answer, and Agent Fabric is a credible one. If you have the scale, you will need something in this shape, and the architecture genuinely holds up.

What I am saying is that the investment case that should get approved is the one that is honest about the human curve, and most of the cases I see are not. They cost the license and the implementation and stop, as if the team absorbs a new abstraction for free in its spare time. It does not. There is no clean number for the learning tax yet. Nobody has one. That absence is not a reason to ignore it. It is exactly the problem, and the first enterprise to put a real figure on it will make better decisions than the ones still pretending the cost is only on the invoice.

The architecture verdict, the four questions about control, runtime ownership, context exit cost, and trust boundaries that I carried into the room, is its own post, and it is coming next. This one was about the cost that never makes the slide.

---

If this resonated, the companion read is The Compliance Tax. That post was about the tax compliance charges your productivity. This one is about the tax a new abstraction charges your capacity, before any productivity shows up.

If you are an architect writing this investment case with a headcount that will not move, I want to compare notes on how you are pricing the curve. Find me on X @orestesgarcia or LinkedIn /in/setsero. The architecture verdict post lands next.