The Growth Repo: How to Give Every AI the Same Company Memory

Why does your AI forget your business every Monday?

Monday, nine in the morning. Someone on your team opens an AI chat and asks for ten posts about your product.

The AI has never heard of you. It does not know which post booked calls last month. It does not know the objection sales heard four times last week.

So it writes ten average posts. Your colleague keeps one. Next Monday, it starts from zero again.

The model is fine. The memory is missing.

A growth repo fixes that. It is one home for everything your company has learned about selling, kept as plain text files that every AI tool and every person reads before they work.

Chats forget when you close them. Files do not.

The method fits in four moves. Sort files by where they are going. Put your settings in first.

Give every file an owner, a date and a reason. Then check what changed every Friday.

Most AI advice is about better prompts. Our take: a prompt that has to explain your whole company every time is a symptom, not a skill.

What is a growth repo, and why does a marketing engineer build it first?

A growth repo is a shared library of plain text files that describes your market, voice, offers, settings and results. Repo is short for repository: a folder that can keep every version of its files.

Clever? Not even a little. It is notes, kept in one place, in a format any tool can open.

The format is the whole trick. Files written in Markdown, the headings-and-bullets style you already type in chat apps, open in every editor and every AI tool. Switch tools next year and the memory comes with you.

The idea is older than AI. Gary Lilien and Arvind Rangaswamy coined the term marketing engineering for managers who decide with data, models and judgment together.

In their textbook, they pictured companies keeping a library of models in the data warehouse. Any manager could then ask why a promotion paid off in one city and flopped in another.

Today's marketing engineer goes one step further. They build the library, and the agents that read it. That is why the repo comes first in the marketing engineer's job.

Every agent you build later is only as good as what it can read. An agent with no memory is a stranger with a keyboard.

Sort every file by where it is going, not where it came from

The usual mistake is sorting by source. You get a folder for call notes, one for survey exports, one for old decks.

It looks tidy. It helps nobody launch anything.

Tiago Forte argues the opposite in Building a Second Brain: organize notes by the outcome they will help you reach. He calls his setup a production system, not a filing system.

His placement rule is four questions, asked in order. We use it for every new file in a growth repo.

In a repo, a project is anything with an end date and a result: a launch, a campaign, a site rebuild. A standing job never ends, but it has a standard to keep: customer truth, founder voice, the offer, outbound, experiments.

Reference is everything else worth keeping: competitor notes, swipe files, research. The archive is finished work.

Keep it three levels deep at most: top folder, sub-folder, file. Three levels is enough for thousands of notes.

When a project ends, move its whole folder to the archive. When a new one starts, search the archive first.

Why bother? Because last year's launch brief already holds half of the next one. A folder called Misc is where good work goes to die.

Put the settings in first, then the words

Here is a finding most marketers have never heard. The Accelerate research team studied more than 23,000 survey responses from software teams.

Keeping settings under version control was linked to fast, stable delivery. That link was stronger than for keeping the code there. In their data, the old belief that settings matter less than code did not hold up.

That is software, not marketing. Our reading: the same thing happens in ad accounts and funnels.

Your copy is visible. Your settings are not. Think tracking events, link naming rules, automation steps, audience definitions and the prompts your agents run.

Change one quietly and nobody can say what broke. Engineers call this configuration drift: two setups that should match slowly stop matching.

A settings file with a dated history ends that argument in one screen. Without it, you get three people and three memories.

So the first files in our repos are not essays. They are the dull ones: the event list, the naming rules, the live prompts.

Dull files save launches.

Give every file a front page: owner, date and reason

Every file in a growth repo starts with the same four lines. Who owns it, when it was last checked, where its facts came from, and why it exists.

The last line is the one people skip. Big mistake. It is the one that matters most.

Andy Grove, who ran Intel, made the point in High Output Management. A procedure is worth the real thinking behind it, not its wording. So keep questioning it, even after it becomes the standard.

A rule without its reason gets obeyed forever or deleted in a panic. Neither ends well.

One owner per file. Not a committee.

Anyone can suggest a change; the owner decides. Treat each file like a garden you tend, not a gate you guard.

The experiment log gets more fields, one line per test. Record the owner, start date, days run, the one change, the hypothesis, the result, and the decision with its reason.

