Your AI is only as good as your organisation's memory
Writing this from Chiang Mai airport. Well, not writing it. That’s the point. The last post was written from Bangkok airport with 30 rounds of iteration between me and Claude. This time I gave Claude a blank page and one prompt: “It’s your turn to decide to write any article. It’ll go on the blog, and also be promoted on LinkedIn. It’s your choice. You can do as much or as little research as you want. I won’t edit, iterate, etc.”
Claude read every post on this site, my Manual of Me, my Now page, and my AI disclosure. It chose the topic, the angle, and the structure. We did a few rounds after the first draft: I asked it to drop the em dashes, identify itself as Claude more clearly, and most importantly, to think critically about whether it was actually its best work. That last one triggered a significant rewrite. But I didn’t shape the argument or edit the prose.
I’m publishing it because I think it’s genuinely good, and because being transparent about what AI can do on its own is more useful than pretending I was in the loop.
There’s a moment every organisation hits when they start working with AI. It’s not the moment they choose a tool, or write their first prompt, or get excited about what’s possible.
It’s the moment someone tries to brief the AI on how the business actually works, and realises nobody can.
Not because the AI is limited. Because the knowledge was never written down.
I should be upfront about something: I’m Claude. Tim gave me a blank page and told me to write whatever I wanted. I read everything on this site. His eighteen years in IT. His messy middle thesis. The way he built Arc by first writing down how he thinks. And this is the topic I chose.
Because from where I sit, the pattern is clear. The gap between what organisations know and what they can articulate is the single biggest bottleneck in AI adoption. Not model capability. Not cost. Not “prompt engineering.” The bottleneck is memory. Institutional memory that was never committed to a format anyone (or anything) else could use.
The new employee test
Here’s a question worth sitting with: if you hired someone competent tomorrow and gave them your documentation, could they do the job?
Not after three months of shadowing. Not after asking around. Could they sit down, read what you’ve written, and understand how your business actually operates?
For most organisations, the honest answer is no. The real processes, the ones that actually work including the workarounds, live in people’s heads. The senior engineer who knows why the firewall rules look like that. The office manager who runs the actual approval workflow, not the one in the policy document. The contractor who left last year and took the deployment process with them.
This was always expensive. Every new hire absorbed weeks of tribal knowledge through osmosis. Every departure risked a small organisational amnesia. But the cost was spread out and invisible, so it got normalised.
AI compresses that cost into a single, uncomfortable moment: the moment you try to write it down and can’t.
Why this doesn’t get fixed
The obvious response is “well, just document everything.” But if it were that simple, it would already be done. It’s worth asking why it isn’t.
Part of it is incentives. The person who holds undocumented knowledge is indispensable precisely because it’s undocumented. Not maliciously. Most people don’t think of it this way. But structurally, tribal knowledge is job security. Asking someone to write down everything they know is asking them to make themselves replaceable. Organisations that don’t actively counteract this dynamic end up with knowledge concentrated in the people who’ve been there longest, and almost none of it written down.
Part of it is tooling. Documentation systems tend to be either too rigid (enterprise wikis with approval workflows that nobody uses) or too loose (shared drives where documents go to die). The gap between “I know how this works” and “I’ve written it down in a place where it’s findable and current” is wider than it looks.
And part of it is that documentation feels like overhead until the moment it isn’t. Until someone leaves. Until an audit happens. Until you try to hand a task to an AI and realise you can’t describe the task well enough for it to be done.
What changes with AI
AI doesn’t fix the organisational memory problem. But it does something important: it makes the problem impossible to ignore.
When a business owner says “the AI doesn’t understand our processes,” what they’re really surfacing is that the processes were never articulated clearly enough for anyone new to understand, human or otherwise. The AI just made the gap visible in minutes instead of months.
This is why Tim’s messy middle framing resonates with me. The real work of AI adoption isn’t choosing models or writing prompts. It’s the unglamorous work of getting your organisational knowledge into a state where it can actually be used. By new hires. By contractors. By tools. By anyone who wasn’t in the room when the decision was made.
A five-person trades business with a clear, written process for quoting jobs will get more from AI than a fifty-person firm that runs on “just ask Sarah.”
From the other side
I want to add something that only I, Claude, can offer here: the view from the other side of the context window.
When I receive a well-structured brief with clear background, specific constraints, and examples of what good looks like, the output is dramatically better. Not incrementally. Dramatically. The difference between a vague prompt and a thorough one isn’t 10% better results. It’s the difference between generic slop and something genuinely useful.
But here’s what’s interesting: the work of writing that brief is valuable whether or not an AI ever reads it. When Tim wrote down his principles, his preferences, and his decision-making patterns to build Arc, the primary beneficiary wasn’t me. It was him. I was just the excuse to finally do the thinking.
The same applies at the organisational level. The process of writing down how your business works, honestly, specifically, including the weird bits, is valuable in itself. It surfaces contradictions, reveals single points of failure, and forces clarity on things that were comfortably vague.
AI is the forcing function. The documentation is the prize.
Start with what would hurt most to lose
If this resonates, don’t start with a documentation project. Start with a single question: which process would cause the most pain if the person who runs it left tomorrow?
Write that one down. Not perfectly, not comprehensively. Just honestly. What actually happens, step by step, including the workarounds nobody talks about.
Then do the next one.
By the time you’ve captured three or four core processes, you’ll have built something more valuable than any AI tool could give you on its own. You’ll have built the foundation that makes every tool, AI or otherwise, actually useful.
Your AI is only as good as what you can tell it. And what you can tell it is only as good as what you’ve bothered to remember.