The previous pillar in this series made the case that the marketing infrastructure category is restructuring around three integration architectures, that a new protocol is consolidating underneath them, and that the build-versus-buy math has flipped at the platform layer. The argument was structural. This piece is more specific. It names the platform that makes the build option viable for a mid-market marketing operation in 2026 and explains why that platform sits at the center of the firm’s own delivery work and the procurement conversations the firm now has with marketing leaders weekly.
Google Enterprise Agent Platform is not the only choice for building owned AI infrastructure. It is the choice that handles the most pieces of the platform-layer build, with the strongest position on the protocol that is becoming the new interface to marketing technology, and with the multi-model architecture that hedges against single-provider lock-in. What follows is a CMO-readable explanation of what the platform is, the four layers it spans, where it differs from the major alternatives, how Model Context Protocol changes the procurement conversation, and what the cost model looks like for a typical mid-market marketing operation. The piece sets up the two tutorials that follow this one, which walk through real agent builds on the platform.
What Google Enterprise Agent Platform actually is
The first thing to get clear is what the platform is not. It is not a SaaS marketing tool. It is not a content generation product. It is not a chat interface bolted onto a vendor’s existing CRM. It is a managed cloud platform for building, deploying, and operating AI agents that work across a marketing operation’s existing systems.
The distinction matters because the way a CMO procures Google Enterprise Agent Platform is meaningfully different from the way the same CMO procures Jasper, HubSpot, or Adobe Experience Cloud. There is no per-seat license. There is no annual contract with a fixed bundle of features. There is no fixed product that a vendor ships and the customer consumes. Google Enterprise Agent Platform is more like AWS or any other cloud platform in its purchasing model: pay for the compute, storage, and API calls consumed, build the application that uses them, own the result.
For a marketing operation that has only ever bought SaaS tools, the model is unfamiliar. It is also the only model that allows the build option from the previous pillar to be a real choice. SaaS sells finished features; the platform sells the primitives that finished features are built from. The buyer choosing the platform is buying the right to build a tool that the SaaS market does not yet sell, or that the SaaS market sells at a price that no longer makes sense given the underlying economics.
The marketing operations that benefit from the platform model are the ones that have a specific capability they want to own, the engineering judgment to build it, and the maturity to operate it. The marketing operations that should stay on SaaS are the ones whose needs are well-served by existing products and whose marginal capability gain from owning is not worth the operational overhead. Both kinds of operations exist. The platform is for the first kind.
The four layers of the platform
Google Enterprise Agent Platform spans four functional layers. Each layer is a category of capability that a marketing infrastructure build needs to address, and each layer is where the platform’s offering compares against alternatives in different ways.
The model layer. At the bottom is the access to frontier and open-source AI models. Google’s own Gemini family (Pro for analytical and creative work, Flash for high-volume and cost-sensitive work) sits as the default. Through Google’s partnership with Anthropic, Claude is available on the same platform alongside Gemini. Open-source models, including the Llama family and various specialized models, are available through Model Garden, the platform’s model catalog. The implication of this multi-model access at the platform level is that the marketing operation building on Google Enterprise Agent Platform is not locked into a single model provider. The same agent can route a structural reasoning task to Claude Opus and a high-volume content task to Gemini Flash, captured under the same billing relationship and the same observability tooling.
The agent layer. Above the model layer sits the part of the platform that handles the actual construction and execution of AI agents. This is where the platform’s name comes from, and where most of the daily build work for a marketing operation lives. The agent layer covers agent definition (the structured description of an agent’s purpose, capabilities, and authority), agent orchestration (how multiple agents pass work to each other), tool integration (how agents call external systems, including through Model Context Protocol), and agent runtime (where the agents actually execute under load). The visual builder, Studio, sits in this layer and lets non-engineering staff configure agents without writing code. The programmatic interface, available through the platform’s SDK, lets engineering staff build the same agents in code for cases where the visual builder is not the right surface. Both approaches produce the same underlying agent definitions, which means a marketing engineer can start in Studio and graduate to code without rebuilding from scratch.
The orchestration layer. Above the agent layer sits the workflow infrastructure that ties agents into the rest of the marketing operation. Cloud Workflows defines multi-step processes that include agent calls alongside other operations. Cloud Tasks manages long-running, asynchronous work. Pub/Sub handles the messaging between agents and external systems. For a marketing operation, this layer is what allows an agent to be invoked as part of a larger workflow rather than standing alone as a chat interface. The editorial audit agent that the third pillar in this series will demonstrate, for example, is invoked by a workflow that pulls posts from WordPress on a schedule, passes each post through the agent, and writes the results back as structured data. The agent itself does the analysis; the orchestration layer makes that analysis a continuous operation rather than a one-shot interaction.
The data and observability layer. Sitting alongside and underneath the other three layers is the infrastructure that handles data storage, retrieval, and the operational telemetry that makes a production agent stack observable. Cloud Storage and BigQuery handle the structured data the agents read from and write to. Vertex AI Search handles retrieval-augmented generation, where the agents need to ground responses in a corpus of documents. Cloud Logging captures every agent invocation, every tool call, every model response, and every error condition. For a marketing operation building production agents, this layer is what separates a real system from a demo. An agent that runs in production needs to be monitored, debugged, and audited. The platform’s data and observability primitives are built for this from the start, rather than being bolted on after the agent has been built.
These four layers operate together. A marketing operation using the platform is buying compute and access at each layer, building the application logic on top, and owning the result. The platform’s job is to make the layers work together cleanly without the operation having to integrate them itself. The operation’s job is to decide what the agents should do and how they should fit into the marketing workflow.
Why Google Enterprise Agent Platform over the alternatives
The platform is not the only place to build AI agents in 2026. Three alternatives deserve direct comparison, because the procurement decision against each one looks different.
AWS Bedrock. Amazon’s managed AI service has the largest installed base among the major cloud platforms because AWS is the largest cloud platform. Bedrock provides access to multiple frontier models, including Anthropic’s Claude family and Amazon’s own Titan models, with a programmatic interface for agent construction. Where Bedrock is meaningfully different from Google Enterprise Agent Platform is in its agent abstractions. Bedrock’s agent capabilities have been catching up to Google’s over the last eighteen months, but the platform’s design started from model access and added agent capabilities on top. Google’s platform started from agent design and exposed model access through it. For a marketing operation primarily interested in agents that operate across multiple systems with Model Context Protocol as the interface, Google’s design tends to land cleaner. For an operation already deeply on AWS, Bedrock is the lower-friction choice. Both are reasonable. The decision often comes down to which cloud platform the marketing organization’s broader engineering team already operates on.
Azure AI Foundry. Microsoft’s platform sits in a different position because of Microsoft’s deep integration with Office 365 and the Microsoft Graph. For marketing operations that run heavily on Microsoft infrastructure, where the agents need to read Outlook, write SharePoint, and operate inside the Microsoft tenant, Azure AI Foundry has structural advantages that the others lack. Where it sits less cleanly is in the Model Context Protocol story. Microsoft has been adopting MCP, but the protocol’s center of gravity has been with Anthropic and Google. For marketing operations whose center of gravity is the website, the CMS, and the marketing platform layer rather than the Microsoft tenant, Azure tends to be the second-best choice. For operations deeply in Microsoft, it is often the right one.
Direct API access to OpenAI, Anthropic, or Google. The simplest alternative to a managed platform is to skip the platform entirely and call the model providers’ APIs directly. This works for small experiments and for cases where the agent’s behavior is simple enough that the marketing operation does not need any of the platform-layer capability. Where it stops working is where production marketing operations actually live: when there are multiple agents that need to coordinate, when there is data that needs to be retrieved with grounding, when there is observability and audit logging that needs to be in place, when there are governance and permission boundaries that need to be enforced. Building those capabilities on top of a raw API call is possible. It is also expensive in engineering time and operationally fragile. The platform exists because the engineering time required to build production infrastructure for direct API access exceeds the platform’s cost for almost every operation that has gotten past the prototype stage.
There is a fourth alternative worth naming for completeness: ChatGPT Enterprise, Claude Enterprise, or similar enterprise SaaS chat products. These solve a different problem. They give employees access to a frontier model with appropriate security and admin controls. They do not give the marketing operation an infrastructure on which to build agents that operate across the operation’s systems. A marketing operation can use ChatGPT Enterprise and Google Enterprise Agent Platform together. They sit at different layers of the stack. Confusing them is a common procurement mistake.
Model Context Protocol as the protocol layer
The first pillar in this series argued that Model Context Protocol is becoming the new universal interface to marketing technology. The argument extends naturally to the procurement conversation around Google Enterprise Agent Platform, because the platform’s relationship to the protocol is what makes it a meaningfully different bet from the alternatives.
Anthropic published Model Context Protocol in November 2024. Google’s adoption of the protocol across its agent infrastructure has been consistent and substantial through 2025 and 2026. The platform’s agent layer is designed to expose tools and consume tools through Model Context Protocol natively. The implication for a marketing operation is that an agent built on the platform inherits, by default, the ability to operate any external system that exposes a Model Context Protocol surface, and to be operated by any external client that speaks the protocol. WordPress.com’s Claude Connector, the WordPress Core Model Context Protocol Adapter shipped in February 2026, and the broader ecosystem of MCP-enabled marketing tools all become addressable surfaces for an agent built on Google Enterprise Agent Platform without requiring custom integration work for each one.
This matters at the procurement level because the protocol consolidation reduces a class of integration cost that has historically been the largest hidden cost in marketing infrastructure projects. A traditional integration between a CRM and a marketing automation platform requires per-pair engineering work. A new integration requires more engineering work. The total integration cost scales with the number of tools in the stack. Model Context Protocol changes that scaling. A tool that exposes a Model Context Protocol surface becomes integratable with any agent that speaks the protocol, without per-pair engineering work. The marginal cost of adding a new tool to an agent-driven workflow approaches zero once the agent infrastructure and the tool both speak the protocol.
For Google Enterprise Agent Platform specifically, the advantage is that the platform was designed against the protocol rather than retrofitted to it. Agent definitions on the platform treat tool calls through Model Context Protocol as the primary integration pattern, with custom integrations as the exception rather than the rule. The procurement implication is that the platform’s tool ecosystem expands automatically as the broader Model Context Protocol ecosystem expands. The platform’s value proposition compounds with the ecosystem’s growth in a way that direct API approaches do not.
The cost model for a CMO
Procuring a managed cloud platform requires a different cost-modeling discipline than procuring SaaS. The SaaS model is largely predictable: an annual contract with seat counts and feature bundles, modulated by renewal increases. The platform model is consumption-based: the marketing operation pays for what the agents actually use, on a monthly basis, with usage that varies with the work the agents are doing.
Three components dominate the cost of running agents on Google Enterprise Agent Platform.
The first is model inference. Each call to a model from an agent consumes tokens, which are billed at per-million-token rates that vary by model. As of mid-2026, Gemini Flash sits at the low end of frontier model pricing, well below ten dollars per million input tokens and similar on output. Gemini Pro sits in the middle. Claude Opus, available through the platform via the partnership with Anthropic, sits at the high end for the most complex reasoning work. A typical mid-market marketing operation running a few agents will spend in the low hundreds to low thousands of dollars per month on model inference, depending on usage. The number scales linearly with the volume of work the agents do.
The second is compute and orchestration. The platform charges for the compute used to run agents, for the storage of agent state and outputs, and for the orchestration infrastructure that ties agents into workflows. These costs are typically smaller than the model inference costs at the marketing operation’s scale. A typical agent stack running production workloads can run on a few hundred dollars per month of compute and orchestration. The number scales with the complexity of the agent architecture and the volume of work, but it scales more slowly than the inference costs.
The third is data and observability. Storage of training data, prompt history, agent outputs, and audit logs adds up over time. For a marketing operation running agents across the platform-layer surfaces, expect storage and observability costs to settle in the low hundreds of dollars per month at maturity, with one-time costs higher when building out the initial data stores.
The total run cost for a serious agent stack at a mid-market marketing operation tends to settle between five hundred and three thousand dollars per month, depending on the volume of work the agents do and the complexity of the architecture. That number is for the platform’s running costs. It does not include the engineering time required to build and maintain the agents themselves, which is a separate budget item.
Comparing this number to the SaaS alternative is the part of the procurement conversation most CMOs have not yet practiced. A typical mid-market marketing operation pays fifteen thousand to fifty thousand dollars per year for an AI content tool subscription, with renewal increases that compound at fifteen to twenty-five percent annually. A platform-based equivalent that does the same work, built once at a one-time engineering cost in the same order of magnitude, runs at the platform’s monthly rate without the SaaS markup. The math from the first pillar applies directly. The break-even point is roughly one year. The savings compound from year two onward.
The procurement framing is not “is the platform cheaper today than the SaaS alternative.” Often the platform is approximately the same cost in year one, when the build investment is amortized. The procurement framing is “is the platform’s cost trajectory better than the SaaS alternative’s over three years.” It almost always is, by a substantial margin, for capability that the operation actually uses.
What the platform solves, and what it does not
An honest reading of Google Enterprise Agent Platform separates the problems it solves from the problems it does not, because conflating them is the most common procurement mistake.
The platform solves the infrastructure problem. The marketing operation building agents on the platform does not need to build its own agent runtime, its own orchestration layer, its own observability tooling, or its own model access infrastructure. These are real engineering problems that take serious teams quarters to build well. The platform handles them.
The platform solves the multi-model problem. Frontier model selection is a moving target. The model that is best for a given task in mid-2026 will likely be a different model by late 2027. The platform’s multi-model architecture means the marketing operation can change models without rebuilding the agent. The agent definitions are model-agnostic at the platform layer.
The platform solves the protocol problem. Model Context Protocol is becoming the standard interface to marketing tools. The platform speaks the protocol natively. The marketing operation building on the platform inherits the protocol’s ecosystem.
The platform solves the governance and audit problem. Every operation an agent performs, every tool call, every model invocation, is logged with full context. Compliance reviews, security audits, and incident response all become tractable in a way that direct API approaches make difficult.
What the platform does not solve is more important to understand than what it solves, because the gaps are where the marketing operation’s own work matters most.
The platform does not decide what to build. A marketing operation can subscribe to Google Enterprise Agent Platform, provision a project, and never produce a working agent because no one has done the strategic work of deciding what the agent should do. The platform is infrastructure. The strategic work of identifying which workflows are agent candidates, which agents are worth the investment, and how those agents fit into the marketing operation’s broader work remains entirely with the operation. This is the work that the firm’s Strategic Briefing engagements address; it is the work that the platform does not.
The platform does not write good prompts. Agent quality depends on prompt quality, and prompt quality is a craft that takes practice to develop. The platform makes it easier to deploy agents, but it does not make the agents themselves good. An agent with a poorly designed prompt will produce poorly designed output, no matter how well the platform handles the orchestration around it.
The platform does not encode brand voice. The single hardest part of the editorial audit agent that the third pillar will demonstrate is the brand voice rubric: the structured definition of what good brand-aligned content looks like for a specific operation. That rubric is unique to each marketing operation. The platform provides the infrastructure to apply the rubric at scale, but writing the rubric well is a senior editorial discipline that AI does not replace.
The platform does not replace organizational change. The build-versus-buy shift discussed in the first pillar has organizational implications: the marketing engineer role, role consolidation, the redefinition of the agency relationship. Adopting the platform without addressing those implications leaves the operation with infrastructure that no one is properly responsible for. The platform is the technology piece of a larger organizational shift, not a substitute for it.
A procurement framework for marketing leaders
For a CMO evaluating whether Google Enterprise Agent Platform belongs in the marketing operation’s 2027 plan, a working framework has five parts.
First, identify the workflows where AI agents would deliver more value than SaaS-based content generation. The platform is not the answer when the marketing operation needs a content generation tool for occasional copy assistance; a SaaS subscription serves that need adequately. The platform becomes the right answer when the operation has identified a continuous workflow that benefits from agentic operation: editorial audit, performance monitoring, customer support triage, content personalization at scale, dynamic asset generation. The first question is whether such a workflow exists in the operation.
Second, evaluate the engineering capacity to build and maintain the agents. The platform reduces but does not eliminate the engineering investment required. A marketing operation with no engineering capacity and no plans to add it should not adopt the platform. A marketing operation with at least one senior engineer or marketing engineer, or willingness to engage a partner firm that brings that capacity, can adopt the platform productively.
Third, model the three-year cost trajectory against the SaaS alternative. The annual SaaS cost compounds; the platform’s monthly cost is more stable. By year three, the gap is usually substantial. The procurement decision is a three-year decision, not a year-one decision. CMOs that model only the first year tend to underestimate the platform’s value.
Fourth, assess the Model Context Protocol readiness of the rest of the marketing stack. The platform’s value compounds with the protocol ecosystem. Marketing operations whose other tools already speak the protocol or have credible roadmaps to do so capture more of the platform’s value than operations whose other tools do not.
Fifth, plan for the organizational implications. The marketing engineer role, the operational responsibility for the agent stack, the change in the agency relationship: these are not optional companions to platform adoption. They are part of it. CMOs who adopt the platform without planning for these implications end up with stranded infrastructure.
What comes next in this series
The two pillars that follow this one move from the strategic question to the operational one. The next piece walks through the actual construction of a publishing agent on Google Enterprise Agent Platform: the agent that takes a brief, drafts a post, and stages it in WordPress for human review. It is a build tutorial with real screenshots, real agent definitions, and the architectural decisions the firm has made in shipping this pattern for client engagements. The piece after that walks through a more complex build: the editorial audit agent that reads existing content, scores it against a brand voice rubric, and produces structured revision suggestions. Together, the three pieces are intended to be the foundation of a marketing operation’s evaluation of whether and how to bring Google Enterprise Agent Platform into the stack.
For marketing leaders who have read this piece and want to begin the strategic conversation about whether the platform belongs in the operation’s plan, the firm’s Strategic Briefing engagement is the right starting point. The Briefing produces a written deliverable that maps the operation’s current stack against the architectures from the first pillar, identifies the workflows where the platform would deliver leverage, and recommends a sequence for the build. It is the appropriate engagement for marketing leaders who want to commit to a direction before committing to a build.
The platform is the place to start
Google Enterprise Agent Platform is not the only path to building owned AI infrastructure for marketing operations. It is the path that handles the most pieces of the platform-layer problem with the least friction, while inheriting the most defensible position on the protocol that is becoming the new interface to marketing technology. For marketing leaders who have read the first pillar in this series and accepted the case for the build-versus-buy flip at the platform layer, the platform is the natural place to start the operational conversation.