Autonomous hierarchical multi-agent system for energy applications

Abstract

A method implements an autonomous hierarchical multi-agent system. The method involves receiving an application prompt from an application. The method further involves executing central instructions of a central agent, corresponding to the application, with a foundational model to process the application prompt, select a specialized agent cluster from a cluster list, and generate a cluster prompt for the specialized agent cluster. The method further involves executing cluster instructions of a cluster agent, corresponding to the specialized agent cluster, with the foundational model to process the cluster prompt, select a domain agent from a domain agent list, and generate a domain prompt for the domain agent. The method further involves executing domain instructions of the domain agent, with the foundational model, based on the domain prompt. The method further involves transmitting an application response to the application, in which the application response is presented by the application.

Description

PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902AUTONOMOUS HIERARCHICAL MULTI-AGENT SYSTEM FOR ENERGY APPLICATIONSCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of US Provisional Application 63 / 694,383 filed September 13, 2024, which is incorporated by reference herein.BACKGROUND

[0002] Artificial intelligence (Al) systems are computational systems that perform tasks associated with intelligence, such as perception, reasoning, learning, and decision-making. Artificial intelligence systems utilize algorithms and statistical models to process large volumes of structured and unstructured data for predictive analytics, pattern recognition, and autonomous control. In industrial applications, artificial intelligence systems optimize processes, reduce downtime, and execute real-time decision making.

[0003] Foundational models are large-scale machine learning models trained on broad and diverse datasets across multiple domains and tasks. Models based on transformer architectures function as a base for fine-tuning and adaptation to specialized applications. The ability to process multi-modal inputs such as text, images, and sensor data makes foundational models highly versatile for complex environments. Foundational models may be used to developing domain-specific solutions without extensive retraining from scratch.

[0004] An agent in machine learning is an autonomous computational entity that perceives an environment, processes information, and takes actions to achieve specific objectives. Systems may apply reinforcement learning for agents to improve performance through interaction and feedback. Agents are used in dynamic and distributed environments such as industrial automation for real-time adaptability and decentralized decision-making.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902SUMMARY

[0005] In general, in one or more aspects, the disclosure relates to a method implementing an autonomous hierarchical multi-agent system. The method involves receiving an application prompt from an application. The method further involves executing central instructions of a central agent, corresponding to the application, with a foundational model to process the application prompt, select a specialized agent cluster from a cluster list, and generate a cluster prompt for the specialized agent cluster. The method further involves executing cluster instructions of a cluster agent, corresponding to the specialized agent cluster, with the foundational model to process the cluster prompt, select a domain agent from a domain agent list, and generate a domain prompt for the domain agent. The method further involves executing domain instructions of the domain agent, with the foundational model, based on the domain prompt to perform one or more of accessing a data store and invoking a domain tool application to generate a domain response. The method further involves processing the domain response using the cluster agent to generate a cluster response. The method further involves processing the cluster response using the central agent to generate an application response. The method further involves transmitting the application response to the application, in which the application response is presented by the application.

[0006] In general, in one or more aspects, the disclosure relates to a system that includes at least one processor and an application that executes on the at least one processor. Executing the application performs receiving an application prompt from an application. Executing the application further performs executing central instructions of a central agent, corresponding to the application, with a foundational model to process the application prompt, select a specialized agent cluster from a cluster list, and generate a cluster prompt for the specialized agent cluster. Executing the application further performs executing cluster instructionsPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 of a cluster agent, corresponding to the specialized agent cluster, with the foundational model to process the cluster prompt, select a domain agent from a domain agent list, and generate a domain prompt for the domain agent. Executing the application further performs executing domain instructions of the domain agent, with the foundational model, based on the domain prompt to perform one or more of accessing a data store and invoking one or more of a domain tool application and a domain application to generate a domain response. Executing the application further performs processing the domain response using the cluster agent to generate a cluster response. Executing the application further performs processing the cluster response using the central agent to generate an application response. Executing the application further performs transmitting the application response to the application, in which the application response is presented by the application.

[0007] In general, in one or more aspects, the disclosure relates to a non-transitory computer readable medium including instructions executable by at least one processor. Executing the instructions performs receiving an application prompt from an application. Executing the instructions further performs executing central instructions of a central agent, corresponding to the application, with a foundational model to process the application prompt, select a specialized agent cluster from a cluster list, and generate a cluster prompt for the specialized agent cluster. Executing the instructions further performs executing cluster instructions of a cluster agent, corresponding to the specialized agent cluster, with the foundational model to process the cluster prompt, select a domain agent from a domain agent list, and generate a domain prompt for the domain agent. Executing the instructions further performs executing domain instructions of the domain agent, with the foundational model, based on the domain prompt to perform one or more of accessing a data store and invoking a domain tool application toPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 generate a domain response. Executing the instructions further performs processing the domain response using the cluster agent to generate a cluster response. Executing the instructions further performs processing the cluster response using the central agent to generate an application response. Executing the instructions further performs transmitting the application response to the application, in which the application response is presented by the application.

[0008] Other aspects of one or more embodiments may be apparent from the following description and the appended claims.BRIEF DESCRIPTION OF DRAWINGS

[0009] FIG. 1 shows a diagram in accordance with the disclosure.

[0010] FIG. 2 shows a method in accordance with the disclosure.

[0011] FIG. 3, FIG. 4, FIG. 5, FIG. 6, FIG. 7, FIG. 8, show examples in accordance with the disclosure.

[0012] FIG. 9 shows a computing system in accordance with the disclosure.

[0013] Similar elements in the various figures may be denoted by similar names and reference numerals. The details of features and elements described in one figure may extend to similarly named features and elements in different figures.DETAILED DESCRIPTION

[0014] Embodiments of the disclosure implement autonomous hierarchical multiagent systems, which may be used in oil and gas domains. Current technologies may lack domain-specific intelligence, flexibility, and integration capabilities for complex, multi-step workflows in a regulated and dynamic industry.

[0015] To address these challenges, embodiments are directed to an agent management system. The agent management system is configured to dynamicallyPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 select a specialized agent cluster and one or more agents within that cluster based on the operational objective. Each agent may be trained on domain-specific datasets and optimized for tasks such as reservoir modeling, drilling optimization, or production forecasting. The targeted approach applies deep technical expertise to each decision, improving accuracy and reliability compared to generic Al solutions.

[0016] Further, the agent management system is a hierarchical, modular framework that includes a central coordination module, cluster managers, and individual agents. The architecture supports distributed decision-making, where each layer focuses on a specific level of abstraction, from global optimization at the central module to granular task execution at the agent level. By decomposing complex workflows into manageable components, the system achieves scalability, fault tolerance, and improved performance across the value chain.

[0017] The agent management system includes the central coordination module to identify a target state for the system and orchestrate multiple specialized clusters to achieve that state. The coordination aligns interdependent tasks in the appropriate sequence or in parallel where applicable, producing a unified, end-to- end workflow that reduces inefficiencies and accelerates operational decision cycles.

[0018] Turning to FIG. 1, the system (100) is a hierarchical multi-agent generative artificial intelligence platform for oil and gas workflows. The system (100) includes components for receiving prompts, generating responses, coordinating agents, and verifying outputs. Each of the prompts and responses used by the system (100) may include natural language text and may include multiple modalities, such as well logs, seismic data, production time series data, drilling equipment data, audio, and images. The system (100) interfaces with the applications (102), foundational models (192), data stores (which may includePATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 vector databases and include traditional exploration and production data sources) (182), and domain tool applications (185) (which may include oil and gas domain tool applications) to orchestrate planning and execution of workflows (which may include oil and gas workflows).

[0019] The applications (102) are software components that interface between user environments and the agent management system (122). The applications (102) generate the application prompts (105), present the application responses (108), and transmit the user feedback (110). The applications (102) include mechanisms for session context management, external system integration, and secure data transmission.

[0020] The application prompts (105) are structured data constructs generated by the applications (102) to initiate processing. Generally, a prompt is a request or set of instructions that identifies specific output. The application prompts (105) include content such as text (e.g., natural language text), images, audio, video, seismic data, well logs, production time series, and metadata for routing and interpretation. The application prompts (105) are formatted using standardized schemas based on data types and include embedded constraints and execution parameters.

[0021] The application responses (108) are structured outputs generated by the agent management system (122) in response to the application prompts (105). One of the application responses (108) may correspond to one of the application prompts (105). The application responses (108) include content such as text (e.g., natural language text), numerical data, images, seismic visualization, production time series forecasts, drilling plans, and metadata for presentation and tracking. The application responses (108) are formatted using standardized schemas and transmitted securely to the applications (102).PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0022] The user feedback (110) is structured data submitted by user environments providing an assessment of the application responses (108). The user feedback (108) may be associated with one or more of a prior application response, a prior cluster response, and a prior domain response of the system. The user feedback (110) includes indicators such as satisfaction ratings, error reports, and annotations for verification and refinement. The user feedback (1 10) is formatted using standardized schemas and used by the agent management system (122) for adaptive planning.

[0023] The agent management system (122) is a hierarchical multi-agent orchestration framework within the system (100). The agent management system (122) includes the central coordination modules (125) and the specialized agent clusters (155) for distributed task execution. The agent management system (122) controls prompt routing, agent selection, task allocation, and feedback integration using probabilistic reasoning with the foundational models (192), which may include a domain foundational model, such as a seismic foundation model, a well log foundation model, and a time series foundation model.

[0024] An agent of the agent management system (122) is a computational entity that performs autonomous decision-making tasks within the system (100). An agent includes logic and prompts executable by one of the foundational models (192) to perform classification, prediction, planning, and verification. An agent may operate independently or within a multi-agent system and access external data sources and tools.

[0025] The cental coordination modules (125) are top-level orchestration components of the agent management system (122). The central coordination modules (125) process the application prompts (105) to generate the cluster prompts (140) and process the cluster responses (142) to generate the application responses (108). The cent al coordination modules (125) contol the cental agentsPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902(128), generate the cluster prompts (140), and maintain metadata such as the cluster agent lists (138). The central coordination modules (125) include planning algorithms, task allocation logic, and supervisory control mechanisms for coordination of the specialized agent clusters (155).

[0026] The central agents (128) are computational entities that execute the central instructions (130) using the foundational models (192). The central agents (128) generate the cluster prompts (140), apply planning and verification logic, and access the central tool applications (135). The central agents (128) include orchestration routines, metadata registries, and communication protocols (like agent to agent protocol) for distributed execution.

[0027] The central instructions (130) are executable directives used by the central agents (128) for hierarchical orchestration. The central instructions (130) include the central planning instructions (131) and the central verification instructions (132) executed by the foundational models (192). The central instructions (130) define logic for prompt decomposition, sub-task definition, cluster selection, response evaluation, content moderation plus prompt injection guardrails and policy compliance.

[0028] The central planning instructions ( 131) are a subset of the central instructions(130) used to construct multi-step workflows. The central planning instructions(131) include prompt templates and routines executed by the foundational models (192) to generate the cluster prompts (140). The central planning instructions (131) reference metadata from the cluster agent lists (138) and include logic for task decomposition and execution path optimization. The central planning instructions may also define the sequence and flow in which specialized cluster agents will be executed. The sequence may be sequential or parallel and may also be nested.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0029] The central verification instructions (132) are a subset of the central instructions (130) used to evaluate cluster responses (142). The central verification instructions (132) include probabilistic routines and benchmark test datasets along with verification prompts and guidelines executed by the foundational models (192) to verify the cluster responses (142). The central verification instructions (132) include logic for re-evaluation workflows, diagnostic generation, and compliance assessment.

[0030] The central tool applications (135) are software components used by the central agents (128) for orchestration tasks. The central tool applications (135) include interfaces, solution verifiers, utility modules, and connectors for metadata retrieval and prompt transmission. The central tool applications (135) are modular and extensible for integration with orchestration platforms and policy engines.

[0031] The cluster agent lists (138) are structured data repositories used by the central agents (128) to identify the specialized agent clusters (155). The cluster agent lists (138) include identifiers, domain descriptions, tool descriptions, access rights, execution constraints, and coordination protocols. The cluster agent lists (138) are referenced by the central planning instructions (131) and the central verification instructions (132) for cluster selection and evaluation.

[0032] The cluster prompts (140) are structured data constructs generated by the central agents (128) to initiate task execution. The cluster prompts (140) include plarming directives, execution parameters, success criteria, and metadata derived from the application prompts (105). The cluster prompts (140) are formatted using standardized schemas and transmitted to the specialized agent clusters (155).

[0033] The cluster responses (142) are structured outputs generated by the specialized agent clusters (155) in response to the cluster prompts (140). One of the cluster responses (142) may correspond to one of the cluster prompts (140).PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902The cluster responses (142) include aggregated results, execution metadata, and policy compliance indicators. The cluster responses (142) are transmitted to the central agents (128) and used to generate the application responses (108).

[0034] The specialized agent clusters (155) are modular computational groupings that process the cluster prompts (140) to generate the cluster responses (142) and process the domain responses (172) to generate the cluster responses (142). The specialized agent clusters (155) include the cluster agents (158), the cluster tool applications (165), and the domain agent lists (168). The specialized agent clusters (155) generate the cluster responses (142) based on the domain responses (172) and transmit the cluster responses (142) to the central agents (128).

[0035] The cluster agents (158) are computational components that execute the cluster instructions (160) within the specialized agent clusters (155). The cluster agents (158) generate the domain prompts (170), evaluate the domain responses (172), and produce the cluster responses (142). The cluster agents (158) maintain execution logs, internal state representations, actions taken, and diagnostic records for traceability.

[0036] The cluster instructions (160) are executable directives used by the cluster agents (158) for intra-cluster orchestration. The cluster instructions (160) include the cluster planning instructions (161) and the cluster verification instructions (162). The cluster instructions (160) define logic for prompt decomposition, agent selection, response evaluation, and cluster tool use.

[0037] The cluster planning instructions (161) are a subset of the cluster instructions(160) used to construct task-specific workflows. The cluster planning instructions(161) generate the domain prompts (170) using domain prompt templates and domain routines executed by the foundational models (192). The cluster planningPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 instructions (161) reference metadata from the domain agent lists (168) and include logic for task decomposition and coordination.

