A typical mid-tier upstream operator runs around 1,800 active wells and 1,500 inactive wells, dispatched by a team of roughly 26 field operators who each visit somewhere between 15 and 22 wells a shift. Every morning, every one of those operators picks an order, picks a sub-set, picks a route. Multiply across the team and the daily plan is one combination drawn from a number with 1,010 digits in it. We are not exaggerating. We worked the math.
How many possible daily plans does your team choose from?
Adjust the inputs to your operation. The widget recomputes the permutation space live.
- Atoms in the observable universe1080(your number is 10929× larger)
- Possible chess positions1047(your number is 10962× larger)
- Grains of sand on every beach on Earth1019(your number is 10990× larger)
- Seconds since the Big Bang1017(your number is 10992× larger)
- People on Earth1010(your number is 10999× larger)
The probability that your team finds the optimal plan by hand? Effectively zero. That is not a training problem; it is an impossible-math problem handed to humans every morning.
The math, plain
With 1,800 active wells and 26 operators, each operator is responsible for about 69 wells in their territory. A typical shift is 22 site visits, roughly 15 minutes per site. The number of ways one operator can choose 22 wells out of 69 and visit them in some order is the permutation P(69, 22), which works out to about 6.6 × 1038. That is 660 trillion trillion trillion possible day-plans for one operator.
Twenty-six operators making independent choices means the team picks one combination out of (6.6 × 1038)26, which works out to a number in the neighborhood of 101,009. To put 101,009 in context, the observable universe contains roughly 1080 atoms. Your team’s daily plan is drawn from a space 10929 times larger.
- Active wells
- 1,800
- Field operators
- 26
- Wells in one operator territory
- ~69
- Site visits in a shiftroughly 15 minutes per site
- 22
- Day-plans for one operatorthe permutation P(69, 22)
- 6.6 × 1038
- Day-plans for the team of 26independent choices
- ~101,009
- Atoms in the observable universefor context
- ~1080
- Times larger the plan space is than that
- ~10929
The probability your foreman's plan was the optimal one this morning is, for all practical purposes, zero. And it isn’t their fault.
Why no human shift solves this
A foreman could be the most experienced upstream operator on the planet and the math still wouldn’t fit a human shift. The problem isn’t intelligence. The problem is the size of the search space and the speed at which conditions change. A tank fills overnight. A pump goes down at 4 AM. Commodity prices move two cents at the open. By the time a foreman has built tomorrow’s plan from yesterday’s context, today’s context is different.
This is the same shape of problem the airlines solved with crew scheduling in the 1990s and the same shape Amazon solved with last-mile routing in the 2010s. The right answer is not smarter humans. The right answer is a constraint-based optimizer that ranks tasks by economic impact, applies safety and qualification constraints, and assembles a ranked plan in the few seconds humans can’t. The pumper still drives the truck. The foreman still makes the calls a human has to make. The agent does the math no human shift can do.
What the ranked plan looks like in practice
The work loop runs on three lenses, scored every night and re-scored mid-shift when conditions change.
Cash-flow delta forecasting. For every well, the system extrapolates the last 48 hours of SCADA data into a short-term production forecast and compares it against the well’s Aries decline projection. Any delta in projected oil production multiplied by current commodity pricing gives a dollar-impact score. Every well is ranked by cash-flow delta. The top of the list is where the operator goes first, not because someone said so, but because that is where the dollars are.
Risk-based scoring. Independent of dollar impact, every well also carries a risk score that combines time since last visit, regulatory constraints, alarm history, SCADA signal degradation, and failure probabilities for major components. Risk scoring is not a weight that gets traded off against cash-flow impact; safety is a hard constraint in the optimizer. Crews don’t get dispatched to a site they aren’t qualified for, regardless of how much money is on the table.
Liquid Management Index. Tank levels, hauling schedules, and fluid production rates feed a forward-looking index that flags wells likely to hit critical inventory thresholds before the next visit. The LMI prevents overflows and the costly downtime that comes from missed pumps, without over-servicing low-risk wells the way a fixed weekly route does.
The three lenses combine into a single ranked task list per operator, route-optimized against the operator’s yard location, vehicle capacity, and shift hours, and pushed to their truck-cab tablet by 6 AM. The pumper picks up the tablet at the yard, knows exactly what to work on, in what order, and why, and drives. Mid-shift, when a tank fills faster than expected or a downhole pump fails, the plan re-optimizes without a phone call.
The proof, anonymized
We deployed this work loop with a top 25 private producer running 5,000+ wells across the Western Anadarko, the Permian, and Wyoming. The operator had spent over $10 million on prior SCADA systems, field automation, and pump-by-exception frameworks without a measurable lift in cash flow. They had the data. What they didn’t have was a system that turned data into the day’s plan.
What changed once the work loop was running:
- +15% gross cash flow uplift over a six-month window, without drilling a new well or adding headcount.
- 35% fewer miles driven on the same production coverage (deployment figure). Fewer wasted truck-rolls, more time on high-value wells.
- 40% lower liquid-hauling inventory across the tank battery, with 60% less redundant tank gauging (deployment figures).
- Safety runs as a hard constraint, not a weight, in the same operation: an unqualified or unsafe dispatch is blocked at the point of assignment rather than flagged afterwards. Safety as a constraint compounds the cash-flow result, not the other way around.
What the operator actually has to do
The deployment we ran with that operator followed a 90-day phased rollout. Three phases, each with a clear deliverable the field could feel.
- Phase 1
Data integration and alignment
Real-time SCADA telemetry, Aries production forecasts, work-order statuses, tank levels: all loaded into a unified cloud-based data warehouse with a dimensional schema that preserves time-series fidelity. Single source of truth. - Phase 2
Mobile app in the field
Lightweight tablet app that gives operators direct access to daily priorities, asset history, and task details. Replaces the morning spreadsheet review and eliminates guesswork. Real-time feedback loops back to engineers and supervisors. - Phase 3
Dynamic routing and real-time prioritization
The digital twin mirrors asset performance and recalibrates nightly. Cash-flow delta + risk score + Liquid Management Index combine into the morning plan, route-optimized against geography and crew. By the end of the rollout, operators and engineers were working from a shared, data-driven set of priorities, without manual compilation, subjective judgment, or delay.
That is the outline. The first phase is what most operators already have, in pieces, scattered across SCADA, accounting, and CMMS. The integration and reconciliation work (Chapter 4) is what makes phases two and three possible. The security architecture (Chapter 5) is what makes the CISO sign off on phase one in the first place.
One ranked work loop, not three programs
The most common mistake we see when an operator first considers this stack is treating the cash-flow win, the safety win, and the back-office win as three separate programs. They aren’t. They are the same work loop, ranked differently. The same ranked plan that surfaces a deferred-production well at 6 AM also makes sure the crew dispatched to it is qualified, also generates the JSA from the live hazard profile, also closes the work order back to financial tracking when the job is done. One loop, one data model, three outcomes.
Chapter 7 picks up the same loop in midstream, where the primary data sources are GIS topology and pipeline SCADA instead of well-level production, and the work output is hydraulic models and pipeline-integrity dispatch instead of pumper routes. Same architecture. Different surface.
Next, chapter 07
Midstream, hydraulic models, pipeline integrity, agentic engineering
Auto-built hydraulic models from GIS, SCADA, and engineering drawings. The Golden Record. What changes when an engineer no longer re-keys data between five systems.