Closing the availability gap: what AI agents can and can't do for Permian production engineers
Most of the oil a mature Permian pad loses is not lost in the reservoir. It is lost on the days the well is not running. When I split the last twelve months of public production for 36 Delaware Basin horizontals into four causes, availability came out largest: about 165 of the 425 barrels a day those wells were short of their own decline curves. Operating issues and reservoir changes split most of the rest. Lift design was a small slice.
Availability is also the cheapest gap to close. A compressor that trips every week, a midstream curtailment nobody chased, a well that loaded up after a shutdown and never came back: none of these need a rig or a new completion. They need someone to notice, connect the evidence and get the right person to the right location. That is where an AI agent can help, as long as we are clear about what the agent is doing.
What the gap looks like on the ground
On a 300-well asset with two or three production engineers, the morning starts with SCADA alarms, a downtime spreadsheet the pumpers fill in when they can, and a stack of emails from the field. Each lost day is small. The problem is volume. By the time a pattern is obvious, say the same compressor feeding five wells tripping on hot afternoons, a month has gone by. If you rely on state-reported monthly data, it shows up six to eight weeks later, averaged into a number that hides which days were lost and why.
I have sat on the other side of this. On a logging unit you learn that the most useful thing you can do at 3 a.m. is catch a bad number at the source, before it travels into a report and becomes somebody else's decision. Downtime is the same. The earlier it is caught and named, the cheaper it is.
Where agents earn their place
An agent here is software that reads the data, applies rules and a language model, and writes something a person can act on. In production surveillance it is good at four jobs:
- Pull and reconcile. Daily volumes, downtime codes, gas-lift injection, casing and tubing pressure, from systems that do not talk to each other. It should also flag problems in the data itself: uncoded zero-rate days, meters that disagree with allocation, tickets that arrive late.
- Detect. Compare every well with its own expected rate every day. Separate lost days from shortfall on producing days, and ignore noise that is inside the well's normal range.
- Explain in plain words. "Down 6 of the last 10 days, all coded compressor. Injection was zero on those days. The same station feeds four other wells and two of them are also down." That cross-reference is the step a tired engineer skips.
- Draft the work. A work order with the well, the symptom, the evidence and a suggested first check, and a morning list ranked by dollars at stake and cost to act.
What this looks like on real numbers
On the public sample, the well with the biggest gap reported zero producing days in June 2026 and five in July. When it last ran a full month, in April, it made 67 barrels per producing day, slightly above its own curve. Nothing is wrong with the rock; the well is simply not running. That is a scheduling and equipment problem, and it is worth about $130,000 a month in gross revenue at $75 oil.
The same exercise also showed why the order of the list matters. The well ranked third on a twelve-month view had been shut in for four months in 2025, but by June and July 2026 it was back on its curve. A ranking that only looks backwards would send an engineer to a problem that has already been fixed. A report that asks what is still open in the last two months sends them to the well that is losing oil today. Laying out that reasoning, well by well, with the numbers beside it, is exactly what an agent does well. Checking it takes an engineer about a minute.
What agents can't do, and shouldn't
- They cannot see the location. The pumper knows the dump valve on that separator sticks when it gets cold, and that "other" in the downtime log usually means a lease road washed out. That knowledge lives in people.
- They cannot own a safety decision. Opening a well, bleeding pressure, working around H2S: anything that happens on location belongs to trained people following their procedures.
- They cannot reliably tell a frac hit from a lift failure from data alone. Both show up as a drop in oil and a jump in water. One means wait and let the well clean up; the other means fix the lift. Getting it wrong is expensive either way. It takes the offset completion schedule and an engineer's judgment.
- They cannot set priorities against the budget and the rig schedule. The agent can rank by barrels and dollars. Whether a workover beats the next well on the drilling schedule is a business call.
- They are confidently wrong when the data is wrong. Late tickets, revised allocations and mislabeled meters all flow straight into the output unless something checks them.
The goal is not an agent that runs the field. It is an engineer who starts the day with five wells, the evidence for each, and a drafted work order.
Where humans stay in the loop
I would build four gates into any deployment, in this order.
- The engineer signs every work order. The agent drafts; a person releases. No exceptions in the first year.
- No setpoint changes from the agent. Anything that touches pressure, injection, chemicals or a rig is decided by people, even when the recommendation looks obvious.
- Rules are readable and editable. If an engineer overrules the agent, the reason is recorded and becomes a rule. I used this pattern in accounting automation: routine items follow rules, only new items go to the model, and every human correction is written back. Review volume falls every month because the system learns the team's judgment instead of replacing it.
- Measure it like any other job. Track what the agent recommended, what was acted on, and the barrels that came back. If its hit rate drops, narrow what it is allowed to flag.
How to start
Start small and boring. One asset, 30 to 50 wells, 30 days, availability only. Daily volumes plus downtime codes are enough. Success is lost days found earlier than before, and barrels a day recovered compared with the prior quarter. Do not start with reservoir questions, and do not start with an agent that changes setpoints on its own.
Spend the first week on the data, not the model. Check that every zero-rate day has a downtime code, that daily meters roughly add up to the monthly allocation, and that each well's lift type and compressor station are on record. Those checks usually find something, and fixing them is useful even if the trial goes nowhere.
If the first month works, the engineers will ask for more, and that is the right way for it to grow: from the people who use it, one rule at a time.