How to set up a Brand Kit in AirOps to guide content creation

Most teams treat the Brand Kit like a nicer prompt field. Then they wonder why the workflow still drifts.

That is the whole mistake.

An AirOps Brand Kit is useful because it gives your workflows a centralized rules and context layer for voice, products, audiences, content types, and regions. It is not useful because it magically turns a weak content system into a reliable one.

That distinction matters more than it sounds. If you use the Brand Kit as a dumping ground for everything vaguely important, the workflow gets muddy. If you use it as a control layer above clean retrieval, structured inputs, and review logic, it becomes one of the most practical ways to keep outputs consistent across repeated runs.

AirOps' own docs are pretty clear on this. Brand Kits are portable, centrally managed context objects, and workflows can consume them through variables and a hierarchical writing-rules system. The platform also lets you pair that with Knowledge Bases, metadata filtering, and workflow inputs. That gives you enough surface area to do this well.

If you have already read What belongs in an AI knowledge base for marketing teams, Context strategy, and Why most AI content systems fail, this article is the AirOps implementation layer. The question is not "can we store brand guidance somewhere?" The question is "how do we make Brand Kits actually guide content creation without confusing rules, evidence, and source truth?"

What should an AirOps Brand Kit actually control?

It should control behavior, not replace evidence

This is the cleanest mental model.

The Brand Kit should answer questions like:

• How should the workflow sound?
• Which audience is this for?
• Which product line is relevant?
• Which content type rules apply?
• Which CTA pattern should be used?

That is behavior.

It should not be the primary place where the workflow goes to verify a sensitive product claim, fetch the latest pricing nuance, or retrieve a detailed internal process doc. Those belong in the retrieval layer, usually through Knowledge Base Search or Get Knowledge Base File.

If you confuse those layers, the workflow starts treating tone as truth. That is when you get extremely confident copy that sounds right while saying something slightly wrong.

The Brand Kit is strongest when the workflow already has shape

AirOps' Using Brand Kits page shows the mechanics clearly: a workflow can accept Brand Kit inputs for product lines, content type, region, and audience, then expose variables like {{brand_kit.writing_rules}}, {{brand_kit.content_type.cta}}, and {{brand_kit.product_lines[0].differentiators}}.

That is powerful because the context is explicit at runtime. The workflow does not have to infer who it is writing for or which rules to use.

But a Brand Kit works best when the surrounding workflow already has:

• A typed intake.
• A retrieval plan.
• A review step.
• Publish checks.

Otherwise it becomes a very sophisticated bandage on an unstructured process.

This is the same larger point behind What is a Content OS?. The operating layer matters more than any single feature surface. A Brand Kit is one component of that operating layer, not the whole thing.

Centralized rules are valuable because updates propagate

One of the genuinely strong parts of the AirOps implementation is centralized change. The Brand Kit docs note that linked workflows inherit updates automatically. That matters because drift usually starts when five different prompts each carry a slightly different version of the same instructions.

Once rules live centrally, you can update:

• Preferred phrasing.
• Product differentiators.
• Audience-specific language.
• CTA patterns.
• Regional nuance.

And let multiple workflows inherit the new version without manually opening each flow and playing prompt janitor.

That is not glamorous. It is operationally excellent.

What should go in the Brand Kit, and what should stay elsewhere?

Foundations should hold the rules that almost always apply

AirOps structures Brand Kits into Foundations, Product Lines, Content Types, Audiences, and Regions. Start by putting the global rules in Foundations:

• Brand name and domain.
• Short "about" context.
• Voice and tone summary.
• Author persona.
• Global writing rules.

Foundations are where you put the rules you would otherwise repeat in every workflow prompt. If a rule should apply to nearly everything, it belongs here.

For Deadwater, that would include ideas like:

• Prefer direct, system-first language.
• Avoid generic SaaS filler.
• Keep headings in sentence case.
• Use practical CTAs.
• Do not overclaim autonomy.

These are durable operating rules. They deserve a central home.

Product Lines should hold differentiated offer context

This is where a lot of teams underbuild.

If you offer more than one service, product, market segment, or implementation path, Product Lines are the place to separate those realities. AirOps exposes variables for product details, differentiators, ideal customer, and competitors. That means your workflow can write differently when the content is about a workflow build versus a full operating-system install.

That matters because "the brand" is often too broad to guide useful writing. Readers buy from the specific offer, not the abstract company.

For Deadwater, Product Lines should reflect the real offer structure from the internal brief:

• Workflow build.
• Content OS install.
• Ongoing support.

That lets the workflow reference the right package logic without flattening everything into one mushy promise.

Content Types, Audiences, and Regions should hold overrides, not duplicates

AirOps uses a hierarchical rules system where Region rules override Audience and Content Type rules, which override Global rules. That is a good system if you use it cleanly.

Bad version:

