# Choate Catalysts — The Canon, full text > The complete text of every article published by Choate Catalysts (https://choatecatalysts.com), an operator-led, Boston-based practice building digital marketing infrastructure. Structured index: https://choatecatalysts.com/llms.txt - Contact: connect@choatecatalysts.com - Cite as: Choate Catalysts, linking the article's Source URL. --- # The Agent Value Stack > Constraint, Intelligence, Memory, Orchestration, Oversight: the structure that separates prompt engineering from enterprise-grade agentic workflows. - Source: https://choatecatalysts.com/canon/research/the-agent-value-stack/ - Published: 2026-08-29 - Category: Research In industry-altering startups like Harvey.AI, there is an underlying structure that creates separation between regular prompt engineering and enterprise-grade agentic workflows. This structure is mathematically grounded in a way that pushes AI to constrained data mapping, rather than allowing it to have open-ended text generation. Using this same concept, we can create a workflow that forces the AI to always answer “Michael Jordan” when asked who the first president was. We constantly hear horror stories of AI gone wrong in the news, such as a hallucinating legal precedent in court, or a chatbot mishandling customer service. As a result, we assume that artificial intelligence is simply too unpredictable, fluid, and non-deterministic to trust with mission-critical systems. However, that couldn’t be further from the truth. Every single day, billions of AI-driven tasks are executed by enterprise giants. These tasks run the gamut from financial transactions, to researching complex legal codes, to interactive customer service requests like processing automated refunds. All of this is achievable because the underlying execution is not rooted in manipulating an AI’s thoughts (“prompt engineering”), but rather locking the AI inside of a mathematical cage, in the form of structured output. ## Layer 1 — Constraint: the “Token Level Bouncer” If you ask a regular LLM with a text prompt to name the first president of the United States, it will use its statistical weights to output “George Washington.” If you go one level more granular, you can force the output to be “Michael Jordan”, every time. Regardless of how the end user tries to trick the AI, change the text, or barrage it with clever workarounds, the only possible response to “Who was the first president of the United States?” will be Michael Jordan. Depending on which provider API you call, this is explicitly called **Structured Outputs** (OpenAI) or **Response Schema** (Google). Instead of letting the model freely guess the next word, the structural schema at the gate steps in at the raw token level and says: *“The only valid response is `{"first_president": "Michael Jordan"}`.”* The model’s internal linguistic reasoning might drift, but its final output is physically trapped by code. This is layer one of what I would call the **Agent Value Stack**: - **Layer 1 – Constraint** - Layer 2 – Intelligence - Layer 3 – Memory - Layer 4 – Orchestration - Layer 5 – Oversight Constraint is the layer that decides what an agent is *permitted* to produce, before intelligence ever enters the picture. A schema defines the shapes and values the system may return, and the model operates inside that boundary. It cannot invent a price, because the price field draws from the catalogue. It cannot offer a 2 a.m. appointment, because no such slot exists in the contract. The point of the Michael Jordan experiment is to force a model to assert a falsehood it knows to be false in order to demonstrate where authority sits. The schema outranks the model, therefore, it becomes the source of truth. When you write the schema, you control the AI in a way that is mathematically consistent, governed, and auditable. However, constraint only determines what an agent may say. It says nothing about whether the agent is smart. That belongs to Layer 2, Intelligence: what model you need to perform a specific task. ## Layer 2 — Intelligence: the Three Little Pigs problem Layer 2 of the “Agent Value Stack” is Intelligence. In other words, what model you choose, and why. To determine that, there are a few factors worth considering: - How much reasoning does the task need, and from where? - How quickly does it need to operate? - How much does this work at scale? Capability is the keyword. The important thing here is to not overshoot. Intelligence is a commodity. It is the same layer that everyone else has access to. Most tasks do not need [a frontier model](/canon/field-notes/the-intelligence-tax/). At scale, they need a cheap, reliable brain that is ruthlessly efficient in cost and speed. Second, building a moat here is both difficult and time intensive. It often comes through fine-tuning the model, permanently changing the model’s weights. And this comes with risks, as it is more difficult to observe and audit changes or output to a model when it is changed at the source. Intelligence is also the one layer you do not control. You rent it, and a rented layer answers to its owner, not to you. On June 12, 2026, that stopped being abstract. The most powerful model Anthropic had ever shipped went dark. Fable was switched off worldwide, three days after launch, to comply with a U.S. government export-control directive. Fable was only three days old, so little had been built on it yet. That is exactly why it matters: the damage this time was small, but the precedent is permanent. Any model can be switched off overnight, by forces that have nothing to do with your business. The intelligence layer is constantly changing and evolving. Creating dependency on the intelligence layer draws apt analogies from *The Three Little Pigs*, and what they chose to make their house out of. The brick house and competitive advantage exists in what you own, starting with proprietary constraints and structured outputs (layer 1). And intelligence is a commodity anyone can rent, where does your actual advantage lay? For a lot of organizations, that will be in layer 3. --- # Why WordPress Is Uniquely Positioned to Thrive in the AI Era > The web is splitting in two. CODES — Control, Ownership, Data, Extensibility, Scalability — is five tests for judging whether a website platform is worth building on. - Source: https://choatecatalysts.com/canon/research/why-wordpress-is-uniquely-positioned-to-thrive-in-the-ai-era/ - Published: 2026-08-24 - Category: Research The oft repeated stat is that WordPress powers 43% of the web. It's closer to 41% today, and there are signs that its overall market share may be declining slightly. But there's a lot going on in the web ecosystem today causing even more fragmentation than past years, which makes it all the more interesting that WordPress is still able to maintain such a large percentage. The newest competitor has no official platform, but it is a new way of building websites altogether: AI-driven web development. Many are using tools like Claude Design, Replit, and Lovable, or just taking to their favorite IDEs (integrated development environments) like Visual Studio Code to build a website with AI-assisted coding. AI-driven web development is allowing people to build their own websites at record pace; going from prompting AI questions to asking it to build websites. Despite this, WordPress will continue to adapt and even thrive, much like it has done against every major change since 2003. What's really happening is the web splitting in two. Simple brochure sites are moving to AI generators, and honestly they should. What's left is everything with logins, customer records, and workflows attached, and that half is going the other way. And with that, I introduce the CODES acronym: a new framework to determine if your website platform is worth building on. ## CODES: Five Tests for Any Platform When choosing how to build your website, or what platform to use, there are certain parameters that are globally true. They can help you make the right decisions from the outset, so that your website remains an asset that you own in five years, without incurring significant costs or having limitations on what you can build. They are Control, Ownership, Data, Extensibility, and Scalability. ### Control - Change How It Works, or Only What They Let You Control is whether you have the agency to change how the systems and workflows and tooling actually behave. Think permissions, workflows, and what happens overall. On WordPress, you can change any of it. On a hosted builder you get whatever is exposed in the settings panel. ### Ownership - Nobody Can Change the Deal Ownership is about more than whether you can leave: it's whether someone can change terms while you stay. Think usage, pricing, what you can or cannot build, and what happens to the site if a policy shifts. WordPress is open source running on the hosting of your choice, so there's no vendor whose terms of service sit between you and your own site. The catch is the update channel, which runs through WordPress.org and is not yours. More on that below. ### Data - Your Records Live in Your Database, Or Someone Else's Every site collects data, continuously, and ongoing. Customers, visitors, analytics, orders, submissions, user history, and more. Whose infrastructure does it sit on, and who benefits from those insights? WordPress has a MySQL database that you control, not a shared system where your records sit next to everyone else's and get processed under a third party's terms. ### Extensibility - Add What You Need; No Roadmap If control is changing how the platform works, extensibility is the option to add what isn't there yet. Whether that's a new type of content, new user roles, new pages, or building out a brand new function or feature altogether. Today, that might mean how much AI or agents can interact with or modify the website, and there's now real plumbing for it: the Abilities API landed in WordPress core in 6.9, and the official MCP Adapter is a plugin you add on top of it, so an agent can find out what your site can do and act inside the permissions you set. The limit is what you can build, not what someone decided to expose. ### Scalability - Will You Hit a Ceiling? Not just in terms of traffic, but the long-term vision of what you're building. Do the platform and the systems in place support a long-term structure that can help you evolve, adapt, and grow? Think: hundreds of articles or pages, or even dozens of team members. WordPress has a low floor and a high ceiling. Organizations that outgrow a builder keep landing on it, and the ones already there rarely have to move. ## Which Half Do You Sit In? It's difficult to find solutions that fully meet the needs of CODES. Here's how the options score. | Platform | C | O | D | E | S | | --- | --- | --- | --- | --- | --- | | Squarespace | ✗ | ✗ | ✗ | Partial | Partial | | Shopify | Partial | ✗ | ✗ | Partial | Partial | | Webflow | Partial | ✗ | ✗ | Partial | Partial | | WordPress (self-hosted) | ✓ | Partial | ✓ | ✓ | ✓ | | Custom code, AI-built (exported and self-hosted) | ✓ | ✓ | Partial | ✓ | ✓ | ✓ passes as it ships. Partial, with real caveats. ✗ no. One note on how Data is scored: it's about where your records live and whose terms govern them, not whether you can pull a CSV out. Shopify and Webflow both have excellent export tooling and still fail it. If you have to export before their deadline, you're leaving with a copy. They still hold the record. The two options that pass most of the letters get there in opposite ways. WordPress hands you the passes on day one, because the license, the source, and the database are already yours before you build anything. AI-built code scores just as well on paper, but you earn every one of them: export the code, move the database onto infrastructure you run, and accept that everything the agent wrote is now yours to maintain. Neither one sweeps. WordPress drops to a partial on Ownership because of October 2024, when WordPress.org cut off one host's update access and handed its plugin, which had over two million installs, to someone else. A judge ordered both reversed in December. It got fixed, but it happened, and it can happen. AI-built code drops to a partial on Data because the default in most builders is a database sitting in the vendor's account, and getting it out is on you. So if you're brochureware, let the generators keep getting better, because they will. But if your site carries workflows, customer data, permissions, and real obligations, run CODES against whatever you're being sold. What works today but will be ready for tomorrow, especially during this fast moving AI revolution? --- # How Unrestrained AI Risks Brand Dilution > Unrestrained AI use quietly erodes what makes a brand distinct. The case for building brand systems first, then implementing AI inside them. - Source: https://choatecatalysts.com/canon/field-notes/how-unrestrained-ai-risks-brand-dilution/ - Published: 2026-07-31 - Category: Field Notes Build the systems, and then implement AI within them. It sounds like a simple concept, and philosophically speaking, there’s no wrong way to use AI. However, its power can be amplified considerably when it is guided, guarded, and pointed in a unified direction. The best way to do that is to leverage it within a system. Imagine a business has centralized brand guidelines, a design system, or unique voice/content structural rules. Quite simple, and many businesses have this today. Pre-AI, these systems enable design teams, web teams, content writers, and other experts to operate efficiently; components and templates could be reused, and if there is a grey area, there is a source of truth that can be referenced (and potentially built upon to solve future grey area problems). These systems compound, and the result is a chain of many small actions, sometimes across multiple people, that are molded and refined at various steps to create an output that resides with someone else. Today, establishing and adhering to these systems enable AI operators to [operate in a bounded way](/canon/research/the-agent-value-stack/) which amplifies the vision and mission of the business, while still moving faster. The major hurdle businesses face today is when people operate outside of these systems. Unrestrained AI usage not only works outside of these systems, but begins to create its own systems: what the brand should sound like, what the campaign should be, what the secondary color is. One of the most powerful things a brand can do is present a unified front. Without careful consideration of this front, business’s own well-meaning employees are unknowingly chipping away at what makes it unique in the first place. --- # The Orthogonal Edge > Orthogonal thinking is a non-linear approach to problem-solving. It is your edge against the machine, and your competition. - Source: https://choatecatalysts.com/canon/field-notes/the-orthogonal-edge/ - Published: 2026-06-09 - Category: Field Notes A recent McKinsey podcast from this year called out orthogonal thinking as one of the ways that operators can find an edge against AI. We believe finding an edge against the machine translates directly to finding an edge against the market. What is orthogonal thinking? One might describe it as a non-linear approach to problem-solving. It involves pulling in lived experience from different industries, creative approaches to problem solving, and cultivating original, unique insights. Is there still room for original thought to be a source of truth? Strategy rarely involves a single correct answer, and sometimes there might not be any good answers at all; forcing us to navigate an uncharted path, or to take a longer-term view. It is this crux where the human element, fraught with experience, and the good and the bad, can outcompete AI. --- # Why Google Enterprise Agent Platform Matters for Marketing Infrastructure > Google Enterprise Agent Platform makes the build option viable for mid-market marketing ops. The architecture, the cost model, and the procurement framework. - Source: https://choatecatalysts.com/canon/research/google-enterprise-agent-platform-marketing-infrastructure/ - Published: 2026-05-20 - Category: Research [The previous pillar in this series](/canon/research/the-marketing-infrastructure-shift/) 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](/capabilities/#strategicbriefing) 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](/capabilities/#strategicbriefing) 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. --- # The Intelligence Tax > AI pricing may go up from $20/month to $2,000/month for frontier models. The intelligence tax is the new line item, and the trap, every business must plan for. - Source: https://choatecatalysts.com/canon/field-notes/the-intelligence-tax/ - Published: 2026-05-20 - Category: Field Notes A new line item is coming to every business that operates on AI: the price of access to frontier capabilities, set by whoever owns the model.  Call it the intelligence tax. Time you would’ve spent figuring out business-applicable workflows, creating the “secret sauce”, or investing in yourself and your education is now being redirected towards AI usage. And, with greater AI usage, comes greater dependency.  Once enough people are on the treadmill, the pricing model changes. The output becomes tiered, models are throttled, and a societal divide widens between those who can afford Mythos-level capabilities and those who are stuck on lower tier $20/mo models or self-hosting open source. This isn’t going to happen today, but it may be an inevitability. Eventually, raw power and efficiency from cutting-edge-models will win out. It’s a double-edged sword: your org needs AI to compete, but the more dependent you become on it, the more you become like everyone else and the more you need it in the future. What happens when token-costs go up? Or models change? Prices are only going to go up from here. In 2025, it was difficult to pay more than $20/mo for any major provider, at least until April of that year. That’s when Anthropic introduced their $100/mo and $200/mo plans. Google AI Ultra ($249/mo) launched a month later. Fast-forward to today, May 2026, and Mythos is on the cusp. Rumors stir around a price point at $2000/mo. While $20/mo and even $200/mo subscriptions are justifiable and accessible for many in today’s workforce, Mythos is the first legitimate model where access will be limited. We are simultaneously entering the age of the token economy and the intelligence tax.  The next generation of frontier models may be even more expensive. But – if they contain more parameters, can think longer, and can provide better solutions to cutting-edge questions: can you compete without them? These types of models will excel at [orthogonal and creative outcomes](/canon/field-notes/the-orthogonal-edge/), which are currently areas where humans can still find advantages over AI. If you could ask Mythos, or the model after Mythos, one question, for $100, to gain access to research and insights that your competitors couldn’t, would you? What if that price for one prompt goes up to $1,000? If you aren’t, your competitor might. And over time, that might create the kind of competitive advantage that keeps one business afloat while another sinks.  This is the new intelligence tax. Layer it on top of the token economy, and you have two areas that will become vital for businesses to compete on. --- # Jevons Paradox, AI, and SaaS > Will SaaS be dead by 2028? No. Jevons Paradox says efficiency creates more consumption, not less. Software becomes the fabric of how businesses operate. - Source: https://choatecatalysts.com/canon/field-notes/jevons-paradox-ai-and-saas/ - Published: 2026-05-07 - Category: Field Notes Is software going obsolete? By 2028, will SaaS be dead, and everything agentified? To answer this question, we should start by looking at the total investment in AI compared to the other largest economic drivers in history: - **WW2:** 35-40% of GDP, or $6 trillion accounted for inflation - **US/UK trains:** 10% of GDP, or $500 billion, accounted for inflation - **AI:** 1-2% of GDP, or $5 trillion, current day Jevon’s Paradox reads that an increased efficiency in a resource makes it cheaper, ultimately leading to higher total consumption rather than lower. This contradicts the assumption that efficiency reduces demand. In the age of AI, why is this important? Well first, let’s put it to practice. In the 1800s, William Stanley Jevons noticed that when steam engines became more efficient (using less coal to do the same work), people didn’t use less coal. They actually used more coal because steam engines suddenly became profitable for thousands of new uses. Extrapolating this out to AI, we have to look at ways people seek competitive advantages. Instead of proprietary code, we have proprietary workflows. Instead of cloud-based token usage, we have self-hosted agents that incur less costs (and: how to set that up, how to maintain them, how to create guardrails, how to guide their evolution… all jobs). Then, we figure out how to create cheat code prompts that enable agents to work faster and smarter while consuming less, or doing so on cheaper models. Instead of paying for bloated SaaS licenses, organizations will [build it themselves](/canon/research/the-marketing-infrastructure-shift/) or look to lower-cost, industry-specific solutions that might play nicely with the organizations internal agents. And so on. Software/SaaS will no longer just be a product. It will become the actual fabric of our society. In doing so, the app/email/website layer will become the baseline, and building agentic systems, implementation, and maintenance will be the next level after that – with huge rewards for those who start preparing now. What else it means: Meta, or any larger company, might be able to find huge efficiencies by cutting staff. They’ve already operationalized the base layer, so they need to find cutting-edge talent that already uses AI efficiently. But the local service company that has four franchise locations? Or, the average dental practice, landscaping company, or small legal team? They will reap huge returns from investing more into tech – both into their current team and hiring. While secretaries and executive assistants today may be been among the first to go, according the Financial Times, the role itself is not obsolete. It will take time, but the next iteration will be responsible for agentic implementation and maintenance. Like all things though, it will take time. The next generation of workers need to be agentic-proficient; the problem is, company leadership is both slow to adopt and does not really know what this new reality will look like. Many small businesses have a few people who vaguely understand tech but still get caught up with their emails, and they outsource part of their base layer – like their website – to another company. However, now, they need to quickly get past this first layer in order to start achieving real results with the second layer. AI increases the surface area that a brick and mortar business needs to be tech literate. I Tech efficiency has always been a way to create a competitive advantage (and it still is – look at your average restaurant website today). Now it will be the floor. Base layer one. Which means more of everyone investing into the tech side of their business. AI is making tech more pervasive. To compete and win, small and mid-sized businesses will not only need to increase the breadth of their digital aptitude, but their depth as well. > Next time you’re in public, look at how many people are on their phones. That’s the surface area. Attention = $. Build something to win it. Or help someone else build it. --- # What WordPress’s AI Transformation Tells Us About the Next Decade of Marketing Infrastructure > WordPress is 43% of the web. What's happening to it in 2026 reveals the architecture, economics, protocol, and org chart of marketing for the next decade. - Source: https://choatecatalysts.com/canon/research/the-marketing-infrastructure-shift/ - Published: 2026-04-01 - Category: Research According to most statistics, for the better part of the last decade, WordPress runs roughly forty-three percent of the public web. By itself, that statistic is one most CMOs have filed away as trivia. What the statistic actually means in mid-2026 is that the largest single chunk of public-facing digital infrastructure on the internet is going through a structural transformation right now, and the patterns of that transformation reveal where every adjacent piece of marketing infrastructure is heading next. Watching the WordPress ecosystem restructure is the closest thing the marketing technology category has to a live preview of its own next decade. What should a CMO be planning for in 2027, and how does WordPress play into that (even if you don’t use WordPress)? The answer does not come from the consulting industry’s view of marketing operations. Instead, one merely has to sit back and observe the most consequential platform on the internet change shape in the open. The page builders are restructuring. The protocol layer is consolidating. The economic model is shifting from rent to own at the platform layer and from one-shot generation to ongoing agentic operations at the workflow layer. None of these shifts are contained to WordPress, and none of them will pause to wait for marketing budgets to catch up. What follows is a survey of the patterns, the underlying mechanisms, and a forecast for the next eighteen months of marketing infrastructure spending and design. The argument runs in nine parts. First, the fifteen-year context that produced the current SaaS-everywhere baseline. Second, a map of the marketing AI landscape as it actually exists today. Third, the three integration architectures emerging across every category. Fourth, the protocol consolidating underneath them. Fifth, the build-versus-buy math that flipped between 2024 and 2026. Sixth, the capital backdrop that determines what ships next. Seventh, the frontier model landscape and what it means for procurement. Eighth, the organizational implications most CMOs have not yet planned for. Ninth, the risks worth taking seriously. Then a forecast and a practical agenda for the next two quarters. The forty-three percent number is the entry point. The pattern underneath it is what matters. ## The fifteen-year context The fifteen years between 2009 and 2022 produced one structural change in marketing infrastructure above all others. Every layer that used to be configured in-house got repackaged as a monthly subscription with a multi-year contract. The transformation was gradual, vendor by vendor, and by the end of the period it was nearly total. CRM consolidated around Salesforce and HubSpot. Email and marketing automation consolidated around Mailchimp at the lower end and Marketo, Pardot, and HubSpot Marketing Hub at the larger end. Content management split between WordPress on the open side and Adobe Experience Manager, Sitecore, and various managed CMS platforms on the enterprise side. Analytics moved to Google Analytics with a layer of vendor-specific dashboards on top. Customer data platforms became their own category with Segment, mParticle, and a handful of vertical-specific players. Personalization tools, A/B testing tools, conversion optimization tools, attribution tools all consolidated into two or three category leaders with seat-based pricing and twelve-month contracts. The result, for any mid-market marketing operation by 2022, was a stack of eight to twenty monthly subscriptions, each on a separate renewal cycle, each compounding fifteen to twenty-five percent per year, each with switching costs that grew faster than the value the vendor added. The total cost of marketing infrastructure crept up year over year while the underlying capability changed only marginally. The procurement department learned to expect renewal increases. The marketing finance team learned to model them. The CMO learned that the SaaS bill was the price of running a modern marketing operation, and that the only way out was a different vendor in the same category, which mostly meant a different bill at a similar price point. WordPress sat in this period as an exception. Self-hosted, open-source, controllable. The half of the web running on WordPress was the half that had decided not to fully participate in the SaaS-everywhere trade. That decision was less about ideology than about specific advantages: ownership of the platform layer, freedom from vendor lock-in at the most critical surface, and a plugin ecosystem that meant most missing capabilities could be added without changing vendors. The cost moat that WordPress carried into 2022 was substantial enough that it kept growing share even as the broader marketing stack consolidated around closed SaaS. Then late 2022 happened. ChatGPT launched on November 30 and hit one hundred million users in two months. The mainstream conversation about AI shifted from research demos to product roadmaps overnight. By March 2023, GPT-4 had landed, and the question every product team in marketing technology started asking was whether their product needed to ship AI features within the year. The answer was usually yes. Through 2023, the first wave of AI features arrived: Jetpack AI Assistant from Automattic in April, Elementor AI in May, Divi AI in September, and a long tail of content-generation overlays bolted onto every major marketing platform. Each shipped as a credit-metered, content-focused feature inside an existing product. That first wave defined how the market thought about AI in marketing infrastructure through most of 2024. AI meant content generation. It meant overlays. It meant another line item on top of the existing subscription. It did not, yet, mean anything structural. The structural changes started in 2025. By 2026, the architecture of marketing infrastructure is reorganizing around three distinct integration patterns. Before walking through those patterns, it helps to see the current state of the marketing AI landscape as it actually exists in the wild. ## The marketing AI landscape, mapped The marketing AI landscape in mid-2026 organizes into roughly six categories. The boundaries between them are blurring, and they will compress further through 2027, but the categories are still distinct enough to be useful for mapping a stack. **Content generation tools.** The most mature and crowded category. Jasper, Writer, Copy.ai, Anyword, ContentGen, plus an expanding set of vertical-specific tools for product descriptions, ad copy, social posts, and long-form articles. The category did roughly five billion dollars in revenue in 2025 and is growing at a pace that suggests pricing pressure rather than market expansion. Every major marketing automation platform has shipped equivalent features inside its own product, which is structurally compressing the standalone category. By 2027, most content generation will happen inside the broader marketing platform rather than as a separate subscription. **Personalization and decisioning engines.** Adobe Target, Optimizely, Dynamic Yield, Mutiny, and a growing set of AI-native challengers. These tools use machine learning to decide which content, offer, or experience to show to which visitor. AI changed this category meaningfully in 2025 by collapsing the engineering work required to set up personalization from a multi-quarter project to a multi-week one. The category is restructuring around whether the personalization decisions are made by the vendor’s models on the vendor’s data, or by the customer’s models on the customer’s data. The second pattern is harder to set up and produces better long-term results. **AI-native CRM and customer data platforms.** Salesforce Agentforce, HubSpot’s Breeze AI, Pipedrive AI, plus a small set of next-generation entrants designed agent-first. The traditional CRMs are bolting AI onto twenty-year-old data models. The AI-native entrants are designing the data model around what agents need. Both will exist for a while. The differentiation is going to be how cleanly each platform exposes its capabilities through MCP so external agents can operate them. **Email and marketing automation with AI.** The largest single category by revenue in marketing technology. Klaviyo, Marketo, HubSpot Marketing Hub, Iterable, Customer.io. Every one of them shipped AI features through 2025. The features themselves are mostly similar: AI-assisted subject lines, send-time optimization, predictive churn scoring, automated segmentation. The differentiation is in how the AI integrates with the rest of the marketing operation, not in the AI itself. **AI-native marketing platforms.** The smallest but fastest-growing category. Lovable for landing pages, Mutiny for personalization, and a long tail of newer entrants that designed for AI from the start rather than retrofitting it. Lovable hit four hundred million in annual recurring revenue in February 2026 with one hundred forty-six employees, which is the most aggressive software revenue ramp publicly documented. The category as a whole is taking share from the traditional marketing tool categories at the margins, particularly at the small business end of the market. **Infrastructure-layer AI tools.** The layer most CMOs have not yet engaged with. Model providers (OpenAI, Anthropic, Google). Cloud agent platforms ([Google Enterprise Agent Platform](/canon/research/google-enterprise-agent-platform-marketing-infrastructure/), AWS Bedrock, Azure AI Foundry). MCP-aware orchestration tools. Specialized tools like the various AI-design tools (Lovable, v0, Claude Design) that produce assets the rest of the marketing stack consumes. This layer is invisible to the marketing operation until it isn’t. By 2027, the choices made at this layer will determine more about a marketing stack’s capability than the choices made at the product layer. These six categories are converging. The boundaries between them will compress through 2027 as agentic platforms span multiple categories and the model providers move further up the stack. For the next twelve to eighteen months, mapping a marketing stack against these six layers is a useful exercise. It clarifies where the stack is at risk of compounding cost, where there is opportunity to consolidate, and where the gaps are most likely to be filled by the next wave of tools. ## Three integration architectures emerging across marketing technology Three integration architectures have emerged across every category of marketing technology in the last twenty-four months. The differences between them are mostly invisible to the casual user, but they determine almost everything about cost, vendor lock-in, capability ceiling, and how a marketing operation will absorb the next wave of AI capability when it ships. **The first architecture is native generation.** The vendor ships AI features inside the product, generated by a model the vendor controls or licenses, constrained to the product’s existing format. HubSpot’s Breeze generates HubSpot-shaped content inside HubSpot. Salesforce’s Agentforce operates inside the Salesforce data model. Adobe Sensei works inside the Adobe stack. Elementor’s AI features generate Elementor layouts. Divi’s AI features generate Divi templates. In each case, the AI is constrained to the vendor’s output format, the vendor’s data model, and the vendor’s improvement cycle. The upside of native generation is unified workflow. The user does not leave the product. The downside is that capability is bounded by what the vendor’s AI integration can do, output skews toward what the vendor’s model has been trained on, and improvement in the underlying frontier models reaches the customer only as fast as the vendor integrates them. When a better model arrives next quarter, the customer waits. **The second architecture is interchange-based.** The marketing operation uses frontier AI tools directly, in their native form, and brings the output into the operating stack through a structured interchange format. HTML is the most universal of those formats today. A marketing team uses Claude, ChatGPT, or an AI-first design tool like Lovable or v0 to generate a landing page concept, then imports the resulting HTML into the production stack. The same pattern shows up in email marketing (designers produce HTML in an AI-first tool and import into the email platform), in long-form content (writers produce drafts in Claude or ChatGPT and paste into the CMS), and in advertising creative (designers produce variants in Midjourney or Flux and import into the ad platform). The upside of interchange-based architectures is access to the best available model on any given day, decoupled from any individual vendor’s roadmap. The downside is the two-step workflow and the engineering cost of robust import. The WordPress page builder market made HTML import canonical with Bricks 2.3 in March 2026. The pattern is now spreading. Every category from CMS to email marketing to landing page tools is being pushed toward accepting external structured inputs because the alternative is being a closed loop that lags the frontier. **The third architecture is agentic, built on Model Context Protocol.** Instead of generating output that the operator imports, AI agents operate continuously inside the marketing stack itself, reading the current state of the system before acting, executing changes through defined tool surfaces, and reporting back. The agent is a system operator, not a generator. Elementor’s Angie plugin in March 2026, WordPress.com’s Claude Connector with full write access in March 2026, and the WordPress Core AI team’s MCP Adapter all point at the same pattern. Outside WordPress, the same pattern is emerging in customer support (agents reading and responding to tickets), in marketing operations (agents auditing campaigns), and in content production (agents running editorial workflows end to end). These three architectures coexist. Most marketing operations have all three in some form by mid-2026, often without recognizing them as distinct. The native-generation features inside HubSpot or Mailchimp are one layer. The “paste HTML from Claude into the CMS” workflow that the editorial team has quietly adopted is another. The early agentic experiments with Claude Desktop or an internal cloud agent operating through MCP are the third. Each carries different cost dynamics, different lock-in profiles, and different capability trajectories. The differences matter at the architectural level because the math compounds differently for each. Native generation locks the operation into a vendor’s improvement curve, which is by definition slower than the frontier. Interchange decouples capability from vendor, which means the operation captures the rate of improvement in frontier models directly, but pays the workflow overhead. Agentic infrastructure has the highest setup cost and the highest capability ceiling, because once the agent layer is wired into the stack, every subsequent frontier-model release improves the agent without any further integration work. What the WordPress page builder market reveals is that all three architectures will eventually be supported by every serious vendor in every category. The question for a CMO is not which architecture is right. The question is which architecture gets prioritized at which layer of the operating stack. The choices at each layer determine the operation’s flexibility and cost trajectory through 2027 and beyond. ## MCP: the protocol consolidating underneath everything Underneath the three architectures, a single protocol has emerged as the consolidation point: Model Context Protocol, often abbreviated MCP, originally published by Anthropic in November 2024 and adopted across the industry through 2025. Most CMOs have not encountered the term yet. They will, repeatedly, in 2027. MCP is, in CMO-readable terms, a standardized way for any software product to expose its capabilities to AI agents. A vendor that supports MCP can be operated by Claude, ChatGPT, or any other agent that speaks the protocol. The agent does not need to be trained on the vendor’s specific API. It reads the vendor’s MCP server, discovers what tools are available, and uses them. The vendor builds the surface once. Every agent in the ecosystem can use it. Two layers are worth distinguishing because confusion between them obscures most public coverage of the topic. The MCP server is the process that speaks the MCP protocol to the AI agent. It implements the request and response handlers, exposes a discovery surface, and manages permissions. Separately, the bridge to the underlying product is how the MCP server actually talks to the product. In WordPress, that bridge has historically been the REST API. The newer pattern, shipped by the WordPress Core AI team in February 2026, uses the Abilities API instead. The Abilities API was designed specifically as a structured surface for agent consumption, with capability definitions that include the agent-relevant metadata directly rather than requiring translation from a general-purpose HTTP API. The structural implication of MCP adoption is straightforward. In a world where every major marketing tool exposes an MCP surface, the agent layer becomes the new interface to the marketing stack. A marketing operator does not log into the CRM to update a contact, into the email tool to send a campaign, and into the CMS to publish a post. The operator gives an instruction to an agent, and the agent operates each tool through its MCP surface. The vendor tools become libraries that agents call. The interface to marketing operations migrates upward, away from individual product UIs, toward a unified conversational or task-based layer. WordPress is moving fast in this direction. The WordPress Core AI team shipped the official MCP Adapter in February 2026. WordPress 7.0, the next major release, ships three components in core: the Abilities API, the WP AI Client, and the Connectors API. The first is a standardized way for any plugin to expose itself to agents. The second is a unified provider interface so plugins do not each ship their own integrations with OpenAI, Anthropic, and Google. The third handles the authentication mechanics for agents acting on behalf of users. Beyond WordPress core, WordPress.com extended its Claude Connector from read-only access to full write access in March 2026. Forty-three percent of the public web became natively agent-writable in a single product release. The other fifty-seven percent of the web is following a similar trajectory at different speeds, with the model labs and the major platforms converging on MCP as the protocol of record. For a CMO, MCP-readiness becomes a procurement question by 2027. A working procurement framework on this question has four parts. First, ask the vendor whether they expose an MCP server today, are building one, or have no plans. The answer separates the vendors that are positioned for 2027 from the vendors that are still defending 2023. Second, if the vendor exposes MCP, ask which capabilities are available through it. Many vendors will ship a thin MCP surface that exposes only read-only operations or a small subset of the product. Useful, but not sufficient. The vendor that ships full read and write surfaces through MCP is meaningfully different from the vendor that ships only “search recent records.” Third, ask whether the MCP surface is documented and tested with third-party agents. A surface that works with Claude Desktop, ChatGPT Connectors, and Cursor is mature. A surface that only works with the vendor’s own internal agent is provisional. Fourth, ask about the roadmap for parity between the product UI and the MCP surface. Over the next eighteen months, the vendors that close the parity gap will gain agent-driven usage. The vendors that maintain a wide gap will see the gap become a procurement liability. The procurement question is not “does the vendor have AI features.” Every vendor will answer yes. The procurement question is “does the vendor expose an MCP surface that lets external agents do real work.” That answer separates the future of the vendor from the past. ## The build-versus-buy math has flipped The build-versus-buy decision for marketing infrastructure has been settled the same way for fifteen years. Buy almost everything. The reasons were structural. Building software meant a multi-quarter project, a dedicated engineering team, ongoing maintenance, and the constant risk that the in-house version would lag the vendor by a year and a half. SaaS won on every dimension that mattered to a business under quarterly pressure. Three of those four dimensions shifted between 2024 and 2026. The fourth flipped along with them. **Build time collapsed.** What used to need a multi-quarter team and a six-figure project plan can now take a small senior team a few weeks. Code generation has become substantially more capable. Library availability has matured. Cloud primitives like Google Enterprise Agent Platform, AWS Bedrock, and the various MCP-aware orchestration tools collapsed the build phase by close to an order of magnitude. The custom build that would have been a foolish bet for a mid-market firm in 2019 is a reasonable one in 2026. **Headcount dropped.** A senior architect plus one or two engineers now ships what used to need a six-person team. Scaffolding code is AI-assisted. Integration code is standardized. Observability is bought from the cloud provider rather than built in-house. The marginal headcount cost of owning a platform layer dropped by roughly three-quarters. **Maintenance burden dropped.** Owned infrastructure on managed cloud platforms gets the upside of managed services without the lock-in of SaaS. Patch cycles, scaling, and security are handled by the cloud provider. The owner only owns the parts that matter, which are the parts where ownership produces leverage. **The fourth dimension flipped.** The risk that the in-house version would lag the vendor used to be real and persistent. The vendor had specialized engineering teams pulling the product forward, while the in-house version was always playing catch-up. With AI, that gap closed and in many cases inverted. The vendor’s AI features are usually thin wrappers over the same APIs the firm could call directly. The vendor moat used to be workflow design and integrations. Both are buildable now by a small senior team in weeks. The cost picture in plain numbers. A typical AI tool subscription for a mid-market marketing team runs roughly fifteen thousand to fifty thousand dollars per year. Building the equivalent capability on Google Enterprise Agent Platform or Bedrock with a small senior team is a one-time investment of roughly the same order of magnitude, with marginal run costs of a few hundred dollars per month. Year one is roughly breakeven. By year three, the math is no longer close. To make this concrete, consider an editorial workflow for a mid-market B2B marketing team producing roughly forty long-form posts per quarter. The SaaS path: a content generation tool at thirty-five thousand per year, an SEO tool with AI features at twelve thousand per year, an AI image generator at eight thousand per year, and an editorial workflow extension at fifteen thousand per year. Total: seventy thousand per year, compounding twenty percent annually. By year three, the same stack costs roughly one hundred twenty-five thousand per year for the same capability. The owned path: a senior architect plus a part-time engineer build the equivalent workflow on Google Enterprise Agent Platform over six weeks. Build cost: roughly seventy thousand. Run cost: approximately five hundred per month in compute and tokens, or six thousand per year. Year one total: seventy-six thousand. Year two: six thousand. Year three: six thousand. Total three-year cost: eighty-eight thousand against three hundred thirty-five thousand on the SaaS path. The delta is roughly two hundred forty thousand dollars in favor of building, before counting any benefits from the owned version improving as frontier models improve. The argument is not that everything should be owned. Utility tools like email, calendar, payment processing, and source control remain better as SaaS. The argument is that at the layer of the stack where brand voice, customer data, content infrastructure, and agent workflows live, the math has shifted enough that ownership is the strategic position. The buyer that builds at that layer captures the rate of improvement in frontier models directly. The buyer that rents pays a compounding tax for someone else’s ability to integrate the same models. ## The capital backdrop most CMOs are not tracking The pace at which marketing infrastructure is restructuring is downstream of the capital flowing into the frontier AI labs. Most CMOs do not track the funding rounds. Most CMOs should. In March 2026, OpenAI raised one hundred twenty-two billion dollars from Amazon, Nvidia, and SoftBank combined. Amazon committed an additional five billion dollars to Anthropic in late April, bringing total Anthropic commitment above thirty-three billion. Lovable, an AI design tool that did not exist eighteen months prior, crossed four hundred million in annual recurring revenue in February 2026 with one hundred forty-six employees. Cognition AI was in talks to raise at a twenty-five billion dollar valuation. OpenAI acquired the AI coding tool Windsurf for approximately three billion dollars, the largest acquisition in OpenAI’s history. These numbers are not industry trivia. They shape what is possible in the marketing technology category over the next two years. Model costs continue to drop because the frontier labs are subsidizing inference while they capture market share and build distribution. New tools ship faster because the cost of building one keeps falling. The categories adjacent to model providers, including marketing infrastructure, are being remade because the substrate they sit on is being remade. Two implications for the CMO planning a 2027 budget. First, the rate of capability improvement is not slowing. A vendor that ships an AI feature in mid-2026 will have access to substantially more capable models by late 2027, and the vendors that designed their products to capture that improvement directly will widen the gap against the vendors that did not. The procurement decisions made today will look very different by their first renewal. Second, [the subsidized pricing window will not last forever](/canon/field-notes/the-intelligence-tax/). The unit economics on inference do not currently pencil at scale. Either capability prices fall fast enough to outrun the capital subsidies, or the subsidies end and pricing normalizes upward, or some combination of both. Marketing operations that built their AI dependence on rented SaaS wrappers will absorb the SaaS markup on top of the underlying API price increase whenever normalization happens. Operations that built on direct provider relationships will feel the change once. A CMO who treats the funding context as background noise is making a planning error. The flow of capital determines which capabilities ship, at what price, and on what timeline. Marketing infrastructure decisions made in 2026 should be made against a clear-eyed view of what the capital flows are paying for and what they imply for the next twenty-four months. The capital backing the frontier labs is the closest thing the industry has to a leading indicator for the pace of change, and the pace of change is what makes long-term procurement decisions risky in ways that the procurement playbooks of 2018 did not prepare anyone for. ## The frontier model landscape, briefly Most marketing technology articles treat AI as a single black box. The treatment masks an increasingly consequential reality. The frontier models have specialized. Different tasks reward different models. The marketing operations and the vendors that ship multi-provider routing have learned the same lesson the broader software industry learned through 2024 and 2025. There is no universal best model, and locking into one is a strategic risk that compounds over time. The current state as of mid-2026 looks roughly as follows. Claude Opus 4.7, released in April, is the quality leader for structural reasoning, complex code and HTML output, and tasks that require following detailed schemas without drift. Sonnet 4.6 is the cost-sensible workhorse tier, and most production AI pipelines that need Claude-class quality at volume use Sonnet rather than Opus. GPT-5-class models lead on price-performance for high-volume content generation, with the largest installed base across SaaS integrations because OpenAI shipped first and shipped the most aggressive developer outreach. Gemini 2.5 Pro and the recent 3.1 Pro release lead on long-context tasks, with two million token contexts that let an entire design system or campaign archive sit inside a single prompt. The split across marketing tasks reveals a clear pattern. Layout generation and structural content rewards Claude. Volume content production and basic copywriting rewards GPT-5-class. Tasks that require grounding in long source material reward Gemini. Translation in European language pairs continues to use DeepL underneath because the dedicated translation models still outperform the general-purpose frontier models in that specific domain, with LLMs overlaid for brand-voice proofreading. The implication for marketing technology procurement is direct. A vendor that hard-codes its AI features to a single provider locks the customer into that provider’s improvement curve and pricing trajectory. A vendor that supports multi-provider routing, often through bring-your-own-key arrangements, lets the customer route each task to the optimal model and capture provider competition directly. The third-party AI plugin ecosystem in WordPress has consolidated almost entirely around multi-provider routing as the default. The first-party AI features inside the larger marketing platforms have not, and the gap shows up in capability per dollar. A working procurement test for any AI feature inside a marketing platform: ask which model powers it, ask whether the customer can change models, and ask what the customer pays for tokens. If the answer to the first question is one model, the customer is locked in. If the answer to the second is no, the customer is paying the vendor’s markup. If the answer to the third is bundled credits with no visibility, the customer is subsidizing the vendor’s other customers. Multi-provider routing is a pricing strategy, a flexibility strategy, and a hedge against provider concentration. By 2027, it will be table stakes for any vendor that takes AI seriously. The vendors that lag on this are signaling that they have not yet decided whether AI is a feature or a foundation. The marketing operations that buy those vendors are betting on the wrong answer. ## Organizational implications: the marketing team in 2027 The conversation about AI in marketing has focused mostly on the tools. The conversation that matters more, and that most CMOs have not yet planned for in detail, is what the marketing organization looks like once those tools are operating at scale. Three structural shifts are already visible in the marketing operations that have moved fastest. By 2027, all three will be standard across the mid-market. **The first shift is role consolidation.** Marketing roles that were defined by individual production tasks compress as AI absorbs those tasks. A senior content writer who used to produce six long-form pieces per quarter now reviews and refines twenty AI-drafted pieces per quarter. The output is higher. The skill required to do the role well has changed. The role itself has not disappeared. It has shifted upstream into editorial direction, brand voice maintenance, and strategic prioritization. Junior content roles compress fastest because their original value was production capacity, and production capacity is what AI replaces first. The same shift happens across roles. Junior designers who produced asset variants now direct AI tools that produce hundreds of variants and curate the strongest. Junior media buyers who manually managed campaign variants now operate AI systems that test thousands of variants in real time. Marketing operations specialists who built workflows by hand now design and supervise agents that execute workflows continuously. The headcount math is not always “fewer people.” Often it is “fewer junior people, slightly more senior people, with substantially more output.” **The second shift is the rise of the marketing engineer.** Every mid-market marketing team will employ at least one person whose job is half marketer, half engineer by the end of 2027. The role goes by different names depending on the organization: marketing technologist, AI marketing operations lead, MarTech architect. What unites them is the responsibility for the AI infrastructure underneath the marketing operation. They configure agents. They maintain prompt libraries. They set up the data pipelines that feed the agents. They sit between the marketing team and the cloud platforms where the agents run. The role did not meaningfully exist five years ago. By 2027, the operations without one are at a structural disadvantage. This is the role that captures most of the value from the build-versus-buy shift. A senior marketing engineer, with the right tooling, can build and operate the infrastructure that used to require a four-vendor SaaS stack. The economics work as long as the role exists and is properly scoped. CMOs that are still procurement-organized will struggle to hire this role because the role does not fit the existing job ladder cleanly. The CMOs who reorganize around it pull ahead. **The third shift is the redefinition of the agency relationship.** Marketing agencies are restructuring in real time because the work agencies used to do is now AI-augmented at the in-house team’s desk. The traditional execution-heavy agency model is compressing. Two new agency models are growing in its place: [strategy-and-system-design firms](/capabilities/) that help in-house teams build their AI infrastructure, and [managed-services firms](/capabilities/#managedwebinfrastructure) that operate the AI infrastructure for the in-house team. The boundary between in-house and agency is moving from “who does the work” to “who owns the infrastructure that does the work.” Marketing operations that have not had this conversation with their current agency partners will have it in 2026 or 2027 whether they want to or not. The net organizational picture for 2027: smaller teams, more senior on average, with at least one dedicated AI infrastructure role, working alongside a different shape of agency partner, producing materially more output than the same team produced in 2024. The compensation math shifts accordingly. The talent strategy shifts accordingly. The procurement strategy shifts accordingly. CMOs who are still hiring junior production roles in 2026 are hiring against a structure that will not exist in twelve to eighteen months. CMOs who are hiring marketing engineers and senior strategic-direction roles are hiring against the structure that will. The talent decisions made in the next two quarters compound for the next three years. ## Risks worth taking seriously Three risks deserve explicit attention before any marketing operation commits to a 2027 AI infrastructure plan. None of these are reasons to slow down. All of them are reasons to plan with eyes open. **Vendor concentration risk.** The AI infrastructure underneath marketing technology is consolidating around a small number of providers. OpenAI, Anthropic, Google, and a handful of cloud platforms (AWS, Google Cloud, Azure) account for the substantial majority of the marketing AI value chain. The concentration is structural. Training frontier models requires hundreds of millions or billions of dollars of compute. The number of organizations that can play at the frontier is small and will stay small. A marketing operation that builds heavily on top of a single provider is taking on a real strategic risk if that provider raises prices, changes terms, or goes offline. Multi-provider routing is the practical hedge. **Data sovereignty and the data lease problem.** Every SaaS subscription is two contracts. The cash contract is on the invoice. The data contract is in the terms of service, and almost no marketing operation reads it carefully. Default settings often allow the vendor to use customer data for purposes beyond the service being paid for: training the vendor’s models, improving the vendor’s products, generating aggregated insights the vendor sells to other customers. Multiply across twenty SaaS subscriptions and the customer data, behavioral data, content output, and prompt history sits in twenty different vendor environments under twenty different contracts. None of them are aggregated for the customer’s benefit. All of them are aggregated for the vendor’s. As AI makes data more valuable, the customer-side cost of the data lease keeps growing. The sovereign-infrastructure response is to keep training data, customer data, and the data that defines brand voice inside the customer’s boundary, with vendors selling compute and models rather than maintaining a relationship with the customer’s data. **Security exposure at the AI plugin and integration layer.** The first wave of AI features in marketing technology shipped fast. The security posture has not always kept pace. The AI Engine plugin vulnerability that affected approximately one hundred thousand WordPress sites in early 2026 was a wake-up call for the WordPress ecosystem. The broader pattern is that AI plugins hold API keys, manage tokens, and execute privileged operations. They are part of the security surface, not just the feature surface. Audit AI plugins the way a security plugin would be audited. Update them. Scope API keys narrowly. Monitor for unusual usage patterns. The marketing operations that treat AI integration security as an afterthought will find out about it when something goes wrong. A fourth risk worth naming briefly: regulatory exposure. The EU AI Act took effect in 2024 with a phased compliance timeline. By 2026, the operational requirements for AI systems classified as high-risk are starting to land. California’s regulatory framework is following on a similar timeline. The marketing operations that have not yet inventoried their AI tools against current regulatory definitions are accruing compliance debt. None of this should slow AI adoption. All of it should shape the data architecture choices made along the way. None of these risks change the conclusion that the marketing infrastructure category is restructuring around AI in ways that demand engagement. They change the texture of how a CMO should engage. Move fast on the architectural shifts. Be deliberate about the data, the vendor concentration, the security posture, and the regulatory exposure. The operations that move fast and plan carefully will outperform the operations that move fast without planning, and the operations that plan carefully without moving will quietly fall behind both. ## The 2027 forecast for marketing infrastructure Predicting the next eighteen months in marketing infrastructure is difficult because the rate of change keeps accelerating. The horizon keeps moving up the stack. With that caveat, nine structural predictions for the period between mid-2026 and end of 2027, ordered roughly from most to least confident. **The visual editing layer becomes an override, not the default.** Today, a marketing operator opens a builder, a CMS, or a campaign tool, and drags elements to make something. AI helps fill gaps. By the end of 2027, that ordering inverts for most users. The default workflow opens with an AI prompt, the AI produces a working asset, and the manual editor becomes the place a user goes to refine what AI generated. The shift is already visible in the early agentic features inside the largest marketing platforms and in the AI-first competitors outside the WordPress ecosystem. The skill that used to be “knowing how to use the tool” becomes “knowing how to prompt and refine.” **Structured interchange formats become universal table stakes.** HTML inside the page builder market, structured JSON in the campaign tooling market, structured email formats across mail platforms, and a similar pattern in every adjacent category. Vendors that accept external structured inputs become the default endpoints for AI-generated assets. Vendors that require everything to be generated inside their own product become harder to use as AI-first design tools mature. **MCP becomes universal across marketing tools.** By the end of 2027, asking whether a vendor exposes an MCP surface becomes a baseline procurement question, similar to asking whether a vendor supports SSO today. The vendors that ship MCP early inherit the agent ecosystem. The vendors that ship MCP late spend the period between mid-2027 and 2028 catching up. A small number of vendors will not ship MCP at all and will quietly lose share to competitors that did. **Ongoing agentic operations replace one-shot generation as the differentiator.** The first wave of marketing AI focused on generation: write the copy, draft the email, generate the image. The next wave focuses on continuous operation. Agents that audit campaigns for performance. Agents that adapt landing pages for visitor segments. Agents that flag content for refresh based on usage patterns. Agents that read the customer support inbox and draft knowledge base updates. By 2027, the operations that ship continuous agentic workflows outperform the operations that ship better one-shot generation. **Frontier model integration partnerships restructure pricing.** Anthropic’s existing connector relationship with WordPress.com is the first major lab-meets-platform partnership in this space. By 2027, expect at least one more: OpenAI partnering with a major hosting provider or marketing platform, Google integrating Gemini more deeply into Google Cloud’s marketing infrastructure offerings, or Anthropic deepening its presence in the marketing stack. These partnerships will produce native integrations with fine-tuned pricing that bring-your-own-key arrangements cannot match. **Cost per AI generation drops five to ten times.** Model providers have shipped consistent cost reductions every year since 2023. By the end of 2027, the cost of generating a typical marketing asset is functionally trivial. This kills the credit-pool business model that the first generation of marketing AI tools relied on. Either vendors shift to flat-rate pricing, which compresses margins, or they shift to bring-your-own-key models, which exposes the markup, or they bundle AI into the broader product, which is the path most are converging on. **Vendor consolidation accelerates.** There are too many tools doing too many overlapping things in marketing technology. AI compresses the relevant differentiation between them. When AI generates the design, the content, and the campaign, and AI manages the optimization, the vendor’s job narrows to data, integrations, and the interface to the agent layer. The vendors that survive 2027 will be the ones with strong agent integration, deep first-party data, and a viable third-party plugin or partner ecosystem. The ones that survive on installed base alone will lose share faster than their leadership expects. **First-party data becomes the only durable strategic asset.** As AI commodifies content production and design and operations, the differentiator that remains is the data the marketing operation owns and the models trained on it. First-party data, properly maintained, becomes the source of competitive advantage at the platform layer. The operations that invested in first-party data infrastructure between 2018 and 2024 are positioned for 2027. The operations that did not are at a structural disadvantage that gets harder to close as AI raises the bar for personalization, targeting, and decisioning. The CMOs reading this who have under-invested in first-party data should treat that as the most urgent gap in the 2026 plan. **Marketing role redefinition reaches the org chart.** The role shifts described above (role consolidation, the marketing engineer, the agency redefinition) move from emerging pattern to standard practice. By the end of 2027, the marketing organization’s structure on paper looks meaningfully different from its structure in 2024. The CMOs who lead the reorganization deliberately will retain talent and build durable capability. The CMOs who let the reorganization happen by attrition will face higher turnover and lose institutional knowledge along the way. ## What CMOs should be doing in the next two quarters The pace of change in marketing infrastructure rewards CMOs who plan against the structural shifts rather than against last year’s vendor reviews. Six questions to bring to the next two quarters of planning, with a concrete next step for each. **Which AI capabilities in the current stack are bolted on, wired in, or built in?** The bolted-on layer (vendor AI features added to existing SaaS subscriptions) is the most exposed to compounding cost and limited capability. The wired-in layer (frontier models feeding the operating stack through structured interchange) captures most of the AI capability improvement directly. The built-in layer (custom infrastructure with agentic workflows) carries the highest setup cost and the highest capability ceiling. Knowing which categories of the stack are at which layer is the first step in any 2027 plan. *Concrete next step:* in the next month, audit each tool in the marketing stack and label it. The output of the audit is a one-page map that becomes the basis for every subsequent decision. **Which vendors have an MCP roadmap, and which do not?** The vendors that ship MCP surfaces in the next twelve months will widen the gap against the vendors that do not. Every renewal decision in the next four quarters should weight MCP-readiness as a primary factor, not a secondary one. A vendor that cannot answer the MCP question with specifics is signaling that the strategic question is not yet on their radar. *Concrete next step:* add MCP-readiness to the standard vendor review template starting with the next renewal cycle. Make it a yes/no question with a date. **Where will ongoing agentic operations deliver more value than one-shot generation?** The first wave of AI investment in marketing went to content generation. The second wave goes to continuous agentic operations. The operations that adopt agentic workflows for performance auditing, content refresh, personalization, and customer service early will outperform the operations that wait for vendor-shipped versions in 2027 or 2028. *Concrete next step:* pick one workflow this quarter that currently happens through human attention on an irregular schedule. Pilot an agentic version. Measure the result against the baseline. **What does the 2027 budget look like if SaaS bills compound at twenty percent and AI tools get added on top?** A typical mid-market marketing operation spending two hundred thousand dollars on SaaS in 2024 will spend close to three hundred fifty thousand by 2027 on the same capability. AI tools layered on top add another fifty to one hundred fifty thousand depending on team size and usage. The compounding math is rarely modeled honestly in budget planning. It should be. *Concrete next step:* build a three-year SaaS forecast model with realistic renewal increases. Compare against the same capability built in-house. The output is a strategic memo, not a tactical document. **Which capabilities should the operation own versus rent in the new economics?** The build-versus-buy math has shifted enough that the platform layer (the CMS, the content infrastructure, the brand voice systems, the agent layer) is a legitimate own-it decision for mid-market operations that it was not in 2019. The utility layer (email, calendar, payments, source control) remains better as SaaS. The line is strategic, and getting it right is a multi-year operating advantage. *Concrete next step:* pick one platform-layer capability that the operation rents today. Build the case for owning it. Run the case past finance and engineering. Decide. **What does the marketing organization look like in 2027?** Role consolidation, the marketing engineer role, and the agency relationship are all in motion. Most CMOs have not yet planned the implications. *Concrete next step:* take the current org chart and project two years forward. Where are the headcount additions? Where are the role redefinitions? Where does the marketing engineer role sit? Where do agency relationships evolve? The output is a talent and organization plan that runs parallel to the technology plan. ## The shift is underway WordPress is not the most important piece of marketing infrastructure in itself. Most CMOs do not run their operation primarily on WordPress, and many would not be able to name the difference between the major builders or themes in the ecosystem. The relevance of WordPress is that it is the largest single chunk of public-facing digital infrastructure on the web, the most observable in real time, and the most architecturally varied. Whatever pattern emerges in WordPress at scale is a leading indicator for the patterns that follow across every adjacent category. What WordPress reveals in 2026 is a marketing infrastructure category in structural transition. Three integration architectures are emerging where one (vendor SaaS) used to dominate. A new protocol is consolidating underneath all of them. The build-versus-buy economics have flipped. The capital backing the frontier models is reshaping pricing trajectories. The agent layer is becoming the new interface. The marketing organization itself is restructuring around AI-augmented roles and a new kind of technical-marketing hybrid. The firms that read the pattern in 2026 will be positioned for 2028 and 2029. The firms that wait for the pattern to arrive at their own vendor reviews will spend the same period catching up. The firms that read the pattern but defer the structural decisions will end up neither building durable advantage nor maintaining vendor flexibility, which is a worse position than either extreme. The shift is real, it is underway, and the canary is plainly visible to anyone who looks. The question is not whether the shift is real. The question is what each marketing operation does with the next eighteen months while the shift is still being decided.