From AI assisted to Agent-ready: How dotCMS is Building for the Agentic-age

The roadmap items in this article are good-faith release estimates, not hard commitments.

Calling functions, reading structured data, chaining operations across systems without waiting for a human click: Agentic AI is here to act on behalf of a user. For enterprise architects, the shift from AI assistants to autonomous agents is a new set of architectural requirements, not an upgrade. Just two years ago, the question was whether AI could write a product description. Today, the question is whether your content infrastructure can be called by an autonomous agent that has never opened a browser.

That is a different problem.

AI assistants work inside the tools humans use. They suggest. Humans approve. Agentic AI is a different order of magnitude. Agents call functions, read structured data, and chain operations across systems without waiting for a human to click "next." According to a June 2025 Gartner press release, by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024. A separate Gartner forecast from August 2025 puts task-specific AI agents in 40% of enterprise apps by as early as 2026.

The organizations best positioned for this shift are not the ones with the most AI-enabled functions. They are the ones that build their content infrastructure to be used by agents.

Most enterprise CMS platforms were not built for this. They were designed for human users navigating menus, filling forms, and clicking publish. They bolt on AI features. They don't expose their functions as tools. They were not designed to be orchestrated by an external agent that needs to create, translate, govern, and publish content at scale without touching a browser.

At dotCMS, we are designed for exactly that. As we approach the end of 2026, much of it is already in customers' hands: dotAI works with seven model providers you configure and test from a dedicated admin screen, and the MCP Server now lets agents operate the full platform, from content types and pages to workflows, under the same permissions as your people.

At a Glance

• Gartner projects 40% of enterprise apps will embed task-specific AI agents by 2026, up from under 5% in 2025.

• Most enterprise CMS platforms bolt AI onto a human-first UI; agents need schemas, events, policy, and stable contracts.

• dotCMS uses a two-layer architecture: Layer 1 = dotAI, AI embedded in the CMS for editors; Layer 2 = the CMS exposed as callable tools for agents.

• Delivered: dotAI is model-agnostic across seven providers (OpenAI, Azure OpenAI, AWS Bedrock, Google Vertex AI, Google AI/Gemini, Anthropic, OpenRouter), configured per function from a dedicated configuration screen with per-capability connection testing.

• MCP Server v2 lets Claude, Cursor, or any MCP client operate the platform in natural language, governed by the same role-based permissions as a human user. Tokens never reach the model.

• Governance travels with every agent call: permission inheritance, working-version-only writes where a human publishes, version history with rollback, and a model and data boundary you choose.

• Next: the Accessibility Fix Agent, AI admin observability, workflow visibility and feedback, Content Quality Agent, Content Intelligence Prompts, and Brand Voice and Content Standards.

A Two-Layer Architecture offers Flexibility

In short, the dotCMS two-layer architecture splits AI into what editors use inside dotCMS (Layer 1) and what agents call against dotCMS (Layer 2) - sharing the same content, governance, and contracts.

The way dotCMS approaches AI is a deliberate two-layer architecture that serves both AI as an assistant and AI as an autonomous agent.

Layer 1 is dotAI, AI embedded inside dotCMS - content and image generation, translation, semantic search, and workflow automation built natively into the platform. This layer makes content teams faster today.

Layer 2 is dotCMS made available to AI - every function, content type, workflow, and asset exposed as a callable tool through the MCP Server, dotCLI, and agent-consumable APIs. This layer makes dotCMS the content backbone for autonomous agents in end-to-end workflows.

The critical point: Layer 1 capabilities become Layer 2 tools. The same generation, translation, and workflow functions a content editor uses through the UI are the exact functions an autonomous agent calls programmatically via MCP. You build one content infrastructure that serves both humans and agents - on the same data, governed by the same rules, through the same contracts.

A practical way to choose between them: use dotAI when you want AI inside the authoring experience (content writing, SEO, translation, search). Use the MCP Server when you want an external agent or coding tool to operate dotCMS on your behalf.

Layer 1: AI Across the Content Lifecycle

dotAI is built into the content lifecycle - not bolted on but available wherever content is created, reviewed, and published.

Current Layer 1 capabilities include:

• AI-assisted content generation through custom fields and natively in the Block Editor.

• Image generation and automatic alt-text tagging via workflow.

• Asynchronous translation at scale.

• Vector-based semantic search with conversational query support.

