The AI Context Problem

You can't engineer context, you never made explicit. Yes, context engineering has an assumption problem. The framework is sound, but if you want AI to perform reliably inside your org, you have to design the information environment it operates in—what it knows, what it doesn't, how it learns.

But that only works if your org already knows what it knows and why. Most don't. Not in any consistently documented, transferable form.

What most orgs actually run on is institutional memory. Judgment held by specific people, transmitted informally, never written down because it never needed to be:

• The senior manager who knows which client relationships are fragile

• The program lead who understands why a particular approval process exists

• The analyst who knows the three exceptions that aren't in the policy document

That knowledge runs the business. It just doesn't exist in a database where the AI can find it.

I've seen this surface most sharply in two moments—onboarding and transformation.

1. Onboarding is often the only time institutional knowledge gets translated into something explicit, because a new person needs it written down.

   
   

2. Transformation reveals it when a redesign breaks something nobody documented, and no one can explain why it existed.

AI implementation is now triggering the same revelation at scale.

You can build the most sophisticated context engineering architecture available. If the operating logic of your business was never made explicit, what you end up with is a system confidently running on the documented layer while the real knowledge stays locked in people's heads.

The fix is treating knowledge externalization as a design discipline. Deciding what needs to be made explicit, who owns it, and how it stays current as the business evolves.

That work has to happen before context engineering. Not alongside it.