FIELD OPERATIONS FRAMEWORK

Description

RELATED APPLICATION

This application claims priority to and the benefit of a U.S. Provisional Application having Serial No. 63/633,818, filed 14 April 2024, which is incorporated by reference herein in its entirety.

BACKGROUND

A reservoir may be a subsurface formation that may be characterized at least in part by its porosity and fluid permeability. As an example, a reservoir may be part of a basin such as a sedimentary basin. A basin may be a depression (e.g., caused by plate tectonic activity, subsidence, etc.) in which sediments accumulate. As an example, where hydrocarbon source rocks occur in combination with appropriate depth and duration of burial, a petroleum system may develop within a basin, which may form a reservoir that includes hydrocarbon fluids (e.g., oil, gas, etc.).

In oil and gas exploration, interpretation is a process that involves analysis of data to identify and locate various subsurface structures (e.g., horizons, faults, geobodies, etc.) in a geologic environment. Various types of structures (e.g., stratigraphic formations) may be indicative of hydrocarbon traps or flow channels, as may be associated with one or more reservoirs (e.g., fluid reservoirs). In the field of resource extraction, enhancements to interpretation may allow for construction of a more accurate model of a subsurface region, which, in turn, may improve characterization of the subsurface region for purposes of resource extraction. Characterization of one or more subsurface regions in a geologic environment may guide, for example, performance of one or more operations (e.g., field operations, etc.). As an example, a plan may depend on a model of a subsurface region where the plan may specify how a drilling operation may accurately construct a borehole according to a trajectory that penetrates a reservoir, etc., where fluid may be produced via the borehole (e.g., as a completed well, etc.). As an example, one or more workflows may be performed using one or more computational frameworks, systems, etc., for one or more of analysis, acquisition, model building, control, etc., for exploration, interpretation, drilling, fracturing, production, etc.

SUMMARY

A method may include receiving a prompt via a large language model agent in a framework that includes multiple large language model agents; responsive to the prompt, generating one or more agent actions; transmitting the one or more agent actions to one or more of the multiple large language model agents; and, responsive to the transmitting, generating a control action implementable by a controller operatively coupled to one or more pieces of equipment at a field site. A system may include one or more processors; memory accessible to at least one of the one or more processors; processor-executable instructions stored in the memory and executable to instruct the system to: receive a prompt via a large language model agent in a framework that includes multiple large language model agents; responsive to the prompt, generate one or more agent actions; transmit the one or more agent actions to one or more of the multiple large language model agents; and, responsive to the transmission, generate a control action implementable by a controller operatively coupled to one or more pieces of equipment at a field site. One or more computer-readable storage media may include processor-executable instructions to instruct a computing system to: receive a prompt via a large language model agent in a framework that includes multiple large language model agents; responsive to the prompt, generate one or more agent actions; transmit the one or more agent actions to one or more of the multiple large language model agents; and, responsive to the transmission, generate a control action implementable by a controller operatively coupled to one or more pieces of equipment at a field site. Various other apparatuses, systems, methods, etc., are also disclosed.

This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in limiting the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description refers to the accompanying drawings. Wherever convenient Features and advantages of the described implementations may be more readily understood by reference to the following description taken in conjunction with the accompanying drawings.

FIG. 1 shows an example of a system;

FIG. 2 shows an example of a system;

FIG. 3 shows an example of a system;

FIG. 4 shows an example of a system;

FIG. 5 shows examples of prompts and actions;

FIG. 6 shows examples of large language model agents;

FIG. 7 shows examples of architectures;

FIG. 8 shows an example of a system;

FIG. 9 shows an example of an architecture;

FIG. 10 shows an example of a system;

FIG. 11 shows an example of a system;

FIG. 12 shows an example of a method and an example of a system; and

FIG. 13 shows an example of a system.

DETAILED DESCRIPTION

This description is not to be taken in a limiting sense, but rather is made merely for the purpose of describing the general principles of the implementations. The scope of the described implementations should be ascertained with reference to the issued claims.

FIG. 1 shows an example of a system 100 that includes a workspace framework 110 that may provide for instantiation of, rendering of, interactions with, etc., a graphical user interface (GUI) 120. In the example of FIG. 1, the GUI 120 may include graphical controls for computational frameworks (e.g., applications, etc.) 121, projects 122, visualization features 123, one or more other features 124, data access 125, and data storage 126.

In the example of FIG. 1, the workspace framework 110 may be tailored to a particular geologic environment such as an example geologic environment 150. For example, the geologic environment 150 may include layers (e.g., stratification) that include a reservoir 151 and that may be intersected by a fault 153. As an example, the geologic environment 150 may be outfitted with a variety of sensors, detectors, actuators, etc. For example, equipment 152 may include communication circuitry to receive and to transmit information with respect to one or more networks 155. Such information may include information associated with downhole equipment 154, which may be equipment to acquire information, to assist with resource recovery, etc. Other equipment 156 may be located remote from a wellsite and include sensing, detecting, emitting or other circuitry. Such equipment may include storage and communication circuitry to store and to communicate data, instructions, etc. As an example, one or more satellites may be provided for purposes of communications, data acquisition, etc. For example, FIG. 1 shows a satellite 170 in communication with the network 155 that may be configured for communications, noting that the satellite 170 may additionally or alternatively include circuitry for imagery (e.g., spatial, spectral, temporal, radiometric, etc.).

FIG. 1 also shows the geologic environment 150 as optionally including equipment 157 and 158 associated with a well that includes a substantially horizontal portion that may intersect with one or more fractures 159. For example, consider a well in a shale formation that may include natural fractures, artificial fractures (e.g., hydraulic fractures) or a combination of natural and artificial fractures. As an example, a well may be drilled for a reservoir that is laterally extensive. In such an example, lateral variations in properties, stresses, etc. may exist where an assessment of such variations may assist with planning, operations, etc. to develop a laterally extensive reservoir (e.g., via fracturing, injecting, extracting, etc.). As an example, the equipment 157 and/or 158 may include components, a system, systems, etc. for fracturing, seismic sensing, analysis of seismic data, assessment of one or more fractures, etc.

In the example of FIG. 1, the GUI 120 shows some examples of computational frameworks, including the DRILLPLAN, DRILLOPS, PETREL, TECHLOG, PETROMOD, ECLIPSE, PIPESIM, and INTERSECT frameworks (SLB, Houston, Texas).

The DRILLPLAN framework provides for digital well construction planning and includes features for automation of repetitive tasks and validation workflows, enabling improved quality drilling programs (e.g., digital drilling plans, etc.) to be produced quickly with assured coherency.

The DRILLOPS framework may execute a digital drilling plan and ensures plan adherence, while delivering goal-based automation. The DRILLOPS framework may generate activity plans automatically individual operations, whether they are monitored and/or controlled on the rig or in town. Automation may utilize data analysis and learning systems to assist and optimize tasks, such as, for example, setting ROP to drilling a stand. A preset menu of automatable drilling tasks may be rendered, and, using data analysis and models, a plan may be executed in a manner to achieve a specified goal, where, for example, measurements may be utilized for calibration. The DRILLOPS framework provides flexibility to modify and replan activities dynamically, for example, based on a live appraisal of various factors (e.g., equipment, personnel, and supplies). Well construction activities (e.g., tripping, drilling, cementing, etc.) may be continually monitored and dynamically updated using feedback from operational activities. The DRILLOPS framework may provide for various levels of automation based on planning and/or re-planning (e.g., via the DRILLPLAN framework), feedback, etc.

The PETREL framework may be part of the DELFI environment for utilization in geosciences and geoengineering, for example, to analyze subsurface data from exploration to production of fluid from a reservoir. The DELFI cognitive exploration and production (E&P) environment (SLB, Houston, Texas), referred to herein as the DELFI environment or DELFI framework, is a secure, cognitive, cloud-based collaborative environment that integrates data and workflows with digital technologies, such as artificial intelligence and machine learning.

The PETREL framework provides components that allow for optimization of various exploration, development and production operations. The PETREL framework includes seismic to simulation software components that may output information for use in increasing reservoir performance, for example, by improving asset team productivity. Through use of such a framework, various professionals (e.g., geophysicists, geologists, and reservoir engineers) may develop collaborative workflows and integrate operations to streamline processes (e.g., with respect to one or more geologic environments, etc.). Such a framework may be considered an application (e.g., executable using one or more devices) and may be considered a data-driven application (e.g., where data is input for purposes of modeling, simulating, etc.).

The TECHLOG framework may handle and process field and laboratory data for a variety of geologic environments (e.g., deepwater exploration, shale, etc.). The TECHLOG framework may structure wellbore data for analyses, planning, etc.

The PETROMOD framework provides petroleum systems modeling capabilities that may combine one or more of seismic, well, and geological information to model the evolution of a sedimentary basin. The PETROMOD framework may predict if, and how, a reservoir has been charged with hydrocarbons, including the source and timing of hydrocarbon generation, migration routes, quantities, and hydrocarbon type in the subsurface or at surface conditions.

The ECLIPSE framework provides a reservoir simulator (e.g., as a computational framework) with numerical solutions for fast and accurate prediction of dynamic behavior for various types of reservoirs and development schemes.

The INTERSECT framework provides a high-resolution reservoir simulator for simulation of detailed geological features and quantification of uncertainties, for example, by creating accurate production scenarios and, with the integration of precise models of the surface facilities and field operations, the INTERSECT framework may produce reliable results, which may be continuously updated by real-time data exchanges (e.g., from one or more types of data acquisition equipment in the field that may acquire data during one or more types of field operations, etc.). The INTERSECT framework may provide completion configurations for complex wells where such configurations may be built in the field, may provide detailed enhanced-oil-recovery (EOR) formulations where such formulations may be implemented in the field, may analyze application of steam injection and other thermal EOR techniques for implementation in the field, advanced production controls in terms of reservoir coupling and flexible field management, and flexibility to script customized solutions for improved modeling and field management control. The INTERSECT framework, as with the other example frameworks, may be utilized as part of the DELFI environment, for example, for rapid simulation of multiple concurrent cases. For example, a workflow may utilize one or more of the DELFI environment on demand reservoir simulation features.

The aforementioned DELFI environment provides various features for workflows as to subsurface analysis, planning, construction and production, for example, as illustrated in the workspace framework 110. As shown in FIG. 1, outputs from the workspace framework 110 may be utilized for directing, controlling, etc., one or more processes in the geologic environment 150 and, feedback 160, may be received via one or more interfaces in one or more forms (e.g., acquired data as to operational conditions, equipment conditions, environment conditions, etc.).

As an example, a workflow may progress to a geology and geophysics (“G&G”) service provider, which may generate a well trajectory, which may involve execution of one or more G&G frameworks (e.g., consider the PETREL framework, etc.).

In the example of FIG. 1, the visualization features 123 may be implemented via the workspace framework 110, for example, to perform tasks as associated with one or more of subsurface regions, planning operations, constructing wells and/or surface fluid networks, and producing from a reservoir.

As an example, a visualization process may implement one or more of various features that may be suitable for one or more web applications. For example, a template may involve use of the JAVASCRIPT object notation format (JSON) and/or one or more other languages/formats. As an example, a framework may include one or more converters. For example, consider a JSON to PYTHON converter and/or a PYTHON to JSON converter. Such an approach may provide for compatibility of devices, frameworks, etc., with respect to one or more sets of instructions.

As an example, visualization features may provide for visualization of various earth models, properties, etc., in one or more dimensions. As an example, visualization features may provide for rendering of information in multiple dimensions, which may optionally include multiple resolution rendering. In such an example, information being rendered may be associated with one or more frameworks and/or one or more data stores. As an example, visualization features may include one or more control features for control of equipment, which may include, for example, field equipment that may perform one or more field operations. As an example, a workflow may utilize one or more frameworks to generate information that may be utilized to control one or more types of field equipment (e.g., drilling equipment, wireline equipment, fracturing equipment, etc.).

