Developing intelligent agents for the oil and gas industry cannot be reduced to “connecting a large language model” or “configuring several agent applications.” Exploration and production involves complex business objects, long professional workflows, diverse data types, high accountability for deliverables, strict standards, and demanding review and traceability requirements. Whether an intelligent agent can progress from question-answering support to controlled execution depends on whether enterprise business resources have been organized into a system that machines can understand, invoke, constrain, review, and continuously enrich. This article proposes an L1–L5 intelligence capability classification for oil and gas intelligent agents. It emphasizes that each level requires a distinct boundary of responsibility between people and machines, degree of business-resource maturity, level of platform runtime control, and closed-loop evidence capability. Drawing on the overall architectural capabilities of the OiO platform while deemphasizing specific product names, the article explains the requirements at each level for Minimum Business Units (MBUs), C+IPOMSQ, data governance, tool components, rules and problem conditions, runtime control, and evidence chains across six capability layers: the business-model foundation, resource curation, resource operations, intelligent services, runtime support, and application delivery, together with closed-loop governance.
Keywords: oil and gas intelligent agents; intelligence capability classification; MBU; C+IPOMSQ; data governance; Runtime Harness; evidence chain; OiO platform architecture
Over the past two years, large language models and intelligent-agent technologies have rapidly entered the oil and gas industry. Many enterprises have begun experimenting with knowledge Q&A, conversational data analytics, intelligent map generation, report generation, production-performance analysis, and single-well diagnostics. Although all these applications may be described as “intelligent agents,” their actual capabilities differ substantially. Some can only help users retrieve information and prepare drafts; some can invoke tools under human direction; some can automatically execute a business unit within clearly defined rules and boundaries; and others can complete multistep task chains within an authorized business domain. Without a capability classification, the ability to “answer questions” can easily be mistaken for the ability to “assume responsibility for business execution,” resulting in distorted capability commitments, construction scope, and acceptance criteria.
Oil and gas work differs from general office tasks. A real exploration and production problem is rarely a simple natural-language question. It is jointly defined by business objects, professional workflows, data resources, maps and documents, standards, expert experience, methodology models, deliverable templates, review responsibilities, and evidence chains. Diagnosing the causes of declining production in a single well, for example, requires identification of the well, time range, production regime, daily oil and liquid production, water cut, pressure, intervention records, and neighboring-well effects. It also requires the selection of decline analysis, trend comparison, correlation analysis, case-based comparison, or other methods; compliance with production-performance analysis rules and deliverable-review requirements; and preservation of evidence for data sources, rule-based judgments, and expert review.
Oil and gas intelligent-agent development must therefore shift from a model-capability orientation to a business-automation-maturity orientation. Large language models are an important source of agent capability, but they are not the sole determinant of capability level. Progression to a higher level depends on whether the enterprise has structured its business resources, made rules executable and tools callable, standardized deliverables through templates, formalized management processes, established controlled runtime operations, and closed the evidence loop. An agent’s level essentially reflects how much responsibility the system can assume in a specific business task for business understanding, resource organization, task planning, tool execution, rule-based judgment, issue handling, deliverable generation, evidence traceability, and closed-loop optimization.
General-purpose large language models excel at language understanding, knowledge synthesis, and text generation. Enterprise-grade oil and gas agents must additionally resolve three questions: whether the business object has been identified accurately; whether the required resources can be loaded and invoked automatically by the system; and whether execution is constrained by rules, problem conditions, and an evidence chain. Only after these three transformations can an agent progress from “able to explain” to “able to execute.”
“Able to explain” mainly refers to answering questions, explaining concepts, producing summaries, and drafting content, which normally corresponds to L1 or L2. “Able to execute” requires the system to compile a user requirement into an MBU execution chain; automatically load context, input resources, tools, rules, deliverable templates, and evidence requirements; and block, downgrade, or transfer execution to a person when exceptions occur. These are the foundations of L3 and above.
Agent classification is not intended to create another concept. It establishes an engineering language that can be communicated, implemented, accepted, and used for investment assessment. For customers and business departments, it clarifies which work should begin with knowledge assistance, which can use human–machine collaboration, which may attempt conditional autonomy, and which can be developed into end-to-end task chains. For R&D and platform teams, it decomposes the work into concrete packages involving MBUs, C+IPOMSQ, data governance, tool components, rules and problem conditions, runtime control, and evidence chains.
From a project-management perspective, workload should not be estimated simply by counting “how many agents” will be built. It should be assessed comprehensively according to the number of business scenarios and MBUs covered, the depth of resource construction for each MBU, the depth of data governance, the difficulty of tool encapsulation, the complexity of rules and problem conditions, and Runtime and evidence-chain requirements. A classification standard enables the provider and customer to discuss stage objectives, investment intensity, and acceptance criteria against the same thresholds.
The classification can draw on the concept of autonomous-driving levels, but transportation standards should not be copied directly. Autonomous-driving levels measure human participation in driving tasks and the driving responsibility assumed by the system. Oil and gas agent levels should measure human participation in business tasks and the business-execution responsibility assumed by the system. The central question is not “Is AI present?” but “Who is responsible for planning, execution, judgment, fallback, and accountability?”
Level | Name | Capability Definition | Human–Machine Responsibility Boundary |
|---|---|---|---|
L1 | Intelligent Assistance | The system assists people with information retrieval, Q&A, summaries, and drafts. | People retain all business judgment and formal-deliverable responsibility. |
L2 | Human–Machine Collaboration | Under human direction, the system completes point tasks or localized business actions. | People plan, confirm, and integrate; the system performs localized execution. |
L3 | Conditional Autonomy | The system automatically executes an MBU within explicit business boundaries and rule conditions, transferring exceptions to a person. | The system assumes controlled-execution responsibility; people confirm exceptions and high-risk decisions. |
L4 | High Autonomy | The system executes an end-to-end task chain within an authorized business domain; people mainly perform sampling checks and risk confirmation. | The system assumes task-chain execution responsibility; people govern authorization, sampling, and risk. |
L5 | Full Autonomy | The system independently completes the business closed loop within its authorized scope. | People do not participate in specific execution and are responsible only for institutional authorization and periodic governance. |
L1 is the starting point for agent development. Its principal value lies in improving the efficiency of knowledge acquisition and content processing. The system can help users retrieve materials, answer knowledge questions, summarize documents, explain technical terminology, and generate report drafts, but it assumes no responsibility for business execution. Typical L1 outputs are reference materials rather than formal business deliverables. Key requirements at this stage are searchable materials, source-backed answers, and relatively unified terminology and business catalogs.
L2 moves beyond knowledge assistance into localized business actions. After the user specifies the business object, parameters, task, and deliverable requirements, the system can invoke a single tool or complete a localized action, such as data retrieval, map generation, parameter statistics, curve generation, or section drafting. People remain responsible for business planning, critical judgments, result integration, and formal confirmation; the system primarily improves localized execution efficiency.
L3 is the central dividing line in the classification. At L3, an agent no longer merely follows human instructions to perform isolated actions. Within explicit business boundaries and defined data, rule, and tool conditions, it automatically locates an MBU, loads its context and resources, generates execution instructions, invokes tools, and produces candidate formal deliverables. It transfers the task to a person or downgrades execution when exceptions, missing data, high risk, rule conflicts, or insufficient evidence arise. The critical L3 thresholds are the MBU Executable Profile, Rule Package, problem Trigger, Tool Contract, output template, and Evidence Requirement.
L4 progresses from execution of a single MBU to autonomy across a multi-MBU task chain. Within an authorized business domain, the system can complete an end-to-end workflow—from data preparation and anomaly detection through root-cause diagnosis and intervention recommendations to report generation, review, and archiving. The key to L4 is not that “the model generates more content,” but that the Runtime Harness controls context, resources, tools, rules, problem conditions, state, output, and evidence across the entire chain, producing deliverables that are reviewable, traceable, archivable, and reusable.
L5 is a long-term objective and should not be a general first-phase commitment. It is appropriate only when authorization is clear, data quality is high, rules are explicit, tools are mature, the evidence chain is complete, and the runtime feedback loop is stable. Exploration should focus on low-risk, high-frequency, repetitive, and standardized activities, such as standardized reporting, batch generation of fixed maps, routine monitoring, data-quality inspections, and rule-based alerts. High-risk, highly regulated, judgment-intensive, and complex cross-domain scenarios should retain mandatory human confirmation or enforced blocking even when partial automation is technically feasible.
The foundation of agent capability classification is not model parameters, but whether business tasks can be decomposed, located, and executed. A Minimum Business Unit (MBU) can be understood as the smallest unit of work in oil and gas operations. It anchors how an intelligent agent understands the business, organizes resources, and executes tasks. Building C+IPOMSQ around the MBU is the core method for transforming enterprise experience, data, methods, deliverables, rules, management requirements, and problem conditions into machine-usable resources.
In oil and gas operations, an agent should not confront scattered documents and databases directly. Instead, it should work with identifiable, loadable, and executable MBU resource packages. When a user submits a request, the system first identifies the object and its temporal, spatial, and professional semantics; maps the request to the relevant MBU; and then loads that MBU’s context, input data, tool components, deliverable templates, management requirements, rule constraints, and problem conditions. The higher the quality of the MBU, the more stable the agent’s task location. The more complete C+IPOMSQ is, the more reliable agent execution becomes.
Element | Term | Business Meaning | Role for the Agent |
|---|---|---|---|
C | Context | MBU node information, including business meaning, applicable scenarios, boundaries, risks, and evidence requirements | Helps the model understand business context and execution boundaries |
I | Input | Data, documents, maps, parameters, cases, and other MBU inputs | Determines result credibility and executability conditions |
P | Process/Tool | Tools, methods, processes, models, and components used by the MBU | Determines whether the agent can truly execute |
O | Output | Maps, tables, reports, conclusions, parameters, recommendations, and other MBU deliverables | Determines whether deliverables can be delivered, reviewed, and reused |
M | Management | Permissions, review, release, archiving, accountability, and version requirements | Determines whether deliverables can enter formal business processes |
S | Standard/Rule | Standards, business rules, and professional constraints observed by the MBU | Determines whether execution is compliant, controllable, and reviewable |
Q | Question/Condition | Potential issues and execution conditions, including missing data, conflicts, exceptions, risks, and insufficient evidence | Determines exception triggering, downgrade, blocking, and transfer-to-human mechanisms |
With only materials and documents and no MBUs, a system can do no more than ordinary Q&A and information retrieval. MBU names, five-dimensional coordinates, and basic Context can support L1/L2. Initial connections among C, I, P, and O enable human–machine collaboration. L3 becomes possible only when priority MBUs have executable profiles and complete S/Q, tools, templates, and evidence requirements. L4 requires multiple MBUs to form a stable Task Chain supported by a Runtime Harness and Evidence Chain. L5 can be explored only after domain-wide resource closure, comprehensive S/Q, end-to-end evidence chains, and mature feedback accumulation have been achieved.
Resource Development Status | Typical Characteristics | Capability Ceiling |
|---|---|---|
Scattered materials; no MBU | Documents and data can be found manually, but the system cannot reliably locate business units. | Below L1 or ordinary Q&A |
MBU names and basic C | Business catalogs, terminology, and basic descriptions are initially established. | L1–L2 |
Initial C+I/P/O connections | Key data, tools, and deliverable templates begin to be assigned to MBUs. | L2 |
Complete MBU executable profile | S/Q, tool contracts, deliverable templates, and evidence requirements are system-callable. | L3 |
Mature task chains and runtime control | Multi-MBU orchestration, runtime control, evidence chains, and KG1 writeback are complete. | L4 |
Mature domain-wide closed loop and autonomous governance | Resources, rules, tools, deliverables, and feedback are continuously optimized automatically. | L5 exploration |
An agent’s level is not determined by whether one capability is exceptional, but by whether MBU, C, I, P, O, M, S, Q, Runtime, and Evidence jointly meet the threshold. A powerful tool alone does not qualify an agent for L3. If rules are not executable, Q is merely an FAQ, deliverables lack templates, or the evidence chain is incomplete, the system remains at the assistance or collaboration level. The weakest-link principle can be expressed as: Agent Level = min [MBU maturity, C maturity, I maturity, P maturity, O maturity, M maturity, S maturity, Q maturity, Runtime maturity, Evidence maturity].
To deemphasize specific product names, OiO platform capabilities can be abstracted as “one foundation, two engines, three domains, six layers, and one closed loop.” The foundation is the Oil and Gas Business World Model. The two engines are the business-semantic engine and intelligent-runtime engine. The three domains are resource services, intelligent services, and application delivery. The six layers are the business-model foundation, resource curation, resource operations, intelligent services, runtime support, and business-application delivery. The closed loop consists of runtime feedback, rule completion, resource optimization, and capability accumulation.
This architecture demonstrates a basic fact: the agent application is only the top-level delivery form. The intelligence level is actually determined by the completeness of the underlying business model, resource governance, rules and problem conditions, tool components, runtime control, and evidence chain. Without the foundation, an agent can only answer questions. Without resource curation, it cannot obtain trustworthy input. Without tool contracts, it cannot execute. Without rules and Q, it cannot operate under control. Without Runtime, it cannot operate reliably. Without an evidence chain, its deliverables cannot be formally accepted.
The Oil and Gas Business World Model comprises business objects, five-dimensional coordinates, MBUs, C+IPOMSQ, business resources, rules and problem conditions, deliverable evidence, the KG0 Industry Ontology Graph, and the KG1 Enterprise Instance Resource Graph. It is not a static knowledge base, but the operational business foundation through which agents understand the business, organize resources, plan tasks, invoke tools, generate deliverables, and establish evidence chains. For a large language model, it provides enterprise context and executable boundaries. For business professionals, it is the vehicle for making tacit experience and professional standards explicit, structured, and reusable.
The business-semantic engine is responsible for “understanding correctly—doing the right thing.” It covers business objects, five-dimensional coordinates, MBUs, C+IPOMSQ, business ontologies, and knowledge graphs. The intelligent-runtime engine is responsible for “executing correctly—doing things right.” It covers intent recognition, task planning, execution-instruction generation, tool invocation, runtime-state management, exception handling, deliverable generation, evidence chains, and feedback loops. The engines are connected through the MBU Task Chain: the semantic engine locates business requirements within executable MBUs, while the runtime engine converts the MBU task chain into a controlled execution process.
The resource-service domain handles resource ingestion, governance, linkage, retrieval, invocation, and evidence management, enabling agents to progress from “able to find” to “able to use.” The intelligent-service domain handles requirement understanding, MBU location, context loading, S/Q matching, task-chain planning, and execution-instruction generation, serving as the compilation layer from user intent to machine task. The application-delivery domain packages underlying capabilities as business agents, Workspaces, conversational data analytics, intelligent mapping, report generation, and specialized applications for business users.
Layer | Capability | Primary Role |
|---|---|---|
Layer 1 | Business-model foundation | Five-dimensional coordinates, MBU, C+IPOMSQ, KG0, and standard business ontology |
Layer 2 | Resource curation | Identification, governance, assignment, and structuring of data, documents, maps, components, models, rules, problem conditions, and cases |
Layer 3 | Resource operations | Resource binding, indexing, permissions, versions, effective-resource views, and physical-storage management |
Layer 4 | Intelligent services | Intent recognition, MBU location, task planning, S/Q matching, and execution-instruction generation |
Layer 5 | Runtime support | Task Run, Context Package, Rule Package, Q Trigger, Tool Contract, Artifact, and Evidence Chain |
Layer 6 | Business-application delivery | Business agents, Workspaces, conversational data analytics, intelligent mapping, report generation, and specialized applications |
L1 primarily depends on Layers 1–2; L2 depends on Layers 1–3; L3 requires initial integration across Layers 1–5; L4 requires mature end-to-end capabilities; and L5 requires autonomous governance and a feedback loop across the complete chain.
L1 aims to help users find materials, understand knowledge, and prepare drafts more quickly. Its core value is time savings, and it assumes no responsibility for formal business deliverables. Resource-development priorities include standard-granularity MBUs, basic business descriptions, document ingestion, terminology lists, and source citations. Platform priorities include organizing data around the business, document parsing, knowledge-graph generation, knowledge and semantic retrieval, summarization, Q&A, and source attribution.
The L1 boundary must be explicit: system-generated content is reference material only and cannot be used directly as a formal conclusion, map, report, or externally released deliverable. At L1, enterprises should prioritize ingestion specifications, document knowledge bases, terminology repositories, and foundational Q&A applications, establishing a base for later L2/L3 resource assignment and business semantics.
L2 aims to complete localized business actions under explicit human direction and produce point deliverables, such as data retrieval, map generation, single-tool calls, section drafts, and parameter statistics. Its core value is labor savings, but people retain responsibility for business planning and formal confirmation. Resource-development priorities are MBU Core, foundational C, initial I/P/O linkage, tool registration, basic templates, and candidate S/Q.
At the platform level, L2 requires intent and object recognition, single-tool routing, basic data queries, map-template invocation, and draft generation. Tools need not yet have a complete Tool Contract, but they should at least have a tool inventory, input/output descriptions, invocation entry points, permission requirements, and basic logging. L2 often releases value quickly, but it must not be represented as autonomy.
L3 is the most critical capability transition in oil and gas agent development. Priority MBUs must have executable profiles: clear business boundaries, a unique core O, explicit upstream and downstream relationships, governable input resources, callable tools, executable rules, triggerable Q, verifiable deliverables, and traceable evidence. An L3 agent can automatically execute an MBU under explicit conditions and transfer it to a person when exceptions, missing data, high risk, or rule conflicts arise.
For business resources, L3 requires C to support execution instructions and S/Q generation; I to support quality checks, version management, and resource binding; P to provide a Tool Contract and input/output Schema; O to provide formal templates and quality checks; M to configure review, release, archiving, and accountability; S to provide reviewed and released rules and applicable conditions; and Q to provide trigger conditions, affected elements, response actions, and Q–S binding. At the platform level, L3 requires task execution, context loading, rule matching, Q inspection, tool calls, Artifact generation, evidence recording, exception handling, and transfer-to-human control.
L4 aims to execute end-to-end task chains within an authorized business domain, coordinating multiple nodes to complete a task independently—for example, single-well diagnosis, production-performance analysis, comprehensive report generation, or intelligent map review and release. Its core value is risk control, consistency, and productivity. L4 depends on multi-MBU Task Chains, the Runtime Harness, effective-resource views, tool-chain orchestration, rule-conflict handling, the Evidence Store, KG1, and review workflows.
At L4, business resources are dynamically loaded according to task context rather than statically linked. The system must control input data, resource versions, tool state, rule applicability, Q triggers, runtime state, and output quality across the complete chain. The Runtime Harness is the L4 execution-control kernel. It must uniformly manage Context, Resource, Tool, Rule, Q, State, Output, and Evidence, preventing the agent from degrading into unconstrained model-driven tool use.
L5 is a long-term evolutionary direction suited to repetitive work that is low-risk and high-frequency, with clear rules, mature tools, and high data quality. It requires high-quality coverage of the domain-wide MBU network and datasets, comprehensive S/Q, autonomous tool selection and continuous optimization, automatic deliverable checking, release, archiving, and reuse, institutional automated governance and auditing under M, 100% end-to-end traceability through the Evidence Chain, and automatic conversion of runtime feedback into rules, components, data-quality rules, and case assets.
L5 should not be committed as a first-phase deliverable. The oil and gas industry includes scenarios with substantial safety, compliance, accountability, and economic risk. Even where automation is technically feasible, institutional human confirmation or mandatory blocking may remain necessary. L5 exploration should begin with standardized reports, batch generation of fixed maps, routine monitoring, data-quality inspection, and rule-based alerts.
Different agent levels impose different requirements on C+IPOMSQ. L1 requires business MBU structuring, business-oriented data organization, resource retrievability, and understandable descriptions. L2 requires linkable resources, registered tools, and usable templates. L3 requires executable resources, enforceable rules, triggerable problem conditions, and recordable evidence. L4 requires orchestratable resources, operational task chains, and manageable exceptions. L5 requires closed-loop resources and autonomous optimization.
Element | L1 | L2 | L3 | L4 | L5 |
|---|---|---|---|---|---|
C | Basic business descriptions | Clear objects, actions, and purposes | Supports execution instructions and S/Q generation | Dynamic Context Package loading | Impact analysis and continuous feedback |
I | Searchable input materials | Explicit key-input inventory | Quality-controlled, traceable, version-managed inputs | Effective-resource views and dynamic loading | Automatic closure of missing-data and quality issues |
P | Searchable method descriptions | Initial tool/script registration | Complete Tool Contract, Schema, and applicable conditions | Tool-chain orchestration, fallback, and substitution | Autonomous selection and continuous optimization |
O | Q&A, summaries, and drafts | Basic map, table, and report templates | Formal templates, quality checks, and evidence requirements | Artifact archiving, reuse, and downstream triggers | Deliverable assetization and feedback closure |
M | Manual management and confirmation | Basic permissions and review | Configurable review, release, archiving, and accountability | Transfer-to-human for high risk and auditable accountability | Institutional autonomous governance |
S | Searchable standards | Candidate or semi-structured rules | Execution of released rule packages | Inheritance, override, conflict, version, and logs | Automatic rule-gap detection and completion |
Q | Risk prompts | Candidate problem conditions | Q Trigger, response action, and Q–S binding | Runtime triggers for data supplementation, downgrade, blocking, and review | Frequent Q feeds back into rules, components, and data quality |
C is the foundation for a model’s understanding of business boundaries and cannot be reduced to a one-sentence “business description.” High-level C should include the business definition, object scope, professional semantics, input/output summary, applicable conditions, boundary limitations, risk prompts, S/Q generation context, and evidence requirements. Missing C leads to generalized answers, inaccurate task location, and distorted rule matching.
I is more than a list of data sources. It covers input-resource availability, quality, version, lineage, permissions, and missing-data strategies. L3/L4 scenarios must establish high-quality datasets and effective-resource views so the system knows what data to use, which version applies, where it originated, what its quality is, whether access is authorized, and whether it can serve as evidence.
P maturity determines whether an agent can truly execute. L2 may require only tool registration. L3 requires a Tool Contract covering the tool name, inputs, outputs, parameters, applicable and prohibited conditions, exception strategy, permissions, and invocation logs. L4 requires tool-chain orchestration, alternative paths, failure retries, health checks, and state observability. L5 requires autonomous tool selection and continuous optimization.
O determines whether an agent’s output can progress from a draft to a formal business deliverable; M determines whether that deliverable can enter a formal enterprise process. Higher-level agents require explicit distinctions among candidate recommendations, deliverables pending review, and formal deliverables. Templates, quality checks, review workflows, release permissions, archive paths, and responsible parties must be defined for maps, tables, reports, conclusions, parameters, and intervention recommendations.
S represents MBU-oriented business rules and professional constraints, not merely standards documents. Formal execution must use a reviewed and released rule repository. Rules should specify applicable conditions, action types, constrained objects, sources, versions, and evidence requirements. Q is not an FAQ; it is an execution-problem-condition resource for detecting missing data, conflicts, invalid methods, unavailable tools, nonconforming deliverables, insufficient evidence, and review rejection, and for triggering data supplementation, quality inspection, method switching, downgrade, blocking, transfer to a person, and feedback.
Business resources determine the upper limit of agent capability; platform capabilities determine whether the agent can operate reliably. Platform capabilities can be grouped into five categories: business semantics, resource services, intelligent services, runtime control, and evidence-loop capabilities. Requirements rise progressively by level.
Platform Capability | L1 | L2 | L3 | L4 | L5 |
|---|---|---|---|---|---|
Business semantics | Catalogs, terminology, basic tags | MBU Core, five-dimensional coordinates, basic C | Executable profiles and C+IPOMSQ linkage | KG0 partial views and upstream/downstream relationships | Domain-wide MBU network and version-impact analysis |
Resource services | Resource retrieval | Resource linkage and indexing | Binding, permissions, quality, versions | Dynamic multi-resource fusion and effective-resource views | Automatic resource completion and continuous governance |
Intelligent services | Q&A, retrieval, summaries | Intent/object recognition and single-tool routing | MBU location, S/Q matching, execution instructions | Task Chain planning and Preflight Check | Autonomous planning and dynamic replanning |
Runtime control | Basic logs | Single-tool invocation | Task Run, Context, Rule, Q, Artifact, Evidence | Runtime Harness, state, exceptions, orchestration, KG1 writeback | Autonomous operation, feedback, and optimization |
Evidence loop | Source citations | Basic input/tool/output records | Complete input, rule, Q, tool, model, output, and review records | Evidence Store, KG1, and deliverable lineage | 100% end-to-end traceability and automated auditing |
Business-semantic capabilities transform enterprise business into machine-understandable objects, relationships, and rule structures. Lower levels support catalogs, terminology, and tags. Intermediate levels develop MBU Core, five-dimensional coordinates, and foundational C. Higher levels require MBU executable profiles, upstream and downstream relationships, task chains, and a domain-wide MBU network.
Resource-service capabilities transform data, documents, maps, models, tools, rules, problem conditions, and cases from scattered materials into managed assets. Core capabilities include ingestion, governance, assignment, indexing, permissions, versions, quality, lineage, effective-resource views, and physical-storage binding. Without resource services, an agent cannot reliably obtain trustworthy inputs or produce traceable deliverables.
Intelligent services do not directly replace all business work; they compile user requirements into machine-executable task plans. They perform intent and object recognition, MBU location, context loading, resource-view generation, S/Q matching, task-chain planning, execution-instruction generation, and exception-path planning. At L3 and above, an intelligent service must output an MBU Execution Command or Task Run Plan rather than merely natural-language advice.
Runtime control is a core L3/L4 platform capability. It executes task plans, manages state, invokes tools, enforces rules, checks Q, generates Artifacts, records evidence, and handles exceptions. Without a Runtime Harness, an agent can degrade into unconstrained model-driven tool use: it may appear automated, yet have unclear state, unstable rules, incomplete evidence, and ungovernable exceptions.
The evidence chain is the basis of customer trust in formal agent deliverables. L1/L2 may record sources and localized tool calls. L3 must record inputs, rules, Q, tools, models, outputs, and human review. L4 requires an Evidence Store, KG1 instance relationships, and deliverable lineage. L5 requires 100% end-to-end traceability that automatically supports audits, reviews, optimization, and downstream reuse.
Agent classification should be applied to specific scenarios rather than used as an abstract label for an entire platform. Different scenarios on the same platform may operate at different levels, and different MBUs within the same scenario may have different degrees of resource maturity. The following examples cover conversational data analytics, intelligent mapping, diagnosis of declining single-well production, and drilling geological design report generation.
Scenario | L1 | L2 | L3 | L4 |
|---|---|---|---|---|
Conversational data analytics | Natural-language retrieval of specific data | Natural-language invocation of an MBU’s I/P to generate O | Convert the request into MBU location, metric-definition rules, quality checks, and a result evidence chain | Automatically identify objectives, query multiple sources, detect exceptions, and generate analysis |
Intelligent mapping | Map retrieval and explanation | Generate a draft through a specified map type and tool | Organize map MBUs, templates, input requirements, layer rules, and quality checks; generate a map editable in natural language | Automatic mapping and checks, archiving, evidence chain, downstream reuse, and natural-language editing |
Single-well diagnosis | Production-data retrieval and curve browsing | Diagnostic draft and basic charts | Load diagnostic MBU and I/P/S/Q to produce a candidate diagnosis automatically | Execute a multi-MBU task chain and generate intervention recommendations and a complete evidence chain |
Report generation | Section-material retrieval and summaries | Single-section draft generation | Executable section MBU and reviewable section generation | Multi-section Task Chain with unified management of dependencies, maps, tables, rules, and evidence |
Although conversational data analytics appears to be natural-language querying, it is actually continued data processing and business-oriented output for tool-based business requirements. Reaching L3 requires metric resources, dataset resources, metric-definition rules, data-quality Q, field mappings, data lineage, and a query-result evidence chain. Otherwise, the system can only indicate where data may be found or generate a SQL draft; it cannot produce reliable analytical results. At L4, the system should automatically identify the business objective, query multiple sources, detect anomalies, generate analytical tables, and retain the evidence chain in the results.
To progress from “finding and explaining maps” to “automatic mapping, automatic checks, deliverable archiving, and free-form editing,” intelligent mapping requires map MBUs, map templates, layers and graphic elements, input-data requirements, layer rules, quality-check rules, mapping components, and map evidence chains. L4 intelligent mapping is not simply a call to a mapping tool; it is a controlled task chain comprising data preparation, template application, layer organization, automatic mapping, quality checks, deliverable archiving, and downstream reuse.
This scenario is well suited to an L3/L4 breakthrough. Its MBUs include anomaly detection, trend analysis, root-cause diagnosis, and intervention recommendations. I includes daily oil and liquid production, water cut, pressure, fluid level, intervention records, and neighboring-well data. P includes trend, decline, correlation, performance-comparison, and case-based analyses. S includes rules for data completeness, abnormal-decline determination, method applicability, and deliverable quality. Q includes missing data, method inapplicability, multi-factor coupling, version conflicts, and insufficient evidence. The recommended first phase is L3, followed by L4 for priority blocks or well classes, while expert review is retained for high-risk interventions.
Generating a drilling geological design report is not simple text generation. It is a multi-section, multi-MBU, multi-resource, multi-rule, and multi-evidence process for organizing and producing a formal deliverable. Section MBUs may include regional geology, formation prediction, pressure prediction, risk identification, well-structure recommendations, and section generation. I includes seismic, well-log, mud-log, offset-well, formation, pressure, structural, and risk information. S/Q covers report-format and map specifications, missing materials, version conflicts, insufficient evidence, and uncovered risks. The recommended path is section-level L2/L3, followed by multi-section collaboration at L3 and, ultimately, a complete report Task Chain at L4.
Oil and gas agent initiatives should not pursue high levels comprehensively from the outset. They should follow a path of “platform-foundation capabilities first, differentiated progress by business scenario, and early L3/L4 breakthroughs in priority scenarios.” This creates L1/L2 experience value quickly, validates the L3/L4 path through high-value scenarios, and progressively accumulates reusable enterprise capabilities.
Phase | Objective | Primary Work | Target Level |
|---|---|---|---|
Phase 1: Standards and foundation | Establish unified classification and business-resource foundations | Classification, MBU standards, C+IPOMSQ Schema, resource types, S/Q Schema | Support L1/L2 |
Phase 2: Basic resources | Develop MBU Core and foundational resource linkage | Initial C and I/P/O linkage, document assignment, tool registration, basic templates | L1–L2 |
Phase 3: Executable priority MBUs | Create an executable MBU reference model | MBU Executable Profile, Rule Package, Q Trigger, Tool Contract, O template | L3 |
Phase 4: Task-chain enablement for priority scenarios | Create benchmark priority business chains | Task Chain, Runtime Harness, Evidence Chain, KG1, review workflow | L3/L4 |
Phase 5: Closed-loop optimization and scaling | Create replicable, continuously evolving capabilities | Runtime feedback, rule completion, component optimization, data governance, template correction, cross-scenario replication | L4 → L5 exploration |
Pilots should not prioritize the most complex, highest-risk scenarios with the least accessible data. They should prioritize scenarios with high business value, relatively available data, encapsulable tools, comparatively explicit rules, expert reviewability, verifiable deliverables, controllable risk, and reusable templates. Using representative MBUs to prove the L3/L4 path is more valuable than deploying many generalized agents at once.
The quality of customer participation determines the upper limit of agent capability. Customers must do more than submit requirements: they must participate in scenario confirmation, expert-team organization, MBU analysis, data provision and governance, rule and standards provision, tool-component confirmation, deliverable-template confirmation, review-process confirmation, pilot validation, and feedback. At L3 and above, customer experts must participate in defining MBU boundaries, reviewing rules, confirming Q conditions, establishing deliverable templates, and designing high-risk review workflows.
Work Package | Customer Input | Platform Development | Deliverable |
|---|---|---|---|
WP1 Classification standard | Business objectives, application scenarios, capability requirements | Classification model, capability dimensions, evaluation criteria | Classification standard and assessment template |
WP2 MBU standardization | Organization, responsibilities, current processes | MBU reference architecture and standard processes | MBU standards manual and process maps |
WP3 C resources | Role inventory, current skills, available resources | Business meaning, context model, resource pool | C resource repository |
WP4 I data governance | Data inventory, current quality, compliance requirements | Data standards, governance processes, lineage, permissions | Data dictionary and governance report |
WP5 P tool components | Existing-tool inventory and integration requirements | Tool selection, component integration, Tool Contract | Component inventory and integration plan |
WP6 O templates | Best practices and business-template requirements | Template-repository design and parameterized configuration | Template repository and user guide |
WP7 M management | Current management mechanisms and review requirements | Management model, permissions, review, release, archiving | Management mechanism and dashboard plan |
WP8 S rules | Compliance requirements and business-rule inventory | Rule modeling, review, and rule-package release | Rule repository and execution strategy |
WP9 Q conditions | Trigger conditions, historical issues, expert experience | Condition model, trigger strategy, monitoring | Q condition inventory and response strategy |
WP10 Intelligent services | Service requirements and effectiveness metrics | Intent recognition, MBU location, task planning | Intelligent-service inventory and evaluation report |
WP11 Runtime Harness | Runtime-environment requirements and integration points | Runtime framework, orchestration, monitoring, alerts | Runtime framework and operations manual |
WP12 Closed-loop governance | Issue inventory and improvement requests | Feedback process, measurement, continuous improvement | Closed-loop report and improvement plan |
If agent levels are not tied to business resources, platform capabilities, and deliverables, classification can easily become a conceptual slogan. The greatest risks are discussing L1–L5 without specifying the MBUs, C+IPOMSQ, data, tools, S/Q, Runtime, and evidence chains required at each level, or overcommitting to L5 and leading customers to believe that experts can be fully replaced in the short term.
Risk | Manifestation | Control Measure |
|---|---|---|
Classification becomes a slogan | L1–L5 labels without evaluation standards or verifiable deliverables | Bind every level to MBU, C+IPOMSQ, data, tools, S/Q, Runtime, and evidence-chain deliverables |
Overcommitment to L5 | Claims of full automation before capabilities, data, and institutions are ready | Define L5 as a long-term goal; focus stages on L2/L3 and priority-scenario L4 |
Unclear MBU | Unclear responsibilities and uncontrolled task chains | Prioritize MBU boundaries, core O, and upstream/downstream relationships |
Insufficient data governance | Poor quality, inconsistent definitions, no lineage, and disordered permissions | Develop standards, quality, versions, lineage, permissions, and missing-data strategies |
Tools not callable | Unstable interfaces, inaccessible permissions, and non-orchestratable tools | Establish Tool Contracts, a tool catalog, health checks, and alternatives |
Immature S/Q | Rules are not executable and Q is treated as an FAQ | Release S in structured form; convert Q into execution conditions bound to response actions |
Missing evidence chain | Deliverables cannot be reviewed or held accountable | Require evidence chains and Artifact archiving at L3 and above |
Insufficient Runtime control | Unconstrained tool use with uncontrolled state and exceptions | Establish runtime-state management, rule packages, Q checks, exception handling, and auditing |
Classifying the intelligence capability of oil and gas agents is, in essence, classifying enterprise business-automation maturity. L1 is retrievable, answerable, and assistive. L2 is connectable, collaborative, and capable of point execution. L3 is executable, rule-constrained, problem-triggered, and able to form an evidence chain. L4 supports task-chain operation, controlled autonomy, reviewable archiving, and knowledge accumulation. L5 supports domain-wide autonomy, closed-loop optimization, and continuous evolution.
The central judgment behind this method is that large language models provide the linguistic, reasoning, and generative foundation for intelligence, but enterprise business-resource development and intelligent-platform capability are more decisive in determining agent level. Without MBUs, an agent cannot locate the business. Without C+IPOMSQ, it cannot understand resources, tools, deliverables, rules, problem conditions, and management requirements. Without data governance, it cannot form trustworthy conclusions. Without tool contracts, it cannot truly execute. Without S/Q, it cannot operate under control. Without a Runtime Harness, it cannot reliably execute task chains. Without an Evidence Chain, its deliverables cannot become formal business assets.
Oil and gas enterprises should therefore avoid simply pursuing “more agents” or “a more powerful model.” They should focus on priority business scenarios and follow a path of tiered development, focused breakthroughs, and closed-loop evolution: use L1/L2 to start quickly and validate user experience; use L3 to establish executable business reference models; use L4 to create benchmark priority business chains; and treat L5 as a long-term exploration of autonomy in low-risk repetitive work. Only when enterprise business-resource systems and intelligent-platform capabilities mature together can oil and gas agents truly progress from knowledge assistants to trustworthy, controlled, reviewable, and reusable systems for intelligent business execution.
This article is synthesized from the Technical Proposal for Oil and Gas Intelligent-Agent Capability Classification and OiO Platform Development Requirements and the Customer Presentation Outline for Oil and Gas Intelligent-Agent Capability Classification and OiO Platform Development Requirements. Specific product names have been deemphasized while the underlying architectural capabilities and product-function logic have been retained.
About Us
