MCP and the New Orchestration Layer for Marketing

A look at how AI agents are learning to work across an entire marketing stack through one shared protocol — how the pieces connect, how several agents coordinate, and what changes once more than one of them is involved.

Disclaimer: the views here are my own and don’t represent my employer’s. This is a generic pattern for reasoning about the problem, not a certification of any specific platform’s current capabilities — verify against live vendor documentation before implementing anything below. The policy syntax in the server-to-server section is illustrative pseudocode, not a tested implementation.

In this post

1. What’s actually connecting
2. A worked example
3. Two kinds of coordination
4. Buying, borrowing, or building the orchestrator
5. What happens once you have more than one agent
6. Authorization gets specific fast
7. Final thoughts
8. Resources

AI agents are changing how marketing teams interact with their own stack — several platforms now brand them as “coworkers” rather than assistants, to signal that you delegate to them rather than prompt them. Ask the right one a question today and it doesn’t just answer — it reaches into your analytics tool, your CMS, your A/B testing engine, and comes back having actually done something, not just described it.

What’s actually connecting

One protocol is rapidly becoming part of that plumbing: the Model Context Protocol (MCP), an open standard for exposing a system’s tools and data to an AI agent in a uniform way. It’s spread fast: by December 2025, the project reported more than 10,000 active servers and upward of 97 million monthly SDK downloads, with first-class client support across most major AI assistants and coding tools. MCP support specifically in marketing and CX tooling — analytics, content, advertising, and experimentation systems among them — is growing quickly too, through a mix of official vendor servers and third-party ones, though that’s a different claim than every major platform having shipped one. That same month, MCP itself moved to neutral governance: its original creator donated it to the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation, with several major cloud and AI providers among the founding and supporting members — the kind of home a shared protocol needs if it’s going to outlast any single vendor’s interest in it.

Before something like this existed, wiring an agent to a system meant reading its API documentation and writing bespoke integration code — once per system, and again whenever that system’s API changed underneath you. MCP flips that around: it standardizes how tools are discovered and invoked, so an MCP-capable client can interact with tools exposed through MCP servers using the same protocol — even though each tool still defines its own schema, arguments, and semantics underneath that shared surface.

Same four tools, two very different amounts of integration code.

The agent doesn’t need to know a CMS’s API looks nothing like an analytics platform’s API — it just asks each MCP server what it can do, and calls it the same way it’d call anything else. That’s the part that makes this feel like delegation rather than just a demo.

Exposing an MCP server doesn’t create orchestration by itself — it creates reachability. A CMS, an analytics platform, and an A/B testing engine can each publish an MCP server and be individually reachable by an agent, and that’s increasingly what’s happening today: a growing number of marketing tools are shipping one, often alongside a built-in AI assistant of their own. Connect an agent to each tool and every tool gets smarter on its own — better search, better suggestions, a chat box bolted onto that one product. That’s real, but it’s still several separate islands of AI, one per tool, not a workflow that spans them.

The shift underway is from AI operating inside individual tools to AI operating across all of them from one place. That’s the actual bet behind the current wave of “coworker”-branded agents — not smarter individual tools, but a single orchestration layer positioned above the whole stack, so a day’s operations happen from one conversational surface instead of five separate logins, each with its own bolted-on AI.

A worked example

The reason this matters specifically for marketing is that the useful work almost never lives inside one system. A realistic chain, inside one conversation with one agent:

1. Ask the analytics platform where the drop-off is for a given segment over the last 30 days. It finds a checkout step losing conversions.
2. Ask the CMS what’s currently on that page.
3. Ask A/B testing to spin up a test with a revised offer for that segment.
4. Ask video for the best-performing explainer clip for that segment, to embed in the variant.

Four systems, four MCP servers, one thread. What’s actually new here isn’t that an agent can answer a question — it’s that it can chain the output of one tool into the input of the next without you doing the stitching by hand.

The same pattern extends beyond analytics and experimentation: a journey agent can identify a stalled segment, personalization can adjust its offer, and search can boost relevant content — or an audience tool can identify churn risk, paid media can retarget it, and email can follow up with non-converters. Different systems and budgets, same underlying pattern: the orchestration layer carries context across tools.

Two kinds of coordination

One layer of detail sits underneath everything above: how an agent actually reaches all those tools in the first place. There are two valid patterns here, not one.

Pattern A is what the first diagram already showed: a single agent holds MCP connections to every tool directly and calls each one itself. It’s the simpler pattern, and plenty of real systems work exactly this way.

Pattern B splits the work: an orchestrator delegates sub-tasks to specialist agents — one good at journey questions, one good at personalization decisions — and each specialist owns a narrower set of tool connections underneath it. Neither pattern is more correct; Pattern B tends to show up once the tool surface gets wide enough that no single agent’s context window or credential footprint should reasonably cover all of it.

When the specialists in Pattern B are independently deployed agents — built by different teams, running on different infrastructure, not just function calls inside one process — Agent2Agent (A2A) is the emerging standard for that hop, while each specialist still reaches its own tools over MCP. A2A’s own documentation is explicit that it isn’t a sub-agent or tool-call protocol: internal coordination inside a single framework can just use that framework’s native primitives instead. A2A earns its place specifically when the agents on both ends are opaque to each other and need to interoperate across a boundary neither one controls.

MCP reaches tools. A2A coordinates the agents reaching them, when those agents are independently deployed. Different hop, different protocol.

Getting this backwards is a common source of confusion. “The agent connects via MCP” is true in Pattern A, but in Pattern B it’s usually the specialist layer doing the connecting — not the orchestrator holding every credential itself.

Buying, borrowing, or building the orchestrator

Once the orchestrator — the thing sitting above individual tools in Pattern B, doing the actual delegating — is the real prize, the practical question becomes who builds it. Three paths, each a real trade-off:

