Enterprise technology evaluations are often reduced to spreadsheets.

Does the product generate text?

Tick.

Does it summarise documents?

Tick.

Does it provide agents?

Tick.

Does it support multiple models?

Tick.

Does it have a chatbot?

Tick.

This approach creates the illusion of objective comparison while ignoring the most important question:

What architecture allows those features to operate safely, reliably and at scale?

Two products may both claim to provide AI agents.

One may be an isolated assistant with broad access to a data repository.

The other may use scoped tools, explicit permissions, observable workflows, evaluation, approval stages and detailed audit records.

The feature appears identical in the spreadsheet.

The operational risk is completely different.

AI features are becoming commodities

Text generation is no longer a meaningful differentiator.

Most enterprise vendors can connect to a capable foundation model.

They can add summarisation, translation, classification and conversational search.

These capabilities will continue to improve, but they are increasingly accessible to everyone.

The long-term differentiation is moving into the surrounding architecture:

• context;
• orchestration;
• tool use;
• permissions;
• memory;
• evaluation;
• governance;
• observability;
• and integration.

The model generates an answer.

The architecture determines whether that answer becomes useful, trustworthy and safe.

The nine layers of enterprise AI architecture

A serious AI platform evaluation should examine at least nine architectural layers.

1. Model layer

The model layer includes the large language models and specialist models used by the system.

Questions include:

• Which models are supported?
• Can the customer select the model?
• Can different tasks use different models?
• Is model routing automatic?
• Can models be replaced without rebuilding the workflow?
• Are private or region-specific deployments supported?
• How are model upgrades tested?

A platform tied completely to one model may become strategically restrictive.

However, supporting many models is not automatically better.

The organisation still needs consistency, evaluation and operational discipline.

2. Context layer

Context determines what the agent knows at the moment it makes a decision.

This may include:

• user instructions;
• organisational policies;
• retrieved documents;
• structured content;
• customer data;
• conversation history;
• workflow state;
• permissions;
• and previous actions.

Poor context produces poor decisions regardless of model quality.

The most effective systems do not simply give the model more information.

They select the right information.

This is why enterprise vendors increasingly emphasise business context and connected systems rather than prompt engineering alone. OpenAI’s Frontier positioning, for example, centres on connecting agents to business systems, shared context and institutional memory.

Context architecture should answer:

• What information is retrieved?
• Why was it selected?
• How fresh is it?
• Does the user have permission to access it?
• Can the source be identified?
• How is conflicting information handled?
• Can sensitive information leak into another workflow?

3. Tool layer

Tools allow an agent to move beyond conversation and interact with software.

A tool might:

• retrieve a content item;
• create a draft;
• query a customer account;
• run an analysis;
• update a workflow;
• or launch an experiment.

The tool layer should expose business capabilities rather than unrestricted technical access.

For example, this is safer:

submit_content_for_review

than this:

execute_arbitrary_database_query

MCP is important here because it standardises how tools and resources can be exposed to AI clients. However, the quality and safety of the tool design remain the responsibility of the platform and implementation team.

4. Orchestration layer

Real enterprise work usually requires multiple steps.

An orchestration layer coordinates:

• goals;
• tasks;
• tool calls;
• branching decisions;
• retries;
• approvals;
• fallbacks;
• and hand-offs between agents or people.

Without orchestration, an agent may be impressive in a demonstration but unreliable in a repeatable business process.

Buyers should ask whether workflows are:

• deterministic;
• model-directed;
• visual;
• code-defined;
• version-controlled;
• testable;
• reusable;
• and observable.

A highly autonomous workflow is not always desirable.

For regulated or high-value processes, a more deterministic orchestration model may be safer.

5. Identity and permission layer

An agent should never be treated as an omnipotent system process.

It should have an identity and a defined authority.

The platform should determine:

• who initiated the task;
• which agent is acting;
• which permissions apply;
• whether authority is delegated;
• which data may be accessed;
• and which actions require additional approval.

Permission checks should happen at execution time, not merely when the workflow is created.

This matters because the agent’s plan may change according to the information it discovers.

6. Governance layer

Governance defines what the system is allowed to do.

It may include:

• brand rules;
• legal constraints;
• prohibited actions;
• approval thresholds;
• data residency;
• retention;
• model policies;
• content standards;
• and escalation procedures.

Governance cannot be reduced to a disclaimer beneath a text box.

It must influence retrieval, generation, tool selection and execution.

OpenAI’s agent-governance guidance argues for making governance part of the underlying infrastructure rather than treating it as a final launch-stage check.

7. Evaluation layer

Traditional software is tested using expected inputs and outputs.

AI systems are probabilistic.

The same input may produce different results.

This makes evaluation a permanent architectural capability rather than a one-off testing exercise.

Evaluation should cover:

• factual accuracy;
• task completion;
• policy compliance;
• relevance;
• tool selection;
• formatting;
• latency;
• cost;
• and business outcomes.

Strong platforms allow organisations to build test datasets, compare versions, inspect failures and prevent regressions.

Without evaluation, an AI workflow cannot be managed with the same confidence as other production software.

8. Observability layer

When an AI system produces a poor result, administrators need to understand why.

That may require visibility into:

• the user request;
• retrieved context;
• model selection;
• prompts and instructions;
• tool calls;
• intermediate decisions;
• permission checks;
• errors;
• retries;
• approvals;
• output evaluations;
• and final actions.

