How to Use AI for Oil and Gas

If you work in upstream oil and gas - as an operator, an analyst, an engineer, an investor, or an advisor - you spend your week doing analytical work that is well-defined, technically demanding, and structurally inefficient. The reservoir engineering is rigorous. The economic modelling is rigorous. The field development planning is rigorous. What surrounds all of it - the data assembly, the cross-system reconciliation, the iteration between technical and financial workflows, the production of reports that summarise what the underlying systems already know - is not rigorous. It is just expensive.

The industry has spent the last decade building digital infrastructure aimed at solving this. Most of it has not worked the way it was supposed to. Asset managers still struggle to get a current view of their fields. Reservoir engineers still build their decline curves in OFM and rebuild them in Excel. Reserves auditors still spend three quarters of their time on documentation rather than analysis. Investment committees still see numbers that are months stale by the time they make decisions.

What is now changing is not another wave of digital transformation. It is the arrival of an analytical layer - built on modern language models combined with deterministic engineering and financial engines - that sits on top of the existing technical stack and collapses the cost of asking analytical questions to nearly zero. This article walks through, in detail, what that means across the workflows that upstream actually runs.

A typical multi-asset E&P with operations across two or three basins has, at any given moment:

• Production data flowing in real time from SCADA into a historian (PI, Cygnet, Inductive Automation, FactoryTalk). Hourly readings of oil rate, gas rate, water cut, tubing pressure, casing pressure, choke setting, and a dozen other parameters per well, going back as far as the wells have been monitored.
• Well files, one per well, sitting in some combination of a document management system, a network drive, and the original drilling contractor's archive. Mud logs, wireline logs, MWD/LWD data, completion reports, perforation records, workover histories, production tests, build-up tests.
• A reservoir model in Petrel with multiple realisations, a simulation grid in Eclipse or CMG, and a history match that was last updated when the previous reservoir engineer was still in the role.
• Production forecasts in OFM, ARIES, PHDWin or Mosaic. Decline curves on every well, type curves by area, type wells by completion vintage. The numbers in the corporate reserves model do not always reconcile to the numbers in the asset team's working forecast.
• A reserves database that gets updated annually for SEC reporting and supplemented quarterly for internal review. The reserves engineer has a separate model for the year-end audit and a different model for the JV partners.
• Field development plans built in a combination of reservoir simulation, surface network modelling (in PIPESIM, Olga, GAP), and a capital cost build-up that lives in someone's spreadsheet. The drilling schedule is in a Primavera or MS Project file. The rig contract terms are in a PDF.
• A corporate financial model in Excel that takes the production forecast as an input, applies the price deck, the operating cost structure, the tax regime, the royalty structure, the JOA terms, and produces an NPV. The model was built in 2019, has been edited by three different analysts, and contains hard-coded numbers in places nobody fully remembers.
• Marketing data covering crude differentials, gas pricing nodes, NGL realisations, transportation deals, hedging positions. This is in a different system from production. The system the marketing team uses to track realisations does not always agree with the system finance uses to book revenue.
• Operational data on facilities - separator performance, compressor uptime, flare volumes, water handling, ESP failures. Sometimes integrated with the production historian, sometimes not. Almost never integrated with the reservoir model, even though reservoir behaviour is what drives the facility design.
• ESG and emissions data in another system entirely, because the sustainability function got set up that way. Methane intensity. Flaring. Spills. Water sourcing and disposal. Each tracked by a different team on a different cadence.
• Land and contracts data - leases, units, royalties, JOAs, transportation agreements, processing agreements, gas balancing - typically in a specialised system like Quorum or Enertia, not connected to anything technical.

