AI Content at Scale Tends Toward the Average. Here Is Why, and What to Do About It.

Something broke in how most organisations are thinking about AI content. The framing that keeps circulating is a human vs. AI binary: use AI for production speed, use humans for authenticity, keep the "crown jewels" away from the machines. It is a clean narrative. It is also missing the actual problem.

The actual problem is not where the humans are in the loop. It is what the humans put into the system before the AI starts generating. The teams producing generic, interchangeable AI content are not generating too much. They are not using the wrong model. They have not automated too aggressively. They have built pipelines that receive generic inputs and are surprised to get generic outputs.

This post is about how that failure maps to concrete architectural decisions in Google ADK, and what it looks like to build a content system that does not have this problem. We will get specific about skill file structure, signal encoding in references/, and model routing with Gemini 3, because the abstraction level of most conversations about this is too high to act on.

Language models are statistical amplifiers. Given a rich, specific, opinionated input, they produce rich, specific, opinionated output. Given a generic input, they produce a synthesis of the training distribution adjacent to that input, which in 2026 is an enormous corpus of enterprise marketing content that has converged toward a very small vocabulary of safe, interchangeable expressions.

This is not a flaw. It is exactly what the model is supposed to do. The model cannot differentiate your output from your competitors' output if your input does not differentiate your position from your competitors' position.

The practical implication: the return on improving your input signal is higher than the return on upgrading your model. We have seen teams get dramatically better output by rewriting their skill instruction structure than by switching between frontier models. The question is not whether the model is good enough. It is whether the model has enough to work with.

Most teams answer the signal problem by putting everything in the system prompt. Brand guidelines, audience descriptions, tone notes, output constraints. One large block of context at session initialisation.

This fails for two reasons.

First, the system prompt is static within a session. A content pipeline processing multiple campaigns, audiences, and formats in a single session cannot differentiate signal per task through a fixed session-level instruction. Every task gets the same base context. Everything drifts toward the same output.

Second, signal in the system prompt competes with everything else that accumulates in the context window. In a long-running multi-agent session, the specific owned claims that were meant to ground the output gradually become background noise diluted by conversation history, tool outputs, and intermediate results. The model is still following instructions, but the instructions are being crowded out.

The right architecture treats signal injection as a skill-level operation, not a session-level configuration. ADK's Skills feature exists precisely to solve this.

In ADK, a Skill is a self-contained unit of functionality loaded on demand by an agent. It is distinct from a tool (a callable Python function). A Skill is a file-based knowledge and instruction package organised into three levels. This incremental loading model is the structural property that makes Skills the right place to encode signal.

The three levels load progressively:

• •L1 (metadata): The frontmatter of SKILL.md. Name and description only. Loaded at agent startup for skill discovery. Negligible context cost.
• •L2 (instructions): The body of SKILL.md. The primary instructions the agent follows when this skill activates. Loaded when the skill triggers.
• •L3 (resources): Everything in references/ and assets/. Detailed signal documents, templates, schemas. Loaded on demand as the skill needs them during execution.

Your brand_signal.md does not occupy context window space during tasks that do not require it. Your audience.md does not load during a compliance check. The signal is available when needed and absent when it is not. This is why Skills are architecturally superior to system prompts for signal encoding: the loading is scoped to the task.

Before going into the skill structure, it is worth being precise about what "signal" means and what it does not mean.

Signal is specific, falsifiable, differentiated claims. Signal is: we deployed a multi-agent compliance system in an NDMO-classified data environment in Saudi Arabia. We reduced false positive escalations by 62%. Our co-founder built NLP systems for cancer genomics AI at Cambridge. These are not interchangeable with your competitors' claims.

Signal is not brand voice guidelines. "Bold, innovative, human-centric" is not signal. It is aspiration described with adjectives. The model cannot use it to make any real output decision because it cannot distinguish your adjectives from the identical adjectives your competitors use.

The test: if you can swap your company name with a direct competitor and the claim still reads true, it is not signal. It is category description. Category description produces category-average output.