As to a reservoir model that may be suitable for utilization by a simulator, consider acquisition of seismic data as acquired via reflection seismology, which finds use in geophysics, for example, to estimate properties of subsurface formations. As an example, reflection seismology may provide seismic data representing waves of elastic energy (e.g., as transmitted by P-waves and S-waves, in a frequency range of approximately 1 Hz to approximately 100 Hz). Seismic data may be processed and interpreted, for example, to understand better composition, fluid content, extent and geometry of subsurface rocks. Such interpretation results may be utilized to plan, simulate, perform, etc., one or more operations for production of fluid from a reservoir (e.g., reservoir rock, etc.).

As an example, a model may be a simulated version of a geologic environment. As an example, a simulator may include features for simulating physical phenomena in a geologic environment based at least in part on a model or models. A simulator, such as a reservoir simulator, may simulate fluid flow in a geologic environment based at least in part on a model that may be generated via a framework that receives seismic data. A simulator may be a computerized system (e.g., a computing system) that may execute instructions using one or more processors to solve a system of equations that describe physical phenomena subject to various constraints. In such an example, the system of equations may be spatially defined (e.g., numerically discretized) according to a spatial model that that includes layers of rock, geobodies, etc., that have corresponding positions that may be based on interpretation of seismic and/or other data. A spatial model may be a cell-based model where cells are defined by a grid (e.g., a mesh). A cell in a cell-based model may represent a physical area or volume in a geologic environment where the cell may be assigned physical properties (e.g., permeability, fluid properties, etc.) that may be germane to one or more physical phenomena (e.g., fluid volume, fluid flow, pressure, etc.). A reservoir simulation model may be a spatial model that may be cell-based.

While several simulators are illustrated in the example of FIG. 1, one or more other simulators may be utilized, additionally or alternatively. For example, consider the VISAGE geomechanics simulator (SLB, Houston Texas) or the PIPESIM network simulator (SLB, Houston Texas), etc.

As an example, a workflow may utilize one or more types of data for one or more processes (e.g., stratigraphic modeling, basin modeling, completion designs, drilling, production, injection, etc.). As an example, one or more tools may provide data that may be used in a workflow or workflows that may implement one or more frameworks (e.g., PETREL, TECHLOG, PETROMOD, ECLIPSE, etc.).

As an example, a platform, such as, for example, the LUMI platform (SLB, Houston, Texas) may be utilized. The LUMI platform includes features that provide for artificial intelligence solutions as may be integrated with data management capabilities. The LUMI platform provides for flexible deployment options and an open, secure, and modular architecture, for example, to empower data-driven decision-making.​ The LUMI platform is operable with the DELFI environment and, hence, one or more of various frameworks. While various platforms, environments, frameworks, libraries, etc., are mentioned, a framework may be operable in an agnostic manner, for example, to be compatible with one or more other platforms, environments, frameworks, libraries, technologies, etc.

In the example of FIG. 1, drilling may be performed in the geologic environment 150, for example, to access the reservoir 151, which may be accessed from land or offshore. In FIG. 1, the downhole equipment 154 may be, for example, part of a bottom hole assembly (BHA). The BHA may be used to drill a well. The downhole equipment 154 may communicate information to equipment at the surface, and may receive instructions and information from the equipment at the surface. During a well construction process, a variety of operations (such as cementing, wireline evaluation, testing, etc.) may be conducted. In such embodiments, data collected by tools and sensors and used for reasons such as reservoir characterization may be collected and transmitted.

A well may include a substantially horizontal portion (e.g., lateral portion) that may intersect with one or more fractures. For example, a well in a shale formation may pass through natural fractures, artificial fractures (e.g., hydraulic fractures), or a combination thereof. Such a well may be constructed using directional drilling techniques as described herein. However, these same techniques may be used in connection with other types of directional wells (such as slant wells, S-shaped wells, deep inclined wells, and others) and are not limited to horizontal wells.

FIG. 2 shows an example of a wellsite system 200 (e.g., at a wellsite that may be onshore or offshore). As shown, the wellsite system 200 may include a mud tank 201 for holding mud and other material (e.g., where mud may be a drilling fluid), a suction line 203 that serves as an inlet to a mud pump 204 for pumping mud from the mud tank 201 such that mud flows to a vibrating hose 206, a drawworks 207 for winching drill line or drill lines 212, a standpipe 208 that receives mud from the vibrating hose 206, a kelly hose 209 that receives mud from the standpipe 208, a gooseneck or goosenecks 210, a traveling block 211, a crown block 213 for carrying the traveling block 211 via the drill line or drill lines 212, a derrick 214, a kelly 218 or a top drive 240, a kelly drive bushing 219, a rotary table 220, a drill floor 221, a bell nipple 222, one or more blowout preventors (BOPs) 223, a drillstring 225, a drill bit 226, a casing head 227 and a flow pipe 228 that carries mud and other material to, for example, the mud tank 201.

In the example system of FIG. 2, a borehole 232 is formed in subsurface formations 230 by rotary drilling; noting that various example embodiments may also use one or more directional drilling techniques, equipment, etc.

As shown in the example of FIG. 2, the drillstring 225 is suspended within the borehole 232 and has a drillstring assembly 250 that includes the drill bit 226 at its lower end. As an example, the drillstring assembly 250 may be a bottom hole assembly (BHA).

The wellsite system 200 may provide for operation of the drillstring 225 and other operations. As shown, the wellsite system 200 includes the traveling block 211 and the derrick 214 positioned over the borehole 232. As mentioned, the wellsite system 200 may include the rotary table 220 where the drillstring 225 pass through an opening in the rotary table 220.

As shown in the example of FIG. 2, the wellsite system 200 may include the kelly 218 and associated components, etc., or a top drive 240 and associated components. As to a kelly example, the kelly 218 may be a square or hexagonal metal/alloy bar with a hole drilled therein that serves as a mud flow path. The kelly 218 may be used to transmit rotary motion from the rotary table 220 via the kelly drive bushing 219 to the drillstring 225, while allowing the drillstring 225 to be lowered or raised during rotation. The kelly 218 may pass through the kelly drive bushing 219, which may be driven by the rotary table 220. As an example, the rotary table 220 may include a master bushing that operatively couples to the kelly drive bushing 219 such that rotation of the rotary table 220 may turn the kelly drive bushing 219 and hence the kelly 218. The kelly drive bushing 219 may include an inside profile matching an outside profile (e.g., square, hexagonal, etc.) of the kelly 218; however, with slightly larger dimensions so that the kelly 218 may freely move up and down inside the kelly drive bushing 219.

As to a top drive example, the top drive 240 may provide functions performed by a kelly and a rotary table. The top drive 240 may turn the drillstring 225. As an example, the top drive 240 may include one or more motors (e.g., electric and/or hydraulic) connected with appropriate gearing to a short section of pipe called a quill, that in turn may be screwed into a saver sub or the drillstring 225 itself. The top drive 240 may be suspended from the traveling block 211, so the rotary mechanism is free to travel up and down the derrick 214. As an example, a top drive 240 may allow for drilling to be performed with more joint stands than a kelly/rotary table approach.

In the example of FIG. 2, the mud tank 201 may hold mud, which may be one or more types of drilling fluids. As an example, a wellbore may be drilled to produce fluid, inject fluid or both (e.g., hydrocarbons, minerals, water, etc.).

In the example of FIG. 2, the drillstring 225 (e.g., including one or more downhole tools) may be composed of a series of pipes threadably connected together to form a long tube with the drill bit 226 at the lower end thereof. As the drillstring 225 is advanced into a wellbore for drilling, at some point in time prior to or coincident with drilling, the mud may be pumped by the pump 204 from the mud tank 201 (e.g., or other source) via the lines 206, 208 and 209 to a port of the kelly 218 or, for example, to a port of the top drive 240. The mud may then flow via a passage (e.g., or passages) in the drillstring 225 and out of ports located on the drill bit 226 (see, e.g., a directional arrow). As the mud exits the drillstring 225 via ports in the drill bit 226, it may then circulate upwardly through an annular region between an outer surface(s) of the drillstring 225 and surrounding wall(s) (e.g., open borehole, casing, etc.), as indicated by directional arrows. In such a manner, the mud lubricates the drill bit 226 and carries heat energy (e.g., frictional or other energy) and formation cuttings to the surface where the mud (e.g., and cuttings) may be returned to the mud tank 201, for example, for recirculation (e.g., with processing to remove cuttings, etc.).

The mud pumped by the pump 204 into the drillstring 225 may, after exiting the drillstring 225, form a mudcake that lines the wellbore which, among other functions, may reduce friction between the drillstring 225 and surrounding wall(s) (e.g., borehole, casing, etc.). A reduction in friction may facilitate advancing or retracting the drillstring 225. During a drilling operation, the entire drillstring 225 may be pulled from a wellbore and optionally replaced, for example, with a new or sharpened drill bit, a smaller diameter drillstring, etc. As mentioned, the act of pulling a drillstring out of a hole or replacing it in a hole is referred to as tripping. A trip may be referred to as an upward trip or an outward trip or as a downward trip or an inward trip depending on trip direction.

As an example, consider a downward trip where upon arrival of the drill bit 226 of the drillstring 225 at a bottom of a wellbore, pumping of the mud commences to lubricate the drill bit 226 for purposes of drilling to enlarge the wellbore. As mentioned, the mud may be pumped by the pump 204 into a passage of the drillstring 225 and, upon filling of the passage, the mud may be used as a transmission medium to transmit energy, for example, energy that may encode information as in mud-pulse telemetry.

As an example, mud-pulse telemetry equipment may include a downhole device configured to effect changes in pressure in the mud to create an acoustic wave or waves upon which information may modulated. In such an example, information from downhole equipment (e.g., one or more modules of the drillstring 225) may be transmitted uphole to an uphole device, which may relay such information to other equipment for processing, control, etc.

As an example, telemetry equipment may operate via transmission of energy via the drillstring 225 itself. For example, consider a signal generator that imparts coded energy signals to the drillstring 225 and repeaters that may receive such energy and repeat it to further transmit the coded energy signals (e.g., information, etc.).

As an example, the drillstring 225 may be fitted with telemetry equipment 252 that includes a rotatable drive shaft, a turbine impeller mechanically coupled to the drive shaft such that the mud may cause the turbine impeller to rotate, a modulator rotor mechanically coupled to the drive shaft such that rotation of the turbine impeller causes said modulator rotor to rotate, a modulator stator mounted adjacent to or proximate to the modulator rotor such that rotation of the modulator rotor relative to the modulator stator creates pressure pulses in the mud, and a controllable brake for selectively braking rotation of the modulator rotor to modulate pressure pulses. In such an example, an alternator may be coupled to the aforementioned drive shaft where the alternator includes at least one stator winding electrically coupled to a control circuit to selectively short the at least one stator winding to electromagnetically brake the alternator and thereby selectively brake rotation of the modulator rotor to modulate the pressure pulses in the mud.

In the example of FIG. 2, an uphole control and/or data acquisition system 262 may include circuitry to sense pressure pulses generated by telemetry equipment 252 and, for example, communicate sensed pressure pulses or information derived therefrom for process, control, etc.

The assembly 250 of the illustrated example includes a logging-while-drilling (LWD) module 254, a measurement-while-drilling (MWD) module 256, an optional module 258, a rotary-steerable system (RSS) and/or motor 260, and the drill bit 226. Such components or modules may be referred to as tools where a drillstring may include a plurality of tools.

As to an RSS, it involves technology utilized for directional drilling. Directional drilling involves drilling into the Earth to form a deviated bore such that the trajectory of the bore is not vertical; rather, the trajectory deviates from vertical along one or more portions of the bore. As an example, consider a target that is located at a lateral distance from a surface location where a rig may be stationed. In such an example, drilling may commence with a vertical portion and then deviate from vertical such that the bore is aimed at the target and, eventually, reaches the target. Directional drilling may be implemented where a target may be inaccessible from a vertical location at the surface of the Earth, where material exists in the Earth that may impede drilling or otherwise be detrimental (e.g., consider a salt dome, etc.), where a formation is laterally extensive (e.g., consider a relatively thin yet laterally extensive reservoir), where multiple bores are to be drilled from a single surface bore, where a relief well is desired, etc.

One approach to directional drilling involves a mud motor; however, a mud motor may present some challenges depending on factors such as rate of penetration (ROP), transferring weight to a bit (e.g., weight on bit, WOB) due to friction, etc. A mud motor may be a positive displacement motor (PDM) that operates to drive a bit (e.g., during directional drilling, etc.). A PDM operates as drilling fluid is pumped through it where the PDM converts hydraulic power of the drilling fluid into mechanical power to cause the bit to rotate.

