Your writer uses one assistant, your founder uses another, and an agent drafts the rest overnight. Each one was told about your brand by a different person, from memory, in a different week. The output is inconsistent for a boring reason: the tools are not reading the same thing, because there is no same thing to read.
Free first build, no credit card. See what your tools currently think your brand is.
Keep one current source of brand context and connect every tool to it, rather than pasting a version of the brand into each one. Write positioning, audience, voice, messaging and proof as structured documents, give each tool a pointer to that source in the form it reads, and re-point the tools instead of re-briefing them when the brand changes.
The five steps below are the runnable version. They take an afternoon for a small team, and the order matters more than the speed: every step after the first is worthless without it.
Positioning, audience, voice, messaging, proof and the relationships between your offers, as connected documents rather than one long file. A person reads the section they need; a tool retrieves the section it needs. A narrative brand book cannot do either, which is why handing a PDF to a model produces a summary of the PDF rather than work in your voice. If you have nothing written today, this is the whole project and the rest is configuration. That is what a brand knowledge base is for.
This is the step teams skip, and it is the one that decides the outcome. The moment your positioning lives in a project file, a custom instruction block and a shared doc, you have three brands that agree today and will not agree in a month. Copies do not drift because people are careless. They drift because only one of them gets updated when you change your mind.
A project file in one assistant, a connector in another, a share link for the freelancer who uses neither, an export for whatever your team adopts next quarter. Different pointers, one source. The section below walks each of those formats, and the test of a good setup is that adding a sixth tool is a configuration task rather than a writing task.
When output is off, the instinct is to edit the sentence. Editing the sentence buys you one sentence. Editing the document the tool read buys you every future draft produced against it, in every tool, by every person. That single habit is the difference between a brand that converges and a brand that needs policing.
Shared context makes output consistent by construction, but construction is not proof. Read what actually shipped against what the source says, monthly, and treat a gap as a signal that either the source is stale or a tool is not connected to it. Both are cheap to fix in the month they appear and expensive to fix a year later.
Because each one was briefed separately. A model holds no memory of your company between sessions, so whatever context it has came from a person typing it that day. Different people remember different things, the same person remembers differently in March and in September, and none of those versions is written down anywhere the others can see.
Your writer opens an assistant, types two sentences about who you serve, and gets a draft. Your founder opens a different assistant and types three different sentences. Both drafts are internally coherent. Together they describe two companies, and the reader who sees both is the buyer.
The brand paragraph in someone's account settings is invisible to everyone else and survives no personnel change. It is the most common brand context in existence and the least durable: nobody else can read it, nobody else can update it, and it leaves when they do.
A shared prompt library helps with format and tone and does nothing about facts. It cannot tell a tool that you renamed an offer in June, that the audience narrowed, or that a claim you used to make is no longer one you are willing to defend. Those are content problems, and they need a content source.
Four pieces a month with a slight wobble is a rounding error. Forty pieces a month with the same wobble is what your market now believes about you. Speed does not cause the inconsistency; it publishes it. That compounding is what brand drift names, and it arrives faster with every tool you add.
Review is a correction, not a cure, and it stops working the moment production outruns reading. The only control that scales with output volume is the one applied before the draft exists, which is why this whole page is about the input rather than the edit.
The general form of this problem, across people as well as tools, is covered in why brand inconsistency happens and how to fix it.
The steps that ensure brand consistency across AI-driven platforms are: write the brand as structured documents rather than a narrative PDF, keep one current version rather than a copy per tool, connect each platform to that version in the form it reads, and verify the published output against the source on a schedule.
Notice what is absent from that list. There is no approval workflow, no style checklist, no rule about which tool the team is allowed to use. Those are all attempts to control the output, and output control is exactly what breaks when the number of producers grows. A shared input scales the other way: the tenth tool is no harder to keep consistent than the second, because consistency is a property of what they all read rather than of how carefully each one is watched.
The practical test takes a minute. Ask two people on your team to produce the same short piece in the two different tools they normally use, without talking to each other first. If the two drafts make the same promise to the same buyer, your context is shared. If they do not, no amount of prompt tuning will close the gap, because the gap is not in the prompts.
This is also the reason the fix is upstream rather than editorial. You cannot review your way to consistency across platforms that produce faster than you can read, and you cannot train your way there either, because the tools change every few months. You can only give them the same starting point, and let consistency come from the system rather than the document.
Put a single CLAUDE.md at the root of the repository or folder your team works in, keep it to one or two screens of load-bearing brand facts, and have it point at the longer documents rather than restating them. Give one person ownership, review it on a schedule, and treat a wrong line in it as a bug rather than a documentation chore.
A CLAUDE.md is read automatically at the start of a session in the directory it sits in. That is the entire mechanism, and it is why the file is useful: nobody has to remember to attach it. For a content marketing team, put it wherever the work lives, whether that is a content repository, a shared folder or the project directory your writers open. One file per working context, not one per person.
The failure mode is a file that grows into a brand book. Every line you add dilutes the lines that matter, and a model reading four screens of context weights your positioning statement the same as a note about which font to use in decks. One or two screens, holding only the facts that change what gets written. Everything longer lives in the documents this file points at.
The moment your voice guide exists both in the file and in your knowledge base, you own two voice guides. Write the pointer instead: name the document, say where it lives, and let the tool retrieve the current version. This is what keeps one file per tool from becoming one brand per tool, and it is the same principle behind every other connector on this page.
An unowned file is a file that is right on the day it is written and wrong within two quarters, which is precisely the life cycle of the brand guideline PDF it was supposed to replace. Name the person, put the review on a calendar, and update the file in the same motion as any positioning or offer change. Five minutes at the moment of the decision, rather than an archaeology project later.
Keeping the file under version control turns brand changes into reviewable events. Someone tightened the audience definition, and there is a line-by-line record of when and why. That history is worth more than it sounds: most brand arguments are really arguments about a change nobody recorded. The step-by-step version of this setup, for a marketer who has never opened a repository, is the CLAUDE.md setup guide.
Positioning in one sentence, who the work is for and who it is not for, voice written as sentences you would and would not publish, the canonical names of your offers, the claims you are allowed to make, the links and CTAs that are correct today, and a pointer to the fuller knowledge base.
What you do, for whom, and why you rather than the obvious alternative. If it takes a paragraph, the tool will produce a paragraph of hedging. If you cannot write it, that is a strategy gap and no file will paper over it.
Exclusions do more work than inclusions. A model told your reader is a marketing lead at a ten-person company, and explicitly not an enterprise CMO, stops producing the enterprise register that creeps into everything by default.
Professional, approachable and bold describe your entire category and constrain nothing. Two sentences you would publish and two you would not, with the reason, constrain a great deal. Contrast is the only form of voice guidance a model can act on.
One name per thing, spelled one way, with the retired names listed as retired. Product-name sprawl is the most common factual inconsistency in AI-produced marketing, and it is the cheapest one to prevent.
Numbers you can support, comparisons you are willing to defend, and the specific things nobody should assert on your behalf. This is the section that keeps a confident model from inventing a statistic in your name.
Where you send readers, and where you no longer do. Dead internal links in generated content come from tools repeating URLs that were right a year ago, and a short list of current destinations ends that class of error entirely.
Name the documents and where they live, so the tool can retrieve the long version of audience, messaging or proof when a piece needs it. The file is the index, not the library.
This quarter's campaign, the current draft, the promotion running until Friday. Fast-moving working state belongs in the brief for that piece. Mixing it into the durable file is how the durable file becomes wrong and stops being trusted.
The separation in that last card is the one structural decision worth getting right on day one. Durable context changes on the scale of quarters and should be identical for every producer. Working state changes weekly and is specific to one piece of work. Keep them apart and both stay useful; mix them and the durable layer goes stale invisibly, which is covered at length in durable knowledge for AI.
Context engineering in marketing is the practice of deciding what an AI tool reads before it writes. Instead of improving the prompt, you improve the material the model retrieves: structured, current documents about positioning, audience, voice and proof. Prompting shapes one output. Context shapes every output produced against it.
The distinction is easiest to see in where the effort accumulates. A better prompt is a skill held by the person who wrote it, applied one session at a time, lost when they move on. A better source document is an asset the whole team and every tool inherits, and it improves the next thousand outputs without anyone doing anything differently. Both are real work. Only one of them compounds.
It also changes what a marketing team spends its time on. Under prompt-led work, the job is producing and correcting drafts, and the backlog never shrinks because each piece starts from nothing. Under context-led work, the job is deciding what is true about the brand and writing it down carefully once. Production becomes the cheap part, which is the only version of this that survives contact with a small team.
The practice has a fuller treatment in marketing context engineering, and the structural question underneath it, how a brand is organised rather than merely described, is brand architecture.
Four formats, one source. A project file for the assistant that reads files, a connector for the one that can query a system, a share link for the person who uses neither, and an export for whatever arrives next. What changes per tool is the pointer, never the content.
Claude reads a CLAUDE.md in the working directory at the start of a session. Other assistants have an equivalent: a project knowledge area, a custom instruction block scoped to a workspace rather than a person. Use the mechanism the tool provides, keep the file short, and have it point at the longer documents. The two sections above cover how to write one and what belongs in it.
The better mechanism, where a tool supports it, is retrieval rather than attachment: the assistant asks your knowledge base for the section it needs at the moment it writes, and therefore always reads the current version. This is what the Model Context Protocol standardised, and it is the difference between a tool that has a copy of your brand and a tool that has access to it. Attachment goes stale. Retrieval cannot.
Contractors, agencies and new hires do not use your tooling and should not have to. One read-only link to the current brand, handed over at the start, replaces the onboarding call where somebody explains the company from memory and the contractor takes notes that are wrong in two places.
Markdown and JSON are the portable forms. If your brand context can be exported, the next assistant your team tries is a configuration decision rather than a rewriting project, and you are never choosing between switching tools and keeping your context. Portability is what keeps this from becoming another lock-in.
Scheduled and autonomous work is where shared context stops being a nicety. An agent producing overnight has no one to ask, so whatever it reads is the whole brief. Point it at the same knowledge base your people read and the output arrives in the same voice as theirs, which is the only practical way to let anything run unattended.
Compare what you published against what your source says, on a schedule, rather than waiting to notice. Read your live pages the way a stranger would, score how clearly the brand comes through, and treat any gap as either a stale source or a disconnected tool. Both are cheap to fix early.
Start with the manual version, because it costs nothing. Open an assistant that has never seen your internal material, give it only your company name and website, and ask what the company does, who it is for, and why someone would choose it. Read the answer as a buyer rather than as the person who wrote the source material. A failed check does not look like an error; it looks like a bland but plausible description of a company in your category, which is exactly what a model produces when it finds no clear signal and falls back on the average.
The scored version of that check is the free brand audit, which reads your public pages and reports how clearly positioning, audience, differentiation and proof come through, with the evidence it can verify against your own page text. Run it before you change anything so a later dip has a baseline to be measured against.
For the ongoing version, a drift check watches the gap between your current brand and what is live, and reports what moved. The point of automating it is not the convenience. It is that drift is invisible in any single piece and obvious only in aggregate, which is precisely the comparison a person never gets around to making.
Whether your public content gives AI assistants a clear enough signal to repeat is a related but separate question, and it has its own checklist in the five-pillar readiness check and in answer engine optimization.
Brand Architect
Drop your URL and Ophelia, your always-on brand strategist, reads your site, drafts your positioning, audience, voice and messaging, and structures them into connected documents you review and approve. That becomes the one source your team, your freelancers and your AI tools all start from, reachable as a share link, a connector or an export. Your first build is free, no credit card, and it is $49/mo to keep the knowledge base current. Cancel anytime and keep everything. Runs in your browser.
Build your knowledge base freeFree first build, no credit card • You review and approve • Export to markdown and JSON
They need different pointers to the same brand, which is not the same thing. A project file, a connector and a share link are three formats for one source. The moment the content itself is duplicated per tool, the copies start diverging the first time you change your mind about anything.
It is enough for one tool and one working directory, which for a solo marketer may be the whole problem. It stops being enough the moment a second tool, a second person or a freelancer enters the picture, because none of them read that file. At that point it should become a pointer to something all of them can reach.
You can, and it works until the guidelines change. Then you have as many versions as you have tools, and no way to tell which one produced any given draft. Pasting is copying, and copies are the mechanism of drift rather than a workaround for it.
At the moment of the decision, not on a calendar. Positioning changes, an offer is renamed, an audience narrows: update the source in the same sitting. The scheduled review is a safety net for what got missed, not the primary mechanism, and a quarterly rhythm is enough for most teams.
It matters soonest for one-person teams, because a solo marketer running three assistants already has three versions of the brand and no colleague to notice the difference. The smaller the team, the more of the brand is running on memory, and memory is exactly what drifts.
Then that is the work, and it is a smaller job than it sounds. Positioning, audience, voice, messaging and proof written carefully once is a matter of days rather than a rebrand. Every connector on this page is configuration on top of that, and none of them helps without it.
Start with the audit if you want to see what your tools currently think your brand is, or build the knowledge base if you already know what the problem is.
Free first build, no credit card • You review and approve