• Vendor orchestrator. Buy the orchestration layer itself, as a platform’s own all-in-one agent. Fastest to stand up, and well-integrated with that vendor’s own tools — but only as good as that vendor’s own coverage, and everything outside its stack becomes a second-class citizen it reaches, if at all, through a bolted-on connector.
• Framework or open-protocol orchestrator. Assemble your own using existing frameworks and open protocols — MCP to reach tools, A2A to coordinate specialists — without adopting any one vendor’s packaged agent. More engineering upfront, but it treats every tool the same way regardless of who built it, and inherits no one’s roadmap but your own.
• Workflow-specific automation. Skip the general-purpose orchestrator altogether and hard-code the handful of workflows that are actually worth it. Maximum control, maximum effort — usually only worth it once you know exactly which workflows deserve that investment.

The likely endpoint is somewhere between the first two: commodity capability gets bought, while organization-specific workflow and policy logic gets built or customized. Deloitte’s 2026 State of AI in the Enterprise report, surveying more than 3,200 business and IT leaders, found 85% of companies expect to customize agents to their particular business needs rather than deploy generic ones unchanged — a narrower claim than “everyone builds hybrid,” but pointing the same direction. In practice that means a vendor’s orchestrator for the tools that vendor owns, glued to a thinner, open orchestrator for everything else.

What happens once you have more than one agent

Everything above works cleanly with one agent, or one orchestrator, and a handful of tools. It stops being clean the moment a second one shows up — which, for a marketing stack spanning multiple vendors, is an increasingly plausible scenario as individual platforms ship agents of their own. Two agents, each independently capable of reaching into the same CMS or the same journey tool, run into the same three problems fast: no shared inventory of which tools are reachable by which agent, duplicated long-lived credentials issued to each one, and no shared audit trail — “what did an agent touch last week” stops having one answer.

The fix is structural: a control plane between the agents and the tools, so every one of them shares it instead of each wiring around it. In practice that’s seven pieces, even when a platform bundles two or three of them under one name:

• Registry — one catalog of which tools exist and what access each needs.
• Gateway — the single point every call passes through.
• Identity provider — proves who, or what, is calling.
• Policy decision point — evaluates your organization’s rules to decide what a proven identity is allowed to do, to what, right now.
• Token broker — mints or exchanges a short-lived, scoped credential for each call, instead of a key an agent holds forever.
• Secrets vault — securely stores the real, long-lived credentials the broker draws on.
• Audit log — a record that finally answers “what did any agent touch.”

Every agent shares one control plane instead of wiring around it. The policy itself is the part that’s genuinely organization-specific.

Much of that is purchasable infrastructure. The one piece that isn’t is the organization’s actual policy — which agents may take which actions, against which data, under which conditions. That’s the part every organization has to write for itself, regardless of which policy engine ends up running it.

Authorization gets specific fast

Two distinctions matter once you’re this deep. First: authentication proves who’s calling; authorization decides what they’re allowed to do. A valid token answers the first question convincingly, and only partially answers the second — it can carry scopes that draw a coarse boundary, but scopes rarely encode the full context an organization actually cares about.

Second: a tool call either happens on behalf of a specific person, or it doesn’t. A scheduled job with no user in the loop generally shouldn’t get the same ceiling as one made on someone’s behalf.

Same first step, same last step. Only how the token gets minted differs.

This is also why the token broker matters more than it might look. MCP’s own authorization spec is explicit on the point: a server must not simply forward an inbound token through to an upstream API unchanged. That kind of passthrough is exactly the confused-deputy pattern the spec calls out by name — the downstream system ends up trusting a token it never actually validated or issued a scope for. A downstream-specific credential — obtained through token exchange or another appropriate flow — is what keeps that audience boundary real.

In practice, a policy decision point doesn’t need to start sophisticated. An initial policy can look more like a short list of rules than a general-purpose rules engine:

allow if:
  agent.id == "marketing-agent"
  tool.name in ["create_experiment", "run_report"]
  user.role in ["marketing_admin", "campaign_lead"]
  resource.data_classification != "restricted"

max_scope := "read_only" if:
  agent.id == "marketing-agent"
  user.id is absent   # no person in the loop

Nothing here is clever, and that’s the point. The rule doesn’t need to anticipate every case — it needs to encode the handful of decisions your organization has already made about which agents can touch sensitive data and which actions need a human in the loop.

There’s a second kind of trust this control plane has to handle, separate from what an agent is allowed to do: whether a given tool is even what it claims to be. MCP’s own specification treats a tool’s self-reported description and annotations as untrusted unless they come from a server you already trust, and requires explicit user consent before any tool actually gets invoked. That makes the registry more than a discovery catalog — it’s also where you’d track which servers are actually approved, which publisher and version you’re trusting, and what a given tool is allowed to claim about itself.

Final thoughts

MCP solved much of the mechanical integration problem: MCP-capable clients can discover and invoke tools through a shared protocol instead of requiring bespoke integration logic for every pairing. That’s what makes an agent chaining a CMS, an analytics platform, and a testing engine into one thread possible at all — and what’s letting a whole category of marketing tools start working together that never had a reason to before.

What’s still being worked out is what happens once more than one agent is doing this across the same stack — coordinator patterns, shared registries, and the policy layer underneath all of it. That’s less a solved problem than a fast-moving one, and worth watching as closely as MCP itself.

Resources

• Model Context Protocol — specification and docs
• MCP joins the Agentic AI Foundation — governance announcement, December 2025
• Agent2Agent (A2A) Protocol — specification
• OAuth 2.1 — the in-progress IETF consolidation of OAuth 2.0 best practices; still a draft, not yet a finalized standard
• Open Policy Agent — for teams building a standalone policy decision point