Your Digital Experience Platform Has a New Kind of User

At Opticon New York, one of the things that caught my attention was not simply how quickly AI capabilities are being added to digital experience platforms. It was the overall direction of travel.

We are moving from AI that assists people to AI that can act on their behalf more and more.

For years, we have designed digital experience platforms around a fairly simple assumption: there are human users on one side and software on the other. Editors log into the CMS. Developers build integrations. Marketers configure campaigns. Someone makes a decision, and the system executes it.

And, as with most other areas that are touched by AI, that model is changing.

Optimizely’s recent introduction of Virtual Teammates is a good example. These AI agents are designed to have defined responsibilities, retain organizational context and proactively complete work across marketing workflows. Within Optimizely, they operate under their own Opti ID identity and assigned permissions; in connected third-party systems, access may instead be delegated through accounts authorized on their behalf.

At the same time, Optimizely CMS (SaaS) now provides an MCP server that lets authorized AI tools work with actual CMS structures and data, under the connected user’s existing permissions, and perform operations such as modeling content, generating components and running bulk content workflows.

To me, these developments point to a bigger change in digital experience:

AI agents are becoming a new kind of operational participant in our platforms. Non-human identities are not new, but agents combine identity and access with persistent context, tool use and a greater degree of autonomy.

And if that is true, we need to start designing for it.

Moving from assistant to actor

The first generation of enterprise AI largely behaved like an assistant.

You asked a question. It generated text. It summarized information. It suggested a headline. A human reviewed the result and then carried out the actual work.

Agentic AI changes the workflow.

An agent can potentially retrieve information, make decisions within defined boundaries, invoke tools, move information between systems and execute a sequence of actions.

That means the important architectural question is no longer only:

How can we add AI to this digital experience?

It becomes:

What should an AI agent be allowed to do inside this digital experience?

That is a much more interesting question for DX teams.

Forrester recently described agentic AI interfaces as an emerging next frontier for digital experience technology, with AI orchestrating workflows across existing SaaS systems. Gartner has similarly identified “agentic CMS” as an emerging category built around a dual audience of humans and AI agents.

The research is all pointing to the reality that this is not just a change to the interface, but to the architecture behind the interface.

What changes when an AI agent becomes a CMS user?

This is where the conversation becomes much more practical.

1. Give the agent an identity before you give it access

One of the most important differences between an AI assistant and an AI agent is that the agent may actually do something.

That makes identity and permissions architectural concerns.

If an agent can create or modify content, trigger a workflow or interact with another system, we need to know:

• Who is the agent?
• What is it allowed to access?
• Which actions can it perform?
• On whose behalf is it acting?
• What happens when it reaches the limits of its authority?

This is why I find the direction of Optimizely’s Virtual Teammates particularly interesting. The agent is not just a chatbot sitting alongside the CMS. It is designed as a digital coworker with an identity, persistent context and defined ability to act.

For implementation teams, that means identity and authorization should be part of the conversation much earlier than they might have been for a conventional AI experiment.

2. Stop thinking about APIs as the whole agent strategy

Giving an AI system API access does not automatically make a platform agent-ready.

An agent needs more than connectivity.

It needs context, tools, predictable actions and boundaries.

This is one reason MCP is an interesting development. Optimizely’s CMS (SaaS) MCP server allows AI tools to work against actual CMS structures and data, including content types and CMS operations.

That moves the conversation beyond:

“Can our AI call the CMS?”

toward:

“Can an AI understand our CMS well enough to perform useful work safely?”

It means we should evaluate not only whether a platform exposes APIs, but whether those interfaces expose the right context and capabilities for the workflows we want agents to perform.

3. Content modeling becomes even more important

This is where some of the principles of composable architecture become particularly relevant.

If content is locked into presentation-specific structures, it becomes harder for both applications and agents to reuse it intelligently.

Structured content gives us something different: reusable information with defined relationships, fields and meaning.

That has always been valuable for headless delivery and omnichannel experiences.

Now it also becomes important for AI.

An agent working with product information, campaign content or localized experiences needs to understand what the information is, how pieces of content relate to each other and what actions are valid.

In other words, content modeling is becoming part of the AI interface.

This is one reason I would not separate discussions about composable CMS architecture from discussions about AI. They are increasingly connected through the need for structured, accessible and reusable content.

4. Design the workflow before you automate it

There is a temptation with agentic AI to start with the question:

“What can we automate?”

I think the better question is:

“What should the agent be responsible for?”

Consider a content workflow.

An agent might be able to identify outdated content, create a draft, check it against a content model, suggest improvements and prepare it for publication.

But should it publish automatically?

The answer may be different for a low-risk campaign landing page and a regulated product statement.

That means agentic workflows need explicit boundaries.

The important point is that automation and autonomy are not the same thing.

Good DX architecture should let us decide where the line sits.

5. Governance has to move into the platform

AI governance cannot remain a document sitting outside the technology stack.

If agents can act, governance needs to exist where those actions happen.

That means thinking about:

• identity and authorization
• audit trails
• approval thresholds
• environment separation
• content provenance
• monitoring
• failure handling
• human escalation

This is also where platform modernization becomes more consequential.

Optimizely CMS 13, for example, makes Optimizely Graph a core platform component and brings Opti ID into the standard identity foundation for cloud-hosted deployments, while subsequent releases have continued to add AI, agent and integration capabilities.

An upgrade is therefore no longer only about moving to a supported version or adopting a newer technical stack.

It can also change what kinds of AI-enabled workflows your platform can support.

So, what should DX teams do now?

I would start with five questions.

1. Which actions could an agent realistically perform?

Don’t start with technology. Map the workflows.

Identify repetitive, rules-based or context-heavy tasks where an agent could create meaningful value.

2. What does the agent need to know?

Map the content, data, systems and context required to complete the task.

This often exposes gaps in content structure and integration architecture.

3. What should the agent be allowed to do?

Define permissions at the action level.

“Access to the CMS” is too broad a concept for an agent.

4. Where does a human need to stay in the loop?

Not every action needs approval. Not every action should be autonomous.

Design those boundaries deliberately.

5. Can we see what the agent did?

If the answer is no, the workflow probably isn’t ready for production.

Observability and auditability should be considered part of the agent architecture, not an afterthought.

The digital experience stack is getting another actor

I don’t think the important takeaway from the current wave of AI development is that every CMS needs to become an “AI CMS.”

The more important shift is that our digital platforms increasingly have two types of participants: humans and agents.

We’ve spent decades designing interfaces, workflows and architectures around how people interact with software. Now we need to consider how software agents will interact with the same systems.

That changes the questions we ask during an implementation.

It changes how we think about content modeling.

It changes what we should evaluate during a platform upgrade.

And it makes architecture, identity, integration and governance central to the AI conversation.

The most interesting question for DX teams may therefore not be “Where can we add AI?”

It may be: “If an AI agent were a user of our digital platform tomorrow, would our architecture be ready for it?”

And that is a very different kind of AI-readiness test.

Last Updated: September 2026