A single final answer is not enough.

Observability is particularly important for multi-step agents because a failure may have occurred several decisions earlier.

Enterprise buyers should ask to see the investigation experience, not only the successful demonstration.

9. Human-control layer

Human involvement should be designed into the workflow rather than added after something goes wrong.

Different actions require different levels of autonomy.

Low risk

Summarise a public article.

Moderate risk

Create a draft content item.

Higher risk

Update a customer record.

Critical risk

Publish regulated content, transfer funds or delete production data.

The architecture should allow approval policies to vary by action, user, market, data sensitivity and confidence.

The most mature AI platform is not necessarily the one with the highest level of autonomy.

It is the one that applies the appropriate level of autonomy.

A practical architecture comparison

Imagine two CMS vendors demonstrating the same request:

Improve this landing page and publish the new version.

Platform A

The assistant reads the page, generates replacement copy and updates the production content using an administrator integration.

Platform B

The agent:

1. authenticates the requesting user;
2. retrieves only the content they may access;
3. checks the content type and brand guidance;
4. analyses performance data;
5. creates a new version;
6. validates required fields;
7. runs quality and compliance evaluations;
8. submits the change for approval;
9. records the tool calls and evidence;
10. and publishes only after the authorised reviewer approves it.

Both vendors may tick “AI content optimisation.”

Only one has an enterprise-ready architecture.

The hidden importance of content architecture

AI architecture depends heavily on the quality of the underlying content architecture.

Agents work more reliably when information is:

• structured;
• uniquely identifiable;
• semantically described;
• versioned;
• permissioned;
• connected;
• and current.

A collection of ungoverned pages and documents may be readable by an AI, but it is difficult to operate on safely.

A structured CMS provides the agent with a domain model.

It can distinguish a product claim from a legal disclaimer, a campaign from a product, and a draft from an approved version.

That structure becomes part of the AI control system.

Why composability alone is not enough

Composable architecture is often presented as the answer to AI flexibility.

It certainly helps.

Open APIs and modular services make it easier to connect models and agents.

However, a composable estate can also create fragmented identity, inconsistent permissions and dispersed context.

An agent may need to coordinate across ten services, each with different data models and security assumptions.

Therefore, AI architecture needs more than connectivity.

It needs a coherent control plane.

That control plane may include:

• shared identity;
• tool registration;
• policy enforcement;
• workflow orchestration;
• evaluation;
• and auditability.

The agent should not be responsible for inventing that consistency at runtime.

Architecture and vendor lock-in

AI architecture also determines how difficult it will be to change providers.

Potential sources of lock-in include:

• proprietary agent definitions;
• platform-specific prompts;
• closed orchestration formats;
• inaccessible execution histories;
• model-specific tooling;
• embedded vector stores;
• and non-exportable evaluations.

Buyers should ask what can be exported.

Can agent workflows be represented as code?

Can tools be accessed through standard protocols?

Can another model use the same enterprise context?

Can logs and evaluation data be retained?

Can a customer-owned orchestration platform invoke the vendor’s capabilities?

Open architecture does not mean avoiding platforms.

It means keeping control over the boundaries between them.

Applying this to Optimizely Opal

Optimizely’s opportunity with Opal is architectural rather than cosmetic.

Optimizely already has several valuable layers:

• structured and governed content;
• experimentation;
• personalisation;
• analytics;
• campaign planning;
• and digital-experience delivery.

Opal can become the orchestration and interaction layer across those capabilities.

Optimizely has also introduced agent-building, workflow orchestration, roles, versioning and execution logs—capabilities that point towards a more operational agent platform rather than a simple embedded assistant.

The strongest Optimizely architecture would allow an agent to reason using:

• the content model;
• editorial permissions;
• approved brand context;
• visitor and audience information;
• experimentation history;
• observed performance;
• and publishing workflow state.

It could then take action through explicit, governed tools.

The differentiator is not that Opal can write a headline.

Any competitive model can write a headline.

The differentiator is that Opal may know:

• which headline belongs to which content type;
• which audience it serves;
• which market restrictions apply;
• which experiment it should become part of;
• who must approve it;
• and whether it actually improved the outcome.

A better enterprise AI scorecard

Instead of scoring products by feature count, score them across the following dimensions:

Dimension	What to assess
Context	Relevance, freshness, permissions and source traceability
Tools	Scope, safety, reversibility and business-level design
Orchestration	Workflow control, approvals, retries and versioning
Identity	Agent identity, delegated authority and access control
Governance	Policies, guardrails, auditability and data handling
Evaluation	Quality tests, regression testing and business measurement
Observability	Logs, traces, tool history and failure investigation
Openness	APIs, MCP, model choice, exports and extensibility
Human control	Approval points, escalation and autonomy thresholds

This scorecard will reveal far more than a checklist of generation features.

Final thoughts

AI capabilities will continue to converge.

Every major enterprise platform will generate text, summarise information and provide some form of agent.

The meaningful differences will sit underneath those features.

Which system understands the right context?

Which system applies permissions at every step?

Which system exposes safe tools?

Which system can demonstrate why an action occurred?

Which system can be evaluated, governed and improved?

Which system allows the organisation—not merely the vendor—to remain in control?

The next enterprise AI decision should not begin with:

What can the demo do?

It should begin with:

What architecture makes that behaviour safe, repeatable and valuable?

Stop comparing AI features.

Start comparing AI architectures.