Why are we heading here?

As AI use expands and makes content creation more accessible, larger volumes of content are being generated at a faster rate.

But as this volume increases, many of the qualities that define good content design, such as context, consistency, and intent, start to fall by the wayside. Consequently, this could lead to an erosion of the trust a brand has built and lead to a disjointed user experience.

With companies leaning into an AI-first approach and looking for ways to introduce AI across the organisation, businesses are increasingly expected to deliver more with fewer specialist resources. This has often meant:
  • leaner content teams, with content production folded into the scopes of product managers and designers
  • AI is used to generate content quickly without direct support from a content specialist. 
It is with this shift towards content production by non-specialists that the need for content systems becomes especially clear. 
  Course: AI Prompt Engineering for Content Creators

Learn how to embed and scale AI 

Get the skills and insights to create repeatable prompts and embed AI into your everyday content workflow. From building a reusable prompt library to evaluating AI outputs, you'll leave with practical tools you can use straight away.

Our 6-hour, online course is designed for any digital content creator.
In the long run, it can also form the foundation of a living content ecosystem that guides and educates teams while evolving alongside the organisation. As such, a robust system can act as a guardrail for non-specialists creating content, helping to elevate and standardise the quality of what is produced.

Here are 5 key pillars I explored while building systems for my team, which you can consider when building your own content governance system.

"A well-structured content system can serve as a bulwark against brand erosion while a company transitions."
— Mark Chapman.

1. Start with evaluation, not generation.

Building something that generates content may seem straightforward in concept, but understanding why you’re building a system is the first step. For instance:

  • What constitutes quality? 
  • What types of risk need to be considered?
  • Which factors are non-negotiable?
  • Which factors can be flexible depending on context?

Spoiler alert: there's no single score or factor for quality.

When I began experimenting with building a governance system, one of the first observations was that a single score or factor could not represent quality. A templated “No network connectivity” message might be considered low-risk when displayed on a standalone screen that asks a user to try again later. 

Place that same message in the middle of a transaction flow, however, and it becomes more critical.

Context changes the consequences of the content and, therefore, the standards against which it should be evaluated.

Evaluation criteria is key

A tone issue might warrant refinement, while a compliance issue could prevent content from progressing altogether. As such, it is important to understand what matters most in a given situation and how those considerations should influence the final recommendation.

Once the evaluation criteria are established, many architectural decisions become simpler.

Workflows, scoring models, mitigation logic, and review processes can be designed around a clearly defined understanding of quality rather than subjective interpretation.

2. Building a source of truth

Many organisations already possess what is required to create quality content. The problem is that this information often exists in formats that are difficult to operationalise.
Content style guides may sit forgotten in a folder.
Brand principles may be embedded in a design system.
Product terminology
may be stored in spreadsheets.
Compliance guidance may live in a stack of
policy documents.
While people can become familiar with this fragmented system, machines struggle when knowledge is spread across multiple repositories.

Before getting into orchestration layers and frameworks, it is necessary to establish a reliable, holistic source of truth. In practice, this often means transforming these fragmented rules into structured datasets by reducing them to their simplest principles.

For instance, if you have a rule that says "This content has to be easy to read", break it down into a set of questions that can be answered with a simple yes or no, such as, "Are there any technical words in this sentence?"

By breaking information into its smallest meaningful components, systems can reference, maintain, and update individual pieces of knowledge without requiring the entire framework to be rewritten.

When building these rules, you can start with simple spreadsheets, as they enforce clarity. Each sentence must stand alone and be clear, while: 
  • information can be organised consistently
  • relationships can be defined
  • updates are easier to manage.

3. Understand the boundaries of your system. 

With the evaluation criteria and knowledge structure set, the next consideration would be the input method. If the collection layer introduces incomplete data, stale context, or inconsistent formatting, even the most sophisticated evaluation framework can produce unreliable outcomes. 

Is content being collected through:
  • an MCP
  • an API integration
  • a custom-built workflow?
The answer often determines both the complexity of the solution and the safeguards that need to be introduced.