[0038] The cluster verification instructions (162) are a subset of the cluster instructions (160) used to evaluate the domain responses (172). The cluster verification instructions (162) include probabilistic routines and domain benchmark data plus prompt templates executed by the foundational models (192). The cluster verification instructions (162) include logic for re-evaluation workflows, anomaly detection, and compliance assessment.

[0039] The cluster tool applications (165) are software interfaces used by the cluster agents (158) for domain-specific computations. The cluster tool applications (165) include connectors to simulation engines, analytics services, charting libraries, and proprietary platforms. The cluster tool applications (165) are monitored for performance and return structured results to the cluster agents (158).

[0040] The domain agent lists (168) are structured data constructs describing or identifying the available domain agents (175) within each specialized agent cluster (155). The domain agent lists (168) may include metadata for agent capabilities, tool capabilities, access rights, and tool integrations. The domain agent lists (168) are referenced during execution of the cluster planning instructions ( 161 ) for agent selection and task allocation.

[0041] The domain prompts (170) are structured data constructs generated by the cluster agents (158) for input to the domain agents (175). The domain prompts (170) include domain task-specific directives, metadata, and modality descriptors derived from the cluster prompts (140). The domain prompts (170) are formatted using standardized schemas and transmitted to the domain agents (175).

[0042] The domain responses (172) are structured outputs generated by the domain agents (175) in response to the domain prompts (170). The domain responses (172)PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 include analytical results, visualizations, and metadata for confidence and provenance. The domain responses (172) may be evaluated for completeness, correctness and compliance before aggregation into the cluster responses (142).

[0043] The domain agents (175) are computational entities that execute the domain instructions (178) in response to the domain prompts (170). The domain agents (175) perform domain-specific reasoning, simulation, and optimization using a domain foundational model of the foundational models (192). The domain agents (175) access the domain tool applications (185) and the data stores (182) to generate the domain responses (172).

[0044] The domain execution instructions (178) are directives used by the domain agents (175) to perform task-specific operations. The domain execution instructions (178) include routines and logic executed by a domain foundational model of the foundational models (192) for simulation and analysis. The domain execution instructions (178) define invocation sequences for the domain tool applications (185), access protocols for the data stores (182), and conditional logic for execution.

[0045] The domain verification instructions (180) are directives used by the domain agents (175) to evaluate the domain responses (172). The domain verification instructions (180) include probabilistic routines, domain benchmark data related to the respective task and rule-based logic executed by the foundational models (192). The domain verification instructions (180) assess correctness, completeness, and compliance with system-wide criteria.

[0046] The data stores (182) are repositories used to persist structured and unstructured data accessed or generated during execution. The data stores (182) include operational datasets, benchmarking records, vector databases with embeddings and simulation outputs. The data stores (182) are queried by thePATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 foundational models (192) and updated with new data generated by the domain agents (175).

[0047] The data stores (182) may include energy data that includes reservoir models, drilling logs, production volumes, and financial forecasts, well reports, contracts, work orders. The energy data is generated by proprietary platforms, sensors, and simulation engines across the oil and gas lifecycle. The energy data is used by the domain agents (175) for optimization, forecasting, anomaly detection, visualization and compliance assessment.

[0048] The domain tool applications (185) are software modules that execute specialized computational tasks within the system (100). The domain tool applications (185) include simulation engines, predictive models, and visualization components. The domain tool applications (185) generate outputs stored in the data stores (182) and used by the domain agents (175). The domain tool applications (185) may provide interfaces for a seismic interpretation platform, a drilling optimization platform, a reservoir simulation tool, a production analytics system, etc.

[0049] The foundational models (192) are machine learning systems that performs reasoning, inference, and task execution. The foundational models (192) may each include transformer-based architectures (e.g., a large language model (LLM)) and operates across distributed computing environments. The foundational models (192) processes the prompts of the system (100) to generate the responses of the system (100). The foundational models (192) interact with domain agents (175), domain tool applications (185), and other system components as coordinated by the specialized agent clusters (155), which are coordinated by the central coordination modules (125). The foundational models (192) may include domain specific models like a seismic foundational model, a well log foundational model and a time series foundational model for operational data.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0050] FIG. 2 shows a flowchart of a method for an autonomous hierarchical multiagent system. The method of FIG. 2 may be implemented using the systems described in the other figures, and one or more of the steps may be performed on, or received at, one or more computer processors. The system may include at least one processor and an application that, when executing on the at least one processor, performs the method. A non-transitory computer readable medium may include instructions that, when executed by one or more processors, perform the method. The outputs from various components (including models, functions, procedures, programs, processors, etc.) for performing the method may be generated by applying a transformation to inputs using the components to create the outputs without using mental processes or human activities.

[0051] Turning to FIG. 2, the method (200) application responses are generated responsive to application prompts using a hierarchy of agents, which may include a central agent, a cluster agent, and a domain agent. The process (200) may include multiple steps (e.g., Block 202 through Block 218) that may execute on the components described in the other figures, including those of FIG. 1 and FIG. 9.

[0052] Block 202 involves receiving an application prompt from an application. Receiving the application prompt initiates a processing sequence within the hierarchical multi-agent management system, which may include establishing a communication channel, detecting an incoming application prompt, capturing the pay load of the application prompt, validating the format of the application prompt, and triggering central agent execution. The application prompt may originate from a user-facing interface, an automated process, or an external service. Upon arrival, the application prompt is handled through a series of discrete operations for the system to interpret and respond to the application prompt. Each operation contributes to the reliable intake and preparation of the application prompt for downstream agent coordination and task execution. The following paragraphsPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 describe the individual operations performed during the receipt of the application prompt.

[0053] Establishing a communication channel involves opening or maintaining a network-accessible interface capable of accepting incoming data from external applications. The interface may include a RESTful API endpoint, a WebSocket listener, a message queue subscriber, or another protocol-compliant mechanism. Initialization of the interface may occur during system startup or dynamically in response to application registration events. The interface may be bound to a specific port, address, or namespace associated with the application domain. Security protocols such as TLS enciyption, token-based authentication, or mutual certificate validation may be applied to the channel.

[0054] Detecting an incoming application prompt involves monitoring the communication channel for new data transmissions. A listener or polling mechanism may continuously inspect the channel for activity matching predefined patterns or headers. Upon identification of a transmission, the system may invoke a handler routine to begin processing the incoming data. Detection may include verification of source identity, inspection of content type, and preliminary filtering based on routing metadata. The detection mechanism may operate asynchronously to support high-throughput environments.

[0055] Capturing the payload of the application prompt involves retrieving the full content of the transmission from the application. The payload may include a query string, structured data, modality descriptors, timestamps, session identifiers, and other contextual metadata. Extraction of the payload may be performed using a parser or deserializer compatible with the format used by the application. The captured data may be temporarily stored in a buffer or passed directly to the next processing module. Payload capture may include error handling routines to address incomplete or malformed transmissions.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0056] Validating the format of the application prompt involves inspecting the structure and syntax of the captured payload. Validation may be performed using schema definitions such as JSON Schema, XML Schema, or protocol buffer descriptors. Each field within the payload may be checked for presence, type conformity, and value constraints. Validation may also include cross-field consistency checks and domain-specific rale enforcement. Failure to validate may trigger rejection of the application prompt or invocation of a remediation workflow.

[0057] Triggering central agent execution involves initiating the primary coordination module responsible for managing processing of the application prompt. The coordination module may be instantiated as a persistent service or dynamically spawned in response to the arrival of the application prompt. Activation may include loading the context of the application prompt, initializing planning routines, and preparing routing logic. The central agent may access internal registries, configuration files, or learned models to guide execution. Execution may proceed in parallel with other application prompts or be queued based on priority indicators.

[0058] The method (200) may involve presenting the application prompt prior to the application response being generated. Presenting the application prompt may include identifying a presentation context, extracting displayable content from the application prompt, formatting the application prompt for presentation, applying presentation rales and styling, transmitting the formatted prompt to a presentation layer, and rendering the application prompt in a presentation interface. The application prompt may be presented to a user, an operator, or an automated observer through a graphical interface, a logging dashboard, a monitoring tool, etc. Presentation of the application prompt may occur before a correspondingPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 application response is generated by the hierarchical multi-agent management system.

[0059] Identifying a presentation context involves determining the environment in which the application prompt will be displayed. The environment may include a graphical user interface, a command-line dashboard, a remote monitoring console, a visualization layer embedded in an external system, etc. Selection of the presentation context may be based on application domain, user role, operational mode, or interface specification. The presentation context may be registered during system initialization or dynamically selected based on routing metadata associated with the application prompt. Multiple presentation contexts may be supported simultaneously to accommodate distributed or multi-modal deployments.

[0060] Extracting displayable content from the application prompt involves parsing the application prompt to isolate elements suitable for visualization. The elements may include query text, modality descriptors, timestamps, session identifiers, priority indicators, and domain-specific annotations. Parsing may be performed using a schema-aware deserializer or a rule-based content extractor. The extracted content may be filtered to exclude non- visual data such as binary payloads, internal routing codes, or encrypted fields. Extraction may also include normalization of values to support consistent rendering across heterogeneous interfaces.

[0061] Formatting the application prompt for presentation involves converting the extracted content into a structure compatible with the target visualization layer identified by the presentation context. The structure may include HTML templates, JSON objects, XML documents, proprietary UI component schemas, etc. Formatting may include insertion of labels, grouping of related fields, and transformation of raw values into human-readable formats. The formatted prompt may be encapsulated in a container object that supports transmission andPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 rendering. Formatting may be guided by interface specifications, user preferences, or domain- specific display rales.

[0062] Applying presentation rales and styling involves enhancing the formatted prompt with visual attributes and layout instructions. Styling may include font selection, color coding, spacing, alignment, and iconography. Presentation rales may define conditional visibility, emphasis indicators, or contextual annotations based on prompt content. Styling may be applied using CSS stylesheets, UI framework directives, or embedded rendering instructions. Presentation rales may be defined in configuration files or dynamically generated based on operational context.

[0063] Transmitting the formatted prompt to a presentation layer involves sending the structured and styled content to the designated visualization interface. The transmission process may include serialization of the formatted prompt, packaging into a transport envelope, and dispatch to a registered endpoint. Error handling routines may be invoked to address transmission failures, retries, or delivery confirmations. Transmission may be logged for diagnostic and auditing purposes.

[0064] Rendering the application prompt in a presentation interface involves displaying the transmitted content within the selected visualization environment. Rendering may be performed by a browser engine, a native UI framework, a remote dashboard, or a custom visualization module. The rendered prompt may appear as a dialog box, a panel, a table row, or another interface element. Rendering may include interactive features such as tooltips, expandable sections, or clickable links. The rendered prompt may remain visible until a response is generated or a user interaction occurs.

[0065] Block 205 involves executing central instructions of a central agent, corresponding to the application, with a foundational model to process thePATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 application prompt, select a specialized agent cluster from a cluster list, and generate a cluster prompt for the specialized agent cluster. Execution of central instructions may include loading central instructions to generate a central agent prompt, initializing the foundational model, transmitting the central agent prompt to the foundational model, receiving a central agent response from the foundational model, parsing the central agent response to select and initialize specialized agent clusters, generating or extracting cluster prompts for the selected specialized agent clusters, along with plan and a sequence of execution for agent clusters and packaging the cluster prompts for transmission to the selected specialized agent clusters. The central agent prompt may include the application prompt, the cluster agent list, central planning instructions, and may include central verification instructions. The foundational model may interpret the central agent prompt and produce a central agent response that includes a workflow plan and cluster-specific directives, and order of execution which can be serial, parallel, and may also be nested.

[0066] Loading the central instructions to generate a central agent prompt involves retrieving a set of planning directives (the central agent instructions and rules) associated with the domain of the application. The central agent prompt may be assembled by combining the application prompt, the cluster agent list, the central planning instructions, and optionally central verification instructions. The central agent prompt may be structured using a format compatible with the foundational model input specification, such as structured text, a tokenized sequence, a structured object, a serialized document, seismic image, well log, oil production time series, etc. The central agent prompt may be constructed dynamically based on application metadata, operational context of the application and the application prompt, routing parameters, etc.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0067] Initializing the foundational model involves activating a model instance to interpret the central agent prompt and executing embedded instructions. Initialization may include loading pretrained weights, allocating memory resources, setting execution parameters, and preparing runtime environments. The foundational model may be selected based on domain compatibility, performance characteristics, operational mode, cost allocation, etc. Initialization may also include registration of model capabilities with an orchestration layer.

[0068] Executing the central instructions by transmitting the central agent prompt to the foundational model involves delivering a structured prompt (e.g., the central agent prompt) to an interface of the foundational model. Transmission may occur through an internal API, a model invocation service, a direct function call, etc. The foundational model may process the central agent prompt using semantic parsing, contextual reasoning, and planning logic derived from the embedded instructions within the central agent prompt. Execution may be performed synchronously or asynchronously.

[0069] Receiving a central agent response from the foundational model responsive to the central agent prompt and including a workflow plan involves capturing the output generated by the foundational model. The central agent response may include a workflow plan, selected agent cluster identifiers, task decomposition, verification outcomes, routing directives, order of execution, etc. Routing directives are structured instructions in the central agent response specifying the direction of cluster prompts to selected specialized agent clusters and may include cluster identifiers, transmission endpoints, execution priorities, modality constraints, timing parameters, etc. The central agent response may be structured as a hierarchical object, a sequence of tokens, a set of serialized instructions, etc.

[0070] Parsing the central agent response to select and initialize the selected specialized agent clusters involves analyzing the workflow plan to identify agentPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 clusters suitable for task execution. Selection may be based on domain expertise, modality compatibility, operational status, priority indicators, domain classifiers, etc., determined by the foundational model from information within the central agent prompt. Initialization of the selected agent clusters may include activation of corresponding modules, loading of domain-specific configurations, and preparation of execution environments. Cluster selection may be guided by routing logic embedded in the central agent response.