As an example, a mud motor (e.g., PDM) may be operated in different modes, which may include a rotating mode and a sliding mode. A sliding mode involves drilling with a mud motor rotating the bit downhole without rotating the drillstring from the surface. Such an operation may be conducted when a BHA has been fitted with a bent sub or a bent housing mud motor, or both, for directional drilling. Sliding may be used in building and controlling or adjusting hole angle. In directional drilling, pointing of a bit may be accomplished through a bent sub, which may have a relatively small angle offset from the axis of a drillstring, and a measurement device to determine the direction of offset. Without turning the drillstring, the bit may be rotated with mud flow through the mud motor to drill in the direction it is pointed. With steerable motors, when a desired wellbore direction is attained, the entire drillstring may be rotated to drill straight rather than at an angle. By controlling the amount of hole drilled in the sliding mode versus the rotating mode, a wellbore trajectory may be controlled rather precisely.

As an example, a PDM may operate in a combined rotating mode where surface equipment is utilized to rotate a bit of a drillstring (e.g., a rotary table, a top drive, etc.) by rotating the entire drillstring and where drilling fluid is utilized to rotate the bit of the drillstring. In such an example, a surface RPM (SRPM) may be determined by use of the surface equipment and a downhole RPM of the mud motor may be determined using various factors related to flow of drilling fluid, mud motor type, etc. As an example, in the combined rotating mode, bit RPM may be determined or estimated as a sum of the SRPM and the mud motor RPM, assuming the SRPM and the mud motor RPM are in the same direction.

As an example, a PDM mud motor may operate in a so-called sliding mode, when the drillstring is not rotated from the surface. In such an example, a bit RPM may be determined or estimated based on the RPM of the mud motor.

An RSS may drill directionally where there is continuous rotation from surface equipment, which may alleviate the sliding of a steerable motor (e.g., a PDM). An RSS may be deployed when drilling directionally (e.g., deviated, horizontal, or extended-reach wells). An RSS may aim to minimize interaction with a borehole wall, which may help to preserve borehole quality. An RSS may aim to exert a relatively consistent side force akin to stabilizers that rotate with the drillstring or orient the bit in the desired direction while continuously rotating at the same number of rotations per minute as the drillstring.

The LWD module 254 may be housed in a suitable type of drill collar and may contain one or a plurality of selected types of logging tools. It will also be understood that more than one LWD and/or MWD module may be employed. Where the position of an LWD module is mentioned, as an example, it may refer to a module at the position of the LWD module 254, the MWD module 256, etc. An LWD module may include capabilities for measuring, processing, and storing information, as well as for communicating with the surface equipment. In the illustrated example, the LWD module 254 may include a seismic measuring device.

The MWD module 256 may be housed in a suitable type of drill collar and may contain one or more devices for measuring characteristics of the drillstring 225 and the drill bit 226. As an example, the MWD module 256 may include equipment for generating electrical power, for example, to power various components of the drillstring 225. As an example, the MWD module 256 may include the telemetry equipment 252, for example, where the turbine impeller may generate power by flow of the mud; it being understood that other power and/or battery systems may be employed for purposes of powering various components. As an example, the MWD module 256 may include one or more of the following types of measuring devices: a weight-on-bit measuring device, a torque measuring device, a vibration measuring device, a shock measuring device, a stick slip measuring device, a direction measuring device, and an inclination measuring device.

FIG. 2 also shows some examples of types of holes that may be drilled. For example, consider a slant hole 272, an S-shaped hole 274, a deep inclined hole 276 and a horizontal hole 278.

As an example, a drilling operation may include directional drilling where, for example, at least a portion of a well includes a curved axis. For example, consider a radius that defines curvature where an inclination with regard to the vertical may vary until reaching an angle between about 30 degrees and about 60 degrees or, for example, an angle to about 90 degrees or possibly greater than about 90 degrees.

As an example, a directional well may include several shapes where each of the shapes may aim to meet particular operational demands. As an example, a drilling process may be performed on the basis of information as and when it is relayed to a drilling engineer. As an example, inclination and/or direction may be modified based on information received during a drilling process.

As an example, deviation of a bore may be accomplished in part by use of a downhole motor and/or a turbine. As to a motor, for example, a drillstring may include a positive displacement motor (PDM).

As an example, a system may be a steerable system and include equipment to perform method such as geosteering. As mentioned, a steerable system may be or include an RSS. As an example, a steerable system may include a PDM or of a turbine on a lower part of a drillstring which, just above a drill bit, a bent sub may be mounted. As an example, above a PDM, MWD equipment that provides real time or near real time data of interest (e.g., inclination, direction, pressure, temperature, real weight on the drill bit, torque stress, etc.) and/or LWD equipment may be installed. As to the latter, LWD equipment may make it possible to send to the surface various types of data of interest, including for example, geological data (e.g., gamma ray log, resistivity, density and sonic logs, etc.).

The coupling of sensors providing information on the course of a well trajectory, in real time or near real time, with, for example, one or more logs characterizing the formations from a geological viewpoint, may allow for implementing a geosteering method. Such a method may include navigating a subsurface environment, for example, to follow a desired route to reach a desired target or targets.

As an example, a drillstring may include an azimuthal density neutron (ADN) tool for measuring density and porosity; a MWD tool for measuring inclination, azimuth and shocks; a compensated dual resistivity (CDR) tool for measuring resistivity and gamma ray related phenomena; one or more variable gauge stabilizers; one or more bend joints; and a geosteering tool, which may include a motor and optionally equipment for measuring and/or responding to one or more of inclination, resistivity and gamma ray related phenomena.

As an example, geosteering may include intentional directional control of a wellbore based on results of downhole geological logging measurements in a manner that aims to keep a directional wellbore within a desired region, zone (e.g., a pay zone), etc. As an example, geosteering may include directing a wellbore to keep the wellbore in a particular section of a reservoir, for example, to minimize gas and/or water breakthrough and, for example, to maximize economic production from a well that includes the wellbore.

Referring again to FIG. 2, the wellsite system 200 may include one or more sensors 264 that are operatively coupled to the control and/or data acquisition system 262. As an example, a sensor or sensors may be at surface locations. As an example, a sensor or sensors may be at downhole locations. As an example, a sensor or sensors may be at one or more remote locations that are not within a distance of the order of about one hundred meters from the wellsite system 200. As an example, a sensor or sensor may be at an offset wellsite where the wellsite system 200 and the offset wellsite are in a common field (e.g., oil and/or gas field).

As an example, one or more of the sensors 264 may be provided for tracking pipe, tracking movement of at least a portion of a drillstring, etc.

As an example, the system 200 may include one or more sensors 266 that may sense and/or transmit signals to a fluid conduit such as a drilling fluid conduit (e.g., a drilling mud conduit). For example, in the system 200, the one or more sensors 266 may be operatively coupled to portions of the standpipe 208 through which mud flows. As an example, a downhole tool may generate pulses that may travel through the mud and be sensed by one or more of the one or more sensors 266. In such an example, the downhole tool may include associated circuitry such as, for example, encoding circuitry that may encode signals, for example, to reduce demands as to transmission. As an example, circuitry at the surface may include decoding circuitry to decode encoded information transmitted at least in part via mud-pulse telemetry. As an example, circuitry at the surface may include encoder circuitry and/or decoder circuitry and circuitry downhole may include encoder circuitry and/or decoder circuitry. As an example, the system 200 may include a transmitter that may generate signals that may be transmitted downhole via mud (e.g., drilling fluid) as a transmission medium.

As an example, one or more portions of a drillstring may become stuck. The term stuck may refer to one or more of varying degrees of inability to move or remove a drillstring from a bore. As an example, in a stuck condition, it might be possible to rotate pipe or lower it back into a bore or, for example, in a stuck condition, there may be an inability to move the drillstring axially in the bore, though some amount of rotation may be possible. As an example, in a stuck condition, there may be an inability to move at least a portion of the drillstring axially and rotationally.

As to the term “stuck pipe”, this may refer to a portion of a drillstring that cannot be rotated or moved axially. As an example, a condition referred to as “differential sticking” may be a condition whereby the drillstring cannot be moved (e.g., rotated or reciprocated) along the axis of the bore. Differential sticking may occur when high-contact forces caused by low reservoir pressures, high wellbore pressures, or both, are exerted over a sufficiently large area of the drillstring. Differential sticking may have time and financial cost.

As an example, a sticking force may be a product of the differential pressure between the wellbore and the reservoir and the area that the differential pressure is acting upon. This means that a relatively low differential pressure (delta p) applied over a large working area may be just as effective in sticking pipe as may a high differential pressure applied over a small area.

As an example, a condition referred to as “mechanical sticking” may be a condition where limiting or prevention of motion of the drillstring by a mechanism other than differential pressure sticking occurs. Mechanical sticking may be caused, for example, by one or more of junk in the hole, wellbore geometry anomalies, cement, keyseats or a buildup of cuttings in the annulus.

As explained, a wellsite system may include various types of equipment for handling fluid such as, for example, drilling fluid (e.g., mud). As explained, drilling fluid may provide one or more functions (e.g., lubrication, transport of cutting, etc.).

Drilling fluid may be composed of a number of liquid and/or gaseous fluids and mixtures of fluids and solids (e.g., as solid suspensions, mixtures and emulsions of liquids, gases and solids) as may be used in various operations to drill boreholes into the earth. Classifications of drilling fluids may utilize one or more types of classification schemes. For example, consider water-based mud (WBM), oil-based mud (OBM), nonaqueous-based mud (NQBM), gaseous-based mud (e.g., pneumatic, etc.) (GBM), etc.

As an example, drilling fluid may be lost to a formation and/or reservoir fluid may enter drilling fluid. Hence, one or more functions of drilling fluid may be compromised by changes to drilling fluid. For example, if density of drilling fluid is altered by introduction of reservoir fluid, the drilling fluid may diminish in its ability to transport cuttings to surface. As a consequence, cuttings may build up within an annulus between a drillstring and a borehole wall or cased wellbore, which may increase risk of sticking (e.g., stuck pipe). To address changes to drilling fluid, one or more actions may be taken, for example, consider adding one or more components to the drilling fluid, adding additional drilling fluid, etc.

As to lost circulation or circulation loss, these terms may refer to loss of drilling fluid to a formation, for example, caused when the hydrostatic head pressure of the column of drilling fluid exceeds the formation pressure. This loss of fluid may be loosely classified as seepage losses, partial losses, or catastrophic losses, each of which may be handled differently depending on the risk to equipment, materials, borehole quality, characteristics of drilling fluid, personnel, etc.

As to influx of formation fluid (e.g., reservoir fluid, etc.), it may include an event known as a kick. A kick may be defined as a flow of formation fluid into a bore during drilling operations. A kick may be physically caused by the pressure in the bore being less than that of the formation fluid, thus causing flow. This condition of lower bore pressure than formation pressure may be caused in various ways. For example, if mud weight is too low, then hydrostatic pressure exerted on a formation by the fluid column may be insufficient to hold the formation fluid in the formation. This may happen if the mud density is suddenly lightened or is not to specification to begin with, or if a drilled formation has a higher pressure than expected. This type of kick might be called an underbalanced kick. As another example, consider a kick that may occur if dynamic and transient fluid pressure effects (e.g., due to motion of the drillstring or casing), effectively lower the pressure in a bore below that of the formation. Such a type of kick may be referred to as an induced kick.

Additional phenomena that may occur during drilling operations include swab and surge. As to swab, it may involve a reduction in pressure in a bore by moving pipe, wireline tools or where rubber-cupped seals up the bore. If the pressure is reduced sufficiently, reservoir fluid may flow into the bore and towards surface. Swabbing tends to be detrimental in drilling operations as it may lead to kick and borewall stability problems. As to surge, consider an example where a drillstring is being tripped-out (e.g., pulled out of hole (POOH)) where upward movement of the drillstring causes friction between the drillstring and drilling fluid. In surge, pressure may decrease in a bore due to the surge effect; noting that the opposite effect may happen when a drillstring is tripping-in (e.g., running in hole (RIH)), as downward movement may cause a pressure increase (e.g., a swab effect).

