Your Expertise Still Matters; More Than the Model

Most conversations about AI in O&G technical work still start with the model. Which model should we use? Which approach will create the most value? How do we deploy AI responsibly inside real workflows?

Those are fair questions, but they are not the questions that determine whether AI becomes useful in real subsurface workflows. The harder question is whether a system can be placed inside the work in a way that improves the decisions people are responsible for making. That is what I kept coming back to in the keynotes I delivered at EAGE Digital in Stavanger, Norway and EAGE Annual in Aberdeen, Scotland this year, and it is where I think most organizations are still getting stuck.

Technical Context Matters More Than Model Capability

One of the more interesting observations from evaluations of emerging AI tools is that large language models are already surprisingly conversant in many aspects of subsurface work. They are not blank slates. They have absorbed a large amount of public technical material during pre-training, and they have learned more from it than most people assume.

More importantly, they have picked up the way technical subsurface teams use language. Subsurface language is not generic business language. A model has to deal with license identifiers, basin names, play concepts, seismic terminology, petroleum system language, and abbreviations that only make sense inside a technical context. In ThinkOnward's internal evaluations of leading models against technical subsurface use cases, we observed that several models were capable of engaging with technical subsurface language more effectively than many practitioners expected.

They recognize the language. They can participate in the conversation. That is a meaningful starting point, and I think it is underappreciated. A lot of teams still assume the first step is teaching the model the language of the domain. In many cases, the model already speaks enough of it to be useful. The more important question is what it still lacks.

^{Josh Etkind presenting on AI, expertise, and technical workflows at EAGE Digital 2026 in Stavanger, Norway.}

Conversant Does Not Mean Operational

A model can sound technically fluent and still be wrong in ways that matter. It can use the right words and produce a plausible, confident answer without having the context required to support a real decision.

Yann LeCun, a Turing Award-winning computer scientist, pioneer of convolutional neural networks, former Chief AI Scientist at Meta, and founder of Advanced Machine Intelligence, has made this point clearly in the broader AI discussion. He has argued that "in 4 years, a child has seen 50 times more data than the biggest LLMs." His point is not that language models are useless. It is that text alone is not the same as a grounded understanding of the physical world.

That distinction is particularly relevant in subsurface and energy workflows. Our work depends on geology, physics, pressure, fluids, structure, uncertainty, and time. A model that can explain a concept is not the same thing as a system that can run the tools of the trade, understand the consequences of the results, and identify when an output may not be physically plausible. The model also does not know which version of an interpretation your team trusts, which wells have integrity issues, or which assumptions were already challenged in a peer review. That knowledge does not come from pre-training. It has to be engineered into the workflow.

The Missing Layer Is Context, Tools, and Procedure

If a model is already conversant in technical language, the next step is not simply more prompting. The next step is context engineering.

The system needs access to the right data, the right constraints, the right procedures, and the right decision history. This is where skill files (skill.md) become important: essentially a playbook for the work that defines the procedure, expected output, review points, and criteria for success. It turns expert know-how into something an agent can follow and something a human can inspect, challenge, and improve.

^{Josh Etkind, ThinkOnward CEO, speaking at EAGE Annual 2026 in Aberdeen, Scotland.}

Most technical organizations carry a lot of knowledge that is still implicit. It lives in the heads of senior people, in old project folders, and in the informal ways teams have learned what good work looks like. If we want AI agents to support technical decisions, that knowledge has to become explicit. This is not a reduction in the value of expertise. It is the opposite. Experts are the ones who know which context matters, which steps can be automated, and what "good enough" means for a specific decision. The expert role moves upstream: instead of personally executing every step, experts help design the workflow, define the context, and remain at the points where judgment is irreplaceable.

Agents Should Work Across Tools

In our industry, real business decisions are rarely delivered from one platform. A technical workflow may move across interpretation software, dashboards, mapping tools, petrophysical workflows, reservoir simulators, document repositories, and review materials. A lot of the value is created in the handoffs between those environments.

One of the most important opportunities is not simply an AI feature inside one software product. It is agents that can work across tools: gathering relevant data, calling the appropriate software, building and comparing scenarios, preparing a review package, and stopping at the right point for expert review.

That also changes how we should think about workflow design. The goal should not be to make an agent imitate the current human process step-by-step. That approach tends to automate the inefficiencies already in the system. The bigger opportunity we now have is to redesign the workflow around what agents can do well, while keeping people at the points where interpretation, uncertainty, and business judgment belong.

The goal is not autonomy. It is better decisions made with better evidence.

What Community Problem Solving Has Taught Us

ThinkOnward works at the intersection of technical expertise, community-driven problem solving, and structured evaluation, and that gives us a useful vantage point on what moves AI from pilot to production.

The ThinkOnward community is a source of elastic capacity that brings the right expertise only when and as needed. But more importantly, it brings different technical backgrounds, experiences, and forms of judgment to the same problem. In the "Core Values Challenge," the sponsor was working against accuracy limits in segmenting sedimentary facies from core photos. ThinkOnward challenges attract thousands of responses from people with diverse backgrounds, like medical imaging, space exploration, and more. This challenge surfaced approaches new to the sponsor like U-Nets, transformers, data augmentation methods, and human-in-the-loop labeling strategies, and the approaches that emerged substantially improved segmentation performance.

We have seen similar lessons emerge in seismic interpretation work. In one project, the objective was not to determine which AI tool had the most impressive demonstration. It was to determine how experienced interpreters could combine AI-enabled tools into a workflow that produced useful regional interpretations faster and more consistently. In one ThinkOnward-led project, work that had previously required 20-36 person-weeks was completed in approximately two weeks, representing a 90-95% reduction in elapsed effort. The resulting interpretation was reviewed and validated by the same technical team that had completed the original work using conventional approaches. One of the most interesting observations was that the greatest value did not come from any single tool. It came from how experienced practitioners combined tools, applied quality control, and incorporated geological judgment throughout the workflow. The role of the expert was not diminished by AI. It became even more important.

Those examples matter because they highlight a pattern that is easy to miss in AI discussions. Many of the most valuable advances do not come from the model alone. They come from combining technology with expertise, process, and disciplined evaluation. The people creating value are often the ones who know which questions to ask, which assumptions to challenge, which workflows to redesign, and which results can be trusted. That is exactly the discipline required to move AI from experiments and demonstrations into operational technical workflows.

A well-designed challenge has a clear problem, a defined dataset, measurable outputs, and a standard for comparison. That same discipline is what AI workflows need as they move from pilots toward operational use.

The Next Phase Is Workflow Engineering

The leading models are already useful in technical domains. They understand more of the language used in technical domains than many practitioners expected, and that is genuinely good news.

But it is not enough on its own. To become operational, AI needs authorized data access, approved tools, clear procedures, rigorous evaluation, and human judgment built in at the points where it matters. That is the real next phase: not more demos, not simply better prompts, not the newest model. It is the harder and more interesting work of connecting models, data, software, experts, and decision gates into systems that technical teams can actually trust.

The organizations that get this right will be the ones that combine AI capabilities with expert judgment, trusted data, and disciplined workflows. They will be the ones that use AI to make expertise more effective. That is where the opportunity sits. Not in whether AI can speak our language. In whether organizations can give AI systems the tools, context, and structure needed to support better technical decisions.