AI is bringing content design, enterprise content strategy, knowledge management, and model behavior into the same user experience. Our ways of working haven’t caught up.

Image generated by Claude

Imagine a finance manager trying to understand why a supplier hasn’t been paid.

The enterprise application shows that the invoice has been approved. The manager asks the AI assistant when the supplier can expect payment, and the assistant explains that the invoice has completed the approval process and is ready for payment.

Except it isn’t.

The invoice is blocked because of a discrepancy between the invoiced amount and the purchase order. Approval and payment eligibility are different things, governed by different parts of the business process.

The assistant hasn’t necessarily misunderstood the approval status. But it has failed to understand what that status means in relation to everything else.

Maybe it retrieved documentation about invoice approvals without the information about payment blocks. Maybe the underlying business concepts aren’t represented consistently across systems. Maybe it didn’t have access to the current payment status. Or maybe it had the right information and still failed to interpret it correctly.

Those are different problems, often owned by different teams.

But from the user’s perspective, it’s one experience — and it’s broken.

This is one of the most consequential challenges emerging as AI becomes part of enterprise software. We’re bringing together content and knowledge ecosystems that we’ve historically managed separately, and we haven’t yet developed the ways of working to manage their interdependence.

We’re going to need more than better AI models, better content systems, or better design guidelines. We’re going to need to rethink how these things work together.

We’re talking about more than one AI transformation

One thing that makes this moment difficult to navigate is that we tend to talk about AI and content as though we’re discussing a single change.

We’re not.

In a 2026 article for Nielsen Norman Group, Sarah Gibbons articulated four different meanings of “AI design”: designing with AI, designing AI products, designing for AI agents, and designing the AI itself.

That distinction is useful because the implications for content work are dramatically different depending on which kind of AI design we’re talking about.

Consider two scenarios.

In the first, a product team uses AI to accelerate its existing design process. It has a content design system with established terminology, voice and tone guidelines, and interaction patterns. Designers use AI to generate candidate UI copy, and content designers review and refine it before shipping.

AI has changed how efficiently the team produces content, but the fundamental model is familiar. People design and approve a defined set of content before it ships, and the product displays that content according to established rules and conditions.

In the second scenario, the product generates content dynamically for each user, drawing on information about their task, their context, the state of the system, and relevant enterprise knowledge.

The content designer can’t anticipate or approve every possible sentence. Instead, they help design the system that determines what the experience should communicate, under what conditions, with which constraints, and how to evaluate whether it’s working.

That’s a fundamentally different design challenge.

And then there’s another dimension: an AI agent that needs to understand the same product well enough to take action on behalf of a user. The information and structures that make sense to humans may not be sufficient for an agent. The system needs reliable representations of concepts, relationships, actions, constraints, and permissions.

Those three situations map to the first three of Gibbons’s categories. The fourth, designing the AI itself, is what is being called things like model design, model behavior, context architecutre, or content engineering — and it shapes all of the others.

These scenarios don’t replace one another. They increasingly coexist, sometimes within the same product.

We’re only beginning to understand what that means for content work.

Specialization is increasing. So is interdependence.

There’s been considerable discussion about whether content design is splitting into different specializations.

One direction moves deeper into content systems: structured content, reusable patterns, guidelines, standards, and the infrastructure that allows content design decisions to scale.

Another moves toward model behavior design: shaping how AI systems communicate, interpret intent, manage ambiguity, explain their decisions, and respond in different situations.

I see value in recognizing these areas of expertise. They involve different technical knowledge, methods, and deliverables.

But there’s another area where content designers need to develop greater expertise: the semantic and context architecture that allows systems to work with meaning.

Taxonomies, ontologies, and knowledge graphs are becoming increasingly relevant to the experiences we’re designing.

These aren’t interchangeable technologies. Taxonomies help organize and classify concepts. Ontologies define concepts and relationships within a domain. Knowledge graphs can represent interconnected information in ways that systems can query and use.

Together, these kinds of structures can help establish shared meaning across systems.

A broader context architecture also needs to account for information about the user’s task, the current state of the product, relevant business rules, permissions, and other conditions that determine what information is appropriate at a particular moment.

For content designers, learning these concepts well enough to communicate with technical teams is a start.

But content designers should also learn to actively help shape the semantic architecture of the experiences they design.

Information architects, knowledge engineers, data specialists, and enterprise architects bring essential expertise to that work. Content designers add what has always been central to our discipline: terminology, conceptual models, information organization, user mental models, and the relationship between language and understanding.

