What is agentic AI in oil and gas?
Agentic AI describes systems that do not just answer questions but plan a task, call external tools, execute a sequence of steps, and check their own work before handing results to a human. In oil and gas, that means an AI that can read a vibration trend, query the historian, cross-check the maintenance history in the CMMS, draft a work order, and route it for approval — rather than simply telling an engineer what a chart means. Unlike a chatbot (which responds) or a copilot (which assists inside one application), an agent operates across systems. For Malaysian operators facing ageing assets, cost pressure and a thinning experienced-engineer pool, that shift changes the economics of routine engineering work.
Key takeaways
- What agentic AI is: software that plans multi-step work, uses tools and data systems to carry it out, and verifies the outcome under human oversight.
- Five highest-value oil and gas use cases: predictive maintenance with automated work-order drafting; corrosion and risk-based inspection support; production optimisation; document control and MOC compliance; emissions monitoring, reporting and verification.
- What data and tooling you need: a clean process historian, a governed CMMS with reliable functional-location hierarchy, a searchable document store with metadata, a vector database and retrieval layer, tool-calling APIs, and an audit log for every agent action.
- Skills teams need: data literacy and asset-data governance, prompt and workflow design, retrieval-augmented generation (RAG) fundamentals, evaluation and testing, OT/IT cybersecurity, and management-of-change discipline applied to AI systems.
- Where to start: one bounded use case, read-only for the first 90 days, with human approval on every action that touches a live system.
➜ Explore EnergyEdge Data Analytics, Machine Learning & Artificial Intelligence training courses — including Agentic AI Applications in Upstream Oil & Gas Operations, delivered in Kuala Lumpur, virtually, or in-house.
Why agentic AI is accelerating in Malaysia’s oil and gas sector
Malaysia’s operating environment has produced a specific set of pressures that agentic AI happens to address well.
The drivers
Cost discipline on mature assets. A large share of Peninsular and Sarawak/Sabah production comes from fields well past plateau. Operating cost per barrel matters more than it did a decade ago, and much of that cost sits in engineering hours spent on repetitive analysis, report assembly and coordination rather than on decisions.
Reliability and unplanned downtime. Offshore platforms and onshore gas processing trains lose more value to unplanned outages than to almost anything else. Any capability that converts reactive maintenance into planned maintenance pays back quickly.
HSSE expectations. Malaysian regulators, PETRONAS as licensor, and international JV partners all expect demonstrable process safety governance. Agents that improve the completeness and traceability of safety documentation are attractive precisely because they generate evidence.
Ageing assets, ageing documentation. Many facilities carry thirty years of drawings, procedures, MOC packs, inspection reports and vendor manuals in formats that no one can search reliably. Retrieval-based agents are unusually good at this problem.
Talent transition. Experienced engineers are retiring or moving into the energy transition, and the knowledge they hold is largely undocumented. Agents that retrieve and structure past decisions partially offset the loss — though they never replace judgement.
PETRONAS’s data direction. The upstream data ecosystem in Malaysia, including the national data gateway, has been moving toward standardised, better-governed data access. That direction matters because agentic systems depend entirely on the quality of what sits underneath them.
The constraints
Data silos. Historian, CMMS, ERP, document management and well databases were procured separately, often decades apart, with no common asset taxonomy. An agent that cannot resolve “P-1201A” to the same physical pump across four systems is not useful.
OT/IT separation. Purdue-model network segmentation exists for good reasons. Any architecture that requires an agent to reach into the control layer will — and should — face resistance. Successful designs read from a historian replica on the IT side and never touch the DCS.
Governance immaturity. Most organisations have no policy defining who owns an agent, who approves its actions, what it is permitted to do autonomously, or how it gets decommissioned.
Cybersecurity. Agents introduce genuinely new attack surfaces: prompt injection through ingested documents, over-broad service-account credentials, and data exfiltration through model providers. These are not theoretical.
Change management. Engineers who have been told three times that a digital transformation will change their working lives, and seen little change, are appropriately sceptical.
Local content and vendor risk. Procurement rules, data residency expectations, and PETRONAS licensing conditions all shape which model providers and hosting arrangements are viable.
Malaysia readiness checklist
Score your organisation honestly. Fewer than seven “yes” answers usually means the first project should be data foundations, not agents.
- Do you have a single, agreed asset register with consistent functional-location tagging across CMMS, historian and ERP?
- Is your process historian trustworthy — tags named consistently, bad data flagged, calibration drift managed?
- Can you retrieve any procedure, P&ID or MOC pack for a given unit within five minutes, in a machine-readable format?
- Do you have a written data classification policy that tells you which datasets may leave your network?
- Is there a named accountable owner for AI systems at asset or business-unit level?
- Does your MOC process explicitly cover changes to software that influences operational decisions?
- Do you have an OT/IT architecture review board that would assess an agent deployment before it goes live?
- Can you log and replay every action a system takes against your CMMS or document store, with user attribution?
- Do you have at least two people who can evaluate whether an AI output is correct, not just whether it sounds correct?
- Has leadership agreed a measurable business outcome — not a technology objective — for the first deployment?
Items 1 to 3 are the ones that most often stall Malaysian pilots. They are also the ones that pay off regardless of whether the agent project proceeds.
Agentic AI vs GenAI vs machine learning vs digital twin: what’s different?
These four terms are used interchangeably in vendor material and they should not be. The distinction determines what you can actually deploy.
| Concept | What it does | Typical oil & gas example | Where it fails |
| Machine learning (ML) | Learns statistical patterns from historical data to predict a numeric value or class | Predicting compressor failure probability from vibration, temperature and load history | Needs large, labelled, representative datasets; degrades silently when operating conditions shift; explains nothing about why |
| Generative AI (GenAI/LLMs) | Produces text, code or summaries from a prompt, using patterns learned from large text corpora | Summarising a 200-page inspection report; drafting a shift handover note | Confidently fabricates specifics; has no access to your data unless you supply it; no memory of what it did last time |
| RAG (retrieval-augmented generation) | Retrieves relevant passages from your documents, then generates an answer grounded in them | Answering “what is the design pressure of V-2301 and which MOC changed it?” with citations | Only as good as document quality and metadata; retrieves the wrong chunk when your taxonomy is inconsistent |
| Agentic AI | Plans a multi-step task, calls tools and systems, executes, then verifies against a defined success condition | Detects a bearing anomaly, pulls maintenance history, checks spares availability, drafts a work order, routes for approval | Compounds errors across steps; can take real-world actions with real consequences; hard to test; requires strict permissioning |
| Digital twin | Maintains a live, physics-based or hybrid virtual model of an asset, synchronised with real sensor data | Simulating separator performance under a proposed rate change before committing | Expensive to build and keep calibrated; drifts from reality without disciplined maintenance; often over-scoped |
The practical relationship: ML gives you predictions. RAG gives you grounded answers. A digital twin gives you a simulation environment. Agentic AI is the layer that orchestrates these — deciding which to call, in what order, and what to do with the result. An agent without good ML models, clean documents or a reliable twin has nothing useful to orchestrate.
If your team is still forming this vocabulary, Introduction to Artificial Intelligence For Non-Data Scientists In Oil & Gas is the right entry point, and Digital Twin Engineering – From Concept to Deployment in Oil & Gas Operations covers the twin side specifically.
Agentic AI applications in oil and gas (with Malaysia examples)
Each use case below follows the same structure so you can compare them on the same terms and pick a realistic starting point. They are ordered roughly by how often they succeed as a first deployment — the earlier ones tend to have cleaner data and clearer ownership.
1. Predictive maintenance with automated work-order drafting (rotating equipment)
Problem. Condition-monitoring systems generate more alerts than reliability engineers can triage. Genuine early warnings get lost among noise, and by the time a pattern is investigated, the intervention window has closed. Meanwhile, converting a confirmed finding into a properly scoped work order takes hours of manual assembly.
Agent workflow
- Observe: monitor vibration, bearing temperature, lube oil pressure, discharge pressure and motor current for a defined equipment class; flag deviations from the ML model’s expected envelope.
- Plan: rank flagged assets by criticality and consequence; determine what supporting evidence is needed for each.
- Act: retrieve failure history for that tag and its sister units, check spare-part availability in ERP, pull the relevant maintenance procedure, and draft a work order with scope, trade requirements, estimated duration and parts list.
- Verify: confirm the draft references a valid functional location, that the parts exist, that no overlapping work order is already open, and that the recommendation is consistent with the failure mode identified. Route to the reliability engineer for approval — the agent never releases the work order itself.
Tools the agent uses. Process historian (PI or equivalent), condition-monitoring platform, CMMS (SAP PM, Maximo), ERP for inventory, document store for procedures and vendor manuals.
Data needed. Consistent tag naming across historian and CMMS; at least 18–24 months of sensor history; complete work-order history with proper failure coding; equipment criticality ranking; spares master data.
KPIs. Reduction in unplanned downtime hours; percentage of work orders originating from condition-based triggers rather than calendar schedules; planner hours saved per week; false-positive rate on agent-raised alerts; percentage of agent-drafted work orders approved without material edits.
Risks and controls. The most common failure is a plausible work order built on a mis-resolved tag. Control it with a hard validation step against the asset register and a mandatory human approval gate. Set a confidence threshold below which the agent escalates rather than drafts. Log every draft, including rejected ones, and review rejection reasons monthly — that review is where the system actually improves.
Where training fits. The bottleneck here is rarely the model; it is maintenance process maturity and failure-code discipline. Maintenance and Reliability Best Practices – Aligned with SMRP Best Practices and CMRP Certification and Maintenance Planning, Scheduling & Control build the foundation the agent depends on. For failure analysis rigour, Apollo Root Cause Analysis Methodology.
2. Corrosion management and risk-based inspection support
Problem. RBI programmes under API 580 require damage-mechanism assessment, consequence modelling and inspection planning across thousands of circuits. The analysis is well-defined but labour-intensive, and inspection findings often sit in reports that never make it back into the risk model. Intervals drift toward calendar-based defaults because nobody has time to justify anything else.
Agent workflow
- Observe: ingest new inspection reports, thickness measurement records, process condition changes and corrosion coupon results as they arrive.
- Plan: identify which circuits have new evidence that could change a risk ranking; determine what analysis each requires.
- Act: extract wall-thickness readings, compute corrosion rates against previous surveys, compare observed damage against the API 571 mechanisms credible for that service, flag circuits where the calculated remaining life falls below the next planned inspection date, and assemble a supporting evidence pack.
- Verify: check readings against physical plausibility bounds, confirm the damage mechanism is consistent with the actual process conditions, and highlight anything anomalous rather than smoothing it over. All outputs go to a corrosion engineer for review.
Tools the agent uses. Inspection data management system, document store for inspection reports, process historian for operating conditions (temperature, water cut, H₂S/CO₂ partial pressures), RBI software, materials database.
Data needed. Circuit definitions with materials of construction; historical thickness surveys with consistent measurement locations; process fluid composition and its variability; existing damage-mechanism assessments; inspection history with findings, not just completion dates.
KPIs. Percentage of circuits with a current, evidence-based risk ranking; inspection findings closed back into the risk model within 30 days; reduction in inspection scope on low-risk circuits without integrity degradation; engineer hours redirected from data assembly to assessment.
Risks and controls. Under-calling corrosion risk is a safety issue, not an efficiency issue. Configure the agent to be asymmetric: it may recommend increasing inspection intensity autonomously as a flag, but any recommendation to extend an interval or reduce scope requires sign-off by a competent person. Never allow the agent to write directly into the RBI model.
Where training fits. The agent needs an engineer who can judge its output. API 580 Risk-Based Inspection (RBI) Certification Course and API 571 Materials and Corrosion Damage Mechanisms are the core competencies; Asset Integrity and Life Extension – Mastering Risk-Based Inspection and Fitness-for-Service Methodologies covers the life-extension decisions that follow.
3. Process safety and HAZOP assistant agent
Problem. HAZOP quality varies enormously with team preparation, facilitator skill and time pressure. Nodes get rushed late in the day, safeguards are recorded generically, and actions are closed without evidence that the underlying scenario was addressed. Revalidation studies repeat work rather than building on it.
Agent workflow
- Observe: ingest P&IDs, cause-and-effect matrices, previous HAZOP worksheets, incident reports, MOC records and the current safeguard register for the node under study.
- Plan: for each node and guideword, identify deviations that have historical precedent in this facility or in comparable units.
- Act: generate a candidate deviation and consequence list as preparation material, map each candidate to safeguards recorded in existing documentation, and flag scenarios where the previous study recorded a safeguard that subsequent MOC records show has since been modified or removed.
- Verify: cross-check every safeguard citation against the source document and present the citation, so the team can confirm it rather than trust it.
Tools the agent uses. Document management system, P&ID repository, MOC system, incident database, safeguard/SIF register, LOPA records.
Data needed. Current, controlled-revision P&IDs; previous HAZOP worksheets in structured form; MOC history linked to affected equipment; incident and near-miss records with causal analysis; SIF register with SIL assignments and proof-test records.
KPIs. Team preparation time reduced; number of safeguard-drift findings surfaced (safeguards credited in an old study that no longer exist); percentage of nodes covered without schedule compression; action-closure quality on audit.
Risks and controls. This is the use case where over-reach does the most damage. The agent prepares; the team decides. It must never author the official worksheet, assign risk rankings, or close actions. A generated deviation list that the team accepts uncritically is worse than no list at all, because it creates an illusion of coverage. Facilitators should be explicitly briefed to challenge agent-suggested items and to add scenarios the agent missed. Treat the agent’s output as a junior engineer’s homework, reviewed accordingly.
Where training fits. Facilitator competence is the controlling variable. Process Hazard Assessment using the HAZOP Technique and HAZOP Team Leader Training (IChemE approved) is the anchor course; Process Safety Management & Engineering Applications and Advanced Process Safety Engineering cover the wider system. For broad awareness across a large workforce, the Introduction to Process Safety e-learning course and HAZOP Participants e-learning course scale more economically.
4. Production optimisation agent (constraint detection and recommendations)
Problem. Production engineers manage dozens of wells with competing constraints — separator capacity, gas lift allocation, water handling, compression availability, export nomination. Deferment is often identified days after it occurs, and the analysis of why rates fell is reconstructed manually from multiple systems.
Agent workflow
- Observe: monitor well test data, wellhead pressures and temperatures, choke positions, gas lift injection rates, separator levels, and facility constraint indicators.
- Plan: when actual production diverges from the potential model beyond a threshold, decompose the gap by candidate cause — well performance, artificial lift, facility constraint, export constraint, or measurement error.
- Act: query nodal analysis or network model outputs for the affected wells, retrieve recent intervention history, check whether a facility constraint is active, and produce a ranked hypothesis list with supporting evidence and a suggested reallocation.
- Verify: validate against mass balance, confirm the recommendation respects declared operating envelopes and well constraints, and quantify the expected gain with an uncertainty range rather than a single number.
Tools the agent uses. Historian, production database, well test database, nodal analysis and network models, artificial lift optimisation software, deferment tracking system.
Data needed. Reliable and recent well tests; a maintained network model; documented operating envelopes and constraints; deferment records with consistent cause coding; measurement uncertainty characterisation.
KPIs. Deferment identified within 24 hours as a percentage of total deferment; production gain attributable to agent-surfaced recommendations; engineer hours redirected from data gathering to optimisation; well test currency.
Risks and controls. Recommendations must be advisory only. No agent should write setpoints to a control system — the operational, safety and regulatory case for that does not currently exist in most Malaysian operations, and the segmentation between IT and OT should not be compromised for a rate gain. Route all recommendations through the production engineer and the control room. Track recommendation acceptance rate; if it falls below roughly half, the model or the data is wrong.
Where training fits. Artificial Lift and Real-Time Production Optimization in Digital Oilfield and Data Analytics Workflows for Artificial Lift, Production and Facility Engineers map directly onto this workflow. Smart Oilfield and Sensor Technology covers the instrumentation layer that determines whether the data is trustworthy in the first place.
5. Drilling operations agent (NPT classification and lessons-learned retrieval)
Problem. Non-productive time is recorded inconsistently across rigs and contractors, which makes trend analysis unreliable. Lessons learned from previous wells exist but are effectively unsearchable, so the same problems recur on adjacent wells in the same field.
Agent workflow
- Observe: ingest daily drilling reports, real-time rig sensor data, mud logs and morning report narratives.
- Plan: identify time segments that meet NPT criteria and determine the appropriate classification against the operator’s taxonomy.
- Act: classify each NPT event with a confidence score, retrieve comparable events from the historical well database — same field, formation, hole section or BHA configuration — and surface the interventions that resolved them, with source citations.
- Verify: reconcile classified NPT hours against the total reported, flag unexplained gaps, and present low-confidence classifications for human coding rather than guessing.
Tools the agent uses. WITSML real-time data feed, daily drilling report system, well database, offset well reports, lessons-learned repository, drilling parameter historian.
Data needed. Consistent NPT taxonomy applied across contractors; historical daily reports in machine-readable form; offset well data for the relevant field; formation tops and geological prognosis; BHA and bit records.
KPIs. NPT classification consistency across rigs; time from event to lessons-learned retrieval; repeat-incident rate on offset wells; percentage of well plans that cite specific offset lessons.
Risks and controls. Real-time drilling data feeds must remain read-only and one-directional. The agent must never influence rig-floor decisions directly; its output goes to the drilling supervisor and the town team. Guard against retrieval that surfaces superficially similar but geologically irrelevant offsets — require the agent to state the basis for each analogue it proposes.
Where training fits. Modelling Drilling Data with Statistics and AI in Python covers the analytical methods; The Automated Oilfield: AI and Drilling Optimization addresses automation strategy and the human-machine interaction questions that decide whether any of it gets adopted on the rig floor.
6. Supply chain and procurement agent (vendor comparison and specification compliance)
Problem. Technical bid evaluation for equipment and services requires cross-checking dozens of vendor submissions against a technical specification, line by line. It is slow, inconsistent between evaluators, and deviations are frequently missed until the equipment arrives on site.
Agent workflow
- Observe: ingest the technical specification, the ITT/RFQ documents and all vendor technical submissions.
- Plan: decompose the specification into discrete, checkable requirements and determine which submission section addresses each.
- Act: produce a requirement-by-requirement compliance matrix showing compliant, partially compliant, deviated or not addressed, with a citation to the exact page and clause of each vendor’s submission; summarise commercial and delivery terms alongside.
- Verify: flag every requirement it could not confidently locate rather than marking it compliant by default; escalate ambiguous language for human interpretation.
Tools the agent uses. E-procurement platform, document store, specification library, vendor master data, historical contract and performance records.
Data needed. Specifications in structured or at least consistently formatted documents; vendor submissions in text-extractable form (scanned drawings need OCR); approved vendor list with performance history; local content requirements and classification rules.
KPIs. Bid evaluation cycle time; deviations identified at evaluation versus at delivery; consistency of evaluation scores between independent evaluators; percentage of specification clauses explicitly addressed in the evaluation record.
Risks and controls. Procurement is a governance-sensitive area with fairness and auditability obligations. The agent must produce evidence, never scores that drive award decisions on their own. Every finding must carry a citation an auditor can check. Restrict access so that no single agent instance can see both technical and commercial envelopes where your process separates them. Vendor-submitted documents are untrusted input — treat embedded instructions as a live prompt-injection risk.
Where training fits. Purchasing & Procurement in the Upstream Oil & Gas Supply Chain and Integrated Supply Chain Excellence: Mastering Smart, Secure and Sustainable Operations cover the digital supply chain directly. For the contractual side, E&P Technical Services Contract Management and Mastering Contract Law and Risk Mitigation in Energy.
7. Energy efficiency and utilities optimisation agent (steam, boilers, CCGT)
Problem. Utility systems — steam networks, fired heaters, cogeneration units, compressed air — drift away from optimal operation gradually. Heat rate degradation of a few percent is invisible day to day but represents substantial fuel cost and Scope 1 emissions over a year. Performance testing happens annually at best.
Agent workflow
- Observe: track fuel consumption, steam production and consumption by header, excess oxygen, stack temperature, condensate return, turbine heat rate and auxiliary power continuously.
- Plan: compare current performance against the design baseline and against best-achieved performance under comparable ambient and load conditions.
- Act: attribute the performance gap to specific equipment or operating practice — fouled exchanger, excess air, steam trap losses, suboptimal load allocation between units — and quantify the fuel and emissions cost of each in local currency and tonnes CO₂e.
- Verify: close the energy balance before reporting; flag instrument drift as a candidate explanation before attributing a gap to real degradation.
Tools the agent uses. Historian, energy management information system, steam system model, emissions calculation engine, CMMS for cleaning and maintenance history.
Data needed. Reliable fuel and steam metering; design performance curves; ambient condition data; equipment cleaning history; fuel composition and heating value; instrument calibration records.
KPIs. Specific energy consumption by unit; heat rate deviation from baseline; identified savings converted to executed actions; Scope 1 emissions intensity; steam system losses as a percentage of generation.
Risks and controls. Attribution errors here are cheap to fix but expensive to act on — an agent that blames a fouled exchanger when the real issue is a drifting flow transmitter will send a crew to clean the wrong thing. Require the agent to rank alternative explanations rather than assert one, and to state which instruments its conclusion depends on. Verify identified savings after implementation and feed the result back.
Where training fits. Combined Cycle Gas Turbine (CCGT) Power Plants – Operational, Performance and Optimisation Strategies, Thermal Power Plant Performance Testing and Maintenance of Steam and Gas Turbines build the thermodynamic judgement needed to challenge an agent’s attribution.
8. Document control and compliance agent (MOC packs, procedures, audit trails)
Problem. Management of change packs are incomplete more often than anyone would like to admit. Required approvals are missing, affected documents are not updated, and training on the change is not delivered. The gap is usually discovered during an audit or, worse, an incident investigation.
Agent workflow
- Observe: monitor MOC records as they progress through the workflow, alongside the document register and training records.
- Plan: for each change, determine the full set of documents, approvals, drawings, procedures and competency updates that the change should trigger.
- Act: check whether each required item exists and is current; identify P&IDs, operating procedures, alarm settings, SIF documentation, spare parts lists and training records that reference the changed equipment but have not been revised; generate a completeness report per MOC.
- Verify: confirm that each identified gap is genuine by checking document revision dates against the change implementation date, and present the evidence chain for each finding.
Tools the agent uses. MOC system, document management system, drawing register, learning management system, competency records, CMMS.
Data needed. MOC records linked to specific equipment tags; document register with revision history and equipment cross-references; procedure library with equipment references; training and competency records mapped to roles and equipment.
KPIs. MOC packs closed with complete documentation on first review; average time from change implementation to full document update; audit findings related to MOC completeness; number of orphaned procedures referencing decommissioned equipment.
Risks and controls. The agent must not close MOC items or approve anything. It reports gaps; humans close them. Because it operates on controlled documents, read-only access is essential and every retrieval should be logged. Be aware that a compliance agent generates findings, and findings create work — brief leadership before deployment or the first month’s output will be perceived as an attack on the organisation rather than a service to it.
Where training fits. MOC discipline is a process safety management element before it is a document management problem. Process Safety Management & Engineering Applications covers it in context; see also the full Process and Safety training course portfolio.
9. Carbon management and emissions reporting agent (MRV workflows)
Problem. Greenhouse gas reporting under the GHG Protocol, and increasingly under ISSB-aligned disclosure requirements, demands the assembly of activity data from dozens of sources every reporting cycle. The process is manual, hard to audit, and the same reconciliation work is repeated each period. Methane quantification in particular relies on emission factors that may not reflect actual site conditions.
Agent workflow
- Observe: collect fuel consumption, flare and vent volumes, fugitive survey results, purchased electricity, and relevant Scope 3 activity data across the reporting boundary.
- Plan: map each data source to the correct GHG Protocol scope and category; identify which emission factor or calculation method applies.
- Act: compute emissions by scope and source, assemble the calculation trail with source references, compare period-on-period and flag variances beyond a threshold, and prepare the reporting pack with supporting evidence.
- Verify: reconcile against fuel purchase and production records, check for double counting across scopes, confirm boundary completeness, and mark every figure as measured, calculated or estimated.
Tools the agent uses. Historian, flare and vent metering, LDAR survey database, ERP for fuel and electricity purchases, emission factor library, sustainability reporting platform.
Data needed. Complete activity data across the organisational boundary; current and correctly versioned emission factors; documented calculation methodologies; previous period submissions for comparison; LDAR survey results with location and quantification.
KPIs. Reporting cycle time; percentage of emissions figures traceable to a primary source; audit adjustments per reporting cycle; proportion of emissions based on measurement rather than generic factors; variance explained on first pass.
Risks and controls. Emissions disclosures carry legal and financial consequences. Version-control the emission factor library rigorously and force the agent to record which factor version it used for every calculation. Never allow silent factor updates. Every published figure requires human sign-off, and the calculation trail must be reproducible by a third-party assurer without the agent’s involvement.
Where training fits. Greenhouse Gas Accounting, Mitigation, Certification and Reporting covers scopes 1–3 and methane quantification methods; Understanding and Managing Scope 3 Emissions addresses the value-chain data problem that agents are best suited to; Accounting and Reporting for Climate Change bridges to financial reporting. For CCS-specific analytics, CCS Analytics: AI-Based Carbon Capture & Storage.
10. Training and competency agent (role-based learning paths)
Problem. Competency frameworks exist on paper but are rarely connected to what individuals actually need next. Training is allocated by budget cycle and availability rather than by gap. When an asset changes — new equipment, new process, new regulation — the training implications are worked out late, if at all.
Agent workflow
- Observe: monitor competency assessment records, role requirements, incident and near-miss causal factors, MOC records affecting operating procedures, and upcoming project scopes.
- Plan: identify the gap between each role’s required competencies and current assessed levels, weighted by criticality and by recent incident patterns.
- Act: generate individual and team development recommendations mapped to specific courses, sequenced by prerequisite, with a suggested calendar aligned to operational availability and budget cycles.
- Verify: check that recommended sequences respect prerequisites, that assessed competency data is current enough to rely on, and that recommendations reflect the actual role rather than the job title.
Tools the agent uses. Competency management system, learning management system, HR records, incident database, MOC system, provider course catalogues and schedules.
Data needed. A defined competency framework mapped to roles; current assessment records; training completion history; incident causal analysis with competency factors coded; project and turnaround schedules.
KPIs. Competency gap closure rate for critical roles; percentage of training spend directed at assessed gaps rather than general awareness; time from identified gap to scheduled training; incident causal factors attributed to competency.
Risks and controls. Competency data is personal data and must be handled under your privacy obligations. Do not let an agent make or influence performance or employment decisions. Recommendations go to the individual and their supervisor as input to a development conversation, not as an automated assignment. Bias in historical data — some roles systematically under-assessed — will be amplified unless someone checks.
Where training fits. Start by making your framework real. The Human Resources training portfolio covers competency system design, and the e-learning catalogue provides the scalable delivery layer that makes gap-driven learning paths practical for a large workforce.
Reference architecture for agentic AI in oil and gas
(Architecture diagram)
A workable architecture has five layers. The mistake most organisations make is starting at the agent layer because that is where the vendor demonstrations are.
Layer 1 — Data
Sources: process historian, CMMS, ERP, document management system, well database, GIS, laboratory information management system, inspection data management system, emissions and metering systems.
What matters here: a single asset taxonomy that resolves the same physical equipment across every system. Without it, nothing above this layer works reliably. Second: a read replica architecture so agents never query production OT systems directly. Third: data contracts that define what each source guarantees — update frequency, quality, ownership.
Layer 2 — Retrieval
Components: document ingestion pipeline with OCR for scanned drawings and reports, chunking strategy that respects document structure, embedding model, vector database, metadata index, and a hybrid search layer combining semantic and keyword retrieval.
What matters here: metadata governance. A chunk of text is only useful if the system knows which asset, which revision, which document class and which date it belongs to. Retrieval quality is determined almost entirely by metadata discipline, not by the choice of embedding model. Superseded document revisions must be marked as such or the agent will confidently cite obsolete procedures.
Layer 3 — Agent
Components: a planner that decomposes tasks into steps; a tool-calling interface with explicitly declared, individually permissioned tools; a working memory for the current task; guardrails that constrain scope and block disallowed actions; and an evaluation harness that scores outputs against a test set.
What matters here: each tool is a permission boundary. “Read historian tag values” and “create CMMS work order” are different permissions with different approval requirements, and they should be granted separately. Agents should be scoped narrowly — one agent per workflow, not one agent that does everything. Narrow agents are testable; broad ones are not.
Layer 4 — Human in the loop
Components: approval queues with clear ownership, escalation paths for low-confidence outputs, rejection capture with reasons, and a feedback route back into evaluation.
What matters here: define the autonomy level per action type before deployment, and write it down. A practical scale: observe only (agent reports, takes no action) → suggest (agent drafts, human edits and submits) → act with approval (agent submits, human approves before execution) → act with notification (agent executes, human is informed). Most oil and gas use cases should sit at suggest or act-with-approval indefinitely. Progression up the scale is a decision requiring evidence, not a natural maturity path.
Design the approval step so that rejecting is as easy as approving. If approval is one click and rejection requires a form, you will get rubber-stamping — which means you have automated the action without retaining the oversight.
Layer 5 — Observability
Components: structured logs of every agent action with inputs, outputs, tool calls and timestamps; execution traces showing the reasoning path; model performance monitoring; drift detection on underlying ML models; cost tracking per workflow.
What matters here: you cannot investigate an incident involving an agent unless you can reconstruct exactly what it did and why. Treat agent logs with the same retention discipline as operational logs. Monitor for silent degradation — an agent whose accuracy declines gradually will not announce itself.
Deployment sequencing
A realistic sequence for a Malaysian operator starting from a typical baseline:
- Months 1–3: asset taxonomy reconciliation and document metadata remediation for one asset or one equipment class. Unglamorous and non-negotiable.
- Months 3–6: retrieval layer only. Deploy a grounded question-answering capability over your documents. No actions, no writes. This builds trust and exposes data quality problems cheaply.
- Months 6–9: first agent at suggest level on one workflow, with full logging and weekly review of accepted versus rejected outputs.
- Months 9–12: evaluate honestly against the business KPI you defined at the start. Expand to a second workflow only if the first one demonstrably worked.
Safety, governance and cybersecurity considerations
Hallucination and how to mitigate it
Language models generate fluent, plausible text regardless of whether it is correct. In an operational context this is the central risk, because a wrong answer that sounds right is more dangerous than an obvious error.
Practical mitigations, in order of effectiveness:
- Ground every factual claim in retrieved source material and require citations. An answer without a citation should be treated as unsupported.
- Constrain scope. An agent restricted to one equipment class and one workflow has far fewer opportunities to invent than a general assistant.
- Build a golden test set. Fifty to two hundred questions with verified answers, run against the system before every change. Without this you have no way to know whether an update improved or degraded performance.
- Calibrate and expose confidence. The agent should be configured to say it does not know, and escalation on low confidence should be the default behaviour rather than an exception.
- Verify structurally. Check that tag numbers exist in the asset register, that dates are plausible, that numeric values fall within physical bounds. Structural validation catches a large share of fabrication cheaply.
- Keep humans reviewing. No mitigation removes the need for a competent reviewer on consequential outputs.
Management of change for AI systems
Most MOC procedures were written for physical and process changes and do not clearly cover software that influences operational decisions. Update yours to address: changes to the model or model version; changes to prompts and system instructions; changes to tool permissions or scope; changes to the underlying data sources; and decommissioning. A model provider silently upgrading a version behind an API is a change to your system whether or not you initiated it — pin versions where you can, and test after every provider update where you cannot.
Access control and least privilege
Agents should hold their own identities, not borrow a human’s credentials. Each tool the agent can call is a separate permission, granted individually and reviewed periodically. Default to read-only. Where write access is necessary, restrict it to a single system, a single object type, and a defined scope — an agent that can draft a work order should not be able to modify the equipment master. Service accounts with broad permissions are the most common serious finding in agent deployments.
Auditability and traceability
Every action needs a record: what triggered it, what data was retrieved, what the agent produced, who approved it, and what was executed. This matters for incident investigation, for regulatory scrutiny, and for defending a decision to a JV partner or insurer. Build it in from the first deployment; retrofitting audit trails is far harder than it sounds.
Data privacy, residency and vendor risk
Before any data leaves your network, classify it. Well data, reserves information, commercial terms and personnel records carry different obligations, and PETRONAS licensing conditions may constrain what can be processed where. Confirm with any model provider whether your inputs are retained or used for training, where processing occurs geographically, and what the contractual position is on confidentiality. For sensitive workloads, private deployment or an in-region hosted model may be the only acceptable option even at higher cost.
Prompt injection and OT boundary integrity
Two threats deserve specific attention:
Prompt injection. Any document an agent ingests is untrusted input. A vendor submission, an inspection report from a contractor, or an email could contain text designed to manipulate the agent’s behaviour. Treat retrieved content as data, never as instruction, and validate agent outputs independently of the content that produced them.
OT boundary. The pressure to give agents live control access will come, usually framed as efficiency. Resist it. Read from replicated data on the IT side. The segmentation between IT and OT exists because the consequence of compromise on the OT side is physical. No production optimisation gain justifies weakening it.
Skills teams in Malaysia need to deploy agentic AI
Capability gaps are the binding constraint in most organisations, not technology access. The requirements differ sharply by role.
Operations and reliability engineers
What they must know
- How to judge whether an AI recommendation is physically plausible — the domain expertise remains the control, and it becomes more important, not less
- Failure modes and effects well enough to evaluate a predictive model’s output rather than accept it
- Basic data literacy: what a false positive rate means, why a model degrades, what “confidence” does and does not indicate
- CMMS and historian data structures, including how their own data entry habits determine whether any of this works
- When to escalate rather than approve
Process safety engineers
What they must know
- Where AI assistance is legitimate (preparation, retrieval, consistency checking) and where it is not (risk ranking, safeguard adequacy, action closure)
- How to apply MOC principles to software and model changes
- How to specify verification requirements for AI-generated safety-relevant content
- The failure modes specific to generative systems, particularly plausible fabrication
- How to maintain team rigour when an agent has already produced a comprehensive-looking list
Data engineers and platform teams
What they must know
- Asset taxonomy design and cross-system entity resolution — the highest-value skill in this entire list
- Historian architecture, tag management and data quality monitoring
- Retrieval pipeline construction: ingestion, OCR, chunking, embedding, metadata schema design
- Tool-calling API design with permission boundaries
- Observability: structured logging, tracing, evaluation harnesses, drift detection
- OT/IT integration patterns that respect segmentation
Product owners and transformation leads
What they must know
- Use case selection: how to identify workflows with clear boundaries, available data and a measurable outcome
- How to write an evaluation plan before deployment rather than after
- Change management with sceptical, experienced technical staff
- Vendor evaluation beyond the demonstration — what to ask about evaluation methodology, data handling and failure behaviour
- How to say no to use cases that are not ready, which is most of the value this role adds
Leaders and decision makers
What they must know
- Realistic capability boundaries, so that investment decisions rest on what these systems do rather than what they are said to do
- The governance model: who owns an agent, who approves what, how it is decommissioned
- ROI framing over a realistic horizon, including the unglamorous data foundation costs that dominate early spend
- Risk appetite, stated explicitly, for autonomy levels in operational contexts
- Why the first project should target learning and foundations rather than headline savings
Recommended training pathway (EnergyEdge / PetroEdge Asia)
The pathway below sequences existing EnergyEdge courses into a capability-building programme. Most teams do not need every course — select by role using the skills section above. All courses are available as public sessions in Kuala Lumpur and Singapore, as virtual instructor-led training, or customised for in-house delivery. EnergyEdge is an HRD Corp registered training provider, so Malaysian employers can claim eligible programmes against their levy.
Tier 1 — Foundations (2–3 days each)
Aimed at engineers, managers and leaders who need shared vocabulary and realistic expectations before any investment decision.
| Course | Focus | Best for |
| Introduction to Artificial Intelligence For Non-Data Scientists In Oil & Gas | AI concepts grounded in oil and gas applications, without requiring a coding background | Engineers, supervisors, technical managers |
| Introduction to Data Analytics & Visualization | The analytics process end to end; identifying opportunities in your own data | Anyone who will interpret AI output |
| Power BI® – Business Data Analytics | Hands-on extraction, manipulation and visualisation | Analysts and reporting teams |
| Webinar: Strategic Applications of Artificial Intelligence for Business Leaders in Energy | Competitive positioning and investment framing | Executives and business leaders |
Tier 2 — Practitioner (3–5 days each)
Aimed at the engineers and specialists who will operate, evaluate and be accountable for these systems.
Digital and data track
| Course | Focus |
| Managing Integrated and Digitalized Oil and Gas Assets | Digital oilfield implementation, IIoT, real-time data, change management |
| Applied Machine Learning and Data Science for Upstream Professionals | Five days from scientific programming through ML applied to subsurface and production workflows |
| Assessment Based Training – Python Programming & Analytics for the Oil & Gas Sector | Python fundamentals with assessed competency |
| Digital Twin Engineering – From Concept to Deployment in Oil & Gas Operations | Building the simulation layer agents orchestrate |
| Smart Oilfield and Sensor Technology | The instrumentation and data-acquisition foundation |
| Computer Vision and Real-Time Analytics | Visual inspection and real-time monitoring architectures |
Domain track — pair with the use case you intend to deploy
Tier 3 — Implementation
The implementation-focused programme in the portfolio, covering agentic AI applications across exploration, drilling and production optimisation. It is the natural conclusion of the pathway for teams moving from understanding to deployment: use case selection, architecture, governance and pilot planning. Available as virtual instructor-led training or as an in-house programme built around your own assets and data.
For teams where the constraint is one or two individuals rather than a whole department, EnergyEdge also offers one-to-one coaching for energy professionals.
Suggested 12-month sequence for an asset team
| Quarter | Activity |
| Q1 | Tier 1 foundations for the whole team; leadership session; agree the target use case and success measure |
| Q2 | Tier 2 domain course for the use case owner; begin asset taxonomy and document metadata remediation |
| Q3 | Tier 2 digital track for the technical lead; Tier 3 agentic AI implementation programme; build and deploy the retrieval layer |
| Q4 | Pilot the first agent at suggest level; evaluate against the Q1 success measure; decide on expansion |
Next steps
Talk to an instructor — discuss which pathway fits your team through the advanced course search or by contacting the EnergyEdge team directly.
Request the Malaysia schedule — see current dates in Kuala Lumpur and across the region on the 2026 training calendar, or download the full calendar.
Corporate in-house training — build a programme around your own assets, data and use cases: request an in-house proposal.
Related reading
Frequently Asked Questions
It is AI that carries out a task rather than just answering a question. Given a goal, it plans the steps, uses your systems and data to complete them, checks its own result, and passes it to a person for approval. A chatbot tells you a pump is running hot; an agent checks the history, finds the pattern, and drafts the work order.
A chatbot responds within a conversation. A copilot assists inside a single application. An agent works across multiple systems and takes multi-step action toward a goal. The difference that matters operationally is that agents can do things, which is why permissioning and approval design matter far more than they do for a chatbot.
It is safe when scoped correctly and unsafe when it is not. The safe pattern is read-only access to operational data, advisory output, and human approval on any action with consequences. Agents should not write to control systems, and in most current oil and gas deployments they should not write autonomously to any operational system at all. The technology is not the control; the architecture and the approval design are.
The Manufacturing Data Record (also called the manufacturing record book or data dossier) is the compiled documentary evidence that an item was made, tested and certified as specified — material certificates, weld and NDT records, test reports, calibration certificates, and manuals. It matters because the asset’s integrity management, inspection planning, insurance position and regulatory compliance all depend on it for the life of the facility. An item delivered without an accepted MDR cannot be properly handed over, which is why final payment should be tied to its acceptance.
A consistent asset register that resolves the same equipment across your historian, CMMS and ERP. This is the single most common blocker. After that: a trustworthy historian, complete work-order history with proper failure coding, and a document store with reliable metadata and revision control. If you only fix one thing, fix the asset taxonomy.
No. A data lake is an architectural choice, not a prerequisite, and building one first is a common way to spend two years without delivering anything. What you need is reliable access to the specific data your first use case requires, with a consistent asset identifier. Start narrow.
OTIF against contractual dates, PR-to-PO cycle time, quoted versus actual lead time by category, cost variance against estimate, NCR rate per vendor, MDR completeness at delivery, and spend under contract as a share of total spend. Track the leading indicators too — requisition quality and time from requisition to enquiry usually explain most of the lagging numbers.
Plan six to nine months from decision to a meaningful result, with the first two to three months spent on data foundations rather than the agent. Pilots promised in six weeks either had unusually clean data or are demonstrating a capability rather than deploying one.
Expect twelve to eighteen months to a defensible return on a first use case, longer if data foundations need substantial work. The foundation investment — taxonomy, metadata, governance — pays back across every subsequent use case, so the second deployment is typically far cheaper and faster than the first. Judge the first project on learning and foundations as much as on savings.
Ground answers in retrieved documents and require citations; constrain the agent to a narrow scope; validate outputs structurally against known-good references such as the asset register; build a test set of verified questions and run it before every change; configure the agent to escalate rather than guess when confidence is low; and keep a competent human reviewing consequential output. No single measure is sufficient.
RAG retrieves relevant passages from your documents at query time and generates an answer grounded in them. Fine-tuning adjusts the model’s weights on your data so it internalises patterns and style. For oil and gas, RAG is almost always the right starting point: it handles frequently changing documents, provides citations you can audit, and does not require retraining when a procedure is revised. Fine-tuning is worth considering later for specialised terminology or consistent output formatting, and the two are complementary rather than alternatives.
Maintenance and reliability, inspection and integrity, and document control tend to succeed first — they have structured historical data, clear workflows, and outputs that are easy to check. Production optimisation and process safety support are valuable but need more mature data and tighter governance. Subsurface applications tend to be high value and high effort.
No, and they should not. Read from a historian replica on the IT side of your network. Any architecture requiring live OT access should be rejected at design review. The efficiency gain from direct control access does not justify weakening OT segmentation.
Data residency, licensing conditions and confidentiality obligations shape which model providers and hosting arrangements are viable. Classify your data before any of it leaves your network, confirm processing location and retention terms with any provider, and involve your legal and compliance functions at the architecture stage rather than at deployment.
Start with Introduction to Artificial Intelligence For Non-Data Scientists In Oil & Gas for shared vocabulary and realistic expectations, then take the domain course matching your intended use case, then the Agentic AI Applications in Upstream Oil & Gas Operations programme when you are ready to design a deployment.
EnergyEdge (PetroEdge Sdn. Bhd.) is an HRD Corp registered training provider offering HRD Corp claimable programmes in Malaysia. Confirm claimability for the specific course and cohort when you enquire.
Buy the model and the platform components; build the integration, the retrieval layer and the evaluation harness. The differentiating asset is your data and your domain knowledge, not the model. Be cautious of vendors offering an end-to-end agentic solution that requires no work on your data — that requirement does not disappear because a vendor does not mention it.
A first deployment typically needs one data engineer, one domain expert who owns the workflow, and a part-time product owner. It also needs a sponsor who will protect the timeline when the data problems surface in month two, because they will.