• Configurable AI workflow sub-actions for batch enrichment and tagging.

Delivered: bring your own model

The original constraint on dotAI was a single vendor behind a single key. That is gone. dotAI is now model-agnostic, with seven providers: OpenAI, Azure OpenAI, AWS Bedrock, Google Vertex AI, Google AI (Gemini), Anthropic, and OpenRouter, an aggregator that fronts hundreds of models behind one key.

You choose the provider, and the model, per function: chat, embeddings, and image generation can each point to a different place. Embeddings run on OpenRouter as well, so multi-provider covers semantic search, not just generation. OpenAI remains the default and the fallback, which means switching or reverting a provider is a configuration change, not a code rollback.

For an architect, this is the answer to "which model processes our content, under whose credentials, under whose contract." It is a model you chose, running under credentials you own. The first full proof came from an enterprise insurance customer that completed a dotAI proof of concept (chat, semantic search, image generation) entirely on its own Azure OpenAI deployment.

Delivered: a configuration screen and a rebuilt dotAI tool

Two pieces make multi-provider usable by someone who does not want to hand-author JSON:

• The dotAI configuration screen. Pick a provider per capability, fill in the fields it needs, and test the connection for each capability before you save. Invalid settings are caught at configuration time, not at runtime.

• The rebuilt dotAI tool (Developer Tools - dotAI), now on the same Angular stack as the rest of the admin. Developers and administrators use it to exercise search, chat, and image generation against real content, manage embeddings, and view every resolved setting read-only, so you can confirm which provider and model are actually in effect before you build on them.

Together they shorten the path from "we approved a provider" to "we have verified it works," which is the first step of any POC.

Available through the API

dotAI is not UI-only. Everything above is callable headlessly under /api/v1/ai: semantic search (/search and /search/related, GET and POST), embeddings management, text and image generation, and completions. The same endpoints sit behind the dotAI viewtool for Velocity templates. A headless front end or an orchestration agent can run vector search against your content through the API. See the dotAI REST API documentation.

Planned

• Accessibility Fix Agent (Q4 2026): Service offering from dotCMS, scan pages for accessibility issues using the WCAG 2.1 AA checker and apply fixes to themes, templates, containers and other front end code objects for human review and approval.

• dotAI security hardening (rolling out in Q4 2026): RAG permission enforcement, output safety, and abuse controls, so semantic search never surfaces content a user is not allowed to see.

• Admin Observability and Governance (Q4 2026): AI usage dashboards, real-time activity feeds, error tracking, and audit trails for compliance reporting.

• Workflow Visibility and Feedback (Q4 2026): show editors what an AI action will do before a workflow runs and what it did afterward, with the ability to review and correct the output.

• Content Quality Agent (Q4 2026): surfaces SEO gaps, metadata issues, and compliance problems during editing, before content reaches a reviewer, as suggestions a human approves.

• Content Intelligence Prompts (Q4 2026): pre-built, scoped queries on top of semantic search for specific content problems, such as finding content similar to a draft, auditing stale content, or sweeping for content that needs compliance review. These are query templates that return actionable lists, not an open-ended chatbot.

• Brand Voice and Content Standards (early 2027): admins define tone, vocabulary, and required disclaimers once, and those rules are applied to every AI prompt and checked against the output. This moved from Q3 2026 because the agentic platform took the capacity.

This is Layer 1 - AI where editors already work, governed from the start, instrumented for audit. But it is not what makes dotCMS agent-ready.

The Composable Spine: Why Architecture Is the Real Differentiator

The agentic era is a validation of composable architecture, not a disruption of it.

The "spine" concept dotCMS has articulated positions the CMS as a thin, durable layer for content, events, policy, and orchestration - not a monolithic DXP that tries to own every function. The spine was designed to survive the next paradigm. AI agents are that paradigm, and here's why the architecture maps directly.

A composable spine has four structural requirements: a portable content model, an observable event stream, codified policy and governance, and stable orchestration contracts. These are precisely what an AI agent needs to operate effectively:

• Portable content model. Structured content types, explicit field definitions, and predictable schemas give an agent the context to act without hallucinating the architecture.

• Observable event stream. Agents operate on state. They need to know what happened - workflow transitions, publish events, content changes. An event-driven system exposes this natively.

• Codified policy and governance. Agents inherit permissions from the system they call into. Governance expressed as policy travels with every programmatic action. Governance enforced only by UI friction does not.