The decisions encoded in a semantic model can have direct consequences for how a user experiences a product.

If a system represents two business concepts as equivalent when users understand them as distinct, that mismatch may surface in navigation, generated explanations, recommendations, or agent behavior.

That’s a UX problem, even if its source is several layers removed from the interface.

This is also why I’m cautious about drawing hard boundaries between emerging content specializations.

We need people who go deep into content systems, model behavior, and semantic architecture. But their work needs to share patterns, concepts, and principles if the experience is going to feel coherent.

An enterprise user might move between a traditional interface, dynamically generated explanations, an AI conversation, and an agent performing a task.

Those interactions won’t use identical language or behave in identical ways, nor should they. But they need to share an understanding of how the product works.

Specialization makes sense. Separation is where I get concerned.

AI is bringing separate content ecosystems into the same experience

The challenge becomes even larger when we look beyond UX content design.

Enterprises have long divided responsibility for content and knowledge across different domains.

UX content design teams work on product experiences, language, interaction patterns, and design systems. Technical communication teams create and maintain product documentation, help content, and educational materials. Marketing, support, and other functions manage their own content ecosystems.

Content strategy and content ops establish content models, workflows, governance, lifecycle processes, and systems for managing content at scale, but usually within individual domains rather than across them.

Information architecture shapes how information is organized, labeled, and connected within each of these domains. Knowledge management varies even more: in some organizations it means maintaining documentation and knowledge bases, and in others it means capturing, sharing, and applying organizational expertise.

Now AI engineering teams are building systems that retrieve knowledge, assemble context, generate responses, and enable agents to act, often drawing on content and information governed by all these different functions.

These connections aren’t entirely new. Documentation has always needed to reflect how products actually work. Terminology in an interface should be consistent with the language in support content. But teams could often manage these dependencies through periodic reviews, handoffs, and separate publication processes.

AI is changing the nature of that dependency.

An AI assistant might draw on technical documentation to answer a question within a product. The semantic architecture can influence what information it retrieves and how it interprets that information. Content design patterns can shape how the assistant communicates its response. And business rules and permissions can determine what actions an agent can take on the user’s behalf.

The experience is increasingly assembled from information and design decisions managed by different teams, sometimes in real time.

Image generated by Claude

That creates new operational challenges. When something goes wrong, no single team may have the visibility or authority to diagnose and fix the problem. And a change made in one system can have consequences for experiences that another team owns.

This is why content ops and design ops need to work much more closely together. But the coordination can’t stop there. It also needs to involve the people responsible for enterprise knowledge, semantic architecture, AI engineering, and evaluation.

We need to scale coordinated decisions

Large enterprises have always struggled to scale content design.

One response has been to invest in reusable patterns, standards, guidelines, design systems, and operational processes that allow teams to create more consistent experiences without requiring a content designer to personally review every decision.

But another response, less often acknowledged, has been to accept uneven quality. When headcount shrinks or demand exceeds capacity, some experiences simply receive less attention. That compromise was never ideal, but organizations could often contain its consequences within particular products or channels.

AI makes that compromise harder to sustain. Inconsistencies in terminology, guidance, or source content can now influence generated responses and actions across many interactions.

Investments in reusable systems are becoming even more essential. AI can also make them more powerful by bringing guidance directly into the tools and workflows where experiences are designed and built.

But scaling content production isn’t the same as scaling content design.

AI can help us generate more content, more quickly. That doesn’t guarantee the content is appropriate, coherent, accurate, or useful.

Scaling content design means making good design decisions repeatable across an organization.

And increasingly, those decisions don’t live in one team’s tools or processes.

Consider what happens when an enterprise changes the terminology for an important business concept.

Traditionally, a content design team might update the design system and work with product teams to change UI strings. A documentation team might update help content and published materials according to its own release process.

Now we may also need to consider whether the change affects a taxonomy or ontology, what an AI assistant retrieves, which terms it uses in generated explanations, how an agent interprets a request, and what our evaluation tests consider a correct response.

Who identifies all those dependencies? Who decides which changes are significant? How do the changes move through the different systems? How do we know when they’re complete?

These are operational questions.

Image generated by Claude

Combining all these functions into one organization could create as many problems as it solves.

What we need is a more integrated operating model: shared standards where they matter, clear ownership, connected workflows, and governance that accounts for how decisions propagate across systems.