[0071] Parsing the central agent response to generate or extract cluster prompts for the selected specialized agent clusters involves identifying task-specific instructions within the central agent response. Each cluster prompt may be constructed by extracting relevant content, contextual metadata, and operational directives from the central agent response. Cluster prompts may be formatted according to the input specification of the corresponding agent cluster. Generation may include transformation of instructions into executable task descriptions.

[0072] Packaging the cluster prompts for transmission to the specialized agent clusters identified in the workflow plan of the central agent response involves formatting and encapsulating each prompt. Packaging may include serialization, insertion of routing metadata, assignment of execution flags, construction of transport envelopes, etc. Each packaged prompt may be prepared for delivery through an internal messaging protocol, a remote invocation interface, a distributed task queue, etc., for delivery to a specialized agent cluster.

[0073] The method (200) may involve accessing the cluster list after being dynamically updated to identify the specialized agent cluster, in which the cluster list includes cluster metadata describing cluster scope, associated domain areas, and coordination protocols for agent selection and task planning. Accessing the cluster list is performed by the hierarchical multi-agent management system to determine which specialized agent cluster is appropriate for handling the receivedPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 application prompt. The cluster list may be stored in a distributed registry, a centralized database, or a memory structure associated with the central coordination module. Each entry in the cluster list may include identifiers, domain descriptors, operational capabilities, and routing protocols. Operations performed during the processes of accessing and interpreting the cluster list include receiving a request to identity a specialized agent cluster, retrieving the cluster list, parsing cluster metadata, filtering clusters, ranking candidate clusters, selecting the specialized agent cluster, and recording the selection. The cluster list is updated by registering new clusters and agents as and the new clusters and agents become available, which increases the system capabilities.

[0074] Receiving a request to identify a specialized agent cluster involves detecting a signal or instruction from the central coordination module indicating that prompt routing is to be performed. The request may be generated after parsing the application prompt and determining that specialized processing is to be performed. Detection of the request may occur through an internal event listener, a message queue, or a function call within the orchestration logic. The request may include contextual data such as prompt type, domain indicators, and priority level.

[0075] Retrieving the cluster list involves accessing a data structure that contains metadata for the available specialized agent clusters. The data structure may reside in a local cache, a distributed key-value store, a cloud-based registry, etc. Access may be performed using a query interface, a lookup function, a subscription to a dynamic update stream, etc. Retrieval may include filtering based on domain relevance, operational status, version compatibility, etc.

[0076] Parsing cluster metadata involves reading and interpreting the descriptive fields associated with each cluster entry, which may be written in natural language. Fields may include cluster scope, supported modalities, domain areas, agent types, and coordination protocols. Parsing may be performed using a schema-awarePATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 parser that validates field types and extracts values for downstream use. Interpretation of metadata may include mapping domain descriptors to internal taxonomies or ontologies.

[0077] Filtering clusters may be based on domain relevance and involve comparing the domain indicators extracted from the application prompt with the domain descriptors in the cluster metadata. The foundational model may perform the comparison by applying string matching, semantic similarity scoring, or embedding-based classification to the domain indicators and cluster descriptors. Clusters that do not match the domain context of the prompt may be excluded from further consideration. Filtering may also consider operational constraints such as availability, latency, or resource allocation by referencing system state variables and runtime metrics.

[0078] Ranking candidate clusters involves assigning scores to each remaining cluster based on relevance, performance histoiy, and coordination efficiency. The foundational model may compute scoring using weighted heuristics, learned models, or rule-based logic applied to the semantic representation of the prompt and the metadata of each cluster. Ranking may include consideration of prompt complexity, agent specialization, and historical success rates derived from prior interactions, customer feedback, and logged outcomes. The highest-ranked cluster may be selected for prompt routing based on the final score aggregation.

[0079] A group of clusters may also be selected with execution happening in parallel, serially, and nested. For example, in the execution workflow below, a first sequence includes cluster 1, cluster2, and a second sequence. Cluster 1, cluster2, and the second sequence execute sequentially, e.g., cluster 1 executes, then cluster2 executes, then the second sequence executes. The second sequence is nested within the first sequence and includes clusters and cluster 4. Clusters and cluster4 execute in parallel.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 cluster 1 -production, cluster2-drilling,clusters -subsurface, cluster4-well-log}}

[0080] Selecting the specialized agent cluster involves choosing the top-ranked cluster from the filtered and ranked list. The foundational model may invoke a routing function that returns the cluster identifier and associated coordination protocol based on the ranking output. The selected cluster may be marked for activation and prompt delivery using internal signaling mechanisms and task dispatch routines. Selection may trigger initialization routines within the cluster to prepare for task execution, including agent loading, context synchronization, and resource allocation.

[0081] Recording the selection involves storing the identifier and metadata of the selected cluster in the session context. Storage may occur in a session-specific memory buffer, a transaction log, or a coordination ledger. Recorded data may include timestamp, cluster identifier, domain mapping, and routing rationale. Recording may support traceability, auditing, and multi-tum interaction continuity.

[0082] The method (200) may involve executing a central planning instruction by the central agent to generate a multi-step workflow plan including sequential or parallel cluster prompts based on the application prompt. Execution of the central planning instruction initiates a structured process in which the foundational modelPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 interprets the application prompt, identifies relevant tasks, and constructs a workflow plan that specifies how specialized agent clusters are to be engaged. The workflow plan may include task-specific cluster prompts, execution logic, contingency instructions, and metadata for coordination and traceability. Operations performed during the generation of the workflow plan include interpreting the application prompt, identifying distinct tasks, analyzing task relationships, assigning tasks to specialized agent clusters, generating cluster prompts, defining execution logic, embedding contingency instructions, assembling the workflow plan, and recording workflow plan metadata.

[0083] Interpreting the application prompt involves extracting semantic meaning, operational intent, and domain context using the foundational model. The foundational model may tokenize the application prompt, apply contextual embeddings, and reference domain-specific ontologies to determine the nature and scope of the requested operation. Interpretation may include identifying modality indicators, priority levels, and coordination constraints relevant to downstream planning.

[0084] Identifying distinct tasks involves segmenting the application prompt into multiple discrete operations using a decomposition algorithm. Each task may correspond to a domain-specifrc inquiry, a modality-specific operation, or a procedural instruction utilizing specialized handling. Segmentation may be performed using syntactic parsing, semantic clustering, or transformer-based attention mechanisms. The output of the segmentation process may be a structured list of tasks annotated with domain and modality descriptors.

[0085] Analyzing task relationships involves evaluating logical, temporal, and data dependencies among the identified tasks. Dependency analysis may be performed using graph-based models, rule-based logic, or learned dependency structures. Tasks may be grouped into sequential chains or parallel execution blocks based onPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 inter-task constraints and coordination specifications. Synchronization points may be identified to manage data flow and execution timing across tasks.

[0086] Assigning tasks to specialized agent clusters involves matching each task to one or more clusters using domain relevance, operational scope, and coordination protocol compatibility. The foundational model may perform the matching using embedding similarity, domain classification, and metadata alignment. Assignment may include referencing the cluster list, evaluating modality support, and selecting clusters with appropriate agent capabilities. Multiple clusters may be assigned to a single task if redundancy or multi-modal processing is to be performed.

[0087] Generating cluster prompts for each task involves constructing individual cluster prompts that encapsulate task-specific instructions, contextual metadata, and routing information. Cluster prompt generation may be performed using template-based construction, dynamic prompt synthesis, or model-driven generation routines. Each cluster prompt may include identifiers, domain tags, modality descriptors, and coordination parameters. Cluster prompts may be serialized for transmission to the assigned clusters.

[0088] Defining execution logic involves specifying the order and structure of cluster prompt execution. Execution logic may include sequential chains, parallel execution groups, and synchronization points for coordination. The foundational model may generate execution logic using planning algorithms, dependency graphs, or learned scheduling models. Execution parameters may include timing constraints, resource allocation policies, and inter-cluster communication protocols.

[0089] Embedding contingency instructions involves incorporating fallback logic into the workflow plan to address failure conditions, timeouts, or unexpected outputs. Contingency logic may specify alternate clusters, retry strategies,PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 escalation paths, or termination conditions. Instructions may be generated using rule-based systems, historical failure data, or predictive models. Contingency metadata may be embedded within cluster prompts or stored in the workflow plan header.

[0090] Assembling the workflow plan involves packaging the cluster prompts, execution logic, contingency instructions, and metadata into a structured workflow object. The workflow object may be represented as a graph, a serialized document, or a modular execution script. Assembly may include indexing, validation, and formatting operations to prepare the plan for execution. The assembled plan may be stored in memory, transmitted to an execution engine, or logged for auditing.

[0091] Recording workflow plan metadata involves storing identifiers, timestamps, domain mappings, planning rationale, and execution parameters in the session context. Metadata may be written to a session-specific buffer, a coordination ledger, or a transaction log. Recorded data may support traceability, auditing, multi-tum interaction continuity, and iterative refinement. Metadata may also be used for performance analysis, error tracking, and future planning optimization.

[0092] Block 208 involves executing cluster instructions of a cluster agent, corresponding to a specialized agent cluster, with the foundational model to process the cluster prompt, select a domain agent from a domain agent list, and generate a domain prompt for the domain agent. Execution of cluster instructions may include loading cluster instructions to generate a cluster agent prompt, initializing the foundational model, transmitting the cluster agent prompt to the foundational model, receiving a cluster agent response from the foundational model, parsing the cluster agent response to select and initialize domain agents, generating or extracting domain prompts for the selected domain agents, and packaging the domain prompts for transmission to the selected domain agents. The cluster agent prompt may include the cluster prompt, the domain agent list, clusterPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 planning instructions, and may include cluster verification instructions. The foundational model may interpret the cluster agent prompt and produce a cluster agent response that includes a task-specific workflow and domain-specific directives.

[0093] Loading the cluster instructions to generate a cluster agent prompt involves retrieving a set of planning directives (the cluster agent instructions) associated with the domain of the specialized agent cluster. The cluster agent prompt may be assembled by combining the cluster prompt, the domain agent list, the cluster planning instructions, and optionally cluster verification instructions. The cluster agent prompt may be structured using a format compatible with the foundational model input specification, such as structured text, a tokenized sequence, a structured object, a serialized document, etc. The cluster agent prompt may be constructed dynamically based on cluster metadata, operational context of the cluster prompt, routing parameters, etc.

[0094] Initializing the foundational model involves activating a model instance to interpret the cluster agent prompt and execute embedded instructions. Initialization may include loading pretrained weights, allocating memory resources, setting execution parameters, and preparing runtime environments. The foundational model may be selected based on domain compatibility, performance characteristics, operational mode, results on benchmark data, etc. Initialization may also include registration of model capabilities with an orchestration layer.

[0095] Executing the cluster instructions by transmitting the cluster agent prompt to the foundational model involves delivering a structured prompt (e.g., the cluster agent prompt) to an interface of the foundational model. Transmission may occur through an internal API, a model invocation service, a direct function call, etc. The foundational model may process the cluster agent prompt using semantic parsing, contextual reasoning, and planning logic derived from the embedded instructionsPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 within the cluster agent prompt. Execution may be performed synchronously or asynchronously.

[0096] Receiving a cluster agent response from the foundational model responsive to the cluster agent prompt and including a task-specific workflow involves capturing the output generated by the foundational model. The cluster agent response may include a workflow plan, selected domain agent identifiers, task segmentation, verification outcomes, routing directives, etc. Routing directives are structured instructions in the cluster agent response specifying the direction of domain prompts to selected domain agents and may include agent identifiers, transmission endpoints, execution priorities, modality constraints, timing parameters, etc. The cluster agent response may be structured as a hierarchical object, a sequence of tokens, a set of serialized instructions, etc.

[0097] Parsing the cluster agent response to select and initialize the selected domain agents involves analyzing the workflow plan to identify domain agents suitable for task execution. Selection may be based on domain expertise, modality compatibility, operational status, priority indicators, past performance of agents to similar prompts, etc., determined by the foundational model from information within the cluster agent prompt. Initialization of the selected domain agents may include activation of corresponding modules, loading of domain-specific configurations, and preparation of execution environments. Agent selection may be guided by routing logic embedded in the cluster agent response.

[0098] Parsing the cluster agent response to generate or extract domain prompts for the selected domain agents involves identifying task-specific instructions within the cluster agent response. Each domain prompt may be constructed by extracting relevant content, contextual metadata, and operational directives from the cluster agent response. Domain prompts may be formatted according to the inputPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 specification of the corresponding domain agent. Generation may include transformation of instructions into executable task descriptions.

[0099] Packaging the domain prompts for transmission to the domain agents identified in the workflow plan of the cluster agent response involves formatting and encapsulating each prompt. Packaging may include serialization, insertion of routing metadata, assignment of execution flags, construction of transport envelopes, etc. Each packaged prompt may be prepared for delivery through an internal messaging protocol, a remote invocation interface, a distributed task queue, etc., for delivery to a domain agent.

[0100] The method (200) may involve accessing the domain agent list after being dynamically updated to identify the domain agent, in which the domain agent list includes domain agent metadata describing agent capabilities, access rights, tool integrations, and tool capabilities, along with input output formats and examples. Accessing the domain agent list is performed by the hierarchical multi-agent management system to determine which domain agent is appropriate for handling the received application prompt. The domain agent list may be stored in a distributed registry, a centralized database, or a memory structure associated with the central coordination module. Each entry in the domain agent list may include identifiers, capability descriptors, access control parameters, and tool integration profiles. Operations performed during the processes of accessing and interpreting the domain agent list include receiving a request to identify a domain agent, retrieving the domain agent list, parsing domain agent metadata, filtering domain agents, ranking candidate domain agents, selecting the domain agent or list of agents, and recording the selection.

[0101] Receiving a request to identify a domain agent involves detecting a signal or instruction from the central coordination module indicating that prompt routing is to be performed. The request may be generated after parsing the applicationPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 prompt and determining that domain-specific processing is to be performed. Detection of the request may occur through an internal event listener, a message queue, or a function call within the orchestration logic. The request may include contextual data such as prompt type, domain indicators, and priority level.