The SKILL.md file is the L2 layer. It is the instruction the agent loads when it decides to use this skill. The quality of what you write here, and the specificity of what it asks the agent to load from references/, determines output quality.

Here is what a SKILL.md for a campaign brief generator looks like when signal architecture is taken seriously:

The references/ directory is where your brand signal lives as structured markdown documents. These are not exported brand guidelines PDFs. They are documents written for AI consumption: structured, specific, testable.

A brand_signal.md that works looks different from one that does not.

Does not work: A brand voice document that says "We are bold, innovative, and human-centric. We speak plainly and avoid jargon. We lead with outcomes." The model cannot use any of this to make a real output decision.

Works:

Two things are worth calling out. The checksum concept is directly practical: it is a short string that encodes your positioning at maximum compression. If you take all your marketing content and ask a language model to summarise who you are in 20 words, and those words do not match your checksum, your signal is failing somewhere in the generation layer. The checksum is a testable standard, not a branding aspiration.

The anti-vocabulary list matters as much as the vocabulary list. Most brand documents tell the model what to say. A document that also tells the model what not to say, and implicitly why (because it appears in every competitor's content), produces substantially more differentiated output. The model has a direction to move away from as well as toward.

With the skill directories built, loading them into an ADK agent is straightforward:

The model routing question is separate from skill loading. Different tasks have genuinely different requirements, and treating model selection as a system-level decision is expensive, slow, and produces inconsistent quality. In ADK, each agent has its own model parameter.

A note on gemini-3-flash-preview: Gemini 3 Flash replaces 2.5 Flash as the default production model for speed-optimised tasks. Its tool use and reasoning performance at Flash latency is substantially better than its predecessor. For agentic pipelines where the bottleneck is generation throughput rather than reasoning depth, it is the right choice. For reasoning-heavy orchestration tasks like brief generation, gemini-3.1-pro-preview is the current recommended model following the deprecation of Gemini 3 Pro Preview in March 2026.

The most important structural decision is enforcing that the brief runs before content generation. In ADK, this is done through the orchestrator agent's instruction layer.

The instruction is doing something specific: it makes the brief mandatory, not optional. The operator cannot skip it. The compliance check is not advisory. This structural enforcement is what separates a content system that maintains signal quality over time from one that degrades as operators find shortcuts.

There is a practical test worth running on any content pipeline before declaring it production-ready. Take a representative sample of output, feed it to three different language models, and ask each one the same question: based solely on this content, what does this company do, what specific claims does it make, and how is it different from competitors in its category?

If the answers are specific and consistent, the signal is working. The brand checksum is surviving generation. The owned claims are present. The anti-vocabulary is absent. The system is doing what it is supposed to do.

If the answers are generic, or if different models produce incompatible descriptions of the same brand, the signal is failing. The owned claims are not making it through the generation layer. The brief is not grounding the output tightly enough. The references/ documents need more specificity.

This test is not a one-time diagnostic. Run it on a sample of output every few weeks. Brand drift in AI content systems is gradual and hard to notice from inside the system. The output continues to look fine. It just stops meaning anything.

A content system with strong signal architecture produces output that, when you strip the logo and the formatting, reads as something a specific organisation would say. Not something any organisation in the category could say.

The work that produces this is upstream of the model and unglamorous relative to the speed of generation. Writing a brand_signal.md with owned claims that have evidence behind them, not adjectives describing aspiration. Writing a campaign_brief skill that enforces proof point quality before a single piece of content is generated. Keeping a single brand_signal.md as a shared reference across the brief generator, content generator, and compliance check skills, so there is one source of truth and no drift between them.

ADK's skill structure makes this work concrete and maintainable. The SKILL.md is the instruction layer. The references/ directory is the signal library. The incremental loading model means signal documents occupy context window space only when the task requires them.

When these layers are built with discipline, the model has something to amplify. When they are not, it amplifies the median of everything it has seen before.

The models are not the constraint. The skill files are.

Bayseian builds AI-native content and marketing systems for enterprise clients across the UK, GCC, and Asia. We specialise in multi-agent architectures on Google Cloud and Vertex AI.

If you are building an AI content pipeline and want to talk about signal architecture, reach out.