As explained, a drillstring may include a mud motor that is rotationally driven by flow of drilling fluid. In such a mode of drilling, the characteristics of drilling fluid may impact mud motor performance. For example, density (e.g., mud weight) may impact how much energy the mud motor may deliver to a drill bit for a given drilling fluid flow rate.

As to a stuck pipe or risk of sticking event, as explained, one or more actions may be taken. For example, consider addition of acid as a remedial action to address the stuck pipe event or to reduce the risk of a sticking event. In such an example, a number of barrels of acid may be added to drilling fluid that is circulated downhole to an annular region between a drilling string and a bore wall in an effort to “dissolve” material that is causing sticking or a risk of sticking. While addition of acid is mentioned, it may be an action within a tiered series of actions that may be taken, where, for example, each action may have associated benefits and detriments. As to detriments, these may include non-productive time (NPT), cost, further remedial actions (e.g., impact of acid on one or more additives in drilling fluid), etc. Hence, where an event occurs or a risk of an event is heightened, in an effort to maintain adherence to a plan, one or more actions may be implemented in a strategic manner to resolve the event or otherwise reduce the risk. While sticking is mentioned as a type of issue, one or more types of issues may occur during field operations at a field site.

FIG. 3 shows an example of a wellsite system 300, specifically, FIG. 3 shows the wellsite system 300 in an approximate side view and an approximate plan view along with a block diagram of a system 370.

In the example of FIG. 3, the wellsite system 300 may include a cabin 310, a rotary table 322, drawworks 324, a mast 326 (e.g., optionally carrying a top drive, etc.), mud tanks 330 (e.g., with one or more pumps, one or more shakers, etc.), one or more pump buildings 340, a boiler building 342, an HPU building 344 (e.g., with a rig fuel tank, etc.), a combination building 348 (e.g., with one or more generators, etc.), pipe tubs 362, a catwalk 364, a flare 368, etc. Such equipment may include one or more associated functions and/or one or more associated operational risks, which may be risks as to time, resources, and/or humans.

As shown in the example of FIG. 3, the wellsite system 300 may include a system 370 that includes one or more processors 372, memory 374 operatively coupled to at least one of the one or more processors 372, instructions 376 that may be, for example, stored in the memory 374, and one or more interfaces 378. As an example, the system 370 may include one or more processor-readable media that include processor-executable instructions executable by at least one of the one or more processors 372 to cause the system 370 to control one or more aspects of the wellsite system 300. In such an example, the memory 374 may be or include the one or more processor-readable media where the processor-executable instructions may be or include instructions. As an example, a processor-readable medium may be a computer-readable storage medium that is not a signal and that is not a carrier wave.

FIG. 3 also shows a battery 380 that may be operatively coupled to the system 370, for example, to power the system 370. As an example, the battery 380 may be a back-up battery that operates when another power supply is unavailable for powering the system 370. As an example, the battery 380 may be operatively coupled to a network, which may be a cloud network. As an example, the battery 380 may include smart battery circuitry and may be operatively coupled to one or more pieces of equipment via a SMBus or other type of bus.

In the example of FIG. 3, services 390 are shown as being available, for example, via a cloud platform. Such services may include data services 392, query services 394 and drilling services 396. As an example, the services 390 may be part of a system such as the system 100 of FIG. 1 (e.g., consider planning services and/or operational services). As an example, the services 390 may include one or more services for directional drilling (e.g., consider a computational framework that may provide for one or more services that utilize real-time data to estimate one or more parameters, etc.).

As an example, the system 370 may be utilized to generate one or more rate of penetration drilling parameter values and/or one or more other types of parameter values, which may, for example, be utilized to control one or more drilling operations.

FIG. 4 shows an example of a system 400 that includes offsite equipment 401 (e.g., remote) and onsite equipment 402 (e.g., local). As shown, the offsite equipment 401 may include a drill operations framework 410, a drill planning framework 420 and a database 430 and the onsite equipment 402 may include a controller 440 that may receive real-time data and output recommendations such as control instructions to control onsite equipment. In such an example, the drill operations framework 410 may provide for steering sheets, execution parameters, etc., and the drill planning framework 420 may provide for evaluation of steering responses and statistics. As shown, the controller 440 may output information to the drill operations framework 410 and receive information from the drill planning framework 420. The system 400 may include plan generation features for real-time plan generation during drilling operations execution phase and/or plan generation during a planning phase. The system 400 may be utilized for one or more types of drilling (e.g., rotary, mud motor, RSS, ABSS, etc.). The system 400 may operate loops, which may include at least one real-time loop that provides for control of equipment to perform drilling operations.

A system such as the system 400 may utilize various functions and constraints for generation of plans, which may provide for single or multiple target aiming. As explained, a plan may be generated that aims to provide for drilling operations for a multi-well structure. As explained, a plan may be a digital plan that may be utilized to instruct one or more controllers such as, for example, an autodriller controller, which may control one or more pieces of equipment (e.g., a drawworks, a top drive, one or more drilling fluid pumps, etc.). As an example, an autodriller may control energy delivered via one or more pieces of equipment to a drill bit where the drill bit crushes and/or cuts rock to extend a borehole. As an example, an autodriller may be controlled in an effort that aims to minimize or otherwise reduce mechanical specific energy (MSE) and to maximize or otherwise increase rate of penetration (ROP).

As explained with respect to the system 100 of FIG. 1, various computational frameworks may be utilized to perform one or more workflows, which may include planning workflows, workflows involving control of field operations, workflows in real-time or near real-time, assessment workflows (e.g., for issues, successes, etc.), etc. As explained, one or more visualization features may be provided and utilized, for example, to implement visualization processes that may be suitable for one or more web applications. As mentioned, JSON and/or one or more other languages and/or formats may be utilized.

As explained, a system may include offsite equipment (e.g., remote) and onsite equipment where onsite equipment may be controlled to perform one or more field operations. As an example, field operations may include one or more of various types of field operations. For example, consider field operations related to drilling, logging, completions, treatments (e.g., fracturing, acid, etc.), EOR, etc. In various scenarios, field operations may include a human-in-the-loop (HITL) that may act using personal knowledge and/or advice; noting that some level of automation may help to reduce demands on one or more humans. For example, consider automation that may be implemented without human interaction and/or with minimal human interaction (e.g., a HITL that actuates a button, etc.). In various scenarios, field operations may benefit from advice being available to a HITL and/or a framework that may help to at least partially automate one or more types of field operations.

In various scenarios, a HITL may be faced with some amount of cognitive overload as to operating one or more pieces of equipment, which may be relatively complex equipment. In various instances, field operations may demand adherence to one or more procedures (e.g., standard operating procedures (SOPs), customer procedures, regulatory procedures, etc.). Where human involvement is reduced, fewer humans may be available and, a human that is available, may be limited as to time. In such instances, compliance and/or reporting of field procedures may become logistically more challenging (e.g., consider interacting with customer personnel becoming more challenging as a wellsite crew size is reduced). In addition, experience and/or skillsets of field personnel may be reduced due to one or more factors (e.g., dilution by asking a person to perform more and varied types of tasks without an ability to acquire deep knowledge, high rate of attrition, etc.). To address such challenges, a system may provide for a combination of equipment automation and guided workflows. For example, consider one or more frameworks that may provide for some level of equipment automation and/or guided workflows.

While various frameworks may provide for some level of equipment automation and/or guided workflows, such frameworks tend to be limited in that domain knowledge tends to be distilled to adhere to programming constructs for framework implementation. For example, consider a programming paradigm where domain knowledge is captured in a programmatic form suitable for software-based execution. Distillation of domain knowledge to a programmatic form can result in loss of knowledge, constraints on knowledge, etc. A distillation process may demand a combination of skillsets to be present and may be a relatively laborious process, that may be biased by one or more members of a team. Hence, a distillation process may not be replicable and/or entirely objective. And, it may not be scalable, for example, to be applied to a number of different types of services, etc.

As an example, a framework may provide for accessing and leveraging knowledge that may exist in one or more types of databases and/or other data storage devices, whether static, dynamic, functional, non-functional, etc. As an example, one or more sources of data, processed data, etc., may be via the Internet and/or via one or more other networks (e.g., private, proprietary, etc.). As an example, one or more sources of data, processed data, etc., may be accessed via one or more cloud platforms (e.g., including cloud-based resources for data storage, data access, computing, etc.). As an example, one or more sources of data, processed data, etc., may be live (e.g., dynamic) where, for example, interactions may provide for data processing, data addition, data modification, data deletion, data quality control, etc.

