The turnover tax: how marketing agencies keep what their people know

This is a composite, put together from what agency owners have told us. A senior account lead resigns after six years on the same client. She knows the client's head of marketing hates exclamation marks, which product shot legal sent back twice and why, and the competitor the brand never names. Almost none of it is written down. And since last year she keeps something new: a chat history with an AI assistant, tuned over hundreds of prompts to sound like that client. She leaves on a Friday. On Monday the account has a new lead, and everything she knew left with her, chat history included.

Call it the turnover tax: the share of what an agency knows that walks out with each person who leaves. Agencies have always paid it, because people move between agencies and senior judgement lives in senior heads. We've written about turning what's in your team's heads into a base. Below: what AI did to the tax, two rules that lower it, our own records, and a one-unit pilot.

What sharpened it is how AI arrived. When a team adopts AI one person at a time, each person builds a private context: their prompts, their corrections, their way of getting the tool to sound right for a client. The agency ends up with as many private memories as it has people, and owns none of them. The tax rises with adoption.

What established agencies say they have

On September 30 we read the websites of 14 established agencies, six in Brazil and eight across the US, the UK and global networks. Seven say nothing about how they use AI in their own work. Two present AI as a capability or a creative output. One talks about codifying its expertise. Four describe an agency-wide AI system, and two of those say it holds a brand's rules: one network promises agents that "learn your brand, goals and guardrails."

So part of the market already claims a system that holds the rules a client hands over on day one. None of the 14 describes the part that decides how much the turnover tax costs: the record of what each client rejected and why, kept after the people on the account change. That record is the memory layer.

Why adding tools leaves the tax where it is

In a Y Combinator talk on building AI-native services companies, the speakers warn founders against buying a legacy services firm and putting AI on top. The warning is aimed at buyers, and it holds from the inside too: "They have different expectations on metrics, hiring, and performance. Adding AI on top of that doesn't immediately change any of those realities."

Those three are management. An agency lowers its turnover tax by changing two management rules about who owns what the team learns.

The first rule: nobody rejects work without writing why. That covers the client sending a post back, and it covers the inside of the agency, when an account lead returns a designer's piece. A rejection with a reason is a lesson the company can keep. Without the reason, the lesson lives in two heads, and one of them may resign.

The second rule: the AI context belongs to the account. When a prompt works for a client, the client-specific part goes into that account's file, where the next person on the account finds it on day one. The reusable method behind it goes into the instructions library the whole agency draws from.

What our own records show

We run this model on Leanboat's Tour Studio for about 110 tour companies, a little over 2,000 published posts in September. Tour companies use an approval page to approve a post or send it back. They're small businesses, so the comparison with an agency's enterprise clients holds for the approve-and-reject loop and stops there. Two findings from that loop changed how we think about the memory layer.

First, capture can be solved by design. The approval page won't accept a rejection without a written reason. Since mid-July, 180 rejections came through it, and all 180 carry one. One company asked us not to feature dolphin watching, because that activity needs a license it doesn't hold. No style guide would have caught that, and the client wrote it in one sentence at the moment of saying no.

Second, knowledge still leaked inside our own system. Turning reasons into rules mostly works: in September the system wrote 58 standing rules from client corrections, across 23 accounts. On September 14 the system wrote up a client's correction, stop mentioning a landmark that had been dropped from the tour, and the save failed. The cause was a bug we already knew about: a fix had been written at the start of September and was waiting for review. It sat unmerged for about four weeks, and the failure went into a log nobody read.

We've merged the fix, restored the rule it dropped, and added a check that flags any rule that fails to save.

In the memory layer post we wrote that the reason is the part a team skips under a deadline. Our records correct that: the reason arrives when the tool requires it. The step to watch is the next one, turning a reason into one of the client's locked rules, the standing instructions the AI applies to every future piece for that client.

That step is the Friday pass we described in what an AI-native agency ships: the AI proposes rule edits from the week's corrections, and a person approves them. The same post named its first failure mode, no write-back, and our lost rule was a quiet version of it. So the pass needs a count of its own. Sort each reason as a one-off or a lasting rule, send each proposed rule to a senior person for approval, with the open questions in that person's queue, and treat a second rejection for the same reason as the alarm that a rule is missing.

Start with one unit: content production

Julien Bek of Sequoia drew the line for companies buying AI-native services: "Replacing an outsourcing contract with an AI-native services provider is a vendor swap. Replacing headcount is a reorg." The same holds for an agency changing itself, so an owner can start smaller. Pick one unit, run it on the new model for a cycle, and let the results decide the next unit.

Content production is the unit we would pick first, end to end: the brief, the organic posts and the pieces for paid campaigns. It's high impact because it runs on approve-and-reject decisions every week, so the memory layer gets its raw material from the first cycle, and a rule learned on an organic post also governs the paid version of the same message. It's low risk, because in the pilot nothing is published until a person approves it. A weak draft ends as a rejection before anyone outside the agency sees it.

A first cycle looks like this:

• One client brand and the creators on one of its campaigns, around ten connected accounts.
• A one-page brief with tone, strategy and campaign context. The system turns it into a brand profile for each account.
• The system researches, plans and writes, and tests each piece against the brief.
• The team approves or rejects every piece, with a reason.
• Approved organic posts go out, and the strongest become paid creatives.
• At the end of the cycle, the agency decides whether to extend to more brands, more creators or another unit.

To start, an agency needs five things:

1. The theme of the first cycle: one campaign or one brand, with dates.
2. A shared folder with the campaign and event material.
3. The names of who approves, at the agency and at the client.
4. The current monthly volume of posts per account.
5. One person at the agency who owns the project.

Then read one number every week, from the first week: how many rejection reasons became locked rules, and whether each one actually saved. If that number reads zero two weeks running, check the save before you check the team.

If you run an agency and want to try this on one unit, send us those five items and we'll set up the first cycle with you.