[0102] Retrieving the domain agent list involves accessing a data structure that contains metadata for the available domain agents. The data structure may reside in a local cache, a distributed key-value store, a cloud-based registry, etc. Access may be performed using a query interface, a lookup function, a subscription to a dynamic update stream, etc. Retrieval may include filtering based on domain relevance, operational status, access control parameters, etc.

[0103] Parsing domain agent metadata involves reading and interpreting the descriptive fields associated with each domain agent entry, which may be written in natural language. Fields may include agent capabilities, supported modalities, domain areas, access rights, and tool integrations. Parsing may be performed using a schema-aware parser that validates field types and extracts values for downstream use. Interpretation of metadata may include mapping capability descriptors to internal taxonomies or ontologies.

[0104] Filtering domain agents may be based on domain relevance and involve comparing the domain indicators extracted from the application prompt with the domain descriptors in the domain agent metadata. The foundational model may perform the comparison by applying string matching, semantic similarity scoring, or embedding -based classification to the domain indicators and agent descriptors. Domain agents that do not match the domain context of the prompt may be excluded from further consideration. Filtering may also consider operational constraints such as availability, latency, access rights, or tool compatibility by referencing system state variables and runtime metrics.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0105] Ranking candidate domain agents involves assigning scores to each remaining domain agent based on relevance, performance history, and integration efficiency. The foundational model may compute scoring using weighted heuristics, learned models, or rule-based logic applied to the semantic representation of the prompt and the metadata of each domain agent. Ranking may include consideration of prompt complexity, agent specialization, and historical success rates derived from prior interactions and logged outcomes. The highest- ranked domain agent may be selected for prompt routing based on the final score aggregation.

[0106] Selecting the domain agent involves choosing the top-ranked domain agent from the filtered and ranked list. The foundational model may invoke a routing function that returns the agent identifier and associated integration protocol based on the ranking output. The selected domain agent may be marked for activation and prompt delivery using internal signaling mechanisms and task dispatch routines. Selection may trigger initialization routines within the domain agent to prepare for task execution, including context synchronization, tool binding, and resource allocation.

[0107] Recording the selection involves storing the identifier and metadata of the selected domain agent in the session context. Storage may occur in a sessionspecific memory buffer, a transaction log, or a coordination ledger. Recorded data may include timestamp, agent identifier, domain mapping, and routing rationale. Recording may support traceability, auditing, and multi-tum interaction continuity.

[0108] The method (200) may involve executing a cluster planning instruction by the cluster agent to decompose the cluster prompt into a set of tasks, in which each task of the set of tasks is assigned to a corresponding domain agent. Execution of the cluster planning instruction initiates a structured process in which thePATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 foundational model interprets the cluster prompt, identifies relevant tasks, and constructs a task assignment plan that specifies how domain agents are to be engaged. The task assignment plan may include domain-specific task definitions, execution logic, contingency instructions, and metadata for coordination and traceability. Operations performed during the decomposition and assignment process include interpreting the cluster prompt, identifying distinct tasks, analyzing task relationships, assigning tasks to domain agents, generating domain agent instructions, defining execution logic, embedding contingency instructions, assembling the task assignment plan, and recording task plan metadata.

[0109] Interpreting the cluster prompt involves extracting semantic meaning, operational intent, and domain context using the foundational model. The foundational model may tokenize the cluster prompt, apply contextual embeddings, and reference domain-specific ontologies to deteimine the nature and scope of the requested operations. Interpretation may include identifying modality indicators, priority levels, and coordination constraints relevant to downstream task decomposition.

[0110] Identifying distinct tasks involves segmenting the cluster prompt into multiple discrete operations using a decomposition algorithm. Each task may correspond to a domain-specific inquiiy, a modality-specific operation, or a procedural instruction utilizing specialized handling. Segmentation may be performed using syntactic parsing, semantic clustering, or transformer-based attention mechanisms. The output of the segmentation process may be a structured list of tasks annotated with domain and modality descriptors.

[0111] Analyzing task relationships involves evaluating logical, temporal, and data dependencies among the identified tasks. Dependency analysis may be performed using graph-based models, rule-based logic, or learned dependency structures. Tasks may be grouped into sequential chains or parallel execution blocks based onPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 inter-task constraints and coordination requirements. Synchronization points may be identified to manage data flow and execution timing across tasks.

[0112] Assigning tasks to domain agents involves matching each task to one or more domain agents using domain relevance, agent capabilities, integration compatibility, and tool capability. The foundational model may perform the matching using embedding similarity, domain classification, and metadata alignment. Assignment may include referencing the domain agent list, evaluating access rights, and selecting agents with appropriate tool integrations and capabilities. Multiple domain agents may be assigned to a single task if redundancy or multi-modal processing is to be performed.

[0113] Generating domain agent instructions for each task involves constructing individual instructions that encapsulate task-specific directives, contextual metadata, and routing information. Instruction generation may be performed using template-based construction, dynamic synthesis, or model-driven generation routines. Each instruction may include agent identifiers, domain tags, modality descriptors, and coordination parameters. Instructions may be serialized for transmission to the assigned domain agents.

[0114] Defining execution logic involves specifying the order and structure of domain agent instruction execution. Execution logic may include sequential chains, parallel execution groups, and synchronization points for coordination. The foundational model may generate execution logic using plarming algorithms, dependency graphs, or learned scheduling models. Execution parameters may include timing constraints, resource allocation policies, and inter-agent communication protocols, such as agent to agent protocol.

[0115] Embedding contingency instructions involves incorporating fallback logic into the task assignment plan to address failure conditions, timeouts, or unexpectedPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 outputs. Contingency logic may specify alternate agents, retry strategies, escalation paths, or termination conditions. Instructions may be generated using rule-based systems, historical failure data, or predictive models. Contingency metadata may be embedded within domain agent instructions or stored in the task assignment plan header.

[0116] Assembling the task assignment plan involves packaging the domain agent instructions, execution logic, contingency instructions, and metadata into a structured task plan object. The task plan object may be represented as a graph, a serialized document, or a modular execution script. Assembly may include indexing, validation, and formatting operations to prepare the plan for execution. The assembled plan may be stored in memory, transmitted to an execution engine, or logged for auditing.

[0117] Recording task plan metadata involves storing identifiers, timestamps, domain mappings, planning rationale, and execution parameters in the session context. Metadata may be written to a session-specific buffer, a coordination ledger, or a transaction log. Recorded data may support traceability, auditing, multi-tum interaction continuity, and iterative refinement. Metadata may also be used for performance analysis, error tracking, and future planning optimization.

[0118] Block 210 involves executing domain instructions of the domain agent, with the foundational model, based on the domain prompt to perform one or more of accessing a data store and invoking a domain tool application to generate a domain response. Execution of domain instructions initiates a structured process in which the foundational model interprets the domain prompt, deteimines the operational scope, and performs task-specific operations using domain tools and data resources. The domain response may include retrieved data, computed results, transformed content, tool-generated outputs, etc. Operations performed during the execution of domain instructions include interpreting the domain prompt, selectingPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 a tool or data source, preparing invocation parameters, invoking the domain tool application, accessing the data store, processing the output, recording the domain response, etc.

[0119] Interpreting the domain prompt involves extracting operational intent, modality indicators, domain-specific parameters, etc., using the foundational model. The foundational model may tokenize the domain prompt, apply semantic embeddings, reference domain ontologies, etc., to identify the requested operation. Interpretation may include identifying tool invocation patterns, data retrieval instructions, transformation directives, etc. The output of the interpretation process may be a structured representation of the task to be executed.

[0120] Selecting a tool or data source involves identifying the appropriate domain resource based on the interpreted domain prompt. Selection may be performed by matching the operational scope of the prompt to the capabilities, access rights, etc., described in the domain agent metadata. The foundational model may reference a registry of tool integrations, data endpoints, etc., to locate compatible resources. Selection may include evaluating availability, latency, authorization constraints, etc.

[0121] Preparing invocation parameters involves constructing the input arguments specified to execute the selected tool or query the selected data source. Parameter construction may be performed using template expansion, dynamic synthesis, rulebased formatting routines, etc. Each parameter may be derived from the domain prompt, session context, metadata associated with the domain agent, etc. Validation routines may be applied to confirm parameter completeness, correctness, type conformity, etc.

[0122] Invoking the domain tool application involves transmitting the prepared parameters to the selected tool interface using an execution protocol. InvocationPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 may be performed using API calls, function invocations, remote procedure executions, etc. The foundational model may manage invocation timing, error handling, response parsing, etc. Tool execution may produce structured outputs, logs, transformed data, etc., based on the tool type.

[0123] Accessing the data store involves querying a structured or unstructured data repository using the interpreted domain prompt and constructed parameters. Queiy execution may be performed using SQL, NoSQL, graph queries, natural language interfaces, etc. The foundational model may manage query formulation, endpoint selection, result parsing, etc. Retrieved data may be filtered, aggregated, transformed, etc., based on domain-specific logic.

[0124] Processing the output involves interpreting the results returned from the tool or data store and formatting the results into a coherent domain response. Processing may include normalization, summarization, enrichment, transformation operations, etc. The foundational model may apply post-processing routines to align the output with the expected response format. Processed results may be annotated with metadata for traceability, downstream use, etc.

[0125] Recording the domain response involves storing the final output in the session context along with relevant metadata. Storage may occur in a session buffer, transaction log, response registry, etc. Recorded data may include timestamps, tool identifiers, data source references, execution rationale, etc. Recording may support traceability, auditing, multi-tum interaction continuity, etc.

[0126] The method (200) may involve retrieving user feedback associated with prior domain responses to execute a probabilistic verification step when the user feedback indicates a threshold level of dissatisfaction. Retrieving user feedback initiates a collective process in which the foundational model evaluates historicalPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 interactions to determine whether a domain response is to be verified. The probabilistic verification step may be triggered when feedback medics such as negative ratings, flagged responses, low confidence scores, etc., exceed a predefined threshold. Operations performed during the process may include accessing user feedback records, evaluating dissatisfaction indicators, selecting candidate domain responses, generating verification queries, executing probabilistic checks, recording verification outcomes, etc.

[0127] Accessing user feedback records involves retrieving stored evaluations, comments, ratings, interaction logs, etc., associated with prior domain responses. Feedback records may be stored in a session history buffer, a feedback database, a user interaction ledger, etc. Retrieval may be performed using query filters based on domain agent identifiers, timestamps, prompt categories, etc. Feedback data may be parsed to extract structured indicators such as sentiment scores, explicit dissatisfaction flags, behavioral signals, etc.

[0128] Evaluating dissatisfaction indicators involves analyzing the retrieved feedback to determine whether the level of dissatisfaction meets or exceeds a predefined threshold. Threshold evaluation may be performed using statistical aggregation, rule-based scoring, learned dissatisfaction models, etc. Indicators may include negative sentiment, repeated correction attempts, low engagement metrics, explicit user complaints, etc. Evaluation may result in a binary or probabilistic decision regarding whether to perform verification.

[0129] Selecting candidate domain responses involves identifying specific responses that are associated with elevated dissatisfaction indicators. Selection may be performed by correlating feedback entries with domain response identifiers, session context, etc. The foundational model may prioritize responses based on recency, impact, relevance to ongoing tasks, etc. Selected responses mayPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 be annotated with metadata describing the nature and severity of the dissatisfaction.

[0130] Generating verification queries involves constructing prompts or instructions used by the foundational model to re-evaluate the correctness or completeness of the selected domain responses. Verification queries may be synthesized using template-based methods, semantic reformulation, contrastive prompting techniques, etc. Each query may include contextual information, original prompt content, response metadata, etc. Queries may be designed to elicit alternative interpretations, confirm factual accuracy, assess procedural validity, etc.

[0131] Executing probabilistic checks involves applying the foundational model to the verification queries to produce confidence scores, alternative responses, validation flags, etc. Probabilistic evaluation may be performed using ensemble methods, uncertainty modeling, comparative inference routines, etc. The output may include a likelihood estimate of correctness, a suggested revision, a recommendation for escalation, etc. Execution may be logged for traceability and used to inform future response generation strategies.

[0132] Recording verification outcomes involves storing the results of the probabilistic checks in the session context or feedback ledger. Stored data may include verification scores, revised responses, escalation decisions, rationale annotations, etc. Recording may support auditing, performance tracking, iterative refinement of domain agent behavior, etc. Verification outcomes may also be used to update domain agent metadata or adjust future task routing logic.

[0133] The method (200) may involve executing a domain verification instruction by the domain agent as part of a probabilistic verification step to validate the domain response using benchmarking data associated with the domain tool application. Execution of the domain verification instruction initiates a validationPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 process in which the domain agent evaluates the accuracy, reliability, and contextual alignment of the domain response. Benchmarking data may include historical outputs, reference datasets, performance metrics, tool-specific validation criteria, etc. Operations performed during the probabilistic verification process include retrieving benchmarking data, generating a verification model, applying the model to the domain response, computing a confidence score, and recording verification metadata.

[0134] Retrieving benchmarking data involves accessing a structured dataset associated with the domain tool application. The dataset may include annotated examples, validated outputs, performance logs, domain-specific reference values, etc. Access may be performed using a query interface, a lookup function, a subscription to a benchmarking repository, etc. Retrieval may include filtering based on domain context, tool version, response modality, etc.

[0135] Generating a verification model involves constructing a probabilistic framework for evaluating the domain response. The foundational model may generate the framework using statistical inference, machine learning algorithms, rule-based logic, etc. Model parameters may be derived from benchmarking data, domain ontologies, historical validation outcomes, etc. The verification model may include scoring functions, threshold definitions, error classification routines, etc.

[0136] Applying the verification model to the domain response involves executing the model against the response content. Evaluation may include semantic comparison, numerical analysis, structural alignment with reference outputs, etc. The foundational model may perform the evaluation using embedding similarity, probabilistic scoring, anomaly detection techniques, etc. The output of the evaluation may include a confidence score, error classification, validation status, etc.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0137] Computing a confidence score involves quantifying the reliability of the domain response based on the verification model output. Scoring may be performed using weighted aggregation of evaluation metrics, statistical normalization, threshold comparison, etc. The confidence score may be expressed as a probability value, a categorical label, a composite index, etc. The score may be used to determine whether the response is accepted, flagged for review, routed for escalation, etc.