• Stable orchestration contracts. Brittle APIs and undocumented schemas are manageable inconveniences for humans. For agents, they are failure modes.

"Model once, deliver anywhere" was always about structured content reaching websites, apps, and partner APIs without channel-specific forks. In the agentic era, agents are consumers too. A content type defined in dotCMS is readable by an editor, a headless frontend, a search index, and an AI agent orchestrating a content pipeline - through the same schema, the same API, the same governance layer.

Layer 2: dotCMS as an Agent-Ready Platform

The right question for an enterprise architect is not "does our CMS have AI features?" It is: Can an autonomous agent create content, move it through a governance workflow, translate it, and return a structured result - without a human touching a browser, and without bypassing the people who must approve it?

dotCMS answers yes. Here is the architecture behind that answer.

The MCP Server

The Model Context Protocol (MCP) Server is the primary interface between AI agent harnesses and dotCMS. Connect Claude Desktop, Cursor, or any MCP-compatible client and operate the platform in natural language: find and bulk-edit content, create and modify content types, build pages, templates, and layouts, run workflow actions, manage site configuration, and generate front-end components and code from your content structure. It covers the hybrid-CMS surface, not just content entries.

Version 2 works differently from the first release, which exposed a handful of hand-written tools. dotCMS has hundreds of API endpoints, and a tool for each would overwhelm an agent's context. Instead, v2 gives the agent two tools: search and execute. The agent searches a catalog of dotCMS operations to discover what exists and what each one needs, then writes a short script that calls them. This removes the schema guessing and hallucinated field names that make a generic LLM fail against an unfamiliar CMS, and it means the ceiling is the API itself rather than a hand-picked tool list.

Those scripts do not run loose. The execute tool runs them in a sandbox built on @dotcms/ai, the governed runtime that is also available as an npm package for developers building their own agents. Your API token stays on the server and never enters the sandbox, so the model never sees it. The script can reach dotCMS only through a curated whitelist of endpoints, each categorized by risk (read, mutate, destructive), and every call runs under the permissions of the role the token belongs to. If the role cannot publish, neither can the agent.

dotCMS also ships skills, including site building and migration, so a coding agent starts from dotCMS conventions instead of from scratch. To try it, run npx dotcms agent setup. One command mints and verifies a token, writes the server into your editor's configuration, installs the skills, and confirms the server starts. It covers Claude Code, Cursor, VS Code (Copilot), Codex, Antigravity, Devin, and OpenCode; Claude Desktop is configured manually.

A public demo site is available at demo.dotcms.com. Read the MCP Server documentation.

dotCLI

The dotCLI provides command-line native access to dotCMS for agents that operate via shell - common in coding agents, infrastructure pipelines, and CI/CD automation. Schema migrations, content imports, and publishing operations are fully scriptable. The most capable agent harnesses (Cursor, Claude Code, GitHub Copilot Workspace) operate in terminal-native environments. A content platform without CLI access is one that those agents work around.

Agent-Consumable APIs

dotCMS's REST and GraphQL APIs are designed for programmatic consumption: predictable schemas, stable versioning, explicit authentication, and structured error responses. The API investment that powered the headless era now powers the agentic era - the same API a React frontend calls to retrieve content is the same API an orchestration agent calls to create, update, and publish at scale.

What Agentic Architecture Unlocks

Launching Compliance-Sensitive Content at Scale

A regulated financial services company is launching a new product across 12 markets in a 48-hour window. Today that is a pipeline that lives on email and spreadsheets: brief, draft, compliance review, legal, translation, regional adaptation, publish. It takes weeks of handoffs, with the content team coordinating rather than creating.

With dotCMS as the agentic backbone, an agent receives the brief, discovers the content type schema via MCP, and generates structured drafts through dotAI on a model provider the company has approved, inside its own cloud boundary. It routes each draft through the approval workflow, triggers translation for the other markets, and queues every variant for regional review. Compliance and legal approve in the same workflow they always have, and the publish step stays with the people the workflow names. Every change carries its author, its approval, and a version you can roll back. The content team's role shifts from managing the pipeline to reviewing the exceptions.

This is Layer 1 and Layer 2 operating together: generation and translation via dotAI, workflow operations via MCP, governance baked in throughout.

Building a New Module with Your Design System