As an example, a framework may provide for utilization of data, processed data, etc. (e.g., knowledge, etc.) in one or more forms (e.g., documents, SOPs, best practices, training materials, wellsite data (e.g., historic, live, etc.). In such an example, one or more large language models may be utilized, tailored, augmented, etc. As an example, a large language model may provide for building and/or executing field operation plans. For example, consider generation of field operational guidance, instructions, control, etc., that may comply with one or more procedures, constraints, etc.

As an example, a framework may provide for prompt generation and responses for one or more large language models (LLMs). For example, consider an advisory framework that may provide for monitoring field operations (e.g., planned, live, etc.) in a manner that allows one or more humans to improve compliance with procedures and/or best practices and, for example, to advise when a human may deviate and/or require assistance (e.g., due to an anomaly, etc.).

As an example, a foundational LLM may be utilized as a conversational agent. As an example, one or more features of an LLM architecture may be utilized to generate an agent that is capable of understanding natural language procedures and taking physical actions that enable the agent to accomplish a goal, as may be, for example, provided by a human (e.g., as direct input, responsive to interaction with a graphical user interface (GUI), etc.).

An article entitled by Yao et al., entitled “ReAct: Synergizing reasoning and acting in language models”, (arXiv:2210.03629v3, 10 March 2023, ICLR 2023) is incorporated by reference herein. As an example, a framework may operate using one or more techniques, one or more architectural features, etc., described in the article by Yao et al.

As an example, a framework may provide for one or more of reasoning abilities (e.g., chain-of-thought prompting, etc.), acting (e.g. action plan generation, etc.), etc. As an example, one or more LLMs may be utilized to generate reasoning traces and task-specific actions, for example, in an interleaved manner. In such an example, reasoning traces may be implemented to assist model induction, tracking, and updating as to action plans and, for example, to handle exceptions, while, for example, actions may allow for interfacing with and gather additional information from one or more sources (e.g., knowledge bases, environments, etc.).

As an example, a framework may implement one or more features of a ReAct approach, as described, for example, in the article by Yao et al. The ReAct approach may be applied to a diverse set of language and decision-making tasks with suitable human interpretability and trustworthiness. Concretely, on question answering (HotpotQA) and fact verification (Fever), a ReAct approach may help to overcome prevalent issues of hallucination and error propagation in chain-of-thought reasoning by, for example, interacting with one or more data sources (e.g., via one or more application programming interfaces (APIs)). As an example, consider interactions with one or more types of wikis (e.g., consider a WIKIPEDIA API, etc.) and generating human-like task-solving trajectories that may be more interpretable than baselines without reasoning traces. As an example, a framework may utilize one or more imitation and/or reinforcement learning techniques.

FIG. 5 shows various examples of prompting 500 in the context of LLMs. In particular, four prompting methods are presented and compared in a first context ((a) standard, (b) chain-of-thought (CoT, Reason Only), (c) act-only, and (d) ReAct (Reason+Act), solving a HotpotQA question) along with a comparison in a second context ((a) Act-only and (b) ReAct prompting to solve an AlfWorld game). In both contexts (e.g., domains), in-context examples are omitted in the prompt, and only show task solving trajectories generated by the model (e.g., Act, Thought) and the environment (Obs).

In the article by Yao et al., the ReAct approach is presented as a paradigm to combine reasoning and acting with language models for solving diverse language reasoning and decision-making tasks (see, e.g., FIG. 5). As an example, ReAct may prompt LLMs to generate both verbal reasoning traces and actions pertaining to a task in an interleaved manner, which allows a model to perform dynamic reasoning to create, maintain, and adjust high-level plans for acting (e.g., reason to act), while also interacting with the external environments (e.g., wikis, etc.) that may provide for incorporating additional information into reasoning (e.g., act to reason).

As an example, a reason and act pattern (e.g., ReAct) may be used to take LLMs (e.g., one or more generic LLMs) and specialize them, within a computational framework, to operate field equipment (e.g., rigsite/wellsite equipment, etc.) under a domain in which the LLMs may not have been originally trained.

As an example, a framework may provide for simplifying the process of taking knowledge and translating it to actions. Such a framework may operate in a manner that is superior to an approach that involves an expert understanding a domain (e.g., by reading documents and talking to humans) and trying to convert this to an algorithm that can be given to a computer to execute, which tends to be a complex and time-consuming process that also demands access to skillsets that may be difficult to find and/or access.

As an example, a framework may provide for leveraging knowledge that may be written in natural language (e.g., manuals, training material, best practices, etc.) and combining it with one or more LLM-based agents to control field equipment and/or to guide one or more humans (e.g., generate advice actionable via a HITL, etc.). Such an approach may be implemented with reduced attention to and/or reliance upon the creation of specialized algorithms to solve a problem.

FIG. 6 shows an example of an architecture 600 that may be part of and/or implemented by a framework. As shown, the architecture 600 includes four LLM agents, including an LLM driller agent 620, an LLM subject matter expert (SME) agent 640, an LLM documentation agent 650, and an LLM observer agent 660. While various arrows are shown in the example of FIG. 6, such agents may be arranged in one or more manners for one or more types of interactions.

As an example, an LLM agent (e.g., or agent) may be specialized. For example, consider specialization (e.g., tailoring, etc.) by one or more of instructions to specialize an agent, a set of tools (e.g., actions) that may be selected from as a library, etc., and/or one or more objectives.

As an example, once an agent is given an objective, it may iterate through the objective by creating a thought, taking an action, and observing the result of that action. As an example, such a process may be repeated until the objective is reached (e.g., or until one or more criteria are met that may cause termination, supplanting, re-starting, etc.).

As an example, an SME agent may be specialized to answer questions about a specific domain. For example, consider an agent that may be given access to a set of documents (e.g., SOPs, etc.) that may describe a domain within with the agent specializes upon. In such an example, the documents may be converted to embeddings and indexed in a database such as, for example, a vector DB. In such an example, an agent may then cause performance of a semantic search on such document and observe the environment in order to answer questions about that specific domain. As an example, for complex domains, multiple SME agents may be created, for example, each SME agent specializing to a specific part of a domain, etc.

As an example, an observer agent may be operable to observe the state of an environment in which it operates. For example, an observer agent may be given tools to read the state of the environment (e.g., via one or more sensors, etc.) and convert its observations, for example, consider conversion to natural language.

As an example, a driller agent may provide for orchestration. For example, consider a driller agent that may provide for framework orchestration that involves utilization of multiple agents. As an example, a driller agent may receive an objective from a human and/or a machine and a set of actions where the driller agent may provide for taking one or more of the actions of the set of actions. As an example, a set of actions may include one or more of the following: ask a question to one or more SME agents about a domain; ask a question to one or more observer agents about an environment; and take an action that changes the environment (e.g., control equipment, etc.).

As an example, a driller agent may provide for thinking, acting and observing in an iterative manner until a goal is reached (e.g., or until one or more criteria are met that may cause termination, supplanting, re-starting, etc.).

As an example, an architecture may include one or more instances of one or more types of agents that may, for example, provide for handling problems in one or more domains. As explained, a framework may provide for control of equipment for drilling at least a portion of a borehole for a well and/or may provide for control of equipment in one or more other types of operations, which may include, for example, wireline, stimulation, coil tubing, completions, etc. As an example, one or more types of operations may involve operations at a rigsite (e.g., wellsite) that may involve surface equipment and/or downhole equipment.

An LLM may be a type of language model notable for its ability to achieve general-purpose language understanding and generation. An LLM may acquire abilities by using relatively massive amounts of data to learn parameters (e.g., determine parameter values, etc.) during training. An LLM may be an artificial neural network or networks (e.g., consider a transformer, etc.) and may be trained and/or pre-trained using one or more types of learning (e.g., self-supervised learning, semi-supervised learning, unsupervised learning, etc.).

As an example, an autoregressive language model (e.g., AR LLM) may operate by taking input text and repeatedly predicting a next token or word. As an example, an LLM may be tuned, for example, for a particular domain. As an example, an LLM such as the Generative Pretrained Transformer (GPT) 3 (GPT-3) may be prompt-engineered. As an example, an LLM may acquire embodied knowledge about syntax, semantics and ontology inherent in human language corpora; noting that an LLM may also acquire inaccuracies and biases present in one or more corpora.

FIG. 7 shows an example architecture 710 of a GPT; noting that one or more features of the architecture 710 may be utilized in an LLM. As an example, a foundational GPT model may be further adapted to produce more targeted systems directed to specific tasks and/or subject-matter domains. Techniques for such adaptation may include additional fine-tuning (e.g., beyond tuning of a foundation model, etc.), certain forms of prompt engineering, etc. As an example, an LLM may be a chatbot type of LLM. For example, consider the OpenAI ChatGPT LLM, which is an online chat interface powered by an instruction-tuned language model trained in a similar fashion to InstructGPT. Other chatbots may include features of GPT-4 (OpenAI), Bard (e.g., LaMDA family of conversation-trained language models, PaLM, etc.) (Google, Mountain View, California), etc.

As an example, a LLM Meta AI (LLaMA) LLM may be utilized, which includes a transformer architecture; noting some architectural differences compared to GPT-3. For example, LLaMA utilizes the SwiGLU activation function rather than ReLU, uses rotary positional embeddings rather than absolute positional embedding, and uses root-mean-squared layer-normalization rather than standard layer-normalization. Further, there may be an increase in context length from 2K (Llama 1) tokens to 4K (Llama 2) tokens between.

As an example, a system may implement a Retrieval-Augmented Generation (RAG) approach (e.g., a Retrieval Augmented Generator) that may provide an LLM with additional information from an external knowledge source. In such an example, the LLM may be able to generate more accurate and contextual answers while reducing hallucinations.

FIG. 7 also shows an example of a RAG architecture 720 that includes a vector database that can generate context for a query to formulate a prompt for an LLM that can generate a response to the prompt. As shown, the vector database may be utilized to augment a query such that the query may include context that may be beneficial in generation of output from the LLM. As an example, one or more features described in an article by Lewis et al. may be utilized (see, e.g., “Retrieval-augmented generation for knowledge-intensive NLP tasks”, Advances in Neural Information Processing Systems, 33, 9459–9474 (2020), which is incorporated by reference herein in its entirety).

LLMs tend to be trained on large amounts of data to achieve a broad spectrum of knowledge, which may be stored in neural network weights (e.g., parametric memory). However, prompting an LLM to generate a completion that demands knowledge that was not included in its training data, such as newer, proprietary, or domain-specific information, can lead to factual inaccuracies (e.g., hallucinations). For example, consider the following scenario concerning ChatGPT:

ChatGPT answering the question “What did the president say about Justice Breyer” with “I don’t know because I don’t have access to real-time information”.

ChatGPT’s answer to the question, “What did the president say about Justice Breyer?”

As seen in this scenario, there is a lack of a bridge across a knowledge gap between the LLM knowledge and additional context to help the LLM generate more accurate and contextual completions while reducing risks of hallucinations.

Neural networks tend to be adapted to domain-specific or proprietary information by model fine-tuning. While fine-tuning may be helpful (e.g., effective), fine-tuning introduces computational demands, which may be intensive, expensive, and requiring technical expertise, which may diminish agility to adapt to evolving information.

A RAG architecture provides for more flexibility through combination of a generative model with a retriever component to provide additional information, for example, from one or more external knowledge sources, which may be, in various instances, updated more readily.

A RAG architecture has been likened to an open-book exam, as additional information can be provided to an LLM such that the LLM generates a “better” response to a query. As an example, factual knowledge may be effectively separated from an LLM’s reasoning capability and stored in an external knowledge source, which may be readily accessed and, as appropriate, updated. As an example, a RAG architecture may provide for parameter knowledge (e.g., learned during training that is implicitly stored in neural network weights) and non-parametric knowledge (e.g., stored in an external knowledge source, such as a vector database).

As shown, the architecture 720 may implement a RAG workflow from query through retrieval with a vector database to prompt stuffing and finally response generation. As shown, as to the retrieve component (e.g., retrieval component), a query is used to retrieve relevant context from an external knowledge source. For example, a query may be embedded with an embedding model into the same vector space as the additional context in the vector database. In such an example, a similarity search may be performed where a top number of closest data objects from the vector database may be returned. As shown, output from the vector database similarity search may be utilized to augment a prompt. For example, the query and the retrieved additional context may be stuffed into a prompt template. Next, the prompt, as a retrieval-augmented prompt, may be fed to an LLM where the LLM generates a response.

FIG. 8 shows an example of a system 800 that may provide for generation of output utilizing a generative process, which may include implementing one or more large language models (LLMs) that can, responsive to input, generate output. As shown, the system 800 can include a vector database (Vector DB) component, a retriever component and an LLM component.

As an example, a vector database may be a type of specialized database designed to store and retrieve vector embeddings, which may be present in the form of numerical arrays representing various characteristics of an object. Such embeddings may be distilled representations of training data and/or other data, for example, serving as a filter through which new data may be run during an inference part of a machine learning process. As explained, in an RAG architecture, vector embeddings may provide for query augmentation, for example, to augment a query with contextual information.

As an example, a vector database may be operatively coupled to a LLM via a retriever component. In the context of LLMs, vector databases can store the vector embeddings, which may include those resulting from model training and/or one or more other sources. In such an example, performance of database-based similarity searches may be improved, where an aim may be to find a best match between a prompt and a particular vector embedding.

Vector embeddings may be considered to be numerical representations of data objects. Vector embeddings may be generated by one or more processes and serve as a distilled, structured representation of data. As an example, each point in a high-dimensional space may provide for a correspondence to a unique data object where distance between points represents similarity between the corresponding data objects. In the context of vector databases, vector embeddings may be used to transform and store data in a way that allows for efficient similarity search, which may be utilized in applications such as semantic search and natural language processing (NLP), where a goal may be to find one or more data objects that are semantically similar to a given query and/or otherwise relevant to a given query.

As an example, the system 800 may employ vector indexing. For example, once data has been transformed into vector embeddings, these embeddings may be stored in a manner that allows for efficient search and retrieval. Vector indexing involves organizing and storing vector embeddings in a database in a way that allows for efficient similarity search. The high dimensionality of a vector space and demands to perform complex distance computations can present challenges where such challenges may be suitably handled using advanced indexing algorithms and data structures. Vector databases tend to handle such tasks efficiently.

As to similarity searches in vector databases, the concept of similarity search in vector databases can involve finding the most similar vectors to a given vector within the database. Similarity may be determined, for example, using one or more distance metrics (e.g., Euclidean distance, cosine similarity, etc.). In the context of LLMs, a similarity search may be used to find a best match between a prompt and a stored vector embedding, which may allow an LLM to generate appropriate responses to questions based on its training (e.g., training data) where, as explained, questions may be augmented (e.g., through a vector database-based search result). As explained, a vector database may be provided as a front end to an LLM whereby one or more searches may generate information that may augment a query as in an RAG architecture.

As shown in the example of FIG. 8, the system 800 may provide for transforming data from one or more sources (e.g., source document library, etc.) to vectors for storage in the vector database component. As shown, data may include image data, tabular data, text data, etc. As an example, such data may include training data that were utilized to train the LLM. As an example, such data may include data from a rigsite, which may be streamed data such as, for example, real-time streamed data. As an example, a vector database may be dynamically maintained to provide for up-to-date, timely information that may be utilized to augment or otherwise enhance a query.

As shown in the example of FIG. 8, the system 800 may utilize the retriever component as an interactive component that interacts with the vector database and that provides output to the LLM. For example, the retriever component may receive one or more questions (e.g., manual, automatic, batch, etc.) and provide for generation of a prompt to the LLM whereby the LLM may generate one or more responses (e.g., answers) responsive to receipt of the prompt. As shown, the retriever component may generate a prompt that is dependent upon a question (e.g., a query) and a context instruction (e.g., contextual information extracted from the vector database using a similarity and/or other type of search). In such an example, a question may be presented with context to the LLM whereby the LLM may generate one or more responses thereto.

The system 800 of FIG. 8 may provide for connecting a knowledge system (e.g., source documents, document parsing methods, vector database, retrieval augmented generation methods, specialized large language model prompting, etc.) with one or more frameworks. As an example, the system 800 may be part of a framework or frameworks.

FIG. 9 shows an example of an architecture 900 and examples of various interactions that may occur using one or more components of the architecture 900. As shown, the architecture 900 may include a number of LLM agents, which may include a driller agent, an SME agent, a documentation agent, and an observer agent; noting that one or more additional and/or alternative agents may be included within an architecture, which may be a framework architecture.

As shown, the driller agent may receive a goal and/or be provided with a direction where, for example, the driller agent may respond in one or more manners such as, for example, asking for clarification of a human and/or a machine, asking another agent of one or more domain specific questions, asking one or more questions about an operational and/or equipment state, issuance of one or more instructions to control an operational and/or equipment state (e.g., to change a state, etc.), etc. As shown, the driller agent may interact with an SME agent and/or an observer agent. As shown, the SME agent may interact with the documentation agent and/or one or more search engine utilities (e.g., APIs, etc.). For example, consider one or more wiki searches, one or more Internet search engine searches (e.g., GOOGLE, DUCKDUCKGO, BING, etc.). As shown, the documentation agent may interact with a database such as, for example, a vector DB that may provide for utilization of embeddings, which may be based at least in part on one or more types of procedures, etc. For example, consider one or more SOPs being a basis for generation of embedding that may be indexed within a database where the documentation agent may perform searches, for example, such that a response to a prompt may comport with one or more procedures, constraints, etc.

As shown in the example of FIG. 9, the observer agent may provide for access to one or more libraries that may provide for computations, processing data, etc. In such an example, the observer agent may provide for access to one or more machine learning components, whether for training a machine learning model, utilizing a machine learning model, etc. As shown, a library such as the WOLFRAM ALPHA library may be utilized, which may be a library that is interactive for providing answers to questions that may be solved using one or more algorithms (e.g., mathematical, physics-based, empirical, machine learning-based, etc.). In such an example, an API may be utilized, which may provide for searching for answers and/or generating answers (e.g., using appropriate library features, etc.). As shown, the observer agent may provide for observation of operational and/or equipment states (e.g., rig states, etc.).

As to the WOLFRAM ALPHA library, it may provide for access to and/or utilization of one or more features of MATHEMATICA. As an example, a library and/or computational service may provide for submission of queries and/or computation requests via an API, a GUI, etc. As an example, in response, a library and/or a service may provide for computation of answers and/or relevant visualizations, which may be based at least in part on a knowledge base of curated, structured data that may be from or derived from sites, texts, etc. As an example, a library and/or a service may provide for receipt of input that may be phrased using natural language, for example, in the form of fact-based questions. As an example, a library and/or a service may provide for rendering of an input interpretation of a question, for example, using one or more standardized phrases. As an example, a library and/or a service may provide for parsing mathematical and/or other symbolism and, for example, respond with numerical results, statistical results, graphical results, etc.

As an example, one or more libraries, services, etc., may include one or more features of one or more types of WOLFRAM products. As an example, one or more architecture components may utilize a language or languages. As an example, the WOLFRAM language includes a variety of capabilities for making use of LLMs. For example, consider functions in the WOLFRAM language that may provide for calling LLM functionality programmatically and for allowing LLMs to access various tools (e.g., WOLFRAM language tools, etc.). As an example, an architecture may utilize and/or be operatively coupled to the WOLFRAM Prompt Repository, which provides a curated collection of prompts for delivering a range of LLM-based capabilities.

As an example, one or more chat and/or generative services may be accessed by a framework. As an example, one or more of the following services may be accessed and/or utilized: OpenAI (e.g., speech, image, text computation with OpenAI); Anthropic (e.g., chat and other text computation with Anthropic); PaLM (e.g., chat and other text computation with PaLM); GoogleSpeech (e.g., speech synthesis and recognition using GoogleSpeech); ElevenLabs (e.g., speech synthesis and recognition using ElevenLabs); etc. As explained, a framework may utilize natural language features for processing, capture, instruction, etc. As an example, a framework may include one or more translation capabilities.

As an example, the architecture 900 may include one or more simulators, which may be physics-based, empirical, machine learning-based, etc. For example, consider utilization of a rig simulator for simulation of rig-based operations. In such an example, an output rig action may be subjected to simulation using a rig simulator to see a corresponding result, which may be a change in rig state (e.g., a transition from one rig state to another rig state). In such an example, an observer agent may be informed as to a simulation result such that the observer agent may be able to compare a simulation result and an actual result where a control action is implemented in the field. In such an example, a framework may provide for monitoring of implementation of a control action and, for example, taking one or more actions in response thereto, whether to tailor, optimize, alter, terminate, substitute, etc.

FIG. 10 shows an example of a system 1000 that may include or be operatively coupled to various components of a computational framework. As shown, the system 1000 can include a prompt block 1010 for receipt of a goal (e.g., in an expressed digital form) and receipt of one or more of output of a functions documents block 1012, an instructions and examples block 1014, and a learned knowledge block 1016 (e.g., from long-term memory). As shown, the prompt block 1010 may also receive input from a chat history block 1080 (e.g., from short-term memory).

As shown in the example of FIG. 10, an LLM block 1020 can receive output from the prompt block 1010 where the LLM block 1020 can generate output that can be directed to an output parser block 1030. As an example, the output parser block 1030 can parse code and reasoning and can direct LLM output to the chat history block 1080. As to the code and reasoning, they may be received by a decision block 1040 that decides whether or not the goal has been reached (e.g., achieved). Per a “yes” branch of the decision block 1040, if the goal has been reached, a final answer may be output and a goal-to-answer process performed by the system 1000 may be terminated, noting that the final answer may be directed to a retrospective block 1055, for example, for assessment to generate learned knowledge appropriate for storage in long-term memory of the learned knowledge block 1016. As explained, output of the learned knowledge block 1016 may provide for supplementing or otherwise informing a prompt of the prompt block 1010.

As shown in the example of FIG. 10, if the decision block 1040 decides that the goal has not been reached, then a “no” branch can proceed to an execution environment block 1060 that may utilize one or more function wrappers from a function wrappers block 1045 where the execution environment block 1060 can issue calls to one or more action services of an action services block 1070, which may implement one or more agent actions as a service (e.g., or services). As indicated, the execution block 1060 can generate output to add to a history data store, such as, for example, a chat history per the chat history block 1080.

In the example of FIG. 10, the action services may provide for performing one or more of a variety of actions. For example, consider interactions with one or more agents, which may include one or more of the agents of the architecture 900 of FIG. 9. As shown in FIG. 9, agents may include LLM agents, which may provide for tool interactions for one or more resources. In particular, driller agent, an observer agent, a subject matter expert (SME), and a document QA agent are shown as some examples. As to the driller agent, it may provide for changing rig state where, for example, one or more rig actions may be noted and fed to a rig simulator, which may additionally or alternatively operate on the basis of rig states. As explained, resources that provide one or more search engines may be leveraged where, for example, output may be generated, which may be helpful in goal achievement, goal assessment, etc. In various instances, output may be captured and utilized in one or more feedback loops, for example, to improve a system, a framework, etc. (e.g., through knowledge building, training, learning, etc.).

In the example of FIG. 10, as indicated, actions may take the form of code that may be generated by an agent and executed in an isolated interpreter environment. For example, the execution environment block 1060 may provide for establishing one or more execution environments that can provide for processing of code. In such an example, an execution environment may be an interpreter environment and/or a more sophisticated type of environment (e.g., with a complier, etc.). Such an approach may enable one or more agents to be more creative in problem solving.

As an example, a complier may be provided that translates code from a high-level programming language into machine code for execution while an interpreter may translate code written in a high-level programming language into machine code line-by-line, or otherwise in chunks, to execute the code. As an example, one or more code converters may be provided such that interoperability exists, which may facilitate using one or more types of agents, which may provide for native mode execution and/or compatible mode execution.

As shown in the example of FIG. 10, the retrospective block 1055 may receive output, such as, for example, a final answer. Such a block may operate as a retrospective agent with capabilities for inspecting work performed by one or more other agents and, for example, to (a) verify that a task was actually completed and, if not, give feedback to a main agent to rectify; and (b) create new functions and/or tools that may be used to accomplish one or more tasks (e.g., similar and/or other) in the future with improved efficiency (e.g., fewer iterations) and/or accuracy.

As an example, one or more features may provide for enabling one or more agents to learn and/or hone skills (e.g., new or old) while operating in a real, live environment. In comparison to such a dynamic system, a static tool-based agent may be limited to operating within constraints of one or more tools provided to it. Again, in a dynamic system, code generation capabilities combined with a retrospective agent can allow for agents to overcome limitations of tools provided to them by allowing for tool creation and/or customization.

As an example, the system 1000 may be utilized to implement a workflow that includes retrieving relevant facts and skills from long-term memory. In such an example, retrieval may extend beyond a simple vector search to utilize an LLM to generate a number of queries (e.g., consider up to three queries, etc.) that are relevant to a given task. In such an example, a similarity search may be performed using a vector database using the number of queries where top ranked results may be returned. In such an example, the probability that relevant information is found may be increased, for example, as providing a number of queries can increase diversity.

In such a workflow, an execution environment may be leveraged (e.g., consider PYTHON, pre-installed modules, etc.), where a prompt may be augmented optionally along with one or more custom function documents (e.g., non-source documents) that one or more agents may access. As an example, functions may include functions for accessing long-term memory and for interacting with one or more users and/or one or more domains (e.g., consider specific functions to facilitate an agent in task completion).

In such a workflow, a prompt may be completed by adding instructions on how an agent is to operate (e.g., a Chain of Thought) and how one or more responses are to be structured.

In such a workflow, an execution environment may be pre-existing (e.g., pre-established) and/or initialized, for example, by running setup code and providing source code of one or more custom functions provided to an agent.

In such a workflow, an LLM chat completion API may be called where, for example, a response may be parsed to extract a thought that explains the reasoning of the LLM and the code it would like to execute as a subsequent action (e.g., a subsequent workflow task).

In such a workflow, code may be transmitted to an execution environment where it can be run to generate output where the output may be returned as appropriate. As an example, such output may be added as a “human” response and the LLM may be called again. The power of such a seemingly simple loop lies in the fact that an agent can iterates through a thought, execute, observe cycle until a given goal is reached. Such an approach can include implementing one or more components for handling one or more types of execution errors, such as, for example, exceptions and code bug fixing. Such an approach may help to ensure robust operation, together with improvements in code generation. For example, when one or more exceptions and/or bugs appear, a code generator may be improved to avoid such exceptions and/or bugs. For example, consider an auto-code generator that may operate using such information, a table approach as to prohibited code and/or code structures, etc. Accordingly, feedback may be utilized in one or more manners to enhance operation such that a system becomes more robust in its operation over time (e.g., responsive to use, etc.).

In such a workflow, a system may repeat a generate and execute loop until one or more criteria are met. For example, consider a maximum number of iterations as being specified and/or goal attainment. As an example, where one or more feedback mechanisms are provided as to performance, a system may be dynamic in that it can reduce number of iterations and/or otherwise help to improve and/or assure goal attainment, particularly over time (e.g., responsive to use, etc.). As an example, within each loop, an agent may be reminded of how many iterations it has used up and given a warning before a final iteration. In general, an agent may be expected to complete a task within a given number of iterations, which may be tracked as a performance metric (e.g., for agent QA, modification, improvement, etc.). As an example, the time it takes for an agent to accomplish a goal may depend on the task given, for example, in a search agent implementation, a task may be accomplished within less than approximately 5 iterations (e.g., plus or minus 2 iterations); whereas, for example, a different agent, such as a driller agent, may demand more time and more iterations in a manner that may depend on nature of a task (e.g., consider instances where a driller agent may take ten minutes or more).

In such a workflow, once an agent believes it has successfully completed a task, the workflow may call for a retrospective assessment. Such an assessment may be performed in one or more of a number of manners. For example, consider an agent-on-agent approach where another agent (e.g., a second agent) examines an agent solution (e.g., of a first agent) to determine how it arrived at a result. In such an example, a retrospective agent may determine if a given goal was reached and, if not, the retrospective agent may provide feedback on why the goal was not met where reasons therefore may be transmitted back to the agent (e.g., first agent) with instructions to try again, optionally with one or more modifications. As explained, if a given goal is met, then a retrospective agent may operate to extract one or more skills that may be useful for solving one or more similar tasks in the future. As an example, such skills may be functions with associated code and a description that may be added in a long-term memory storage. In such an example, a stored skill may then be retrieved, as appropriate, for example, if relevant for one or more future tasks. Such an approach allows an agent to learn as it accomplishes tasks, so that next time a task may be performed more efficiently (e.g., with fewer errors). As an example, a retrospective component or components of a system may be selectable and/or configurable. Such an approach may provide for dynamic retrospectives and dynamic agent improvement, noting that a retrospective may be performed using an agent or agents, which may be dynamically improved. As explained, a system, such as the system 1000 of FIG. 10, may provide for continual improvement, for example, by improving knowledge and/or improving one or more components (e.g., agents, etc.).

As explained, skills may be represented using code where, for example, one or more skills and/or one or more primitive functions may be injected into a prompt. As an example, primitive functions may be frequently injected, optionally by default; whereas, skills may be injected based on relevance (e.g., consider retrieval of one or more skills on the basis of relevance). In such an approach, a system may allow for more functions to be added as skills without increasing prompt size and complexity (e.g., as skills may be retrieved on demand and by relevance). As explained, code may be in the form of instructions, which may be, as appropriate, suitable for interpretation, compilation, translation, etc. As an example, an instruction database may be secure and an execution environment may be secure. In such an example, security may help to assure that risks of unintended consequences are minimized (e.g., errant code, malicious code, etc.). As an example, code may be limited in terms of size, capabilities, functions, output, etc. As an example, where an execution environment catches a code execution issue, a loop may provide for halting execution, flagging the code, and optionally resubmitting a prompt with one or more constraints, etc., to provide for performing a constrained relevance search for more effective code. As explained, where appropriate features are included in a system, problematic code may be repaired, whether on the fly and/or by a human-in-the-loop (HITL). Such an approach may make a system more robust, while improving a code database and/or an associated relevance search mechanism, etc. As an example, a system may provide for custom agent and/or code building and, for example, one or more runtime environments for testing thereof prior to implementation.

FIG. 11 shows an example of a system 1100 that includes an actor 1110 (e.g., a human and/or a machine), a plan 1112 (e.g., for drilling a stand, circulating mud, setting a drilling limit, etc.), one or more datastores of standard operating procedures (SOPs) and/or other information 1114, an embodied agent 1130, a drilling framework 1150 (e.g., consider the DRILLOPS framework), and field equipment 1170.

In the example of FIG. 11, the system 1100 the embodied agent 1130 may provide for dynamic interactions that improve field operations, as may be based at least in part on the plan 1112 and input from the actor 1110. In such an example, the embodied agent 1130 can provide reasoning for improved generation of compliant plans and control of physical actions that enable the embodied agent 1130 agent to accomplish a goal given by the actor 1110. Such an approach may involve interaction between an LLM and an environment, for example, within a system that leverages a GenAI enabled embodied agent.

As an example, the embodied agent 1130 may receive a goal from the actor 1110 in a natural language (e.g. “drill to 5000 ft, after 2000 ft increase the WOB by 20% also if the ROP drops below 50 ft/hr increase the WOB by a further 10%”). In such an example, the embodied agent 1130 may leverage knowledge provided the one or more datastores 1110 (e.g., procedures and material written in natural language, etc.) to generate a plan 1112 that complies with appropriate provided practices. The embodied agent 1130 may then select actions to be taken to execute the plan 1112, while monitoring the state of the environment (e.g., a rigsite, etc.) to help ensure that the environment is in a desired state, transitions appropriately from one state to another, etc. In such an example, if an observation of the environment (e.g., via sensors, feedback, controllers, etc.) may indicate non-compliance compared to what was expected, then the embodied agent 1130 may operate to revise the plan 1112 while complying with the provided procedures. In such an example, the embodied agent 1130 can repeat such a loop. As an example, such a loop may be iterated optionally without additional input from the actor 1110, noting that the system 1100 may include one or more interaction mechanisms suitable for providing output to the actor 1110 and/or receiving additional input from the actor 1110, which may be in the form of interactions with one or more graphical user interfaces, voice interface, gesture interfaces, etc., which may provide for natural gesture input (e.g., a form of sign language), natural language input, etc.

As explained, the embodied agent 1130 may iterate through multiple reason, act, observe iterations until a goal is met. As explained, an embodied agent may perform such iterations based at least in part on interactions with an environment (e.g., field equipment). As explained, an embodied agent can generate control actions and receive feedback such that a control loop is established.

As explained, an agent may operate according to a given goal. For example, if a goal given to an agent is to “drill until a depth of 10,000 ft is reached”, then the agent may operate to retrieve information related to drilling a stand, adding a stand, how to set drilling parameters and best practices related to the drilling process. As explained, a system may provide for such content to be injected into a prompt such that a general purpose LLM may be able to follow domain specific procedures.

As explained, an agent may access an execution environment, which may be, for example, a sandboxed environment where it can execute code that it generates an action. Such an approach provides an agent with flexibility in that the agent may create more complex sequences and loops to achieve a specific goal. Further, in such an approach an agent may build code routines that may be suitable for reuse (e.g., to solve a similar problem in the future).

As explained, a system may include long-term memory (e.g., a datastore, etc.). Such an approach may provide an agent with additional information, as may be appropriate, for example, to adjust a plan to comply with directions that may result in fact creation in long-term memory that can be recalled in the future. As an example, long-term memory may be used by an agent to store code recipes, for example, code that has successfully worked to accomplish a goal. As explained, a skill may be represented by code such that the skill can then be recalled such that a task may accomplished faster and more consistently.

In the example of FIG. 11, the system 1100 may provide for control of field equipment responsive to input from the actor 1110, which may be in a natural language. For example, consider input as follows: Drill a stand, then trip out 2 stands, Circulate on-bottom for 5 minutes, drill another stand and increase the ROP (Rate of penetration) limit to 200 ft/hr when you get to 1500 ft. In response, the embodied agent 1130 may generate a plan, for example, consider the following plan:

To accomplish the task, we need to follow these steps:

1. Drill a Stand: Check the current planMotivation to ensure no other procedure is in progress. Check the bit depth and hole depth to ensure they are within one stand's length. If the bit depth is not within one stand's length of the hole depth, trip in until it is. Request to drill a stand and monitor the planMotivation until it indicates the procedure has started and finished.

2. Trip Out 2 Stands: Ensure the planMotivation is set to Nothing. Request to trip out and monitor the planMotivation until it indicates the procedure has started and finished. Repeat the process to trip out the second stand.

3. Circulate Off Bottom for 5 Minutes: Ensure the planMotivation is set to Nothing. Request to circulate off bottom and monitor the planMotivation until it indicates the procedure has started. Wait for 5 minutes and then ensure the planMotivation indicates the procedure has finished.

4. Drill Another Stand: Ensure the planMotivation is set to Nothing. Check the bit depth and hole depth to ensure they are within one stand's length. If the bit depth is not within one stand's length of the hole depth, trip in until it is. Request to drill a stand and monitor the planMotivation until it indicates the procedure has started and finished.

5. Increase the ROP Limit to 200 ft/hr when the bit depth reaches 1500 ft: Continuously monitor the bit depth. When the bit depth reaches 1500 ft, request to change the ROP limit to 200 ft/hr. Let's start by checking the current planMotivation and the rig state to get the bit depth and hole depth.

In such an example, the embodied agent 1130 may execute the plan by sending requests to the drilling framework 1150 where the embodied agent 1130 can monitor the drilling framework 1150 and/or the field equipment 1170 to track progress and make one or more adjustments to help ensure successful execution.

As an example, the embodied agent 1130 may provide for gap filling. For example, if the drill bit is not in range to drill, the embodied agent 1130 can reason that tripping in (RIH) is to be performed prior to commencing drilling. In such an example, the embodied agent 1130 may check preconditions, determine if tripping in is needed, request tripping in, monitor plan execution, and request drilling a stand, when and if appropriate.

By leveraging dynamic planning and reasoning capabilities of an embodied agent, a system may successfully automate field operations for one or more purposes (e.g., construction of a well, etc.), in a manner that may allow for a variety of custom procedures. For example, consider trip to certain depths, change how hole cleaning is performed, perform friction tests, set drilling parameters based on observed rig state, etc. As explained, an agent may add a level of customizability and performance to drilling automation.

As explained, a system, framework, etc., may provide for implementation of one or more agentic workflows, which may provide for human and machine interactions, which may be, for example, at a wellsite. As an example, an agent may provide for monitoring and/or control. For example, if an issue may arise, such as an elevated risk, an agent may provide for adjusting a level of automation that calls for more human involvement. In such an example, where things are going smoothly, an agent may call for less human involvement by increasing a level of automation.

FIG. 12 shows an example of a method 1200 and an example of a system 1290. As shown, the method 1200 may include a reception block 1210 for receiving a prompt via a large language model agent in a framework that includes multiple large language model agents; a generation block 1220 for, responsive to the prompt, generating one or more agent actions; a transmission block 1230 for transmitting the one or more agent actions to one or more of the multiple large language model agents; and a generation block 1240 for, responsive to the transmitting, generating a control action implementable by a controller operatively coupled to one or more pieces of equipment at a field site.

FIG. 12 also shows various computer-readable media (CRM) blocks 1211, 1221, 1231, and 1241. Such blocks may include instructions that are executable by one or more processors, which may be one or more processors of a computational framework, a system, a computer, etc. A computer-readable medium may be a computer-readable storage medium that is not a signal, not a carrier wave and that is non-transitory. For example, a computer-readable medium may be a physical memory component that may store information in a digital format.

In the example of FIG. 12, a system 1290 includes one or more information storage devices 1291, one or more computers 1292, one or more networks 1295 and instructions 1296. As to the one or more computers 1292, each computer may include one or more processors (e.g., or processing cores) 1293 and memory 1294 for storing the instructions 1296, for example, executable by at least one of the one or more processors. As an example, a computer may include one or more network interfaces (e.g., wired or wireless), one or more graphics cards, a display interface (e.g., wired or wireless), etc. The system 1290 may be specially configured to perform one or more portions of the method 1200 of FIG. 12.

As an example, a computational framework may include a solver, which may be implemented via executable instructions. For example, consider a computational framework that includes a processor and memory accessible to the processor where executable instructions may be stored in the memory and accessed for execution by the processor to cause the computational framework to perform one or more actions. Such a computational framework may include one or more interfaces for receipt of information and/or for output of information, which may include values of parameters, an instruction, etc. As an example, a computational framework may be part of a controller. As an example, a computational framework may be part of a system.

As an example, various systems, methods, etc., may implement one or more ML models. As to types of ML models, consider one or more of a support vector machine (SVM) model, a k-nearest neighbors (KNN) model, an ensemble classifier model, a neural network (NN) model, etc. As an example, a machine learning model may be a deep learning model (e.g., deep Boltzmann machine, deep belief network, convolutional neural network, stacked auto-encoder, etc.), an ensemble model (e.g., random forest, gradient boosting machine, bootstrapped aggregation, AdaBoost, stacked generalization, gradient boosted regression tree, etc.), a neural network model (e.g., radial basis function network, perceptron, back-propagation, Hopfield network, etc.), a regularization model (e.g., ridge regression, least absolute shrinkage and selection operator, elastic net, least angle regression), a rule system model (e.g., cubist, one rule, zero rule, repeated incremental pruning to produce error reduction), a regression model (e.g., linear regression, ordinary least squares regression, stepwise regression, multivariate adaptive regression splines, locally estimated scatterplot smoothing, logistic regression, etc.), a Bayesian model (e.g., naïve Bayes, average on-dependence estimators, Bayesian belief network, Gaussian naïve Bayes, multinomial naïve Bayes, Bayesian network), a decision tree model (e.g., classification and regression tree, iterative dichotomiser 3, C4.5, C5.0, chi-squared automatic interaction detection, decision stump, conditional decision tree, M5), a dimensionality reduction model (e.g., principal component analysis, partial least squares regression, Sammon mapping, multidimensional scaling, projection pursuit, principal component regression, partial least squares discriminant analysis, mixture discriminant analysis, quadratic discriminant analysis, regularized discriminant analysis, flexible discriminant analysis, linear discriminant analysis, etc.), an instance model (e.g., k-nearest neighbor, learning vector quantization, self-organizing map, locally weighted learning, etc.), a clustering model (e.g., k-means, k-medians, expectation maximization, hierarchical clustering, etc.), etc.

As an example, a system may utilize one or more recurrent neural networks (RNNs). One type of RNN is referred to as long short-term memory (LSTM), which may be a unit or component (e.g., of one or more units) that may be in a layer or layers. A LSTM component may be a type of artificial neural network (ANN) designed to recognize patterns in sequences of data, such as time series data. When provided with time series data, LSTMs take time and sequence into account such that an LSTM may include a temporal dimension. For example, consider utilization of one or more RNNs for processing temporal data from one or more sources, optionally in combination with spatial data. Such an approach may recognize temporal patterns, which may be utilized for making predictions (e.g., as to a pattern or patterns for future times, etc.).

As an example, the TENSORFLOW framework (Google LLC, Mountain View, California) may be implemented, which is an open-source software library for dataflow programming that includes a symbolic math library, which may be implemented for machine learning applications that may include neural networks. As an example, the CAFFE framework may be implemented, which is a DL framework developed by Berkeley AI Research (BAIR) (University of California, Berkeley, California). As another example, consider the SCIKIT platform (e.g., scikit-learn), which utilizes the PYTHON programming language. As an example, a framework such as the APOLLO AI framework may be utilized (APOLLO.AI GmbH, Germany). As mentioned, a framework such as the PYTORCH framework may be utilized.

As an example, a training method may include various actions that may operate on a dataset to train a ML model. As an example, a dataset may be split into training data and test data where test data may provide for evaluation. A method may include cross-validation of parameters and best parameters, which may be provided for model training.

The TENSORFLOW framework may run on multiple CPUs and GPUs (with optional CUDA (NVIDIA Corp., Santa Clara, California) and SYCL (The Khronos Group Inc., Beaverton, Oregon) extensions for general-purpose computing on graphics processing units (GPUs)). TENSORFLOW is available on 64-bit LINUX, MACOS (Apple Inc., Cupertino, California), WINDOWS (Microsoft Corp., Redmond, Washington), and mobile computing platforms including ANDROID (Google LLC, Mountain View, California) and IOS (Apple Inc.) operating system-based platforms.

TENSORFLOW computations may be expressed as stateful dataflow graphs; noting that the name TENSORFLOW derives from the operations that such neural networks perform on multidimensional data arrays. Such arrays may be referred to as “tensors”.

As an example, a method may include receiving a prompt via a large language model agent in a framework that includes multiple large language model agents; responsive to the prompt, generating one or more agent actions; transmitting the one or more agent actions to one or more of the multiple large language model agents; and, responsive to the transmitting, generating a control action implementable by a controller operatively coupled to one or more pieces of equipment at a field site. In such an example, the large language model agent may be an operator agent for an operator at the field site. In such an example, the operator may be a driller, where the field site is a rig site, and where the one or more pieces of equipment are at the rig site. In such an example, a driller may be a human driller and/or a machine driller. As an example, a driller may be an autodriller that may provide for equipment automation to perform one or more field operations. As an example, an autodriller may be a controller that may provide for implementation of automatic control at one or more levels of automation. In such an example, where confidence in automated control is increased, a level of automation may be increased (e.g., consider an ability to operate with less human interaction and/or decision-making) and/or where confidence in automated control is decreased, a level of automation may be decreased (e.g., consider more human interaction and/or decision-making).

As an example, multiple large language model agents may include an observer agent that operates based at least in part on sensor data from one or more sensors at the field site. In such an example, the observer agent may determine a state at a field site, where the state may be an operational state and/or an equipment state. As an example, an observer agent may generate one or more application programming interface calls. In such an example, the one or more application programming interface calls may include at least one library call to a computational library that may include data processing routines. For example, consider data processing routines that may include one or more of statistical, physics-based, and probabilistic data processing routines. As an example, a machine learning-based data processing routine may provide for receipt of input and generation of output, which may be accompanied by one or more statistical and/or probabilistic metrics. As an example, a framework may operate using one or more statistical and/or probabilistic metrics, for example, to make decisions as to one or more actions, one or more results, etc.

As an example, multiple large language model agents may include a subject matter expert agent. As an example, a subject matter expert agent may generate one or more application programming interface calls. In such an example, the one or more application program interface calls may include one or more of an Internet search engine call and a wiki database call; noting that one or more other types of API calls may be performed.

As an example, multiple large language model agents may include a subject matter expert agent and an observer agent, where the subject matter expert agent may be operatively coupled to the observer agent.

As an example, multiple large language model agents may include a subject matter expert agent and a documentation agent, where the subject matter expert agent is operatively coupled to the documentation agent. In such an example, the documentation agent may be operatively coupled to one or more databases. As an example, one or more databases may include a vector database. As an example, one or more databases may include embeddings. In such an example, the embeddings may include embeddings derived from one or more documents that specify one or more operational procedures for equipment-based operations at the field site.

As an example, a method may include, responsive to implementation of a control action by a controller for completion of an associated task, performing a retrospective assessment of the completed task for learning a new skill for the large language model agent. As explained, agents may be dynamic in that new skills (e.g., code, methods, etc.) may be learned, which may help to improve an agent or agents. As explained, an agentic system may include components for self-learning, self-improvement, etc., where, for example, as control actions are performed as to field equipment, the agentic system becomes more adept at controlling field equipment for one or more purposes (e.g., efficiency, emissions reduction, improved production, improved safety, reduced risk, etc.).

As an example, a prompt may be generated by a human and/or a machine. For example, in the domain of drilling, a human driller and/or a drilling controller may provide for prompt generation. For example, consider a control routine that may include codes, natural language, etc., that may be issued as a prompt or prompts. As an example, a human driller may provide for prompt generation via a keyboard, a microphone, interaction with a graphical user interface and/or another type of user interface, etc.

As an example, a system may include one or more processors; memory accessible to at least one of the one or more processors; processor-executable instructions stored in the memory and executable to instruct the system to: receive a prompt via a large language model agent in a framework that includes multiple large language model agents; responsive to the prompt, generate one or more agent actions; transmit the one or more agent actions to one or more of the multiple large language model agents; and, responsive to the transmission, generate a control action implementable by a controller operatively coupled to one or more pieces of equipment at a field site.

As an example, one or more computer-readable storage media may include processor-executable instructions to instruct a computing system to: receive a prompt via a large language model agent in a framework that includes multiple large language model agents; responsive to the prompt, generate one or more agent actions; transmit the one or more agent actions to one or more of the multiple large language model agents; and, responsive to the transmission, generate a control action implementable by a controller operatively coupled to one or more pieces of equipment at a field site.

As an example, a computer program product that may include computer-executable instructions to instruct a computing system to perform one or more methods such as one or more of the methods described herein (e.g., in part, in whole and/or in various combinations).

In some embodiments, a method or methods may be executed by a computing system. FIG. 13 shows an example of a system 1300 that may include one or more computing systems 1301-1, 1301-2, 1301-3 and 1301-4, which may be operatively coupled via one or more networks 1309, which may include wired and/or wireless networks. As shown, the system 1300 may include one or more other components 1308.

As an example, a system may include an individual computer system or an arrangement of distributed computer systems. In the example of FIG. 13, the computer system 1301-1 may include one or more modules 1302, which may be or include processor-executable instructions, for example, executable to perform various tasks (e.g., receiving information, requesting information, processing information, simulation, outputting information, etc.).

As an example, a module may be executed independently, or in coordination with, one or more processors 1304, which is (or are) operatively coupled to one or more storage media 1306 (e.g., via wire, wirelessly, etc.). As an example, one or more of the one or more processors 1304 may be operatively coupled to at least one of one or more network interface 1307. In such an example, the computer system 1301-1 may transmit and/or receive information, for example, via the one or more networks 1309 (e.g., consider one or more of the Internet, a private network, a cellular network, a satellite network, etc.). As shown, one or more other components 1308 may be included in the computer system 1301-1.

As an example, the computer system 1301-1 may receive from and/or transmit information to one or more other devices, which may be or include, for example, one or more of the computer systems 1301-2, etc. A device may be located in a physical location that differs from that of the computer system 1301-1. As an example, a location may be, for example, a processing facility location, a data center location (e.g., server farm, etc.), a rig location, a wellsite location, a downhole location, etc.

As an example, a processor may be or include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array, or another control or computing device.

As an example, the storage media 1306 may be implemented as one or more computer-readable or machine-readable storage media. As an example, storage may be distributed within and/or across multiple internal and/or external enclosures of a computing system and/or additional computing systems.

As an example, a storage medium or storage media may include one or more different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories, magnetic disks such as fixed, floppy and removable disks, other magnetic media including tape, optical media such as compact disks (CDs) or digital video disks (DVDs), BLUERAY disks, or other types of optical storage, or other types of storage devices.

As an example, a storage medium or media may be located in a machine running machine-readable instructions, or located at a remote site from which machine-readable instructions may be downloaded over a network for execution.

As an example, various components of a system such as, for example, a computer system, may be implemented in hardware, software, or a combination of both hardware and software (e.g., including firmware), including one or more signal processing and/or application specific integrated circuits.

As an example, a system may include a processing apparatus that may be or include a general-purpose processors or application specific chips (e.g., or chipsets), such as ASICs, FPGAs, PLDs, or other appropriate devices.

As an example, a device may be a mobile device that includes one or more network interfaces for communication of information. For example, a mobile device may include a wireless network interface (e.g., operable via IEEE 802.11, ETSI GSM, BLUETOOTH, satellite, etc.). As an example, a mobile device may include components such as a main processor, memory, a display, display graphics circuitry (e.g., optionally including touch and gesture circuitry), a SIM slot, audio/video circuitry, motion processing circuitry (e.g., accelerometer, gyroscope), wireless LAN circuitry, smart card circuitry, transmitter circuitry, GPS circuitry, and a battery. As an example, a mobile device may be configured as a cell phone, a tablet, etc. As an example, a method may be implemented (e.g., wholly or in part) using a mobile device. As an example, a system may include one or more mobile devices.

As an example, a system may be a distributed environment, for example, a so-called “cloud” environment where various devices, components, etc. interact for purposes of data storage, communications, computing, etc. As an example, a device or a system may include one or more components for communication of information via one or more of the Internet (e.g., where communication occurs via one or more Internet protocols), a cellular network, a satellite network, etc. As an example, a method may be implemented in a distributed environment (e.g., wholly or in part as a cloud-based service).

As an example, information may be input from a display (e.g., consider a touchscreen), output to a display or both. As an example, information may be output to a projector, a laser device, a printer, etc. such that the information may be viewed. As an example, information may be output stereographically or holographically. As to a printer, consider a 2D or a 3D printer. As an example, a 3D printer may include one or more substances that may be output to construct a 3D object. For example, data may be provided to a 3D printer to construct a 3D representation of a subterranean formation. As an example, layers may be constructed in 3D (e.g., horizons, etc.), geobodies constructed in 3D, etc. As an example, holes, fractures, etc., may be constructed in 3D (e.g., as positive structures, as negative structures, etc.).

Although only a few examples have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the examples. Accordingly, all such modifications are intended to be included within the scope of this disclosure as defined in the following claims. In the claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents, but also equivalent structures. Thus, although a nail and a screw may not be structural equivalents in that a nail employs a cylindrical surface to secure wooden parts together, whereas a screw employs a helical surface, in the environment of fastening wooden parts, a nail and a screw may be equivalent structures.