PLB   Playbook

Most marketing teams are running AI in single-player mode. One person gets comfortable with Claude or ChatGPT, builds their own prompts and shortcuts, and gets meaningfully faster, and almost none of it transfers to the person at the next desk. Nobody should feel behind about that. This wave of AI has only recently taken the workplace by storm and it keeps changing shape. Plenty of capable operators are still working out whether what they're doing with it is actually moving the business.

What decides whether team AI becomes useful gets much less attention than the tools do: feeding the AI real context about your business, and putting that context in front of every person on the team, so the output anyone gets is specific, accurate, and yours.

We're in the middle of solving this with a few clients that have small to mid-size marketing teams. This is a report from mid-build, and what's fascinating is that one of the biggest challenges has nothing to do with AI.

One of these teams runs Claude as its general-purpose AI. When Claude originally introduced skills (stored, targeted capabilities the AI can tap into), they existed only at the individual level. If someone built a skill worth sharing, like a copywriting skill or a theme skill for producing brand materials, the Markdown file got passed around by hand and everyone loaded it into their own instance.

Then skills became something that could live at the organization level. That one product change made a private problem public. Every skill that had been passed around now had to be reconciled. Nobody knew exactly how many people had a given skill installed, whether they'd adjusted their own copies, or how much use each version was actually getting. Like a game of telephone, the versions had drifted, and it was interesting to see what each had evolved into. All of it had to be pulled back into one cohesive skill for the whole team, rooted in the brand and built to a standard.

There was no crisis, just a product update that exposed how many versions of "how we do things" were quietly running in parallel. The fix would need to be a living capture system, and one that wouldn't care which AI tool it fed, because the tools themselves clearly weren't going to hold still.

The divergence ran deeper than the skills feature. On the same team, people were at completely different levels of the same technology. Some worked in Claude in the browser and went months without downloading the desktop app. Some were more comfortable using a free ChatGPT window with no account and no context to prompt their way through a work task. Others were power users producing branded decks that put the company's best foot forward. The diversity of use cases all led to the same results: inconsistency and team discombobulation.

That gap is not an individual competence problem, and treating it like one is unfair. Good leadership teams push their people to learn new technology, and the better ones put real budget behind it. Even with that support, competent adoption takes time. It always has. This wave is harder than most because of its pace: the technology keeps evolving while everyone is still absorbing the last version of it. So push the team to learn. But learning is the staff's half of the deal. Putting AI to work in ways that serve the business, like building the knowledge system underneath it, is where leaders have to lead. It isn't fair to ask an email marketer, a designer, or an acquisition manager to comprehend the full context of the business well enough to prompt it into an AI. The individual was never the right unit. Deciding what the AI should understand about the company, and what it should not understand at all, is a leadership responsibility. If you run the department, you own its knowledge architecture.

The build is less intimidating once you name what it actually is: institutional knowledge the company already maintains, moved into a format a new kind of reader can use. Companies have always stored that knowledge in a variety of ways. The file server, a shared cloud system, the SOP library: here's the sales script, here's how a sale gets designed, here's where the process is documented. Those systems were built for humans to navigate, folders a person clicks through and PDFs a person reads. While AI can technically get through that, it's far more comfortable scanning structured data, like Markdown, JSON, and skill files, with clear instructions on how to navigate each.

So that's the fix underway: a version-controlled knowledge repository that holds what the old file server held, restructured for a new reader. We've chosen to build in GitHub, focused on brand, marketing, and compliance knowledge first. The early contents:

Two properties make the repository worth the effort of architecting well. The first is coverage. Every person on the team is going to use AI more next quarter than they did last quarter, whatever the readiness picture looks like today. When the knowledge hub is built right, the tools they lean on every day follow the brand systems and carry the institutional knowledge even when a busy human doesn't, and often more reliably than a mid-fluency team member would on their own. In other words, the floor rises for everyone at once.

The second is portability. Built deliberately tool-agnostic, the hub is a brain that any number of tools can plug into. The repository doesn't care whether it feeds Claude, ChatGPT, Cursor, or whatever new platform launches next quarter, because the context layer is the one investment every model will still need. The pace of AI releases is usually the argument against investing in anything durable. Here it's the argument for the one stable layer underneath the technology.

The more interesting decisions are about what doesn't go into these knowledge repositories.

Take the way a marketing team handles its highest-value customers. Deciding who qualifies, reading their behavior across a dozen signals, and choosing which offer or gesture to extend still runs on human intuition. There are parameters, but the actual triage isn't documentable as clean rules yet, and the technology is not ready to make judgment calls of that weight. So it stayed out, deliberately. That's the test we'd hand anyone building one of these: if you can't encode your own human judgment, don't pretend the AI can solve it for you.

Volatility is the other filter. Anything that changes hourly or daily doesn't belong in the knowledge base. It needs a human-driven system instead. But the base isn't only for the permanent, either. Company name and domain are set in stone, while mission, positioning, and target audience move slowly. That middle band is the sweet spot.

And every file needs an update cadence decided up front: monthly, quarterly, annually. This is exactly where the old SOP libraries died. Nobody owned the updating, material went stale, and nobody noticed. Staleness is worse now. An org chart that hasn't kept up with turnover doesn't just sit there being wrong. The AI reads it and confidently gives the whole team false answers about who does what.

Building the repository turns out to be the straightforward half of the job. If the knowledge base stood up complete overnight, the answers coming out of the AI would be dramatically stronger overnight. The technology side is that direct. What's not direct is everything around it: collaboration, personalities, different abilities, different rates of adoption. Better tools and better plans don't always translate to better work.

Who should own each domain of the knowledge base, whether brand, compliance, sales, or voice? It depends on the company, and be wary of anyone with a universal governance framework to sell. The teams we're working with are appointing domain owners and treating each repo as a living thing. Your version will look different, and that's fine.

The honest part: we're the kind of operators who spend free time learning this, which puts us ahead of most rooms we're in. That's a disposition, and it isn't reasonable to build a plan that expects a whole department to share it. The leadership solve is unglamorous: a real learning budget, pushed regularly, with the acceptance that people will upskill at different paces. That unevenness is the sloppiness of humans, and it doesn't go away. Right now, improving staff fluency with AI is about the cheapest high-impact investment available to a good company. Companies that won't make it will pay for it.

If you run a company or a department, start before any repo and before any tool decision.

Picture handing your role off to a successor. A strong handoff would cover what the business does, who it sells to, which tools and systems the operation runs on, and who owns which decisions and work streams. That handoff is your knowledge architecture. It's the same set of fundamentals AI needs to produce quality outputs specific to your business.

Now, think about maintenance before structure: how the information gets gathered, cleaned, updated, and maintained. There's a side benefit to this step and that is that this process doubles as an audit. You will find outdated strategy docs and SOPs that needed updating anyway, so use this exercise to hone your company or team's knowledge.

Another pro tip, use the tool to build its own foundation. Tell the AI the intended outcome, which is living access to strong context about the business so it can give the whole team specific, quality output, and ask it how to architect that. Have it interview you. Point it at where the information lives. Let it reformat the PDFs and decks into structures it can navigate. GitHub holds this build. Obsidian or Notion can hold and connect the same layer. Ask the AI what fits you, and stay the course.

The tools will keep getting better on their own. The context, the team's alignment, and the knowledge hub's upkeep only improve when leadership decides they're worth owning. The toughest challenges remain the human ones.

We build these knowledge systems with marketing teams. If yours is working through the same problem, get in touch.