A developer working in Cursor needs a new page module that follows the company's design system, documented in a Design.md file. Without context, the agent guesses at field names and generates components that fail on the first run. With the dotCMS MCP Server and skills, the agent reads Design.md and the existing content types, creates the content model for the module through MCP, and generates the front-end component to match the design system. It then creates sample content so the developer can preview and test the module right away.

The developer reviews and refines instead of writing it all from scratch. Research from GitHub and Microsoft has documented up to 55% faster task completion when developers use AI coding tools, and the key variable is how much relevant context the agent has. The MCP Server is what delivers that context.

Migrating an Existing Site

A developer needs to move a site from WordPress, or another CMS, onto dotCMS. Using the MCP Server and the dotCMS migration and site-building skills, the agent learns how dotCMS is structured, proposes a content model based on the source site, and creates the content types. It then migrates the content and assets and generates the front-end components to match the existing pages. The developer (or maybe the content manager!) reviews the model and the results at each stage and makes the calls that need judgment, while the repetitive work is handled by the agent.

The Enterprise Case: Governance Is the Architecture

AI agents introduce a governance challenge that feature-level AI does not. A content editor using an AI suggestion is accountable for the output. An autonomous agent acting without human review is not accountable in the same way. This is the primary objection enterprise buyers raise when evaluating agentic workflows - and it is a valid objection.

dotCMS's response is structural, not a feature layer added on top. The same controls that govern your editors govern your agents, and they answer the three questions every security and legal team asks: which model, where does the data go, and who is allowed to do what. We cover the full seven-control framework in AI You Can Actually Turn On. Here is how it applies to agents.

Permission inheritance. An agent operating via the MCP Server inherits the same role-based access controls governing human editors. It cannot publish what a human with the same token scope cannot publish. There is no separate "agent policy" to maintain: you give an agent a token scoped to a role, and you decide how much autonomy it gets the same way you do for people. If the role requires approval before publish, so does the agent. If you grant publishing rights, every action is still logged and reversible.

Human in the loop. Permissions decide what an actor can do; workflows decide the path content must travel before it goes live. AI acts as a step inside that process. First-party agents write to the working version only, so a person takes the publish action.

Audit and rollback. Every workflow action is recorded: state transitions, actors, timestamps. AI-assisted changes appear in the same version history as human edits, with one-click "Bring Back" rollback. Admin Observability and Governance (Q4 2026) adds AI-specific activity dashboards, real-time activity feeds, and error tracking, making AI actions as visible and auditable as any other content operation.

Model choice and data boundary. dotAI's seven providers let enterprises route AI operations to approved providers - Azure OpenAI for financial services and healthcare, AWS Bedrock for AWS-compliant organizations, Google Vertex AI for global deployments, or Anthropic and OpenRouter directly. Pair that with dotCMS's deployment options (on-premise, your own cloud, or fully managed as Cloud Anywhere) and a provider configured against your own tenant, and AI requests stay inside the boundary you already trust. The model is a configuration, not an architectural constraint.

Brand voice as policy (planned). Brand Voice and Content Standards (early 2027) will let admins define tone, vocabulary, and required disclaimers once and apply them to every AI prompt, with output checked against the same ruleset regardless of model or channel. Gartner projects AI governance platforms will become a $492 million market in 2026, growing to over $1 billion by 2030, driven by regulatory pressure and enterprise risk requirements. Organizations building on platforms without native AI governance will be retrofitting compliance. dotCMS's governance model is independently certified, including ISO/IEC 42001 for AI management, alongside ISO 27001, SOC 2 Type II, and TX-RAMP.

Conclusion: The Spine is ready for the Agentic Age

The spine concept was always a bet that organizations needed a thin, well-governed content layer - composable, stable, observable, built on contracts that hold under change. It was designed to survive the next paradigm without a rewrite.

AI agents are the paradigm. They expose every brittle API, every undocumented schema, every piece of governance that existed only as UI friction. The platforms that survive this test are the ones whose architecture is already oriented toward composability and programmatic access.

dotCMS built that architecture before agents were a mainstream concern. The content types that structured your web content are the same schemas agents read. The workflows that govern your editorial process are the same tools agents call via MCP. The APIs that power your headless frontends are the same APIs agents use to build, translate, and publish at scale.

Models will commoditize. What will not commoditize is a content infrastructure designed to put any capable agent to work on governed data, through stable contracts, with a complete audit trail.