[0138] Recording verification metadata involves storing the results of the probabilistic verification process in the session context. Metadata may include the confidence score, benchmarking references, model parameters, validation rationale, etc. Storage may occur in a session-specific buffer, a transaction log, a coordination ledger, etc. Recorded data may support traceability, auditing, performance analysis, iterative refinement of domain agent behavior, etc.

[0139] The method (200) may involve invoking one or more of a domain tool application and a domain application by the domain agent to interface with a software system including one or more of a seismic interpretation platform, a drilling optimization platform, a reservoir simulation tool, a production analytics system, etc. Invoking the domain tool application includes interpreting the domain prompt using a foundational model, identifying the appropriate tool integration based on domain agent metadata, preparing invocation parameters, executing the tool interface, etc. The domain agent may access a registry of tool integrations and select the appropriate software system based on domain relevance, operational scope, compatibility with the task described in the domain prompt, etc. The foundational model may generate structured invocation parameters using embedded logic and contextual information extracted from the domain prompt, etc. The invocation may be performed using an API call, a remote procedurePATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 execution, a command-line interface, etc., based on the integration protocol defined for the selected tool.

[0140] Interfacing with a seismic interpretation platform involves transmitting structured seismic data and analytical directives to the platform using a predefined integration protocol, etc. The domain agent may format the seismic data into a compatible schema, such as SEG-Y, JSON, etc., and include metadata such as survey location, acquisition parameters, interpretation objectives, etc. The platform may be accessed through a RESTful API, a plugin interface, a containerized microservice, etc., and may return processed outputs such as fault maps, horizon picks, attribute volumes, etc. The domain agent may parse the returned outputs and format the returned outputs into a domain response for further processing or presentation, etc.

[0141] Interfacing with a drilling optimization platform involves transmitting drilling parameters, trajectory constraints, performance objectives, etc., to the platform using a structured invocation. The domain agent may extract relevant data from the domain prompt, including bit type, mud properties, formation characteristics, target depth, etc. The invocation may include a serialized payload formatted according to the platform’s specification, such as XML, protocol buffers, etc. The platform may return optimized drilling plans, rate-of-penetration predictions, torque and drag simulations, etc., which are parsed and incorporated into the domain response.

[0142] Interfacing with a reservoir simulation tool involves transmitting reservoir models, production scenarios, boundary conditions, etc., to the simulation engine. The domain agent may construct a simulation input deck using parameters such as porosity, permeability, fluid properties, well configurations, etc. The simulation tool may be accessed through a batch execution interface, a cloud-based API, a containerized runtime environment, etc. The tool may return outputs such asPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 pressure maps, saturation profiles, production forecasts, etc., which are formatted and validated by the domain agent before inclusion in the domain response.

[0143] Interfacing with a production analytics system involves transmitting operational data, production metrics, diagnostic queries, etc., to the analytics engine. The domain agent may prepare a query payload including well identifiers, flow rates, equipment status, historical production data, etc. The analytics system may be accessed through a dashboard API, a data pipeline connector, a real-time streaming interface, etc. The system may return insights such as decline curve analysis, artificial lift performance, anomaly detection results, etc., which are parsed and structured into the domain response.

[0144] Block 212 involves processing the domain response using the cluster agent to generate a cluster response. Processing the domain response includes receiving the domain response from the domain agent, validating the domain response against cluster specifications, aggregating the domain response with other domain responses, formatting the aggregated content into a cluster response, recording the cluster response for transmission to the central coordination module, etc. Each identified operation contributes to the transformation of domain-level outputs into a structured, cluster-level result suitable for hierarchical orchestration.

[0145] Receiving the domain response involves detecting completion of domain agent execution and capturing the output transmitted from the domain agent. The cluster agent may monitor a message queue, an internal buffer, a remote endpoint, etc., for incoming domain responses. The received domain response may include structured data, metadata annotations, execution logs, diagnostic flags, etc. Reception may trigger a parsing routine to extract relevant content and prepare the domain response for validation.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0146] Validating the domain response against cluster specifications involves applying verification logic to assess completeness, consistency, alignment with the cluster prompt, etc. The cluster agent may execute cluster verification instructions using a foundational model to compare the domain response with expected output formats, operational constraints, coordination parameters, etc. Validation may include schema conformity checks, semantic consistency analysis, thresholdbased scoring using historical benchmarking data, checks against the laws of physics, etc. Responses that fail validation may be flagged for reprocessing, escalation, exclusion from aggregation, etc.

[0147] Aggregating the domain response with other domain responses involves combining multiple validated outputs into a unified representation. The cluster agent may apply a merging algorithm to align data structures, normalize values, resolve conflicts across domain responses, etc. Aggregation may include concatenation of textual content, averaging of numerical metrics, synthesis of visualizations, etc. The aggregated result may be structured as a composite object annotated with provenance metadata, execution timestamps, domain identifiers, etc.

[0148] Formatting the aggregated content into a cluster response involves transforming the unified representation into a foimat suitable for transmission to the central coordination module. The cluster agent may serialize the cluster response using a standardized schema such as JSON, XML, protocol buffers, etc. Formatting may include insertion of routing metadata, confidence scores, execution summaries, compliance indicators, etc. The formatted cluster response may be encapsulated in a transport envelope and queued for delivery to the central coordination module.

[0149] Recording the cluster response for transmission involves storing the finalized output in a session context, transaction log, coordination ledger, etc. The clusterPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 agent may annotate the cluster response with metadata including cluster identifiers, task mappings, verification outcomes, planning rationale, etc. Storage may support traceability, auditing, multi-tum interaction continuity, performance analysis, etc. The recorded cluster response may be referenced during subsequent orchestration steps or used to inform future planning decisions.

[0150] The method (200) may involve executing a cluster verification instruction by the cluster agent as part of a probabilistic verification step to determine whether the domain response satisfies a predefined objective associated with the specialized agent cluster. Executing the cluster verification instruction includes retrieving verification criteria from the cluster metadata, selecting domain responses for evaluation, generating verification prompts, applying the foundational model to assess alignment with the predefined objective, and recording the verification outcome. Each operation contributes to the probabilistic determination of whether the domain response meets the operational specification defined for the specialized agent cluster. The verification process may be triggered based on historical performance data, user feedback, stochastic sampling logic, etc., embedded in the cluster agent instructions.

[0151] Retrieving verification criteria from the cluster metadata involves accessing structured descriptors associated with the specialized agent cluster. The descriptors may include domain objectives, performance thresholds, modality constraints, physical constraints, coordination parameters, etc. The foundational model may parse the metadata using schema-aware logic and extract relevant fields for use in the verification process. The retrieved criteria may be formatted into a structured object that defines the expected characteristics of a valid domain response.

[0152] Selecting domain responses for evaluation involves identifying outputs generated by domain agents that are subject to probabilistic verification. Selection may be based on random sampling, anomaly detection, feedback indicators suchPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 as low confidence scores, flagged inconsistencies, etc. The foundational model may apply rale-based logic or learned heuristics to determine which domain responses warrant further analysis. Selected responses may be annotated with metadata describing context, agent identity, associated task parameters, etc.

[0153] Generating verification prompts involves constructing structured queries that encapsulate the verification criteria and the selected domain response. The foundational model may synthesize the prompts using template-based generation, semantic reformulation, contrastive prompting techniques, etc. Each prompt may include the original domain response, the predefined objective, contextual metadata, etc., for accurate interpretation. The prompts may be formatted for input to the foundational model using standardized schemas such as JSON, protocol buffers, etc.

[0154] Applying the foundational model to assess alignment with the predefined objective involves executing the verification prompt and interpreting the output. The foundational model may perform semantic comparison, probabilistic scoring, rale-based evaluation, etc., to determine whether the domain response satisfies the objective. The output may include a validation flag, a confidence score, a recommendation for escalation, etc. Recording the verification outcome involves storing the result in a session context, a transaction log, a coordination ledger, etc., for traceability and future reference.

[0155] Block 215 involves processing the cluster response using the central agent to generate an application response. Processing the cluster response includes retrieving the cluster response, interpreting the response content using the foundational model, applying central verification logic, synthesizing the application response, and formatting the application response for transmission. Each operation contributes to the transformation of intermediate results into a final output that aligns with the application prompt and the meta-policy. The centralPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 agent may perform the operations using structured instructions, embedded prompts, coordination metadata, etc., retrieved from the session context.

[0156] Retrieving the cluster response involves accessing the structured output generated by the specialized agent cluster. The cluster response may include domain results, execution metadata, confidence scores, diagnostic annotations, etc. The central agent may locate the cluster response using session identifiers, routing metadata, task completion signals, etc. The retrieved response may be parsed and loaded into a processing buffer for further analysis.

[0157] Interpreting the response content using the foundational model involves analyzing the semantic structure, operational relevance, and policy alignment of the cluster response. The foundational model may apply contextual embeddings, rule-based logic, learned heuristics, etc., to extract insights from the response. Interpretation may include identifying response segments, evaluating completeness, mapping outputs to application-level objectives, etc. The interpreted content may be annotated with metadata describing relevance, confidence, traceability, etc.

[0158] Applying central verification logic involves executing instructions that determine whether the cluster response satisfies the meta-policy associated with the application. Verification may include probabilistic evaluation, rule-based comparison, threshold-based scoring, etc. The foundational model may assess alignment with global optimization goals, compliance attributes, operational constraints, physics constraints, etc. The verification outcome may influence whether the response is accepted, revised, escalated for further analysis, etc.

[0159] Synthesizing the application response involves assembling the verified content into a structured output suitable for presentation. The central agent may format the response using standardized schemas such as JSON, XMT, protocolPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 buffers, etc. Formatting may include insertion of labels, grouping of related fields, transformation of raw values into display-ready formats, etc. The application response may be packaged with metadata such as timestamps, response identifiers, modality descriptors, etc., and transmitted to the application interface.

[0160] The method (200) may involve executing a central verification instruction by the central agent as part of a probabilistic verification step to determine whether the cluster response satisfies a predefined meta-policy associated with the application. Executing the central verification instruction includes retrieving the meta-policy from the application context, selecting cluster responses for evaluation, generating verification prompts, applying the foundational model to assess alignment with the meta-policy, and recording the verification result. Each operation contributes to the probabilistic determination of whether the cluster response meets the strategic specification defined for the application. The verification process may be initiated based on stochastic sampling, historical performance metrics, feedback indicators, etc., embedded in the central agent instructions.

[0161] Retrieving the meta-policy from the application context involves accessing structured policy definitions associated with the application. The meta-policy may include optimization goals, compliance constraints, coordination rales, performance thresholds, physics constraints of oil and gas domain, etc. The foundational model may parse the policy using schema-aware logic and extract relevant fields for use in the verification process. The retrieved meta-policy may be formatted into a structured object that defines the expected characteristics of a valid cluster response.

[0162] Selecting cluster responses for evaluation involves identifying outputs generated by specialized agent clusters that are subject to probabilistic verification. Selection may be based on random sampling, deviation from expected patterns,PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 feedback indicators such as low satisfaction scores, flagged inconsistencies, etc. The foundational model may apply rale-based logic or learned heuristics to determine which cluster responses warrant further analysis. Selected responses may be annotated with metadata describing the context, cluster identity, associated task parameters, etc.

[0163] Generating verification prompts involves constructing structured queries that encapsulate the meta-policy and the selected cluster response. The foundational model may synthesize the prompts using template-based generation, semantic reformulation, contrastive prompting techniques, etc. Each prompt may include the original cluster response, the predefined meta-policy, contextual metadata, etc., for accurate interpretation. The prompts may be formatted for input to the foundational model using standardized schemas such as JSON, protocol buffers, etc.

[0164] Applying the foundational model to assess alignment with the meta-policy involves executing the verification prompt and interpreting the output. The foundational model may perform semantic comparison, probabilistic scoring, ralebased evaluation, etc., to determine whether the cluster response satisfies the meta- policy. The output may include a validation flag, a confidence score, a recommendation for escalation, etc. Recording the verification result involves storing the outcome in a session context, a transaction log, a coordination ledger, etc., for traceability and future reference.

[0165] Block 218 involves transmitting the application response to the application, in which the application response is presented by the application. Transmitting the application response includes formatting the response for delivery, selecting a transmission protocol, dispatching the response to the application endpoint, confirming delivery status, and initiating presentation within the application interface. Each operation contributes to the final stage of the hierarchical multi-PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 agent workflow, in which the processed output is made available for user interaction, visualization, downstream integration with other software (e.g., Petrel® of Schlumberger Technology Corporation, Suite 100, 5599 San Felipe, Houston, TEXAS UNITED STATES 77056), etc. The transmission process may be initiated upon completion of central agent processing, verification routines, coordination logic, etc.

[0166] Formatting the response for delivery involves structuring the application response into a format compatible with the receiving application. The formatting process may include serialization into JSON, XML, protocol buffers, etc., insertion of metadata such as timestamps, session identifiers, response identifiers, etc., and application of schema validation rules. The foundational model may apply formatting templates based on the application type, operational context, presentation specification, etc. The formatted response may be encapsulated in a transport envelope for transmission.

[0167] Selecting a transmission protocol involves identifying the appropriate communication mechanism for delivering the application response. Protocol selection may include RESTful API calls, WebSocket streams, message queue dispatches, remote procedure invocations, etc. The foundational model may reference application metadata to determine endpoint addresses, authentication tokens, encryption parameters, etc. The selected protocol may be initialized with connection parameters and transmission headers.

[0168] Dispatching the response to the application endpoint involves transmitting the formatted response using the selected protocol. The transmission process may include opening a communication channel, sending the payload, monitoring transmission status, handling errors, retries, etc. The foundational model may log transmission metadata such as delivery time, response size, endpoint status, etc.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902The dispatched response may be acknowledged by the application through a confirmation signal, receipt log, etc.

