Agentic content modelling: why structured content matters for AI agents

An AI agent that reads, creates or changes content inherits the assumptions in your content model. If a location is represented as reusable content in one place, written as free text somewhere else and buried inside rich text on another page, an editor may still understand that all three refer to the same thing. An agent has to work that out from the context available to it.

That becomes more important as we give AI a bigger role in websites and digital platforms. Agents no longer only generate copy or code. They increasingly read content through APIs, propose content structures, migrate information and make changes inside a CMS.

I wrote earlier, in Dutch, about the CMS as a control layer. As AI makes creating websites, components and content cheaper, the CMS provides the structure and governance around what gets created. The content model sits underneath that layer. It defines what your organisation knows, how concepts relate to each other and which rules apply.

That is where agentic content modelling starts to become interesting.

A content model gives AI context

Content modelling has always been about more than creating fields in a CMS. Before deciding whether something needs a text field, taxonomy or relationship, you first need to understand what that information actually means.

What is a Location in your organisation? Can a Service belong to several departments? Is an Author always a person, or can an organisation also be the author? Which information is reusable, and which only makes sense in the context of one page?

Marc Salvatierra, Senior Product Manager for Web Content Operations at ICANN and a long-time content modelling practitioner, made this case on stage at CMS Kickoff 26 in a presentation titled Beyond Schemas: How Conceptual Content Modeling Prepares You for an AI-Driven Future. In a Boye & Company member call, written up by Janus Boye in Why You Need to Know Your Content Better Than AI, he coined a shorthand for it: what you model is what you get (WYMIWYG), a deliberate echo of WYSIWYG.

That observation becomes even more relevant once machines start using the model themselves.

LLMs are increasingly capable of extracting entities and relationships from unstructured text. Research into knowledge extraction with large language models shows that this works surprisingly well, but also that results improve when the model is given an explicit schema and relevant context.

That distinction matters. AI can often reconstruct structure afterwards, but every reconstruction introduces interpretation. If your organisation already knows that fifteen pages refer to the same office, product or person, there is little value in asking a machine to rediscover that relationship every time.

A structured content model makes that meaning explicit.

An address that exists on fifteen pages gives an agent fifteen claims to interpret. Fifteen pages that reference one Location give it one source of truth.

From business meaning to machine-readable content

I find it useful to think about this as three connected layers:

• Domain meaning: what concepts such as Person, Location, Service or Event mean to the organisation.
• Content model: how the CMS represents those concepts through fields, relationships, taxonomies, permissions and validation.
• Machine interface: how that information becomes available through a website, API, structured data or MCP server.

The content model sits in the middle. It translates human understanding into something a system can enforce.

A date becomes an actual date field instead of a string. An author becomes a relationship to a Person. A relationship can specify whether one or several items are allowed. A taxonomy expresses controlled terminology instead of leaving every editor to invent their own variation.

Those details matter much more when an agent is allowed to write content.

An editor will often understand an unwritten rule because somebody explained it during onboarding. An agent sees the model and the tools it has access to. If twenty relationships are technically allowed, twenty relationships are a valid outcome from its perspective.

Field types, required fields, relationship constraints, permissions and validation therefore become part of the guardrails around the agent.

The better the model expresses the rules of the organisation, the less an agent has to infer from prompts or existing content.

This also explains why content modelling should start before the CMS. In our own projects, some of the most important modelling decisions are made while discussing terminology with stakeholders rather than configuring content types.

Once the meaning is clear, the technology becomes much easier.

Where Schema.org and GEO fit

The same model can also help when information leaves the CMS.

External search engines and AI systems usually do not see your internal content model. They see HTML, APIs and machine-readable data published from it. Schema.org provides a shared vocabulary for describing entities such as an Organization, Person, Event or Product.

A well-structured CMS makes that mapping much easier. If an Event already has a start date, location and organiser, those semantics can be translated into structured data. If the same information is spread across arbitrary text fields, much more interpretation is needed.

I would still treat Schema.org as an external vocabulary rather than the blueprint for the internal content model. Its data model is deliberately flexible because it needs to work across organisations and industries. Your own model usually needs stricter business rules.

The relationship therefore looks more like this:

This is also where content modelling touches SEO, GEO and AEO.

