The cautious-with-foundation vs cautious-without-foundation distinction is the most useful reframe I've seen on the AI adoption debate. Most organisations I've worked with conflate the two — and the caution gets blamed when the real failure is the idleness underneath it.
The individual equivalent of your context audit question is equally revealing. Most people using AI daily have no persistent context layer at all — they just prompt into a void and wonder why the outputs are inconsistent. The bottleneck is the same whether you're a FTSE board or a solo operator: it's not the model, it's what the model knows when it answers.
I've been writing about the individual-level version of this problem — building a personal context infrastructure without an IT department or a data governance team. Different scale, same principle.
Absolutely — I think that’s exactly the right parallel.
The same pattern exists in personal productivity. When building one’s own “intelligence operating system,” the real leverage often comes less from the model itself and more from the context layer around it: skills, voice tones, writing styles, recurring preferences, trusted sources, decision patterns, and personal workflows.
Once those elements are well trained and structured, they become portable. They can then be used flexibly across different AI models and future model developments. In that sense, the foundation is not only technical infrastructure, but also personal context infrastructure.
So yes: whether at organisational level or individual level, the key question is increasingly not just “Which model do we use?” but “What does the model know when it answers?”
"Portable" is the word I'd push on — in a good way. The context layer you're describing becomes portable precisely because it lives in files, not in the model. The moment people understand that the briefing is the asset, not the conversation, something shifts. You can move models, switch platforms, start a new session — and arrive oriented rather than blank.
The "well trained and structured" framing is interesting though. I'd gently resist the idea that this requires training in any formal sense. What it requires is deliberate architecture — deciding what the model should know, writing it down somewhere it can read, and maintaining it. That's closer to good documentation practice than model training. Most people can do it with a text file and an afternoon.
The question "what does the model know when it answers?" is the right one. I'd add a second: "who decided what it knows?" Because the answer is usually nobody — it's accumulated by accident, session by session, with no structure. The individual-level version of your context audit is just asking that question out loud for the first time.
That’s a very helpful addition — and I fully agree with the distinction.
“Training” was probably not the best word on my side. What I meant is much closer to what you describe: deliberate architecture and disciplined documentation. The value is not hidden inside the model, but in the briefing layer around it.
That is also what makes it portable. If the context lives in files, notes, instructions, examples, voice guidance, writing preferences and reusable briefing documents, then the individual is no longer locked into a single model or platform. The model becomes replaceable; the context becomes the real gold.
I especially like your second question: “Who decided what it knows?” That may be the most uncomfortable and most important part. In many organisations — and also for many individuals — the answer is still: nobody. Context accumulates by accident instead of being designed.
For organisations, this also means assigning clear responsibilities: who owns the context, who maintains it, who updates it, and who decides what should be included or removed. Without that, even the best context layer will slowly become outdated or inconsistent.
So perhaps the real maturity step is moving from accidental context to intentional context — and from unowned context to responsibly managed context.
"Accidental to intentional" is a clean formulation — and the ownership question is where most organisations will get stuck longest. That's the gap between knowing it matters and actually doing something about it.
The cautious-with-foundation vs cautious-without-foundation distinction is the most useful reframe I've seen on the AI adoption debate. Most organisations I've worked with conflate the two — and the caution gets blamed when the real failure is the idleness underneath it.
The individual equivalent of your context audit question is equally revealing. Most people using AI daily have no persistent context layer at all — they just prompt into a void and wonder why the outputs are inconsistent. The bottleneck is the same whether you're a FTSE board or a solo operator: it's not the model, it's what the model knows when it answers.
I've been writing about the individual-level version of this problem — building a personal context infrastructure without an IT department or a data governance team. Different scale, same principle.
https://timdifford.substack.com/p/how-i-turned-claude-into-a-self-briefing
Absolutely — I think that’s exactly the right parallel.
The same pattern exists in personal productivity. When building one’s own “intelligence operating system,” the real leverage often comes less from the model itself and more from the context layer around it: skills, voice tones, writing styles, recurring preferences, trusted sources, decision patterns, and personal workflows.
Once those elements are well trained and structured, they become portable. They can then be used flexibly across different AI models and future model developments. In that sense, the foundation is not only technical infrastructure, but also personal context infrastructure.
So yes: whether at organisational level or individual level, the key question is increasingly not just “Which model do we use?” but “What does the model know when it answers?”
Exciting times.
"Portable" is the word I'd push on — in a good way. The context layer you're describing becomes portable precisely because it lives in files, not in the model. The moment people understand that the briefing is the asset, not the conversation, something shifts. You can move models, switch platforms, start a new session — and arrive oriented rather than blank.
The "well trained and structured" framing is interesting though. I'd gently resist the idea that this requires training in any formal sense. What it requires is deliberate architecture — deciding what the model should know, writing it down somewhere it can read, and maintaining it. That's closer to good documentation practice than model training. Most people can do it with a text file and an afternoon.
The question "what does the model know when it answers?" is the right one. I'd add a second: "who decided what it knows?" Because the answer is usually nobody — it's accumulated by accident, session by session, with no structure. The individual-level version of your context audit is just asking that question out loud for the first time.
That’s a very helpful addition — and I fully agree with the distinction.
“Training” was probably not the best word on my side. What I meant is much closer to what you describe: deliberate architecture and disciplined documentation. The value is not hidden inside the model, but in the briefing layer around it.
That is also what makes it portable. If the context lives in files, notes, instructions, examples, voice guidance, writing preferences and reusable briefing documents, then the individual is no longer locked into a single model or platform. The model becomes replaceable; the context becomes the real gold.
I especially like your second question: “Who decided what it knows?” That may be the most uncomfortable and most important part. In many organisations — and also for many individuals — the answer is still: nobody. Context accumulates by accident instead of being designed.
For organisations, this also means assigning clear responsibilities: who owns the context, who maintains it, who updates it, and who decides what should be included or removed. Without that, even the best context layer will slowly become outdated or inconsistent.
So perhaps the real maturity step is moving from accidental context to intentional context — and from unowned context to responsibly managed context.
"Accidental to intentional" is a clean formulation — and the ownership question is where most organisations will get stuck longest. That's the gap between knowing it matters and actually doing something about it.