Organizational Context Engineering
The discipline of making an organization legible to AI.
Organizational Context Engineering is the design of how an organization's authoritative knowledge, terminology, rules, responsibilities, permissions and exceptions reach AI systems, so that the systems can be trusted in real work.
Discuss your AI initiativeWhat the model does not know
What a capable model does not know about you: which document is authoritative when two disagree, what “customer” means in your billing system and what it means in your CRM, who may approve an exception and who may only propose one, what the policy says and how experienced people actually handle it.
These facts live in your organization, spread across documents, systems and the heads of people who have been there a long time. Until they are made explicit and delivered to the AI in a form it can use, every answer is a guess that happens to be well phrased.
A better model alone frequently cannot close that gap. Closing it is design work, and that design work is the discipline.
What the discipline covers
Authoritative sources.
Which documents, systems and people have the last word, and in what order when they conflict.Terminology.
What words mean inside your organization, including the words that mean something different in every department.Rules and exceptions.
The written policy, the unwritten practice, and the cases where experienced people deliberately deviate, and why.Responsibilities and permissions.
Who decides, who approves, who may only propose, and what the AI itself may do without asking anyone.Evaluation.
How reliability is measured against your own standards, with your own cases, before the system goes live and every time something changes.Stewardship.
Named owners, and the routine that keeps all of this current as the organization changes.
A closer look, for the technically inclined
How context reaches a model
Context reaches a model through four channels: instructions, retrieval, tools and training. Instructions are what the model is told at the start of a task; quick to write and easy to break. Retrieval is what is fetched for the task at hand, documents, records, the results of tools; targeted, but only as good as the sources, the way they are cut and the way they are ranked. Tools are what the model is allowed to do, with their permissions; powerful, and in need of the tightest governance. Training, including fine-tuning, is what the model has absorbed in advance; durable, and slow to change. Most systems in production need a mix of all four, and the mix does not happen by itself.
Making knowledge available is not the same as making it usable. A four-hundred-page manual in a search index is available. Context is that manual cut into the units a task actually needs, each marked with what is authoritative, what is current and what is permitted. Cutting and indexing is routine engineering. Deciding what is authoritative, current and permitted is the organization's own work, and nobody else can do it.
Evaluation against your own standards works like this. You build a set of cases from real work, with answers your experts agree on, including the hard ones and the exceptions. You test the system against them before launch and again whenever anything changes: the model, the sources, the rules. A small set your experts stand behind is worth more than a large one nobody does. The case set has a second use: it is where disagreements between your own experts become visible, and resolving those can be worth more than the system itself.
Human judgment, by design
Where approval or accountability is required, the system routes to a person. Not only as a fallback when the AI is unsure, but as a step the organization has decided it wants. Which decisions those are, and who holds them, is itself part of the context.
Where this comes from
Ulrich Callmeier spent two decades at Acrolinx making organizations' terminology, standards and communication rules machine-readable, inside the tools where people wrote: quality gates that checked text against each enterprise's own rules, in more than thirty authoring environments. The hard problems were never the language technology alone. They were deciding whose rules counted, keeping them current, measuring against the organization's own standard, and winning the trust of the people who wrote every day.
Organizational Context Engineering is that experience applied to generative AI, where the context is no longer only language rules but everything a system needs in order to act on an organization's behalf.
We use the name for our own practice. It is not an industry standard. It is the way we work, written down.
Bring us the pilot nobody will sign off on
If an AI initiative in your organization works in the demo and not in daily use, the gap is often context. The first conversation is directly with Ulrich Callmeier.
Discuss your AI initiative