There is plenty of speculation about special optimisation techniques for generative search, but Google’s current guidance for generative AI in Search is much more pragmatic. Google does not require a special AI-specific Schema.org type or separate markup strategy. Useful content, crawlability, internal linking and structured data that accurately represents the visible content remain important.

For me, that reinforces the architectural argument. A strong content model helps maintain consistent entities, facts and relationships across pages and channels. That was already valuable for SEO. It becomes even more useful when machines combine information from multiple sources into an answer.

The objective is therefore not to rewrite your content for an LLM. It is to reduce the amount of meaning that an LLM has to guess.

Agentic content modelling also changes how models are built

Until recently, content modelling was mostly a human activity. Architects and developers translated workshops, requirements and designs into content types. AI is beginning to participate in that process as well.

That can speed things up enormously, but it also introduces a new risk. An LLM is very good at generating a model that looks plausible. Plausible and correct are not the same thing.

Imagine asking an agent to model an event. It may create a field called Date as text. The model looks sensible, but you have lost date validation, sorting, timezone handling and reliable structured output. The same issue applies to relationships, taxonomy and reusable content.

That is why I think AI-assisted content modelling needs two capabilities at the same time: generative reasoning and deterministic validation.

AI is useful for interviewing stakeholders, recognising repeated structures, proposing relationships and identifying opportunities for reuse. The platform still needs to validate whether the result follows its rules and established modelling practices.

This combination is more interesting to me than simply asking a larger model to produce better JSON.

How Xperience by Kentico is approaching this

Xperience by Kentico is starting to put this principle directly into its AI development tooling.

Its Content Modeling MCP Server guides an AI client through a structured modelling process. Requirements, content types, relationships, cardinality and Page Builder concepts are handled in separate stages, with deterministic validation alongside the LLM’s reasoning.

That separation is important. The agent can explore and propose a model, while the platform contributes knowledge about how Xperience is designed to work.

Once the model has been agreed, the Management MCP Server gives AI development tools controlled access to management operations inside Xperience. As of September 2026, the Management MCP is a supported part of Kentico’s agentic development tooling rather than a preview feature. Kentico has continued to expand those capabilities with validation, Workspaces and control over which management tools are available to an agent. The Xperience by Kentico roadmap is worth following because this area is evolving quickly.

This creates a useful separation of responsibilities:

First decide what the model should mean. Then validate it. Then allow an agent to implement it.

KentiCopilot extends that approach beyond content modelling. The KentiCopilot tooling provides agent skills, MCP integration and platform-specific development guidance. Its agentify skill can analyse a project and help establish persistent instructions and MCP configuration so that agents start with the relevant project context.

I see that as an important development. Agentic development cannot depend on developers remembering every rule in every prompt. The rules increasingly need to become part of the environment around the agent.

The same principle applies to content.

A model change is also a content change

There is one part of agentic content modelling that I expect to become much more important: changing existing models safely.

Creating a new field or relationship is easy. Changing a model that already contains thousands of content items is different.

If an agent moves several fields into a reusable schema, the task is not finished when the new schema exists. Existing content may need to be migrated, relationships updated and output validated.

For that reason, I increasingly think about model evolution as:

Agents are already becoming capable of handling all three parts. The important step is ensuring they are treated as one operation rather than allowing structural changes to happen without considering the content that already exists.

This is where content architecture, development and AI governance start to overlap.

The content architect becomes more important

It is easy to look at current AI tooling and conclude that content modelling itself will eventually be automated. AI can already propose content types, analyse existing websites and implement models through APIs.

I think that changes the role more than it removes it.

The difficult questions were never primarily about creating fields.

They are questions such as:

• What does this information mean?
• Which source is authoritative?
• Which relationships are allowed?
• Who owns the information?
• What should be reusable?
• What may an agent change automatically?
• What requires human validation?

Those are architecture and governance decisions.

As generating code, content and CMS structures becomes cheaper, those decisions become a larger part of the value.

That is ultimately what agentic content modelling means to me. It is designing a content model that works for editors and developers, while also giving AI agents enough semantics, constraints and context to operate safely inside it.

The content model becomes part of the interface between your organisation and AI.

The clearer that interface is, the less your agents have to guess.