When building these systems, I found it useful to think beyond the content system and examine the plumbing around it.

For instance:
  • Connecting your system to a design tool through an MCP might be immediately convenient.
  • However, larger files may create a bottleneck, and contextual design elements may be missed if the system is not designed to account for them.
  • On the other hand, including everything creates another problem.
  • The more complex the collection layer becomes, the more guardrails need to be set.
Understanding these limitations early often has a greater impact on system reliability than trying to fix them after the content structure has been built.

4. Architecture should follow the problem.

This is often where discussions become dominated by buzzwords such as:
  • agents
  • orchestration frameworks
  • memory systems
  • specialised reasoning layers.
While useful, these concepts should be treated as options to be picked apart and selected, as different content problems suit different architectures.

While building the orchestration for my system, I found that some activities benefited from sequential processing while others worked better in parallel. For instance:
  • Checking content against a style guide and glossary is likely best handled through a linear process that passes work between stages.
  • Adding complexity, such as creating two agents to run both checks simultaneously, may sound ideal, but would add little practical value and could, in fact, increase token costs.
In contrast, if every content check needed to end with a report in a fixed format, a parallel system may be more useful. One agent could prepare the HTML report structure while another checks the content and logs the necessary findings, allowing the results to be added once both stages are complete, rather than handling each task one after the other. 

Ultimately, the strongest systems come from understanding the problem first. And borrowing principles to solve that problem tends to yield stronger outcomes than borrowing wholesale methodologies. 

5. Good enough is more valuable than perfect.

Lastly, building a content system also requires a shift in mindset.


Traditional content processes often involve content designers refining every piece of content to a high standard. 

This works when content volume is manageable and specialist reviewers are involved throughout the process.

But as non-content specialists get involved in the content writing process, this becomes increasingly difficult to maintain.
"The focus must shift from perfecting every flow to recognising that not every issue carries the same level of risk."
— Mark Chapman.

Embedding AI decison-making

A product campaign may allow for tonal variation, such as shifting from formal to more upbeat, without affecting the core message. However, language that creates ambiguity or could be perceived as making a false promise would present a compliance issue, regardless of tone.

Systems that treat all issues equally create unnecessary review work because they fail to distinguish between imperfect content and content that could negatively impact a user’s experience.

Good principles of governance systems

One principle that should influence a governance system is that recommendations should support decision-making rather than enforce perfection.

The objective would not be to determine whether content is flawless, but whether it:
  • is ready to proceed 
  • requires intervention
  • poses sufficient risk to warrant further review.
This would allow reviewers to spend less time debating low-risk issues and more time focusing on situations where judgment genuinely matters.

Content designers could shift away from granular reviews and become more involved in:

  • shaping standards 
  • resolving edge cases
  • improving the system’s reasoning layer.
This would create a more sustainable approach to maintaining quality at scale.

What's next?

Building content systems often looks markedly different from traditional content design work.

The focus shifts from refining individual pieces of content to:

  • shaping the evaluation models
  • knowledge structures
  • the orchestration logic behind them.
Yet many of the underlying skills remain familiar. Information architecture, taxonomy design, content standards, and structured thinking become even more important when applied to machine-assisted workflows.

As organisations continue to explore AI, the role of content designers may not be to produce more content, but to move upstream and design the systems that determine how content is created, evaluated, and iterated upon.

Through clear governance systems, we have an opportunity to do something many content designers have dreamed of doing: shift from improving content one piece at a time to influencing the system that produces it, and demonstrating the importance of content design on a larger scale.

Create your own content-at-scale system

Let us help you:
  • improve content quality and consistency
  • reduce delivery time
  • automate repetitive, low-risk tasks
  • free up time for creative and complex work
  • surface content issues before they reach customers
  • empower everyone to write a good first draft.
Mark Chapman
Author bio
Mark Chapman is a UX Strategist and Conversation Designer.

In recent years, Mark has turned his focus toward the ethical impact of AI on conversational design. He explores how generative technology intersects with content strategy.
Created with