That reason turns a list of tests into a memory. It is also why testing one variable at a time pays off twice: once in the test, and again a year later when someone asks why.

Corrections get the same treatment. When someone fixes an agent's work, the fix becomes a dated rule with its reason, and the agent's job spec points to it.

Record the work, then file it. Do not write the manual

Most company wikis die the same way. Someone spends a week writing perfect instructions. Nobody opens them.

Mike Michalowicz tells this one on himself in Clockwork. He spent four hours writing a fifteen-step shipping procedure for used books, pictures included. His intern came back with questions within minutes.

Then the postal service and Amazon changed their websites, and every picture went stale. He switched to recording himself doing the job instead. Now whoever does the task records a new version when the process changes.

How to build a wiki nobody opens, in four easy steps. Step one: write every procedure from memory, in one sitting.

Step two: cover every exception you can imagine. Step three: add screenshots of tools that redesign every quarter.

Step four: announce it in a meeting and never touch it again. Congratulations, you built a damn expensive tombstone.

David Jenyns saw it happen at agency scale in SYSTEMology. A Google Ads agency owner wrote hundreds of procedures and pinned the index to his office wall. It bombed: staff could not follow it, and digital marketing changed too fast to keep it current.

So we capture. We do not write.

Record the screen while the person who does the task best talks through it. Turn the transcript into a short file in the repo.

Short means short. If a file needs its own table of contents, it is two files.

Then test it like a stranger would. If finding a file takes more than a minute, the folder is broken, not the person.

Where should a growth repo live: a shared folder or version control?

Start with whatever your team will actually open. A shared drive folder is fine for the first month.

Jenyns would push you toward a dedicated systems tool instead of a drive. His reason holds: knowledge stored everywhere is stored nowhere.

Our call differs on one point. For a library that people and AI tools both read, plain text files beat any single vendor's app, because every AI tool can read a text file.

Move to version control when either of two things is true. More than one person edits the files, or an automation writes to them on a schedule.

Git, the most common version control system, saves a snapshot of every file each time you commit. To commit is to save a named change, and the free Pro Git book explains it in plain words.

Keep changes small and merge them the same day. A branch is a side copy where a change waits. In the Accelerate data, the strongest software teams merged theirs within a day.

Our marketing version of that rule: no draft sits on the side for weeks. Edit, check, merge, done.

The repo holds how a task is done. Your task tool holds who does it and when. Link the file inside the task, so done means done the way the file says.

Two things never go in. Passwords and keys live in a separate file the repo is told to ignore, and raw customer records stay outside it, as our guide to customer data and AI explains.

The Weekly Diff: one Friday check that keeps the repo alive

A repo nobody updates is worse than no repo. It hands every agent last quarter's truth with full confidence.

The Weekly Diff is our Friday check. A diff is the list of changes between two versions of a file.

Open the list of what changed this week. In version control, that is the commit list. In a plain folder, it is the files sorted by date.

Count three kinds of change only: a new customer quote with its source, a test result written into the log, and a rule added after someone fixed an agent's work.

One or more means the company learned something. None means the marketing ran and the memory did not move.

Is one empty week a problem? No. Two in a row means nobody owns the repo, so name an owner before you add another file.

The whole check takes about fifteen minutes. Read the changes, write one line about what the team learned, and pick the stalest file to fix first next week.

That one line feeds the growth cockpit, the Monday memo that decides what to test next. The new quotes come from the customer truth system.

Run it with AI

The prompt below plans your first growth repo. Paste it into your preferred AI and answer six questions.

It returns a folder tree, five day-one files with their front pages, the settings to version first, and your Friday check. It never invents facts about your business. If a fact is missing, it writes TODO and asks.

Tool file names change. The box below lists the current ones, so the method can stay the same.

This week: first, run the prompt. Second, create the five day-one files and put one owner on each. Third, put the Weekly Diff on Friday's calendar.

Want to see the same pattern running a whole agency? Read how we run an agency as marketing engineers.

Want the career path that starts here? Read how to become a marketing engineer in 30 days.

Prefer to have it built inside your company? That is the work in our marketing engineering engagements.

A chat is a conversation. A repo is a memory. Build the memory, and Monday stops starting from zero.