Now ask a question that crosses these systems. "Our production guidance for the year assumed an exit rate of X. We are tracking below that. How much of the gap is well productivity decline, how much is downtime, how much is takeaway constraints, and what does the gap mean for our coverage of the hedge book and our compliance with the borrowing base?" That is a question with an answer in the data. To produce the answer with current workflows, you need a production engineer to pull the rate variance, a reservoir engineer to assess decline behaviour, a facilities engineer to look at downtime, a marketing person to look at takeaway, a treasury analyst to look at hedge coverage, and a finance person to look at the borrowing base implications. By the time the answer is produced and reconciled, the question is two weeks old.

This is the structural reality of upstream analytical work. The technical disciplines are rigorous in isolation. The integration between them is held together by people running spreadsheets and sending each other emails. That integration layer is where AI is now landing.

There are roughly thirteen analytical workflows that consume the bulk of upstream analytical time. AI changes the economics of each. Below I work through them in detail - what the current workflow looks like, where AI lands, what the after state actually feels like, and what the magnitude of the change is.

Current state: every producing well in a portfolio needs a forecast. The forecast is built by a reservoir or production engineer using software like OFM, ARIES, PHDWin or Mosaic. They look at the production history, judge which decline regime the well is in (transient flow, boundary-dominated flow, terminal decline), select a curve method (Arps hyperbolic, exponential, harmonic, modified hyperbolic with a terminal exponential, power-law exponential, stretched exponential, the Duong method for unconventionals), fit it, apply engineering judgement to the b factor and the terminal decline, and produce an EUR estimate.

This is procedural for the bulk of wells. The engineering judgement matters at the boundaries - wells with anomalous behaviour, wells where the regime is changing, wells where the data quality is poor - but for most wells in most portfolios, the curve fit is mechanical.

Most operators and most acquiring funds do this once a year for the formal reserves process and once a quarter for management reporting. The workflow is too time-consuming to do more often. Which means a well that has been deviating from its forecast for the last six weeks is invisible to the analytical layer until the next quarterly review.

What AI does: it runs the curve fit continuously, across multiple methods simultaneously, and surfaces the cases that require engineering judgement. For a 500-well portfolio, the platform fits Arps hyperbolic, modified hyperbolic, exponential, and Duong (for unconventional wells) automatically. It generates P10/P50/P90 forecasts with proper uncertainty quantification. It identifies wells where the recent production data has materially diverged from the prior forecast, where the regime has shifted, where the b factor has been driven into a value that does not make physical sense. It also runs the reconciliation against the prior reserves vintage automatically - a step that is itself a substantial workflow for any reserves engineer.

What the engineer still does: makes the calls on the wells that matter. Is the deviation we are seeing on the eastern flank wells a function of pressure depletion, communication with offset development, or completion under-performance? Is the b factor of 1.4 the model is fitting on these unconventional wells defensible, or do we need to apply a terminal decline assumption earlier? Those questions are where reservoir engineering judgement belongs, and they are where the engineer's time should go. The mechanical work of fitting curves on the other 95% of the portfolio gets handled by the platform.

The compression here is structural. A workflow that took a reservoir engineer two weeks now takes them two days, and the two days are spent on the wells that actually need their attention.

Current state: SEC and SPE-PRMS reserves reporting is one of the most heavily-burdened workflows in the industry. The technical work is non-trivial - proved, probable, possible classification, supporting economic limits, evidence of producibility, definite plans for development of undrilled locations, the five-year development rule for proved undeveloped reserves. But most of the actual time goes into documentation, reconciliation against prior years, and audit support. A typical reserves audit at a mid-cap operator runs from October to March and consumes a substantial fraction of the reservoir engineering team's bandwidth.

The audit firm - Netherland Sewell, Ryder Scott, DeGolyer & MacNaughton, Cawley Gillespie - sends in a team. They request data. The internal team prepares the data. Discrepancies are identified. The internal team explains them. Reconciling notes are written. Eventually a report gets signed off and the 10-K reserves disclosure gets filed.

