Draw the Boundary Before You Buy Deeper

I’m flying out a day early for the Data 360 developer bootcamp, and the badge is not the reason. I can learn the click-path from Trailhead on the plane. What I want out of the week is something a bootcamp does not hand you: the boundaries. Every platform I evaluate now runs the same play, opening one layer so it can quietly own the layer above it, and Salesforce runs it better than most. So before I let anyone talk me into buying deeper, I want to draw the lines myself. Where the data layer ends and integration begins. Where an agent should run on platform and where it should not. Where source control stops being a suggestion. That line-drawing is the whole job this week.

The bootcamp is the cheap part

Data 360 is the artist formerly known as Data Cloud, renamed at last year’s Dreamforce to signal that it grounds every Agentforce agent, not just marketing. The developer primitives are learnable in a day: data streams for ingestion, data model objects for the harmonized schema, identity resolution to collapse duplicate profiles, data graphs for fast structured retrieval, and a vector index with retrievers for the unstructured half. Wire a retriever into a prompt template into an agent action and you have retrieval-augmented grounding, the thing that keeps the model answering from your records instead of its imagination.

None of that is the hard part. The hard part is the decision tree the bootcamp will breeze past.

When do I federate and when do I copy? Zero-copy federation queries Snowflake, Databricks, or BigQuery in place, no duplication, freshness bounded by the source. Physical ingestion buys sub-second latency and centralized governance at the cost of a second copy to secure. The catch the demo skips: federated data still has to map onto a data model object and pass through identity resolution, so “zero copy” is not “zero work.” Which grounds a given question, the data graph or the vector index? When is the auto-provisioned Agentforce Data Library good enough, and when do I need to hand-build the ingestion, chunking, and index because I care about what goes into the model? And the one nobody volunteers: how does my chunking strategy feed straight into per-action token thresholds, so a sloppy retriever quietly triples my bill?

That last question is the theme of this whole trip. The primitives are free to learn. The judgment is what costs you, and it is the only thing worth flying early for. I made a version of this argument in The Data Was Always the Problem and again in The Zero-Copy Promise. Data 360 does not change the thesis. It raises the stakes, because now the data feeds an agent that acts.

On platform, off platform, and the action ceiling

Agentforce is genuinely good at a specific shape of work, and it helps to name it precisely before deciding what to keep off platform. The Atlas reasoning engine plans a turn, picks tools, and self-corrects across multiple model calls. Topics scope the agent, actions are the things it can do, and the Einstein Trust Layer sits between every prompt and every model doing PII masking, toxicity checks, and zero retention. Since Claudeforce landed in August, Claude runs the reasoning engine through Bedrock inside that trust boundary, which is the version of bring-your-own-model that a regulated shop can actually defend. The reciprocal deal put Salesforce skills inside Claude, a story I covered when it broke.

So what should live on platform? Governed actions on Salesforce records, where the context is already resolved and the audit trail is free. What should not? Three things push me off platform fast, and I want them confirmed on the floor.

The action ceiling. The widely cited limit is roughly fifteen topics-and-actions before a single agent gets unreliable. Past that you are not building one clever agent, you are building an orchestrator that delegates to specialized workers. That is a design decision, not a setting, and it changes your whole cost model.

Synchronous limits. For a cross-system transaction that has to be atomic, the pattern in the field is to push the work to a MuleSoft endpoint acting as a tool so it runs outside Salesforce’s synchronous governor limits and keeps the agent prompt lean.

The bill at volume. Flex Credits price a standard action near ten cents covering up to ten thousand tokens, and anything over threshold bills as a silent multiple. A five to fifteen action conversation is cheaper than the legacy two-dollar flat model. A thirty-five action agent sequence is not. There is a break-even, and above it the “modern” pricing is the expensive one.

My lean before I walk in: keep the orchestration and decision layer portable, use Agentforce for the governed Salesforce-native actions it does better than anyone, and treat the Model Context Protocol as the seam between the two. That is the same instinct I argued in Salesforce Without the Full Buy-In and stress-tested against Vibes in the developer-experience comparison. The question I need answered is whether MCP support has matured from Agentforce-as-client into Agentforce-as-server, because my architecture needs external agents to call into Salesforce, not only the reverse.

Same data, three ways to reach it

First, the naming, because getting it wrong on the floor costs you credibility. The thing you keep hearing about is MuleSoft Agent Fabric, not “MuleSoft Fabric,” and it has nothing to do with Microsoft Fabric, which is a different company’s data platform. Agent Fabric is a registry, a broker, a governance layer with token and cost visibility, and a visualizer. It takes the API-led connectivity playbook, discoverability and reusability and governance, and applies it to agents instead of APIs. The honest read from analysts is that this repositions MuleSoft from integration middleware to core AI infrastructure. That is the strategy, not a feature.

The clean boundary Salesforce draws is that Data 360 is the data and grounding layer while MuleSoft is integration and action across everything else, exposed to agents through Topic Center. Fine. Now here is where I plan to push.

There are at least three separately-metered ways to get the same external customer record in front of an agent. Zero-copy federation through Data 360. A MuleSoft API dressed as an agent action. A native Flow or Apex call. Salesforce will happily sell you all three, and each meters somewhere different: federation shifts cost to compute and consumption credits, the MuleSoft path shifts it to integration build plus API latency, the native path is bounded by platform limits. None is obviously cheapest. It depends entirely on query volume and how fresh the data has to be, which is exactly the kind of judgment the interoperability decision guide gestures at without deciding for you.