[0169] Initiating presentation within the application interface involves triggering the rendering or display of the application response. The application may parse the received response, extract displayable content, apply styling rules, render the output in a graphical interface, dashboard, report, etc. Displaying the application response may include updating the display of the application prompt to include the application response. Presentation may include interactive elements such as expandable sections, tooltips, charts, embedded visualizations, etc. The rendered response may remain visible for user review, feedback, further interaction, etc.

[0170] The method (200) may involve updating presentation of the application prompt to include the application response. Updating presentation of the application prompt includes retrieving the original prompt context, merging the application response with the prompt content, formatting the combined output for display, transmitting the formatted content to the presentation layer, and rendering the updated prompt within the application interface. Each operation contributes to the integration of the generated output into the original query context for improved continuity, traceability, user comprehension, etc. The update may occur in real time or as part of a scheduled refresh cycle depending on the application environment, operational mode, user interaction pattern, etc.

[0171] Retrieving the original prompt context involves accessing stored data associated with the initial application prompt. The stored data may include query text, modality descriptors, timestamps, session identifiers, metadata annotations, etc. Retrieval may be performed using a session buffer, a prompt registry, a transaction log, a contextual memory store, etc. The foundational model may parse the retrieved content to isolate displayable elements and prepare for integration with the application response.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0172] Merging the application response with the prompt content involves combining the retrieved prompt with the generated response into a unified presentation object. The merging process may include alignment of semantic elements, insertion of response indicators, contextual tagging, etc. The foundational model may apply formatting logic to maintain coherence between the original prompt and the appended response. The merged content may be structured using a hierarchical schema, a nested object model, a composite rendering template, etc.

[0173] Formatting the combined output for display involves applying styling rules, layout parameters, visualization directives, etc., to the merged prompt and response. Formatting may include font selection, color coding, spacing, alignment, iconography, etc. The foundational model may reference interface specifications, user preferences, domain-specific display rules, etc., to generate the final visual structure. The formatted output may be encapsulated in a display container compatible with the application interface.

[0174] Transmitting the formatted content to the presentation layer involves sending the updated prompt and response to the application for rendering. Transmission may occur through a UI framework, a visualization engine, a remote dashboard, a native rendering module, etc. The transmission process may include serialization, packaging, endpoint dispatch, delivery confirmation, etc. Rendering the updated prompt within the application interface involves displaying the merged content in a graphical panel, a dialog box, a report section, another visual element, etc.

[0175] Turning to FIG. 3 through FIG. 8, examples of systems and methods for autonomous hierarchical multi-agent systems are described. The examples of FIG. 3 through FIG. 8 may describe the application of autonomous hierarchical multiagent systems to oil and gas systems.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0176] FIG. 3 is a representation of a sample environment of an oil and gas management system (300), according to at least one embodiment of the present disclosure. The oil and gas management system (300) may include a hierarchical multi-agent management system (302) that may process complex requests and queries from a user at a user device (304). The user may enter a user query regarding an oil and gas system (306) into the user device (304). The user device (304) and elements of the oil and gas system (306) may be in communication with the hierarchical multi-agent management system (302) over a network (308).

[0177] The oil and gas system (306) may include any oil and gas system, including a drill planning system, a drill rig, and underground drilling system, a surveying system, subsurface imaging, a production system, an oil and gas processing system, any other oil and gas system (306), and combinations thereof.

[0178] As discussed herein, the hierarchical multi-agent management system (302) includes a central coordination module (310). The central coordination module (310) may process the user request and identify various elements within the request. The user request may be any type of request, including a request for information about the oil and gas system (306), a request to optimize a particular aspect of the oil and gas system (306), a request to change a particular aspect of the oil and gas system (306), a request to identify a problem in the oil and gas system (306), any other request, and combinations thereof. The central coordination module (310) may identify various elements of the user request and prepare one or more queries to specialized agents to respond to the query.

[0179] The hierarchical multi-agent management system (302) may further include one or more specialized agent clusters (312). The specialized agent clusters (312) may include multiple agents (314) focused on a specialized subject matter. Each of the agents (314) may be trained based on an aspect of the specialized subject matter. In some embodiments, the agents (314) may be trained using differentPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 training methodologies. In some embodiments, the multiple agents (314) may be trained on a different focus within the specialized subject matter.

[0180] Examples of the specialized agent clusters (312) may include an exploration cluster, a drilling and completion cluster, a production and operations cluster, a midstream and transportation cluster, a refining and processing cluster, a distribution and marketing cluster, a safety and environmental cluster, a data quality and management cluster, a financial and economic cluster, a human resources and training cluster, and so forth. The specialized agent clusters (312) may include various agents associated with a corresponding specialty. For example, the exploration cluster may include, without limitation, geophysical modeling agents, play-based exploration agents, prospect evaluation agents, seismic processing agents, any other agents, and combinations thereof. In some examples, the drilling and completion cluster may include, without limitation, fracture design agents, geosteering agents, bit performance agents, mud management agents, trajectory optimization agents, any other drilling and completion agents, and combinations thereof. The production and operation cluster may include, without limitation, maintenance agents, well intervention agents, reservoir management agents, production allocation agents, artificial lift optimization agents, sand management agents, multiphase flow optimization agents, any other production and operation agents, and combinations thereof. The midstream and transportation agents may include, without limitation, transportation optimization agents, storage management agents, pipeline optimization agents, any other midstream and transportation agents, and combinations thereof. The refining and processing agents may include, without limitation, emissions monitoring agents, energy management agents, process optimization agents, any other refining and processing agent, and combinations thereof. The distribution and marketing agents may include, without limitation,PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 pricing optimization agents, logistics agents, demand forecasting agents, any other distribution and marketing agents, and combinations thereof. A maintenance agent cluster may include, without limitation, predictive maintenance agents, corrosion management agents, integrity management agents, spare parts optimization agents, any other maintenance agents, and combinations thereof. A reservoir management agent cluster may include, without limitation, history matching agents, injection optimization agents, fracture design agents, decline analysis agents, any other reservoir management agent, and combinations thereof. A safety and environmental cluster may include emissions monitoring agents, spill prevention agents, emergency response agents, regulatory compliance agents, any other safety and environmental agent, and combinations thereof. A logistics and supply chain cluster may include, without limitation, inventory management agents, transportation optimization agents, procurement agents, demand forecasting agents, any other logistics and supply chain agents, and combinations thereof. An energy management cluster may include, without limitation, power generation optimization agents, demand response agents, renewable integration agents, microgrid management agents, any other energy management cluster agents, and combinations thereof. A well intervention cluster may include, without limitation, workover planning agents, stimulation design agents, coiled tubing operation agents, well abandonment agents, any other well intervention agents, and combinations thereof. A data quality and management cluster may include, without limitation, data cleansing agents, data integration agents, metadata management agents, data security agents, any other data quality and management agents, and combinations thereof. A financial and economic agent may include, without limitation, investment portfolio agents, risk assessment agents, cost optimization agents, revenue forecasting agents, any other financial and economic agent, and combinations thereof. A human resources and training cluster may include, without limitation, skills gap analysis agents, training program agents,PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 crew scheduling agents, safety training agents, any other human resources and training agents, and combinations thereof.

[0181] These diverse agent types work in concert to manage the complex, interrelated aspects of oil and gas operations. The specialized capabilities allow for deep optimization within specific domains, while the ability to communicate and coordinate enables system-wide improvements that would be impossible with traditional, siloed approaches.

[0182] In accordance with at least one embodiment of the present disclosure, the multiple agents (314) may be modular. For example, the hierarchical multi-agent management system (302) may utilize one or more of the modular agents (314) to perform a particular task, or respond to a particular user request. Different combinations of agents may be used to respond to different requests. The modular nature of the agents allows for easy expansion of the capabilities of the system as new technologies emerge or operational capabilities evolve. For example, as carbon capture and storage becomes more prevalent, new agent types could be rapidly developed and integrated to manage the operations.

[0183] In some embodiments, the oil and gas management system (300) may identify a state of the oil and gas system (306). The state of the oil and gas system (306) may be a representation of the current condition of one or more elements of the oil and gas system (306). For example, the state of the oil and gas system (306) may include a representation of operating equipment status and location, operating personnel assignment and location, costs, production, sensor values, profit, any other status of the oil and gas system (306), and combinations thereof. The status of the oil and gas system (306) may be determined in any manner. For example, the status of the oil and gas system (306) may be determined based on sensor data, daily reports, equipment reports, costs (such as payroll, vendor invoices), revenuePATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902(such as accounts receivable, stock value), any other information, and combinations thereof.

[0184] In accordance with at least one embodiment of the present disclosure, the hierarchical multi-agent management system (302) may prepare responses to various requests and / or changes in the status of the oil and gas system (306). For example, the user may provide a user request regarding the status of the oil and gas system (306), such as a question about the operating costs, profit, supply chain, and so forth. The central coordination module (310) may identify which specialized agent clusters (312) may provide an answer to the request, and a cluster manager for the specialized agent clusters (312) may submit the request to one or more multiple agents (314) in the specialized agent clusters (312).

[0185] In some embodiments, the hierarchical multi-agent management system (302) may, based on a meta-policy, identify a target state for the oil and gas system (306). The target state may include a balance of local and global optimization goals for the oil and gas system (306). When the oil and gas system (306) is not at the target state, the hierarchical multi-agent management system (302) may identify various aspects of the oil and gas system (306) that may cause the current state to vary from the target state. For example, the hierarchical multi-agent management system (302) may autonomously identify the variance in the current state from the target state. The hierarchical multi-agent management system (302) may further identify the reason for the variance between the current state and the target state. In some embodiments, the hierarchical multi-agent management system (302) may identify one or more actions that the oil and gas system (306) may implement to transition the oil and gas system (306) from the current state to the target state.

[0186] In some embodiments, the user request may include a request regarding the impact of the oil and gas system (306) based on a change to one or more parameters of the oil and gas system (306). For example, the user request may include aPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 request regarding the impact of increasing the production at one or more wells. The central coordination module (310) may identify the request and identify which of the specialized agent clusters (312) may analyze the impact on the oil and gas system (306). The cluster manager for the specialized agent clusters (312) may identify which agents (314) may respond to the request. The agents (314) may identify one or more impacts of the request, and submit the response, through the central coordination module (310), to the user. In some embodiments, multiple specialized agent clusters (312) may analyze the impact of increased production, which may provide the user with previously-unforeseen results. For example, increased production may result in increased wear and tear on equipment, supply chain issues, environmental issues, and so forth. By leveraging the expertise of the various specialized agent clusters (312), the hierarchical multi-agent management system (302) may identify the total impact on the oil and gas system (306) and maintain operation of the oil and gas system (306) based on the meta-policy.

[0187] In accordance with at least one embodiment of the present disclosure, the cluster managers for the specialized agent clusters (312) may utilize federated learning to share insights among the agents in the specialized agent clusters (312), as well as between the various clusters of the specialized agent clusters (312). Federated learning may include training the agents (314) from a decentralized datastore, which may facilitate training of the agents (314) from different datasets, from different clients, or corporate entities while maintaining data privacy between the different datasets.

[0188] The agents (314) may include dynamic skill libraries, or collaborative libraries or databases that may be shared among agents (314) in the same cluster. The inclusion may facilitate the access of the agents (314) to the same dataset, thereby improving the consistency and relevancy of results between agents (314) of the same cluster.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0189] In some embodiments, the agents (314) may implement curiosity-driven exploration to discover novel solutions to problems, requests, and queries. For example, the agents (314) may identify a change in the current state of the oil and gas system (306) compared to a previous state or a target state. The agents (314) may provide a request to identify the source of the change in the current state. For example, when the agents (314) may identify that a sensor value has changed, the agents (314) may be trained to identify the extent of the change in the sensor value. When the sensor value has changed to a high threshold or a low threshold, the agents (314) may flag the sensor results. The cluster manager of the specialized agent cluster (312) and / or other agents (314) may identify the cause of the change in sensor value, such as a miscalibrated and / or damaged sensor. Such curiosity- driven data analysis may improve the results of the hierarchical multi-agent management system (302), thereby improving the operating efficiency of the oil and gas system (306).

[0190] FIG. 4 is a representation of a hierarchical multi-agent management system (402), according to at least one embodiment of the present disclosure. Each of the components of the hierarchical multi-agent management system (402) may include software, hardware, or both. For example, the components may include one or more instructions stored on a computer readable storage medium and executable by processors of one or more computing devices, such as a client device or server device. When executed by the one or more processors, the computer-executable instructions of the hierarchical multi-agent management system (402) may cause the computing device(s) to perform the methods described herein. Alternatively, the components may include hardware, such as a special-purpose processing device to perform a certain function or group of functions. Alternatively, the components of the hierarchical multi-agent management system (402) may include a combination of computer-executable instructions and hardware.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0191] Furthermore, the components of the hierarchical multi-agent management system (402) may, for example, be implemented as one or more operating systems, as one or more stand-alone applications, as one or more modules of an application, as one or more plug-ins, as one or more library functions or functions that may be called by other applications, and / or as a cloud-computing model. Thus, the components may be implemented as a stand-alone application, such as a desktop or mobile application. Furthermore, the components may be implemented as one or more web-based applications hosted on a remote server. The components may also be implemented in a suite of mobile device applications or “apps.”

[0192] As discussed herein, the hierarchical multi-agent management system (402) may include a central coordination module (410). The central coordination module (410) may analyze user requests and other inputs and identify aspects of the inputs. Based on the various aspects of the inputs, the central coordination module (410) may identify one or more specialized agent clusters (412) that are associated with the input or aspect of the input. The central coordination module (410) may provide the input, or the aspect of the input, to the specialized agent clusters (412). The specialized agent clusters (412) may include a cluster manager (416), which may receive the input, or the aspect of the input. In some embodiments, the central coordination module (410) may generate a query or a prompt to input to the specialized agent clusters (412).

[0193] The cluster manager (416) may receive the input, the aspect of the input, or the prompt (e.g., a cluster input) generated by the central coordination module (410) and identify one or more agents (414) that may be responsive to the input. For example, the cluster manager (416) may analyze the content of the cluster input, and identify the features and functions of the various agents (414). The cluster manager (416) may select one or more of the agents (414).PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0194] The cluster manager (416) may provide the selected agents (414) with an agent input. In some embodiments, the agent input may include the cluster input. In some embodiments, the cluster manager (416) may generate the agent input by generating a prompt or query based on the features and functions of the selected agents (414). For example, the selected agents (414) may provide a particular specialized output. The cluster manager (416) may generate a prompt for the agent input that is focused on the particular agent (414).