In practice, that means:

  • Shared governance of enterprise terminology and semantic standards, so a change to an important business concept is made deliberately and carried everywhere it matters.
  • Content design patterns that inform both traditional interfaces and AI behavior, so the product communicates as one product.
  • Workflows that identify which experiences need review when enterprise knowledge changes, so teams find the dependencies before users do.
  • Feedback loops that run in the other direction, so what we learn about AI behavior and user understanding reaches the teams who can fix the source.

That last one deserves more attention than it usually gets.

If testing reveals that an AI assistant consistently misunderstands a business concept, how does that information reach the teams responsible for the underlying knowledge, semantic structure, or content model?

If a documentation team discovers that users misunderstand a particular process, how does that insight influence the design of the product and its AI interactions?

We’ve spent years developing ways to scale the work within content functions. Now we need to get better at scaling the work across them.

Image generated by Claude

Evaluation is becoming part of content and experience operations

Evaluation is another area where this interdependence becomes clear.

With traditional UI content, we can review a relatively stable set of artifacts before they ship. We can assess the language, test it with users, and make revisions.

When an AI system generates responses dynamically, we can’t review every possible output in advance.

Instead, we need to evaluate the system’s behavior across different situations and continue evaluating it as the system, its knowledge, and its users’ needs change.

We’re still at a very early stage of learning how to do this well.

Much of the initial work must be exploratory. People examine outputs, identify patterns, form hypotheses about why something went wrong, and determine what needs to change.

As with the invoice, the cause can sit in several places. Sometimes the issue is with the model’s behavior. Sometimes the system retrieved the wrong information. Sometimes the underlying content was incomplete, outdated, or contradictory. Sometimes the system lacked the context necessary to interpret the request correctly.

And sometimes the response is factually accurate but still represents a poor experience.

It might misunderstand the user’s intent, communicate uncertainty inappropriately, fail to explain an important limitation, or suggest an action without adequately establishing what the user wants.

These are different kinds of problems, and they require different kinds of expertise.

I expect we’ll get much better at translating what we learn into evals: repeatable tests that assess how AI systems perform against defined expectations. These can help us identify recurring failures, assess the impact of changes, and improve the system over time.

But first, we need to understand what we’re evaluating.

It’s not enough to ask whether a response is accurate. We also need to ask whether it was appropriate in context, supported the user’s goals, and made sense as part of the overall experience. And when the system recommends or takes action, we need to evaluate whether users understand what’s happening and retain appropriate control.

Go back to the finance manager. An evaluation that only checked whether the assistant described the approval status accurately would have passed that response. The manager still wouldn’t know when the supplier would be paid.

One tempting response to poor AI outputs is to give the system more context. But more isn’t necessarily better. Irrelevant, outdated, or conflicting information can actually make responses less reliable. The challenge is determining which knowledge, rules, and details about the user’s task are needed in a particular situation, and using evaluation to understand whether we’re providing the right context.

This is another place where content designers and strategists, design researchers, AI engineers, and the people responsible for enterprise knowledge and semantic architecture need to work closely together.

As these practices mature, we’ll be able to automate more of our evaluations. But human judgment will remain essential, not only for assessing outputs, but for identifying new failure patterns and refining our understanding of what good AI behavior looks like.

This is particularly important for experience quality, where success depends on context, user expectations, and judgments that aren’t always easily reduced to pass-or-fail criteria. Automated evals and human evaluation will need to work together, each informing and improving the other.

The operational challenge will be to turn what we learn through evaluation into improvements across the systems involved.

An evaluation finding shouldn’t stop at identifying a bad response. It should help us diagnose what needs to change, whether that’s the model’s instructions, the knowledge it retrieves, the semantic architecture, the interaction patterns, or even the underlying business process. And that diagnosis needs to reach the people who can address it.

Those changes then need to be governed, tested, and maintained.

Evaluation used to be a checkpoint at the end of the design process. It’s becoming one of the ways we maintain the experience itself.

Enterprise knowledge is becoming part of experience architecture

There’s a larger shift underneath all of this.

We’ve often treated content as something we produce, manage, and deliver through products and systems.

But AI is making content and knowledge increasingly important to what those products and systems can understand, communicate, and do.

Enterprise knowledge is becoming part of experience architecture.

That doesn’t mean every document becomes a product component, or that every content specialist needs to become an AI engineer.

It means decisions about how information is structured, represented, governed, and made available can directly shape the behavior and quality of an experience.

And it means the distinction between designing an experience and designing the knowledge that supports it is becoming harder to maintain.

I’m not suggesting that anyone has figured out the right organizational structures or operating models for this work. I certainly haven’t. We’re just beginning to understand the scope of the transformation, and the practices we need