What AI does: the documentation, reconciliation and consistency-checking burden gets automated. The platform maintains a continuous reserves view - every well, every category, every economic assumption - and produces the audit support package on demand. Year-on-year reconciliation by category (revisions, extensions, discoveries, acquisitions, divestitures, production) is generated automatically with each underlying number traceable to the well-level forecast and the supporting production data. Inconsistencies between the technical view and the booked view are surfaced in real time rather than discovered in November when the audit team starts asking questions.

What the qualified reserves engineer still does: makes the technical and classification calls, signs off, takes professional responsibility. The audit firm still does its work. The 10-K still gets filed. None of that changes. What changes is that the team supporting the process spends their time on the technical questions, not on the documentation.

Current state: the production engineer's daily job is to know whether each well is producing what it should be, and if not, why not. In practice, this is done through morning reports, exception lists, and walking the field. It works for the obvious cases - a well goes down, an alarm fires, somebody investigates. It works less well for the subtle cases - a well that has been quietly under-performing its forecast for two months because of a partial blockage in the perforations, or a field-level water cut increase that is consistent with a coning issue rather than a sweep efficiency issue.

The reason it works less well is the same reason as elsewhere: the cross-domain analytical work that would distinguish those cases takes time, and it does not happen until the under-performance has accumulated to the point that it is impossible to ignore.

What AI does: it runs the surveillance continuously and surfaces the inflections that warrant investigation. A well whose realised gas-oil ratio is drifting away from its expected GOR profile is flagged. A field whose aggregate water production is rising faster than the reservoir model anticipated is flagged. A well whose tubing pressure has stepped down without a corresponding rate response is flagged. The flags come with an attempted attribution - likely choke change, likely artificial lift problem, likely reservoir behaviour - and the supporting data is linked.

The production engineer's day shifts from "find the problems" to "diagnose the problems the platform has surfaced." That is a different and substantially better use of expert time.

Current state: every operator and every fund wants to know the breakeven price on every well. In practice, breakevens are calculated at the type-well level for new development, and only occasionally re-run on existing wells when a major commodity move forces the question.

The reason is that well-level economics requires linking the well's production forecast to its share of capex, its operating cost structure, its specific differential to the regional pricing benchmark, the applicable royalty and tax structure, and the appropriate discount rate. Doing that for every well in a portfolio is not difficult mathematically - it is just data assembly that nobody has time for.