• Repeat the same rules in every dimension.
• Stuff giant blocks of duplicated guidance into each section.
• Create contradictions everywhere.

Better version:

• Put the always-true rules in Foundations.
• Add content-type-specific structure, samples, and CTA logic in Content Types.
• Add audience-specific framing and objections in Audiences.
• Add localization or regulatory nuance in Regions only when needed.

That keeps the override model legible.

For example:

foundations:
  writing_rules:
    - Use direct, analytical language.
    - Avoid generic AI hype.
    - Keep headings in sentence case.

content_type:
  blog_post:
    writing_rules:
      - Open with a sharp hook.
      - Use 3-5 H2 sections.
      - End with a practical CTA.

audience:
  growth_lead:
    writing_rules:
      - Emphasize workflow reliability and throughput.
      - Speak to process pain, not just content quality.

That is a much better setup than five overlapping instruction blobs.

How should the Brand Kit connect to the rest of the workflow?

Add Brand Kit input early and keep it explicit

AirOps recommends adding a Brand Kit input so the workflow can access the selected product line, content type, audience, and region. Do that early.

Do not bury brand context in the middle of an LLM step and hope the model infers the rest.

The reason is simple: early explicit context improves every downstream stage:

• Topic interpretation.
• Outline shape.
• Retrieval filters.
• CTA selection.
• Review criteria.

If the workflow knows up front that it is writing a top-of-funnel blog post for a growth operator about the workflow-build offer, it can make better decisions than if it only receives "write about content operations" and a vague brand paragraph.

Pair the Brand Kit with filtered retrieval

This is where teams usually get the biggest improvement.

The Brand Kit gives you runtime context. Knowledge Base Metadata gives you scoped retrieval. Together, they let the workflow pull the right supporting material instead of everything remotely adjacent.

For example, if the Brand Kit input says:

• Product line: Workflow build.
• Content type: Blog post.
• Audience: SEO lead.
• Region: United States.

Then your knowledge-base filters can search only documents tagged for that product, audience, or region. AirOps explicitly supports metadata-based filtering in Knowledge Base steps, including dynamic filters based on workflow inputs. That means the retrieval layer can stay narrow and relevant.

That is how you avoid the classic failure mode where the workflow receives perfect brand rules and then pulls irrelevant source material anyway.

Keep examples and source truth in the right layer

Content-type samples in the Brand Kit are useful. AirOps supports template outlines, samples, CTA text, and content-type-specific rules. Use those.

But do not let samples become your only source of truth.

The Brand Kit should guide:

• Format.
• Voice.
• Audience fit.
• CTA behavior.

The retrieval layer should support:

• Current product facts.
• Internal link targets.
• Supporting evidence.
• Claims that need verification.

That split is why Living docs for agents and Markdown knowledge systems matter. The workflow behaves better when guidance and evidence are both maintained, but kept distinct.

How do you test whether the Brand Kit is actually guiding content creation?

Run contrast tests, not just one happy-path draft

A lot of teams create the Brand Kit, generate one decent article, and declare victory.

That proves almost nothing.

You want contrast tests:

• Same prompt, different audience.
• Same topic, different content type.
• Same article type, different product line.
• Same workflow, different region.

If the workflow really is using the Brand Kit correctly, those outputs should change in sensible ways. The angle should shift. The examples should shift. The CTA should shift. The framing should shift.

If nothing meaningful changes, your Brand Kit probably exists, but is not actually steering the workflow.

Look for the three common failure modes

The repeated failure modes are boring and predictable:

1. The Brand Kit is too generic.
2. The Brand Kit duplicates everything from the prompts.
3. The Brand Kit is doing work that belongs in retrieval.

Symptoms look like this:

• Outputs are technically on brand but still shallow.
• Different audiences receive basically the same article.
• Product-specific posts flatten into general company copy.
• Factual errors survive because the workflow relied on style context instead of source truth.

Google's guidance on helpful, reliable, people-first content is useful here, because it keeps forcing the right question: does the content actually provide substantial value and trustworthy information? Brand consistency matters, but it is not enough on its own.

Treat the Brand Kit as a living operating asset

This is the right final frame.

The Brand Kit is not a setup chore you finish once. It is part of the operating system. As your offer changes, your audience sharpens, your content types diversify, or your review standards improve, the Brand Kit should change too.

That is where the compounding value comes from:

• New workflows start cleaner.
• Old workflows inherit better rules.
• Editors spend less time fixing the same tone and messaging mistakes.
• Content quality becomes more consistent across different runs and formats.

That is the real win. Not "the AI sounds more like us." The real win is that your workflows stop improvising the basics every time they run.

If you want help designing the larger system around Brand Kits, explore Content OS. Deadwater builds workflow and content-system infrastructure that connects brand rules, retrieval, QA, and publishing into one reliable operating layer.