[0195] As discussed herein, each specialized agent cluster (412) may include a shared datastore (418). Each of the agents (414) in the specialized agent cluster (412) may be trained on and / or have access to the shared datastore (418). The shared datastore (418) may include data that is relevant to the subject matter of the specialized agent cluster (412). The inclusion may reduce the amount of data the agents (414) may access, thereby reducing the processing load and / or processing time for the agents (414).

[0196] In some embodiments, the hierarchical multi-agent management system (402) may include an integration manager (420). The integration manager (420) may receive input from various sources. For example, the integration manager (420) may receive user input from a user device. In some embodiments, the integration manager (420) may be integrated with various software solutions or other software elements that may perform functions in the oil and gas system. In some embodiments, the integration manager (420) may include a universal adapter framework that may interface with industry- standard protocols. In some embodiments, the integration manager (420) may include an adapter framework that may interface with proprietary systems, including proprietary systems to which the hierarchical multi-agent management system (402) has access. In some embodiments, the integration manager (420) may implement digital shadowing to create virtual representations of non-smart equipment (e.g., equipment that is notPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 connected to the internet (e.g., non-intemet-of-things (IoT)) equipment). In some embodiments, the integration manager (420) may use natural-language processing to extract operational knowledge from existing manuals and procedures to train and / or fine-tune the various agents (414).

[0197] In some embodiments, the integration manager (420) may automatically receive sensor information from sensors (424) in the oil and gas system. The sensors may be located at any part of the oil and gas system, including IoT devices and other sensors located at various locations within the oil and gas system.

[0198] The hierarchical multi-agent management system (402) may further include an inter-level communication manager (422). The inter-level communication manager (422) may manage communication between the various levels of the hierarchical multi-agent management system (402). For example, the inter-level communication manager (422) may receive the cluster input from the central coordination module (410). The inter-level communication manager (422) may package the cluster input into a protocol that is based on the oil and gas input. The inter-level communication manager (422) may transmit the cluster input to the cluster manager (416). In some embodiments, the inter-level communication manager (422) may further package the agent input from the cluster manager (416) and provide the agent input to the agents (414). The inter-level communication manager (422) may further package the results of the agents’ (414) analysis and provide the results to the cluster manager (416) and / or the central coordination module (410). The protocol used by the inter-level communication manager (422) may reduce the latency of communication between layers of the hierarchical multiagent management system (402), thereby reducing the processing time of the hierarchical multi-agent management system (402).

[0199] FIG. 5 is a representation of a hierarchical multi-agent management system (502), according to at least one embodiment of the present disclosure. ThePATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 hierarchical multi-agent management system (502) includes a central coordination module (510). The central coordination module (510) may be in communication with multiple specialized agent clusters (collectively (512)). The specialized agent clusters (512) may each be specialized in a particular subject matter. Each specialized agent clusters (512) includes multiple agents (collectively (514)). Each agent (514) may be focused on a particular aspect of the subject matter of the specialized agent cluster (512).

[0200] In the embodiment shown, the hierarchical multi-agent management system (502) includes a first specialized agent cluster (512-1), a second specialized agent cluster (512-2), and a third specialized agent cluster (512-3). The first specialized agent cluster (512-1) may have a first agent (514-1A), a second agent (514-2A), and a third agent (514-3 A). The second specialized agent cluster (512-2) may have a first agent (514-1B), a second agent (514-2B), and a third agent (514-3B). The third specialized agent cluster (512-3) may have a first agent (514-1C), a second agent (514-2C), and a third agent (514-3C).

[0201] As may be seen, the hierarchical multi-agent management system (502) is hierarchical. The hierarchy of the hierarchical multi-agent management system (502) includes a first level with the central coordination module (510). The central coordination module (510) coordinates overall strategy of the hierarchical multiagent management system (502) according to the meta-policy. Contained in the second level of the hierarchical multi-agent management system (502) are the specialized agent clusters (512). Each specialized agent cluster (512) is focused on a specialized subject matter, and the agents (514) are focused on a particular aspect of the subject matter. Thus, at lower levels of the hierarchy, the hierarchical multiagent management system (502) focuses on greater detail regarding a query or input, and at higher levels of the hierarchy, the hierarchical multi-agent management system (502) focuses on strategic goals for the oil and gas system.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902

[0202] When the central coordination module (510) receives a user request, the central coordination module (510) may identify various aspects of the user request. For example, the central coordination module (510) may identify which portions of the hierarchical multi-agent management system (502) may prepare a response to at least one aspect of the user request. The central coordination module (510) may identify a set of one or more specialized agent clusters (512) that may prepare a full response to the user input. The set of one or more specialized agent clusters (512) may include any number of specialized agent clusters (512) that may prepare the response to the user request.

[0203] In some embodiments, each specialized agent cluster (512) may identify a set of one or more agents (514). The set of one or more agents (514) may be the agents (514) that may prepare a response that is responsive or relevant to the user request, or the aspect of the user request associated with the specialized agent cluster (512). In some embodiments, the set of one or more agents (514) may include multiple of the same agent (514) or similar agents associated with the specialized agent cluster (512).

[0204] In some embodiments, in response to a single input or query, the hierarchical multi-agent management system (502) may transmit queries and responses up and down the hierarchy multiple times until the response is consistent with the metapolicy. For example, the central coordination module (510) may generate a cluster input to one or more of the specialized agent clusters (512). The specialized agent clusters (512) may generate agent inputs for the agents (514). The agent (514) may generate a response and provide the response to the specialized agent cluster (512). The specialized agent cluster (512) may analyze the response to see if the response is consistent with the cluster input. When the response is not consistent with the cluster input, the specialized agent cluster (512) may adjust the input, or generate a revised agent input for one or more of the agents (514). The agents (514) mayPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 then prepare a new response based on the revised agent input. The process may be repeated until the agent responses are consistent with the cluster input or desired state to take the oil and gas system to the required outcome. In some embodiments, the hierarchical multi-agent management system (502) may request an adjusted user request to clarify the user request. In some embodiments, the hierarchical multi-agent management system (502) may adjust the cluster input and / or the agent input to facilitate a transition of the oil and gas system from the current state to the target state.

[0205] The specialized agent clusters (512) may provide the responses (and / or a summary of the responses) to the central coordination module (510). The central coordination module (510) may determine whether the responses or the summary of the responses are consistent with the meta-policy. When the response or summaiy are not consistent with the meta-policy, the central coordination module (510) may generate a new cluster input and transmit the new cluster input to the specialized agent clusters (512). In this manner, the hierarchical multi-agent management system (502) may facilitate the balance of optimizing local goals (e.g. , at the agent (514) level) and global goals (e.g. , at the specialized agent cluster (512) and / or the central coordination module (510)), consistent with the meta- policy.

[0206] In some embodiments, the agents (514) may identify a change to one or more operating parameters. In some embodiments, as the hierarchical multi-agent management system (502) iteratively processes the user request, the agents (514) may provide additional changes, based on the new cluster input.

[0207] The hierarchical multi-agent management system (502) may implement an agent to agent protocol for efficient information dissemination in unreliable network conditions and multi agent settings. For example, the agents (514) may communicate information between the various agents (514) when the agents are inPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 direct communication. In some embodiments, the hierarchical multi-agent management system (502) may incorporate the use of zero-knowledge proofs for secure sharing of sensitive operational data between agents (514). This may allow agents (514) to be trained on and / or use proprietary information without undesired disclosure or sharing of that proprietary communication. In some embodiments, the hierarchical multi-agent management system (502) may utilize multi-modal domain-specific LLMs for oil and gas operations to facilitate precise inter-agent communication.

[0208] In accordance with at least one embodiment of the present disclosure, the hierarchical multi-agent management system (502) may implement one or more conflict resolution mechanism. For example, the hierarchical multi-agent management system (502) may implement a reputation system to weigh agent inputs of the various agents (514) based on past performance of the agents (514). The hierarchical multi-agent management system (502) may further utilize game theory-based negotiation protocols for resolving resource conflicts. The hierarchical multi-agent management system (502) may further utilize a devil’s advocate agent to challenge consensus and prevent groupthink. For example, the hierarchical multi-agent management system (502) may provide fabricated information to one or more agents (514) to analyze. The hierarchical multi-agent management system (502) may analyze the difference between the analysis of the fabricated information and the actual input to determine which of the agents (514) are providing the most accurate and / or representative responses to the agent input.

[0209] The hierarchical multi-agent management system (502) may further include one or more safety and redundancy features. For example, the hierarchical multiagent management system (502) may implement formal verification techniques to mathematically provide the safety of agent (514) behaviors. The hierarchical multi-agent management system (502) may further use adversarial training toPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 improve agent robustness against unexpected inputs or conditions. The hierarchical multi-agent management system (502) may further implement Byzantine fault tolerance protocols to maintain system integrity even if some agents are compromised. The hierarchical multi-agent management system (502) may use heterogenous agent designs to reduce the risk of systemic failures. The hierarchical multi-agent management system (502) may develop a dormant agent system, or a system that may rapidly spawn new agents if primary and standby agents fail.

[0210] FIG. 6 is a representation of a hierarchical multi-agent management system (602), according to at least one embodiment of the present disclosure. The hierarchical multi-agent management system (602) includes a central coordination module (610), as discussed herein. The central coordination module (610) may be in communication with multiple specialized agent clusters (collectively (612)). The specialized agent clusters (612) may each be specialized in a particular subject matter. Each specialized agent clusters (612) includes multiple agents (collectively (614)). Each agent (614) may be focused on a particular aspect of the subject matter of the specialized agent cluster (612).

[0211] In the embodiment shown, the hierarchical multi-agent management system (602) includes a first specialized agent cluster (612-1), a second specialized agent cluster (612-2), and a third specialized agent cluster (612-3). The first specialized agent cluster (612-1) may have a first agent (614-1 A), a second agent (614-2A), and a third agent (614-3 A). The second specialized agent cluster (612-2) may have a first agent (614- IB), a second agent (614-2B), and a third agent (614-3B). The third specialized agent cluster (612-3) may have a first agent (614-1C), a second agent (614-2C), and a third agent (614-3C). The first specialized agent cluster (612-1) may be a production agent cluster. The second specialized agent clusterPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902(612-2) may be a drilling agent cluster. The third specialized agent cluster (612-1) may be a subsurface agent cluster.

[0212] The hierarchical multi-agent management system (602) may include an integration layer (626). The integration layer (626) may facilitate integration of the hierarchical multi-agent management system (602) with the user via a user device (604) and other existing systems from an oil and gas system (606). The integration layer (626) may include a universal adapter framework that may interface with other industry- standard protocols or proprietary systems. For example, the adapter framework may include a framework to receive information from the oil and gas system (606) and / or various user devices (604). As an operator desires to integrate new systems into the hierarchical multi-agent management system (602), the integration layer (626) may add to the framework to receive information and / or additional specialized agent clusters (612) and / or agents (614) for the new system.

[0213] FIG. 7 and FIG. 8, the corresponding text, and the examples provide a number of different methods, systems, devices, and computer readable media of the hierarchical multi-agent management system. In addition to the foregoing, one or more embodiments may also be described in terms of flowcharts including acts for accomplishing a particular result, as shown in FIG. 7 and FIG. 8. FIG. 7 and FIG. 8 may be performed with more or fewer acts. Further, the acts may be performed in differing orders. Additionally, the acts described herein may be repeated or performed in parallel with one another or parallel with different instances of the same or similar acts.

[0214] As mentioned, FIG. 7 illustrates a flowchart of a series of acts or a method (700) for managing an oil and gas system, according to at least one embodiment of the present disclosure. While FIG. 7 illustrates acts according to one embodiment, alternative embodiments may omit, add to, reorder, and / or modify any of the acts shown in FIG. 7. The acts of FIG. 7 may be performed as part of aPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 method. Alternatively, a computer readable medium may include instructions that, when executed by one or more processors, cause a computing device to perform the acts of FIG. 7. In some embodiments, a system may perform the acts of FIG. 7.

[0215] A hierarchical multi-agent management system may, at a central coordination module, and based on a current state of the oil and gas system, identify a target state for the oil and gas system at (701). The hierarchical multiagent management system may, at the central coordination module, identify a specialized agent cluster associated with the target state at (702). The specialized agent cluster includes multiple agents associated with the subject matter of the specialized agent cluster. The specialized agent cluster includes multiple agents. The central coordination module may provide a cluster manager with the target state at (703). The cluster manager is associated with the specialized agent cluster. Put another way, the cluster manager may include a model trained to work with the various agents in the agent cluster. The hierarchical multi-agent management system may, at the cluster manager, identify one or more agents of the plurality of agents to identify a change in the oil and gas system to transition the oil and gas system to the target state at (704). Transitioning the oil and gas system to the target state may include any type of transition, such as a change in parameters that may change the output of the oil and gas system. Changing the output of the oil and gas system may result in a change, or a transition, in the oil and gas system to or toward the target state.

[0216] As mentioned, FIG. 8 illustrates a flowchart of a series of acts or a method (800) for managing an oil and gas system, according to at least one embodiment of the present disclosure. While FIG. 8 illustrates acts according to one embodiment, alternative embodiments may omit, add to, reorder, and / or modify any of the acts shown in FIG. 8. The acts of FIG. 8 may be performed as part of aPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 method. Alternatively, a computer readable medium may include instructions that, when executed by one or more processors, cause a computing device to perform the acts of FIG. 8. In some embodiments, a system may perform the acts of FIG. 8.