What AI does: maintains the well-level economic model continuously. Each well has an associated forecast, an associated capex (allocated from the program if it is a development well, sunk for an existing well), an associated operating cost stream (modelled as a function of the well's specific characteristics - ESP-lifted wells cost more to operate than naturally flowing wells, gassy wells in regions with limited takeaway have different netbacks than oily wells), and an associated revenue stream linked to the price deck and the differential structure.

When a price deck moves, every well's economics moves. When operating costs at a particular field move, every well's economics in that field moves. When a takeaway constraint changes the differential, every well affected by that takeaway changes. The team can ask, at any moment, "which wells are uneconomic at $55/bbl WTI" or "what is the marginal operating cost above which the southwestern fields stop covering their lifting cost" and have an answer with full traceability.

This is the kind of analysis that a sophisticated commodity-focused PE fund builds an entire analytics team to support. AI puts it inside the platform without the team.

Current state: development planning is the central capital allocation question in upstream. For an unconventional play, it is well spacing, lateral length, completion design, and drilling sequence. For a conventional development, it is well count, well placement, surface facility sizing, and phasing. The analytical work that supports the decision involves reservoir simulation, well performance forecasting, surface capacity modelling, and economic optimisation under multiple scenarios.

A development plan for a meaningful field development project - say, a $500M unconventional program or a $2B conventional development - typically takes six to twelve months to produce. The bulk of the time is consumed by iteration between sub-disciplines and by the manual integration of their outputs.

What AI does: it does not replace the reservoir simulation. Eclipse, INTERSECT and CMG are doing things that current ML cannot reliably reproduce - the multiphase flow physics is not something language models reason about. What AI does is sit alongside the simulator. It manages the case generation and the sensitivity matrix. It runs the surface network modelling and the economic evaluation off the back of each simulation case. It maintains the master view of the development scenarios - well count, sequencing, capex profile, production profile, NPV, breakeven - and lets the planning team run revisions in hours rather than weeks.

For an unconventional program, where the simulation work is lighter and the economic optimisation is heavier, the change is more dramatic. Optimal spacing as a function of commodity price. Optimal completion size as a function of in-basin service costs. Optimal drilling sequence under different rig availability and capital pacing constraints. All of these become things you query rather than things you commission.

Current state: an upstream M&A data room contains anywhere from 500 to 5,000 documents. Reserves reports, well files, production data, geological studies, financial models, JOAs, transportation agreements, environmental assessments, abandonment cost estimates, title summaries, hedge positions, ad valorem tax data. Even the screening question - "is this asset worth a serious bid" - takes a deal team a couple of weeks to answer.

For a competitive process with a 30-45 day first-round window, that means the analytical depth on each opportunity is necessarily shallow. Funds and operators look at many deals and bid seriously on a few. The selection of which to bid on is itself based on incomplete information.

What AI does: it reads the data room. Within hours, you have a structured view of the asset - well count, current production by stream, reserves by category, identified development inventory, operating cost structure, hedge book, contractual arrangements, identified risks. You have a draft valuation under your house price deck. You have a list of items that should be in the data room but are not, with an assessment of which gaps are material.

The deal team starts the actual investment work - the questions of whether the asset is mispriced, what the operating upside is, what the integration looks like, where the value-creation thesis is - from a synthesised baseline rather than from a stack of PDFs. The team can run their analytical work on three opportunities in the time it currently takes to do one. Over a 24-month window in an active deal environment, this changes how much capital gets deployed and at what quality.

Current state: most independent E&Ps are financed in part through reserves-based loans. The borrowing base gets re-determined twice a year. The redetermination is run by the bank's engineering team, working off the operator's reserves data. The exercise is heavy on documentation and reconciliation.

In between redeterminations, the operator has to maintain its own view of the borrowing base - what the value of the proved reserves is at the bank's price deck, what the implied availability is, where the headroom is, what the implications are for hedging and for capital plans.

What AI does: maintains the borrowing base view continuously. The bank's price deck is loaded. The reserves are run against that deck. The implied advance rate is calculated. The headroom is updated as production comes in and as the price deck adjusts. When a price move is large enough that the borrowing base is at risk of being constrained, the treasury team sees it in real time, not at the next redetermination.

For a leveraged independent, this is genuinely material. The cost of being caught short on a borrowing base - forced asset sales, distressed amendments, equity raises at bad prices - is large enough that having a continuous view is worth real money.

Current state: the treasury or marketing team manages the hedge book. They know the position. What they often do not have, in any timely way, is a clear view of how the hedge book is performing against the underlying production it is supposed to protect. Hedge effectiveness assessment, rolling exposure, the right next trade - all of these depend on a current view of expected production by month, by stream, by location, that is reconciled to the financial model.

That reconciliation is currently done manually, on a cadence of weeks, and is often out of date by the time it informs a hedging decision.

What AI does: maintains the linkage between the production forecast, the realised pricing structure, the hedge book and the corporate financial plan. The treasury team can see, at any moment, what the next dollar of hedging does to the risk profile. They can see the actual versus the planned cash flow under multiple scenarios. They can run the optimisation that selects the hedges that minimise variance in distributable cash flow subject to a headroom constraint on the borrowing base.

This is workflow that exists at the supermajors with full risk management infrastructure. It does not exist at most independents because the data layer cannot support it. AI changes that.

Current state: lifting cost per BOE, cash margin per BOE, all-in cost per BOE - these are the headline numbers in every quarterly report. Decomposing them into the structural drivers is what every operator says they want to do and what most struggle to do well. Power costs, chemicals, water handling, contract labour, salt water disposal, well services, transportation, processing, gathering, gas treating, royalty, severance tax. Each is a separate line in a separate ledger.

A good cost analysis answers questions like: "our LOE per BOE went from $9.50 to $11.20 over the last year, what is the structural driver, and how much of it is recoverable through operational change versus structural in our cost base." That analysis takes a finance team weeks to produce well, which is why it usually does not get produced well.

What AI does: maintains the structural cost decomposition continuously. Every cost element is mapped to its driver - water handling cost moves with water cut, power cost moves with consumption and tariff, transportation cost moves with volume and contracted commitments. The variance against plan, against prior year, against peer benchmarks, is decomposed automatically. The asset manager and the CFO see the same view, in the same numbers, with the same underlying logic.

Current state: every producing well in the world has an eventual plug and abandonment cost. For mature operators, the aggregate liability is large and the timing is uncertain. The accounting estimate is updated periodically. The actual cost when the well goes off depends on local service costs, the well's specific characteristics, and the regulatory regime.

Most operators do not have a current view of their P&A liability at the well level. They have a corporate accrual that gets updated annually. When an asset gets sold, the P&A liability becomes a major component of the negotiation, and the analysis to support the position is built bespoke each time.

What AI does: maintains the well-level P&A view. Each well has an associated abandonment cost estimate based on its characteristics, the relevant regulatory regime, and the current service cost environment. Aggregating to asset and corporate levels is automatic. When a divestment is being considered, the P&A position is already in the right form to support the negotiation.

Current state: regulatory and investor pressure on emissions has produced a substantial reporting burden. Methane intensity per unit of production. Scope 1, 2 and 3 inventories. Flaring volumes. Water sourcing. Each is reported separately. Most operators struggle to link their emissions performance back to operational decisions in any way that supports either better operations or better disclosure.

What AI does: connects the emissions data to the operational data. Methane intensity becomes a calculated function of fugitive monitoring, flare metering, and production volume. Flaring becomes a function of takeaway constraints and facility operations. Water sourcing becomes a function of completion design and source water availability. Asset-level decisions - whether to invest in a vapour recovery unit, whether to reduce flaring through additional gas processing capacity, whether to switch a particular field to recycled produced water - get evaluated with a current view of the financial and emissions implications of each.

For operators in jurisdictions with methane fees or emissions-linked finance covenants, this is not a soft issue. It is a direct cost and a direct constraint on capital availability.

Current state: in any meaningful upstream operation, somebody else owns part of the asset. The JOA governs the relationship. The non-operating partners have approval rights, audit rights, dispute rights, and reporting rights. Producing the partner reports - monthly production, AFE updates, capex tracking, well-level data - is itself a substantial workflow at any operator that runs a large non-op book.

What AI does: produces the partner reporting from the underlying data continuously, in the format the JOA requires, with the audit trail to support each number. AFEs get tracked against actuals well by well. Cost overruns get flagged before they escalate to a partner dispute. Disputes that do arise get supported with cleaner data than the manual process produces.

Current state: a public E&P has to disclose material events, has to publish quarterly results, has to provide guidance, and has to maintain a current narrative on its operations and outlook. The IR function is heavy on data-gathering - pulling numbers from operations, from finance, from reserves, into a coherent story for the market. A typical earnings preparation cycle runs three weeks of intensive work for a relatively short presentation.

What AI does: maintains the data layer that feeds investor reporting in a current state. The IR team starts from a synthesised, current view of every metric the market wants to see - production by stream, well count, capex, lifting cost, realised pricing, hedge position, reserves, debt - and spends their time on the narrative rather than on the assembly. Earnings preparation that took three weeks takes four days.

The change in upstream is the same in shape as the change in mining, but the magnitudes are larger because the data volume is larger and the decision cadence is faster. Once the data layer is connected and the analytical layer above it is working, the operating tempo of the asset team and the corporate functions shifts.

Reserves and forecasting move from annual cycles to continuous views. The corporate forecast that drives guidance is the same forecast the asset team uses for daily operations. The reserves report that gets filed with the SEC is the same view the bank uses to set the borrowing base. The reconciliations between these views, which currently consume substantial team time, mostly disappear because the views are constructed from the same underlying data.

Capital allocation tightens. Field development decisions get re-evaluated when the inputs to them change, not on the calendar. The Tuesday morning question "should we drop a rig given the price action" has an answer with the analytical depth behind it, rather than a guess that gets formalised three weeks later.

M&A response times improve. The team that can read a data room, value an asset, identify the risks, and make a credible bid in a week will systematically out-position the team that takes a month. In an active deal environment, this is the largest source of structural advantage available to a fund or an operator.

Operational decisions tighten. Surveillance happens continuously rather than in morning meetings. Variance analysis happens continuously rather than at month-end. The asset team's working week shifts toward the technical questions and away from data assembly.

The technical disciplines stay human. Reservoir engineers still do reservoir engineering. Reserves engineers still take professional responsibility for the booked numbers. Drilling engineers still design wells. Facilities engineers still design facilities. None of that changes - it cannot, both for engineering and regulatory reasons. What changes is the ratio of analytical time to assembly time, and the cadence of analytical work to the cadence of the underlying business.

What I have described is not assembled from a stack of cloud services and a few language models. It is a connected data layer, a set of modular analytical engines for the specific workflows upstream actually runs, and an interface that lets the people who need answers get them without going through a five-person workflow first. Building all of that is a multi-year effort, and operators that try to do it in-house run into the problem that the existing data layer is the thing that needs replacing.

This is what we built Honeycomb for. The platform ingests upstream data - production history, well files, reservoir studies, technical reports, financial models, contracts, operational data - into a unified knowledge graph. It maintains a queryable digital twin of every asset, every field, every well. The modular analytical engines cover the workflows above: decline curve analysis across multiple methods with proper uncertainty quantification, EUR estimation, reserves classification support, production reconciliation, well-level economics, field development scenario modelling, M&A due diligence acceleration, portfolio optimisation, hedge effectiveness analysis, P&A liability tracking, emissions linkage, partner reporting. All outputs are traceable to source. The interface is natural language.

The architecture is the same one we built for mining, because the structural problem is the same - fragmented technical and operational data, analytical workflows that depend on cross-domain reconciliation, decisions that depend on synthesis. The specific analytical engines are different because upstream is a different industry, but the foundation is shared.

The operators using Honeycomb are not buying it because it is novel. They are buying it because the alternative - continuing to run the upstream analytical stack the way it has been run for fifteen years - is no longer competitive. The teams whose analytical cadence matches their data cadence will outperform the teams whose analytical cadence matches their reporting cycle. The window for getting on the right side of that gap is open now.

If you are running upstream assets, financing them, advising on them, or investing in them, the first thing to do is not to commission a digital strategy review. It is to take a single workflow you currently run more slowly than you should, and run it through the platform.

Some workflows that produce immediate, measurable results:

• A field-level production reconciliation. Pull the last six months of data, run it through the platform, and see how many wells are deviating from forecast in a way that warrants attention.
• A target asset's data room. Take an opportunity that came in last week and is sitting on someone's desk waiting for a free moment. Run it through, get the synthesised view, and see what the cycle time looks like compared to the manual process.
• A development scenario set. Pick an undeveloped block in your portfolio. Run the scenarios you would normally commission a study to produce and see how many you can run, how fast, and at what level of analytical depth.
• A reserves reconciliation. Run last year's booked reserves against this year's well-level forecasts and see how the reconciliation falls out before the audit team starts asking.

Free trial at honeycomb.sirca.io. Upload a single asset, run a workflow you currently run, and decide for yourself whether the cycle time looks the same. The point is not to be sold a platform - the point is to see what your existing workflow looks like with the synthesis layer solved. That is the only test that actually matters, and it is the test the operators ahead of the curve are already running.