Every major MarTech vendor now ships “agents” of some flavor. Salesforce has Agentforce. Adobe offers Agent Orchestrator. ServiceNow has AI Agent Fabric. HubSpot has Breeze. Treasure Data has Treasure Code. There are more. Each one promises autonomous AI that takes action on your behalf.

And each one works best inside its own walls.

The pattern we keep seeing at the Real Story Group, in our research as well as while advising enterprise clients, is familiar to anyone who lived through the personalization wars of the 2010s: every platform personalizes at platform/channel-level, while no supplier owns the global picture.

We’ve seen this pattern berfore

Remember channel-specific personalization? Your ESP had its own segmentation. Your Web CMS had its own targeting rules. Your ad platform had its own audience models. They all created and stored their channel-specific content variants. Each one “personalized” within its silo. The result was incoherent customer experiences, competing optimization objectives, and a reporting / attribution nightmare.

Agent AI is heading down the same path.

When every box in your stack runs its own agent, each one operates under its own data model, its own permissions, its own policy logic, and its own logs. The email agent doesn’t know what the website agent just offered. The CRM agent doesn’t know that the CDP agent just suppressed that customer. The ad agent doesn’t know the service agent just resolved a complaint.

You end up with agent sprawl. And sprawl is what happens when you adopt capabilities without choosing an architecture.

Vendor agents: active mostly inside the walls

Vendor agents are AI capabilities in which the control plane lives inside the MarTech vendor’s platform. Note that this is even the case for so-called suite or “cloud” vendors, whose agent platforms, while nominally independent, tend to be scoped to individual platforms.

By “control plane,” I mean the layer that decides what happens next. It holds the planning logic, identity and permissions, policy guardrails, available actions, and the audit trail. If you’ve managed a MarTech stack, think of it as a combination of a workflow engine, governance rules, and a reporting dashboard that determines how a process transpires.

This is a big deal. In an agent context, whoever owns the control plane owns what the agent can do, what it can’t, and what gets logged when it acts.

With platform-embedded agents, all of that sits inside the platform boundary. The agent’s strongest, most reliable behaviors operate on that tool's own objects and workflows. Cross-silo reach may be available, but routed through integration layers.

Let’s review what some vendors are doing.

Salesforce has two pieces here, and the relationship matters. Agentforce is the agent builder: it creates and deploys AI agents that automate tasks inside Sales Cloud, Service Cloud, Marketing Cloud, and the rest of the Salesforce ecosystem. Separately, Mulesoft Agent Fabric is the orchestration and governance layer that’s supposed to extend those agents beyond Salesforce. Its marketing says it will “intelligently orchestrate and govern every AI agent, regardless of where it’s built.”

If your scenario spans external systems along with Salesforce, you’re funding an integration program where MuleSoft becomes the glue. That can work, but it is not a neutral orchestrator.

ServiceNow is somewhat more interoperability-forward. AI Agent Fabric supports both MCP (Model Context Protocol) and Google’s A2A (Agent-to-Agent) protocol. Their product page says you can “connect third-party AI agents and tools to enhance agentic workflow orchestration” and “equip ServiceNow AI Agents with best-of-breed external tools via MCP.” That’s good progress toward openness.

But read the architecture: in a classic martech power move, ServiceNow positions itself as the hub. External agents connect to ServiceNow, not through a neutral layer.

Adobe launched Agent Orchestrator at Summit 2025 with a broad partner ecosystem including Acxiom, AWS, Genesys, IBM, Microsoft, and ServiceNow. But dig into their actual documentation, and you find this: “These agents align with Experience Cloud products.” Their docs describe it as “the agentic layer in Adobe Experience Platform that powers customer experience orchestration with purpose-built agents.” Additional capabilities are coming in 2026, but for now, the core agents are built to orchestrate Adobe tools in general and AEP in particular. The practical question is whether you get true agentic cross-system orchestration, or just an Adobe orchestrator occasionally calling external APIs.

HubSpot offers two MCP options: a client to connect Breeze agents to external systems like Notion, Atlassian, and Asana, and a remote server to “bring your HubSpot context into the environments where you work and build.” So it focuses on HubSpot-native work. But the external connections are limited to a handful of pre-built MCP servers. Cross-stack orchestration still depends on installed apps, permissions, and tool wrappers.