Two more things I want to interrogate. Do I even need Agent Fabric for a Salesforce-centric estate, or is it a second governance plane layered over the orchestration Agentforce already does, redundant governance I pay for twice? And the trap that catches teams late: an API that works in Postman is not agent-ready. If the schema is loose or the endpoint returns a generic object Salesforce cannot map to action inputs and outputs, “integration done” and “agent-ready” are different milestones. This is the boundary story from Foundry and Fabric, Not Foundry or Fabric and the load-bearing-layers question from the TDX floor read, one turn further down the road.

Source-driven or the AI doesn’t touch it

This is the track I care about most, because it is the prerequisite for everything else. You cannot run an AI-assisted development lifecycle on a platform where changes happen by clicking around in production. You need source control as the source of truth first, and only then does the AI get to write.

The good news is that native tooling moved this year. DevOps Center graduated from a managed package to a native core application in the Spring release, which is effectively a different product wearing the same name: Git as source of truth, sandbox pipelines with quality gates, side-by-side merge resolution, and commits from both the UI and from outside the org, which is the bridge between click-admins and code-devs. Agentforce Vibes and the DX tooling then layer version-controlled AI development on top, so agent-generated changes land in a pull request instead of straight into an org.

The argument for why this is non-optional is simple. An AI generates change at a volume no human review cadence was designed for. Without Git you cannot diff what it did, attribute it, test it, or revert it, and “unattributable and unrollbackable” is a compliance failure, not just an engineering smell. Reproducibility through scratch orgs and unlocked packages is what lets you rebuild and test agent-generated config deterministically. I made this case for infrastructure in Don’t Vibe Your Infrastructure and for the platform in You Can’t Edit What You Can’t Write. The Salesforce version is the same shape.

Now the adversarial half, because native tooling still has holes third parties get paid to fill. No native rollback, so recovery from a bad deploy is manual. No org-diff or drift detection engine. No backup, that is a separate purchase. Metadata coverage gaps where some types will not retrieve or deploy cleanly. Org-dependent config, profiles and record types and hard-coded IDs, that breaks reproducibility across orgs. And the one that undoes the whole thesis: a click-admin can still change production directly and bypass the pipeline entirely.

So the question I need answered is not whether Salesforce lets me do source-driven development. It clearly does. It is whether I can enforce it, so that nothing reaches production outside Git, and what my drift-detection story is when someone inevitably does. Enablement is a feature. Enforcement is an architecture. And I want to know, before I commit, whether Vibes can even reach a Git repo that lives behind a corporate VPN, because for a lot of regulated shops that is where the code actually is.

The announcement I’m actually watching

I split my time at these conferences between the Salesforce hall and the MuleSoft sessions, and the thing I am watching for is any real movement on MuleSoft talking to Azure AI Foundry. The concrete piece that already ships is the MuleSoft Inference Connector, which reaches Azure AI Foundry and Azure OpenAI alongside a dozen other providers, so you can swap the model behind an integration by changing config instead of code. That decouples business logic from model choice, which is genuinely useful.

What does not exist is a first-party MuleSoft-to-Foundry partnership. The interop is standards-based coopetition, not a bilateral deal. Agentforce and Copilot Studio are direct rivals aimed at different bases. The bridge between them is open protocols: Agent2Agent hit v1.0 and was donated to the Linux Foundation, giving it the same institutional standing as MCP, and Foundry advertises a Salesforce connector among its many. The plumbing between the two vendors is being built, mostly through the Informatica side of the house rather than under the MuleSoft brand.

My skepticism going in, and it is the same skepticism I want the demos to survive. Provider-agnostic is oversold: the Inference Connector abstracts the model call, but orchestration, grounding, memory, and governance stay proprietary to whichever platform you standardize on, so swapping the LLM is not swapping the platform. Run Agentforce agents and Foundry or Copilot agents in the same estate and you now have two governance planes, duplicate cost and split observability with no single pane of glass. And every hop, agent to MuleSoft to external system to Azure-hosted model and back, is metered somewhere. My lean is unchanged from Foundry and Fabric: the two coexist, and the only thing you actually make portable is the model call at the bottom. What I want on the floor is a demo where Agent Fabric governs a non-Salesforce agent end to end. If that works, the coexistence story gets real. If it is a slide, it stays a thesis.

What I’m still figuring out

Here is the honest admission. Every boundary I just drew is a judgment call, not a rule, and every vendor in that convention center is paid to blur exactly these lines. I will walk the floor with these decision trees in hand, and I still will not have clean thresholds until I run real workloads through them, because the numbers that decide federate-versus-ingest or on-platform-versus-off only show up under load. The open problem underneath all of it is metering: the industry has gotten good at governing agents and is still bad at predicting what they cost, and until that closes, every one of these architectures ships with a financial unknown baked in.

I am also one architect splitting a week across two tracks, which means this is a boundary-drawing exercise, not a buy recommendation. The point of drawing the line before you go is not that the line is final. It is that you notice when someone moves it. So do not buy deeper into any platform until you can draw its boundaries yourself, in your own hand, on your own terms. The vendor will draw them for you otherwise, and they will draw them around their invoice.

---

If this resonated, read Foundry and Fabric, Not Foundry or Fabric, on why the agent control plane ends in coexistence rather than a winner, and Salesforce Without the Full Buy-In, on the opt-out architecture for an Azure-invested enterprise.

Find me on X @orestesgarcia or LinkedIn /in/setsero.