[0217] A hierarchical multi-agent management system may receive an input from a user at (801). The input may include a user request. The hierarchical multi-agent management system may, at a central coordination module, identify a specialized agent cluster based on the user request at (802). The hierarchical multi-agent management system may transmit a query (e.g, a cluster input) to a cluster manager associated with the specialized agent cluster at (803). The query may be based on the user request. The hierarchical multi-agent management system may, at the cluster manager, input the query to one or more agents to prepare a response to the user request at (804). The hierarchical multi-agent management system may transmit, from the cluster manager to the central coordination module, the response at (805). The hierarchical multi-agent management system may present the response to the user at (806). For example, the hierarchical multi-agent management system may present the response to the user on the user device, in a program operated by the user, or other mechanism.

[0218] FIG. 9 illustrates certain components that may be included within a computer system (900). One or more computer systems (900) may be used to implement the various devices, components, and systems described herein.

[0219] The computer system (900) includes a processor (901). The processor (901) may be a general-purpose single or multi-chip microprocessor (e.g., an Advanced RISC (Reduced Instruction Set Computer) Machine (ARM)), a special purpose microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, etc. The processor (901) may be referred to as a central processing unit (CPU). Although just a single processor (901) is shown in thePATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 computer system (900) of FIG. 9, in an alternative configuration, a combination of processors (e.g., an ARM and DSP) could be used.

[0220] The computer system (900) also includes memory (903) in electronic communication with the processor (901). The memory (903) may be any electronic component capable of storing electronic information. For example, the memory (903) may be embodied as random access memory (RAM), read-only memory (ROM), magnetic disk storage media, optical storage media, flash memory devices in RAM, on-board memory included with the processor, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memoiy, registers, and so forth, including combinations thereof.

[0221] Instructions (905) and data (907) may be stored in the memory (903). The instructions (905) may be executable by the processor (901) to implement some or all of the functionality disclosed herein. Executing the instructions (905) may involve the use of the data (907) that is stored in the memory (903). Any of the various examples of modules and components described herein may be implemented, partially or wholly, as instructions (905) stored in memory (903) and executed by the processor (901). Any of the various examples of data described herein may be among the data (907) that is stored in memoiy (903) and used during execution of the instructions (905) by the processor (901).

[0222] A computer system (900) may also include one or more communication interfaces (909) for communicating with other electronic devices. The communication interface(s) (909) may be based on wired communication technology, wireless communication technology, or both. Some examples of communication interfaces (909) include a Universal Serial Bus (USB), an Ethernet adapter, a wireless adapter that operates in accordance with an Institute of Electrical and Electronics Engineers (IEEE) (902).11 wireless communicationPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 protocol, a Bluetooth® wireless communication adapter, and an infrared (IR) communication port.

[0223] A computer system (900) may also include one or more input devices (91 1) and one or more output devices (913). Some examples of input devices (911) include a keyboard, mouse, microphone, remote control device, button, joystick, hackball, touchpad, and lightpen. Some examples of output devices (913) include a speaker and a printer. One specific type of output device that may be included in a computer system (900) is a display device (915). Display devices (915) used with embodiments disclosed herein may utilize any suitable image projection technology, such as liquid crystal display (LCD), light-emitting diode (LED), gas plasma, electroluminescence, or the like. A display controller (917) may also be provided, for converting data (907) stored in the memory (903) into text, graphics, and / or moving images (as appropriate) shown on the display device (915).

[0224] The various components of the computer system (900) may be coupled together by one or more buses, which may include a power bus, a control signal bus, a status signal bus, a data bus, etc. For the sake of clarity, the various buses are illustrated in FIG. 9 as a bus system (919).

[0225] The embodiments of the hierarchical multi-agent management system have been primarily described with reference to wellbore drilling operations; the hierarchical multi-agent management systems described herein may be used in applications other than the drilling of a wellbore. In other embodiments, hierarchical multi-agent management systems according to the present disclosure may be used outside a wellbore or other downhole environment used for the exploration or production of natural resources. For instance, hierarchical multiagent management systems of the present disclosure may be used in a borehole used for placement of utility lines. Accordingly, the terms “wellbore,” “borehole”PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 and the like should not be interpreted to limit tools, systems, assemblies, or methods of the present disclosure to any particular industry, field, or environment.

[0226] One or more specific embodiments of the present disclosure are described herein. These described embodiments are examples of the presently disclosed techniques. Additionally, in an effort to provide a concise description of these embodiments, not all features of an actual embodiment may be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous embodimentspecific decisions will be made to achieve the developers’ specific goals, such as compliance with system-related and business-related constraints, which may vary from one embodiment to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.

[0227] Additionally, it should be understood that references to “one embodiment” or “an embodiment” of the present disclosure are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features. For example, any element described in relation to an embodiment herein may be combinable with any element of any other embodiment described herein. Numbers, percentages, ratios, or other values stated herein are intended to include that value, and also other values that are “about” or “approximately” the stated value, as would be appreciated by one of ordinary skill in the art encompassed by embodiments of the present disclosure. A stated value should therefore be interpreted broadly enough to encompass values that are at least close enough to the stated value to perform a desired function or achieve a desired result. The stated values include at least the variation to be expected in a suitable manufacturing orPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 production process, and may include values that are within 5%, within 1%, within 0.1%, or within 0.01% of a stated value.

[0228] A person having ordinary skill in the art should realize in view of the present disclosure that equivalent constructions do not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and alterations may be made to embodiments disclosed herein without departing from the spirit and scope of the present disclosure. Equivalent constructions, including functional “means-phis-function” clauses are intended to cover the structures described herein as performing the recited function, including both structural equivalents that operate in the same maimer, and equivalent structures that provide the same function. It is the express intention of the applicant not to invoke means-plus- function or other functional claiming for any claim except for those in which the words ‘means for’ appear together with an associated function. Each addition, deletion, and modification to the embodiments that falls within the meaning and scope of the claims is to be embraced by the claims.

[0229] The terms “approximately,” “about,” and “substantially” as used herein represent an amount close to the stated amount that is within standard manufacturing or process tolerances, or which still performs a desired function or achieves a desired result. For example, the terms “approximately,” “about,” and “substantially” may refer to an amount that is within less than 5% of, within less than 1% of, within less than 0.1% of, and within less than 0.01% of a stated amount. Further, it should be understood that any directions or reference frames in the preceding description are merely relative directions or movements. For example, any references to “up” and “down” or “above” or “below” are merely descriptive of the relative position or movement of the related elements.

[0230] The present disclosure may be embodied in other specific forms without departing from its spirit or characteristics. The described embodiments are to bePATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 considered as illustrative and not restrictive. The scope of the disclosure is, therefore, indicated by the appended claims rather than by the foregoing description. Changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

[0231] As used herein, the term “connected to” contemplates multiple meanings. A connection may be direct or indirect (e.g. , through another component or network). A connection may be wired or wireless. A connection may be a temporary, permanent, or a semi-permanent communication channel between two entities.

[0232] The various descriptions of the figures may be combined and may include, or be included within, the features described in the other figures of the application. The various elements, systems, components, and steps shown in the figures may be omitted, repeated, combined, or altered as shown in the figures. Accordingly, the scope of the present disclosure should not be considered limited to the specific arrangements shown in the figures.

[0233] In the application, ordinal numbers e.g., first, second, third, etc.) may be used as an adjective for an element (i.e., any noun in the application). The use of ordinal numbers is not to imply or create any particular ordering of the elements, nor to limit any element to being only a single element unless expressly disclosed, such as by the use of the terms “before,” “after,” “single,” and other such terminology. Rather, ordinal numbers distinguish between the elements. By way of an example, a first element is distinct from a second element, and the first element may encompass more than one element and succeed (or precede) the second element in an ordering of elements.

[0234] Further, unless expressly stated otherwise, the conjunction “or” is an inclusive “or” and, as such, automatically includes the conjunction “and,” unless expressly stated otherwise. Further, items joined by the conjunction “or” mayPATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 include any combination of the items with any number of each item, unless expressly stated otherwise.

[0235] In the above description, numerous specific details are set forth in order to provide a more thorough understanding of the disclosure. However, it will be apparent to one of ordinary skill in the art that the technology may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description. Further, other embodiments not explicitly described above can be devised which do not depart from the scope of the claims as disclosed herein. Accordingly, the scope should be limited only by the attached claims.

Claims

PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902CLAIMSWhat is claimed is:

1. A method comprising : receiving an application prompt from an application; executing central instructions of a central agent, corresponding to the application, with a foundational model to process the application prompt, select a specialized agent cluster from a cluster list, and generate a cluster prompt for the specialized agent cluster; executing cluster instructions of a cluster agent, corresponding to the specialized agent cluster, with the foundational model to process the cluster prompt, select a domain agent from a domain agent list, and generate a domain prompt for the domain agent; executing domain instructions of the domain agent, with the foundational model, based on the domain prompt to perform one or more of accessing a data store and invoking a domain tool application to generate a domain response; processing the domain response using the cluster agent to generate a cluster response; processing the cluster response using the central agent to generate an application response; and transmitting the application response to the application, wherein the application response is presented by the application.

2. The method of claim 1, further comprising: presenting the application prompt prior to the application response being generated; and updating presentation of the application prompt to include the application response.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 7679023. The method of claim 1, further comprising: retrieving user feedback associated with prior domain responses to execute a probabilistic verification step when the user feedback indicates a threshold level of dissatisfaction.

4. The method of claim 1, further comprising: executing a central verification instruction by the central agent as part of a probabilistic verification step to determine whether the cluster response satisfies a predefined meta-policy associated with the application.

5. The method of claim 1, further comprising: executing a cluster verification instruction by the cluster agent as part of a probabilistic verification step to determine whether the domain response satisfies a predefined objective associated with the specialized agent cluster.

6. The method of claim 1, further comprising: executing a domain verification instruction by the domain agent as part of a probabilistic verification step to validate the domain response using benchmarking data associated with the domain tool application.

7. The method of claim 1, further comprising: accessing the domain agent list after being dynamically updated to identify the domain agent, wherein the domain agent list includes domain agent metadata describing agent capabilities, access rights, tool integrations, and tool capabilities; and accessing the cluster list after being dynamically updated to identify the specialized agent cluster, wherein the cluster list includes cluster metadata describing cluster scope, associated domain areas, and coordination protocols for agent selection and task planning.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 7679028. The method of claim 1, further comprising: executing a central planning instruction by the central agent to generate, based on the application prompt, a multi-step workflow plan comprising sequential or parallel cluster prompts.

9. The method of claim 1, further comprising: executing a cluster planning instruction by the cluster agent to decompose the cluster prompt into a set of tasks, wherein each task of the set of tasks is assigned to a corresponding domain agent.

10. The method of claim 1, further comprising: invoking one or more of the domain tool application and a domain application by the domain agent to interface with a software system comprising one or more of a seismic interpretation platform, a drilling optimization platform, a reservoir simulation tool, and a production analytics system.

11. A system comprising: a computer processor; and an application that, when executing on the computer processor, performs operations comprising: receiving an application prompt from an application, executing central instructions of a central agent, corresponding to the application, with a foundational model to process the application prompt, select a specialized agent cluster from a cluster list, and generate a cluster prompt for the specialized agent cluster, executing cluster instructions of a cluster agent, corresponding to the specialized agent cluster, with the foundational model to process the cluster prompt, select a domain agent from a domain agent list, and generate a domain prompt for the domain agent,PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 767902 executing domain instructions of the domain agent, with the foundational model, based on the domain prompt to perform one or more of accessing a data store and invoking one or more of a domain tool application and a domain application to generate a domain response, processing the domain response using the cluster agent to generate a cluster response, processing the cluster response using the central agent to generate an application response, and transmitting the application response to the application, wherein the application response is presented by the application.

12. The system of claim 11, wherein the application performs operations further comprising: presenting the application prompt prior to the application response being generated; and updating presentation of the application prompt to include the application response.

13. The system of claim 11, wherein the application performs operations further comprising: retrieving user feedback associated with one or more of a prior application response, a prior cluster response, and a prior domain response to execute a probabilistic verification step when the user feedback indicates a threshold level of dissatisfaction.

14. The system of claim 11, wherein the application performs operations further comprising: executing a central verification instruction by the central agent as part of a probabilistic verification step to determine whether the cluster response satisfies a predefined meta-policy associated with the application.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 76790215. The system of claim 11, wherein the application performs operations further comprising: executing a cluster verification instruction by the cluster agent as part of a probabilistic verification step to determine whether the domain response satisfies a predefined objective associated with the specialized agent cluster.

16. The system of claim 11, wherein the application performs operations further comprising: executing a domain verification instruction by the domain agent as part of a probabilistic verification step to validate the domain response using benchmarking data associated with the domain tool application.

17. The system of claim 11, wherein the application performs operations further comprising: accessing the domain agent list after being dynamically updated to identify the domain agent, wherein the domain agent list includes domain agent metadata describing agent capabilities, access rights, tool integrations, and tool capabilities; and accessing the cluster list after being dynamically updated to identify the specialized agent cluster, wherein the cluster list includes cluster metadata describing cluster scope, associated domain areas, and coordination protocols for agent selection and task planning.

18. The system of claim 11, wherein the application performs operations further comprising: executing a central planning instruction by the cent al agent to generate, based on the application prompt, a multi-step workflow plan comprising sequential or parallel cluster prompts.PATENT APPLICATIONIS24. 1213-US-NP; SCH-166 76790219. The system of claim 11, wherein the application performs operations further comprising: executing a cluster planning instruction by the cluster agent to decompose the cluster prompt into a set of tasks, wherein each task of the set of tasks is assigned to a corresponding domain agent.

20. A non- transitory computer readable medium comprising instructions executable by a computer processor to perform: receiving an application prompt from an application; executing central instructions of a central agent, corresponding to the application, with a foundational model to process the application prompt, select a specialized agent cluster from a cluster list, and generate a cluster prompt for the specialized agent cluster; executing cluster instructions of a cluster agent, corresponding to the specialized agent cluster, with the foundational model to process the cluster prompt, select a domain agent from a domain agent list, and generate a domain prompt for the domain agent; executing domain instructions of the domain agent, with the foundational model, based on the domain prompt to perform one or more of accessing a data store and invoking a domain tool application to generate a domain response; processing the domain response using the cluster agent to generate a cluster response; processing the cluster response using the central agent to generate an application response; and transmitting the application response to the application, wherein the application response is presented by the application.

Images