Treasure Data has two AI plays. Agent Foundry is a no-code/low-code platform for building AI agents that “utilize data stored in the TD Plazma database,” their unified customer record. Separately, they launched Treasure Code, an AI-native CLI that lets teams operate the CDP “as code” using natural language. Treasure Code is a DevOps tool for managing data workflows and configurations; Agent Foundry is where you build the agents themselves. At CDP World 2025, they rebranded the whole thing as an “AI Marketing Cloud.” But both tools are scoped to Treasure Data’s data layer. It offers CDP operations with agents, not enterprise-wide orchestration.

These are all decent stabs at intra-platform workflow capabilities but within their domains. The problem shows up when you assume that your vendor’s agent can become your enterprise-wide orchestration layer.

What an independent agentic layer does differently

Independent frameworks like CrewAI and LangChain/LangGraph treat the control plane as yours to define. You own memory, context, policy binding, approval gates, and the run log.

The structural advantages for cross-silo work are real. One orchestrator calls many tools. One context packet travels with the agent across all systems, carrying brand voice, approved sources, budget caps, consent rules, and freshness constraints. One run log spans everything, so when the CMO asks “why did it pick email over paid social?” you can answer from a single trace. And you get portability: swap models, swap tools, keep the orchestration logic.

An independent layer does have disadvantages too. Once you span several systems (say, more than a couple), you have to handle retries, timeouts, rate limits, idempotency, rollback logic, context transfer, auth scoping per system, data freshness mismatches, and end-to-end observability. Nobody gives you that for free.

At RSG, we’ve tested scenarios end-to-end in different tools, mimicking real marketing teams with social intelligence, strategy, content, and scheduling agents. What breaks first is never the framework. It’s the missing context. The agent acts on stale data. It hallucinates a statistic. It ignores a regional policy it was never given. It doesn’t know when to say “I don’t have enough information.”

Frameworks make it easier to build the flow. They don’t automatically make it easy to run the flow reliably.

The real question: where does the control plane live?

Strip away the vendor marketing, and you’re making an architectural choice about five things. In both cases, you’re the one doing the work. The difference is where you do it: inside each platform separately, or once at a cross-platform level.

How to decide

It might be tempting to frame this as “build vs buy” but that’s not exactly right. Instead, start with these questions:

Does the business process span more than two or three systems? If yes, prefer an independent orchestrator. Trying to make your CRM the control plane for seven systems creates engineering debt you’ll surely regret.

Does the scenario require consistent policy, consent rules, and budget caps across systems? If yes, that policy enforcement needs to sit above the individual apps. No single suite’s governance model will extend cleanly to competitors’ products.

Do you need an end-to-end “why” trail? If so, one control plane needs to own the decision trace across all tools. Your CMO doesn’t want to hear “the Salesforce log says X, but we don’t know what the CDP agent did.”

If you said yes to any two of these, independent orchestration should become your default architecture.

The pragmatic pattern

The practical enterprise pattern isn’t either/or but a layered model.

The independent layer handles planning and coordination across systems, enforces policy and consent consistently, owns memory and context with a defined scope, and owns the run log and evidence binding.

Suite agents handle executing native tasks in their domain. Salesforce actions, Adobe content check-ins, ServiceNow ticket routing, Treasure Data segment updates. They provide domain-specific affordances, such as ad platform bid constraints, ESP template rules, and DAM rendition logic.

In this model, suite agents are workers, not orchestrators. They’re good at what they do within their walls. The independent layer above them is what makes the whole stack coherent.

What you should demand from any vendor

Whether you’re evaluating a suite agent or an independent framework, ask for one demonstration that touches five to seven systems and shows:

One shared context packet active across all steps, with version tracking One run log spanning all systems with tool calls, sources, reasons, and costs Policy checks applied consistently end-to-end, not just inside the suite boundary Degraded-mode behavior when one system fails. Does the agent halt, retry, or hallucinate?

If the suite vendor says “use MuleSoft” or “configure an MCP tool” or “integrate external agents,” that’s not automatically a disqualifier. But it confirms the point: cross-silo orchestration is an integration program, not an out-of-the-box agent feature.

What you should do

Suite agents are platform control planes with connectors. That’s a useful and valuable thing. It is not the thing that spans your entire stack – where many high-value orchestration business cases lie.

If your most important marketing scenarios live inside one suite, start there. If they span CRM, CDP, ESP, ads, DAM, and analytics, and they increasingly do, then choose your control plane deliberately. Don’t let the vendor who happened to win your last CRM deal choose it for you.

Local agents optimize locally. Your brand, your budget, and your customer live globally. Put orchestration where you put governance: above the apps.

At RSG, we can help you figure all this out. You can contact us about consulting offerings.