What Does Your Organisation Know?
A new engineer joins and asks why the release process has seven gates. It is a fair question, and most of the time nobody in the room can answer it properly. Someone will say it has always been that way. Someone else will half-remember an incident. The real answer is usually that gate four exists because of something that went badly wrong in 2019, and the two people who understood why have since left.
That is the thing I find genuinely interesting about organisations, and it is almost never on the balance sheet. Every successful company is an accumulation of shared human experience. Over decades, people work out what breaks, how customers actually behave, how money gets lost, how systems fail at three in the morning, and how a completely reasonable-looking architectural decision can quietly detonate eighteen months later. It is probably the most valuable asset most companies own and one of the least understood.
We turn those lessons into policies, standards, controls and processes, because humans cannot reliably carry the accumulated experience of an organisation around in their heads. A new engineer does not know why the release has seven gates. A new finance manager does not know why one particular transaction type needs two approvals. A developer does not know that the pattern they just reached for violates a control written after an incident five years before they were hired.
So we build process. A process is the organisation saying: we have already learned this lesson, and here is how we make sure you do not have to learn it again. For roughly a century that has been one of the main mechanisms by which organisations scale.
The problem is what process costs
Process introduces friction, and it introduces friction because it is designed around the limitations of people. Someone has to remember the rule. Someone has to interpret it. Someone has to check it was followed. Someone has to approve the exception, and someone has to audit the evidence afterwards, usually months later, usually by reconstructing it from Confluence pages and their own memory.
We have built entire departments around this. Compliance, risk, governance, quality, security, financial control. Not because any of that is intrinsically bureaucratic, whatever the engineering team mutters at standup, but because we needed humans to carry the rules and enforce the experience of the institution. The department is the storage mechanism.
AI changes this, though not in the way the vendors keep implying. It is not that a language model suddenly understands everything your organisation knows. It does not, and anyone selling you that should be shown the door. The opportunity is narrower and considerably more useful: we can now give machines access to that accumulated experience in a form they can act on.
That is the difference between giving a machine your information and giving it your organisational knowledge. Handing an LLM a folder of documents is the first thing. It is not the second.
Compliance is the clearest example, so let us be concrete about it
We built the AppGenie Compliance MCP for exactly this. The interesting part is not that an assistant can now look things up about ISO 9001, ISO 27001, NIST, FedRAMP or IRAP. Retrieval is the easy bit and everyone has it. The interesting part is that the rules and controls people spent decades developing become part of the environment the machine is operating in.
In practice the assistant asks a delivery question and gets back something like this:
{
"status": "allowed",
"selected_profile": "iso-9001",
"enforcement_decision": "Proceed",
"required_register_entries": [ ... ],
"required_evidence_classes": [ ... ],
"sources": [ ... ]
}
That is not a search result. It is an instruction set. It states which profile applies, whether the work may proceed, what has to be written into a register, what evidence has to exist by the end, and which controlled sources produced that answer. The developer did not have to know the control existed. They did not have to stop, open a compliance document and work out whether their implementation was acceptable. The machine knew, because someone put what the organisation knows somewhere a machine could reach it.
One point of precision, because I would rather be accurate than impressive. A service like this returns an enforcement decision. It does not physically stop anything on its own. The actual prevention is a build gate in the pipeline that refuses the merge, and that gate is the second half of the pattern. The knowledge layer decides what should be true; the pipeline makes it non-negotiable. Both halves matter, and a lot of "AI governance" products only ship the first one and hope you do not notice.
Where this gets genuinely interesting
Today we assume governance constrains innovation, and we assume it because it usually does. You want to move quickly, but you have to go through security. You want to deploy, but compliance needs a look. You want to change the architecture, but somebody has to review it. So every organisation makes the same miserable trade: move fast and carry more risk, or add controls and carry more friction.
That trade-off exists because a human has to perform the control. Change who performs it and the trade-off changes shape. The developer gets something close to complete creative freedom. The machine assisting them does not, because it is operating inside the rules the whole time. The human experiences unrestricted development while the organisation experiences continuous control, and for the first time those two things are not in direct opposition.
The machine is effectively saying: build whatever you want, experiment, try something nobody here has tried, move fast, but you are not crossing this particular line. And most of the time the human never notices the line was there at all. That is the part I keep coming back to. We have historically put controls in front of people. We are starting to put them around machines instead, and once a control is machine-readable it does not have to show up as bureaucracy in anyone's day.
Which means the process itself starts to look different
This is where the agent conversation needs to grow up. We keep discussing agents as though the point is to automate the processes humans currently perform. The more significant shift is that the reason those processes existed starts to erode. If the environment continuously understands the rules, observes what is being built and enforces the boundaries, then walking a person through a workflow purely to demonstrate that the rules were followed is ceremony. If the system can prove what happened at the time it happened, reconstructing it six months later in a meeting room is not governance, it is archaeology.
None of this eliminates governance. It relocates it. Governance moves out of the meeting and into the operating environment, which is a considerably better place for it. And the same move works well beyond compliance. How software should be designed, tested, secured and released. How financial controls apply to a transaction. What risk the business will actually tolerate on a Friday afternoon. Anywhere humans built a process to stop hard-won experience being forgotten, the same substitution is available.
The common thread is not automation. It is institutional memory becoming executable.
The intelligence is not in the model
This leads somewhere uncomfortable for anyone whose AI strategy is a procurement decision.
My own view, and I will flag it as a forecast rather than a fact, is that foundation models are heading towards commodity. The gap between the top models keeps narrowing, and the interoperability protocols increasingly let any of them reach the same classes of system. If that holds, then the model stops being the differentiator and whatever sits around it becomes the whole game.
One organisation gives its machines access to generic information. Another gives them twenty years of institutional experience: its standards, its decisions, its failures, its customers, its operating principles, its controls, its exceptions, its evidence, and its actual understanding of how the business works rather than how the org chart says it works. Those two organisations can be running precisely the same model. They will not have the same intelligence.
So the question worth asking is not which LLM you have chosen. It is not even how many agents you have deployed, which is rapidly becoming the new vanity metric, sitting somewhere alongside lines of code. It is this: what does your organisation know, and how much of that can a machine actually use?
For most organisations the honest answer today is "a great deal, and almost none of it". The knowledge exists. It is in documents nobody reads, decisions nobody recorded, and the heads of people who are one resignation away from taking it with them.
What this is actually worth
When organisational knowledge becomes machine-usable, the freedom-versus-control choice stops being quite so binary. You can give people and machines real room to build, experiment and move quickly, precisely because the accumulated experience of the organisation is embedded in the environment where the work happens rather than stapled to the front of it as an approval queue.
The rules go quiet. The expertise becomes ambient. The controls run continuously instead of in quarterly bursts. And people spend less time proving they followed the process and more time doing the thing the process was invented to protect in the first place, which was always just building something good without repeating an expensive mistake.
That is the actual prize, and it is not replacing what your organisation has learned with AI. It is taking everything the institution learned the hard way, over decades, at genuine cost, and finally making it available to every machine working inside it.
Most companies are still storing that knowledge in people who are going to leave.