From Heroes to Systems
Somewhere in this industry there is a geoscientist who has read the same aging field for thirty years. Hand them a log from two thousand feet down and they will tell you what is happening before the data confirms it. Every company I know has someone like that, whether it is the engineer to whom the hard problems quietly get routed to, or the operator who hears a machine going wrong before the sensors do.
A lot of good businesses were built on people like that. The risk lies around them rather than with them: everything they know reaches the organization through one channel, which is their time, their inbox, and their presence in the room.
The risk
Heroes retire, get poached or move on, and when they go, they take years of pattern recognition that never needed writing down, because they were always there to answer the question themselves.
The cost is on them long before that, though. The person everyone routes questions to rarely gets an uninterrupted afternoon, struggles to take a real holiday, and spends a surprising share of the week answering the same questions again instead of working on the problems only they can solve.
A Panopto survey of about a thousand US workers found that roughly 42 percent of the knowledge people use at work is unique to them, and that people lose around 5.3 hours a week waiting on colleagues or recreating knowledge that already exists. It is a vendor survey, but the direction matches what I see.
In oil and gas the stakes are sharper. Mature basins carry decades of judgment about which anomaly in a well log is a real problem and which is noise, and that judgment is often the difference between a costly mistake and a routine decision. Most of it reaches the rest of the organization one conversation at a time. A business can be profitable and admired and still carry that constraint, with no line on the P&L for it until the day it bites.
Why writing it down rarely works
The usual reaction is to ask the expert to document everything. But decades of expertise do not compress into a manual, and the parts that matter most (the judgment calls, the exceptions, the things they would only mention if you asked exactly the right follow-up) are the parts that fit worst in a document. The manual also starts going stale the day it is finished.
The better approach is to build the system with the expert, while they are there to shape it. They decide which sources it should trust, they review what it gets wrong, and the way it reasons ends up reflecting theirs.
What the system has to do
This is exactly the point where the technical topics we write about at Fabriq stop being technical. Explainability, retrieval, traces and operations each answer part of one business question: how do we get what our best people know to everyone who needs it, without it all having to pass through their calendar?
What the expert really does comes down to knowing where things are, knowing which sources to trust, and being able to explain a conclusion when someone asks. Retrieval covers the first. Explainability and traces cover the other two.
Operations is what keeps the system reliable after the launch: keeping sources current, watching answer quality, and making sure it doesn't quietly turn its own builder into the next person everyone needs to depends on.
Explainability matters more than it sounds. People trust the expert because they can ask why and get an answer that makes sense. A system that hands back an answer without showing its work has captured the output and lost the judgment, and it is harder to challenge than the expert it learned from.
We saw what this means in practice in our work with the Norwegian Offshore Directorate. The assistant answered questions about wells, discoveries and geology from relinquishment reports, well histories and news articles, material that was public but hard to search unless you knew where to look. The Directorate's first requirement was that everything it said had to be documentable, so every answer carried references a user could click through and read. Much of the effort went into teaching it to say it had no information rather than produce something plausible, and from a risk point of view I would rank that refusal among its most valuable features. A system that knows its limits also know when a question should be addressed to an expert, which is exactly where their time should go.
Traces are what turn this into an organizational asset. An answer given in the corridor leaves with the conversation, while a system can keep the question, the sources, the reasoning and the result. That record shows where the knowledge is thin and where answers drift. The experts are the ones correcting it, and the traces show precisely where their judgment changed the answer.
Where vendors fit
There is a trap here. Organizations set out to fix an internal bottleneck and end up depending on an external one: a vendor whose system works but whose logic nobody inside understands. The bottleneck has moved outside the walls and picked up a contract on the way.
Partnering with specialists is usually the right call, since the in-house efforts I have watched often stall before reaching users. The questions to put to any vendor, including us, are whether the traces, evaluation results and configuration belong to you, whether it runs in your environment, and whether another team could pick it up if they had to.
If not, you have hired a more expensive hero.
It is also why we favor a platform with shared retrieval, tracing and access control over a collection of separate bots, each understood only by whoever built it.
The scalable version
Done well; this makes the expert more valuable. Their judgment reaches people they will never meet, like the engineer three years into a career or the team that just inherited an aging asset, and they get their time back for the hard problems they took the job to solve. A hero can mentor a handful of people over a career. A system they helped shape can carry their way of thinking to everyone who needs it, including long after they have moved on.
The test I discuss with a leadership team has two parts. The uncomfortable one: if your three most knowledgeable people left next quarter, which decisions would slow down, and which would quietly get worse? And the more useful one: if those same people could spend their week only on the problems that genuinely need them, what would they be working on, and what is stopping them today? The answers to both usually point to the same thing, and that is where AI should start.
Heroes are what make a business good. A system that carries their judgment, and that people can see inside and question, lets more of the business work the way they do.