Integrated generative artificial intelligence platform for energy applications

The integrated generative AI platform addresses contextual ambiguity and scalability issues by using an orchestration agent to unify data and model access, enhancing reliability and efficiency in complex decision-making environments.

WO2026060206A1PCT designated stage Publication Date: 2026-03-19SCHLUMBERGER TECH CORP +3
View PDF 5 Cites 0 Cited by

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-09-12
Publication Date
2026-03-19

AI Technical Summary

Technical Problem

Conventional artificial intelligence technologies face challenges with contextual ambiguity, scalability across heterogeneous data sources, maintaining interpretability in complex decision-making environments, and lack robustness in adapting to evolving linguistic patterns and semantic structures, leading to degraded performance and operational inefficiencies.

Method used

An integrated generative artificial intelligence platform with an orchestration agent that routes queries through a unified orchestration layer, providing access to private and public data stores and models, ensuring coherent task execution and traceable decision outputs by integrating retrieval and analysis operations.

Benefits of technology

The platform enhances reliability and applicability in dynamic, multi-agent environments by maintaining contextual alignment and semantic precision, improving scalability and operational efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2025046090_19032026_PF_FP_ABST
    Figure US2025046090_19032026_PF_FP_ABST
Patent Text Reader

Abstract

A method implements an integrated generative artificial intelligence platform. The method involves routing a query from an application to an orchestration agent corresponding to the application. The method involves executing a set of tasks with the orchestration agent based on the query using an orchestration layer as a single point of access to a private data store, a public data store, a private foundational model, and a public foundational model. The method involves executing a retrieval program to access the private data store and / or the public data store for a retrieval task using the orchestration layer to generate retrieval data. The method involves executing an analysis prompt to process the retrieval data with a foundational model accessed through a foundational model hub for an analysis task using the orchestration layer to generate an analysis response. The method involves transmitting a query response including the analysis response to the application.
Need to check novelty before this filing date? Find Prior Art

Description

IS24.1152-WO-PCTINTEGRATED GENERATIVE ARTIFICIAL INTELLIGENCE PLATFORM FOR ENERGY APPLICATIONSCROSS REFERENCE TO RELATED APPLICATIONS

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

[0002] Artificial intelligence (Al) technologies include foundational components for artificial intelligence systems to perceive, reason, learn, and interact. The technologies include machine learning algorithms, deep learning architectures, natural language processing (NLP), computer vision, and speech recognition. The technologies are built upon mathematical models, statistical inference, and large- scale data processing, allowing systems to extract patterns, make predictions, and adapt over time. Artificial intelligence also includes techniques for model training, optimization, and evaluation, as well as ethical and safety frameworks for responsible deployment.

[0003] Agentic artificial intelligence technologies focus on systems that exhibit autonomous decision-making, goal-directed behavior, adaptive planning, etc. The technologies include agents that may operate with a degree of independence. Components include various systems and architectures for multi-agent systems, cognitive architectures, memory and reasoning modules, tools for long-term planning and self-improvement, etc. Agentic artificial intelligence may integrate reinforcement learning, symbolic reasoning, and real-time feedback loops to simulate human-like agency and problem-solving capabilities. Agentic systems may be designed to collaborate and self-organized to be used in a variety of complex domains.80844624. v8 1IS24.1152-WO-PCTSUMMARY

[0004] In general, in one or more aspects, the disclosure relates to a method that implements an integrated generative artificial intelligence platform. The method involves routing a query from an application to an orchestration agent corresponding to the application. The method further involves executing a set of tasks with the orchestration agent based on the query using an orchestration layer as a single point of access to a private data store, a public data store, a private foundational model, and a public foundational model. The method further involves executing a retrieval program of the orchestration agent to access one or more of the private data store and the public data store for a retrieval task of the set of tasks using the orchestration layer to generate retrieval data. The method further involves executing an analysis prompt of the orchestration agent to process the retrieval data with one of the private foundational model and the public foundational model accessed through a foundational model hub for an analysis task of the set of tasks using the orchestration layer to generate an analysis response. The method further involves transmitting a query response including the analysis response to the application in response to the query.

[0005] 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 routing a query from an application to an orchestration agent corresponding to the application. Executing the application further performs executing a set of tasks with the orchestration agent based on the query using an orchestration layer as a single point of access to a private data store, a public data store, a private foundational model, and a public foundational model. Executing the application further performs executing a retrieval program of the orchestration agent to access one or more of the private data store and the public data store for a retrieval task of the set of tasks using the orchestration layer to generate retrieval data. Executing the application further80844624. v8 2IS24.1152-WO-PCT performs executing an analysis prompt of the orchestration agent to process the retrieval data with one of the private foundational model and the public foundational model accessed through a foundational model hub for an analysis task of the set of tasks using the orchestration layer to generate an analysis response. Executing the application further performs transmitting a query response including the analysis response to the application in response to the query.

[0006] 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 routing a query from an application to an orchestration agent corresponding to the application. Executing the instructions further performs executing a set of tasks with the orchestration agent based on the query using an orchestration layer as a single point of access to a private data store, a public data store, a private foundational model, and a public foundational model. Executing the instructions further performs executing a retrieval program of the orchestration agent to access one or more of the private data store and the public data store for a retrieval task of the set of tasks using the orchestration layer to generate retrieval data. Executing the instructions further performs executing an analysis prompt of the orchestration agent to process the retrieval data with one of the private foundational model and the public foundational model accessed through a foundational model hub for an analysis task of the set of tasks using the orchestration layer to generate an analysis response. Executing the instructions further performs transmitting a query response including the analysis response to the application in response to the query.

[0007] Other aspects of one or more embodiments may be apparent from the following description and the appended claims.80844624. v8 3IS24.1152-WO-PCTBRIEF DESCRIPTION OF DRAWINGS

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

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

[0010] FIG. 3, FIG. 4, FIG. 5, FIG. 6, FIG. 7, FIG. 8, FIG. 9, FIG. 10, and FIG. 11 show examples in accordance with the disclosure.

[0011] FIG. 12 shows a computing system in accordance with the disclosure.

[0012] 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

[0013] Embodiments of the disclosure implement integrated generative artificial intelligence platforms. Conventional artificial intelligence technologies may struggle with contextual ambiguity, scalability across heterogeneous data sources, maintaining interpretability in complex decision-making environments, etc. The limitations hinder the ability to extract actionable insights from unstructured documents, particularly when dealing with dynamic or domain-specific content. Existing systems may also lack robustness in adapting to evolving linguistic patterns and semantic structures, resulting in degraded performance over time.

[0014] Platform infrastructure technologies, while offering scalability and computational efficiency, frequently encounter bottlenecks in integrating diverse Al components into cohesive workflows. Fragmented toolchains and inconsistent data governance mechanisms contribute to operational inefficiencies and increased deployment complexity. Current infrastructure solutions may not adequately support fine-grained control over model behavior or facilitate transparent monitoring of autonomous processes.80844624. v8 4IS24.1152-WO-PCT

[0015] Agentic artificial intelligence technologies introduce additional challenges related to autonomous decision-making, long-term planning, and adaptive reasoning. The systems may use sophisticated coordination across multiple agents and environments, yet existing implementations may fall short in maintaining coherence, accountability, and traceability of agent actions. The absence of unified frameworks for memory management and symbolic reasoning further limits the applicability of agentic systems in high-stakes domains.

[0016] Agentic artificial intelligence systems face persistent limitations in maintaining coherence, accountability, and traceability across autonomous operations, particularly when coordinating multiple agents and interacting with diverse data environments. The limitations are compounded by the absence of unified frameworks for memory management and symbolic reasoning, which restrict the systems’ capacity for long-term planning and adaptive behavior in complex domains.

[0017] The claimed method may address the above challenges by implementing an orchestration agent that routes application queries through a unified orchestration layer, serving as a single point of access to foundational models and data sources. The architecture supports structured task execution, including retrieval and analysis operations, while maintaining consistent access pathways and modular control. By integrating private and public models and data stores through a foundational model hub, the method reinforces contextual alignment and semantic precision. The orchestration agent’s retrieval and analysis programs contribute to coherent task progression and traceable decision outputs, improving reliability and applicability in dynamic, multi-agent environments.

[0018] Turning to FIG. 1, a system includes several components that implement integrated generative artificial intelligence platforms. The components may be80844624. v8 5IS24.1152-WO-PCT implemented with and executed on computing systems, such as those described in FIG. 12.

[0019] The applications (102) are software components that interact with the orchestration layer (122) by generating the queries (105) and receiving the responses (108). The applications (102) may include embedded copilot functionalities within productivity platforms, enterprise systems, or domainspecific tools. The user interface components may support input capture, output rendering, and contextual interaction. The applications (102) may communicate with the orchestration agents (128) using standardized protocols and application programming interfaces (APIs). The applications (102) may be deployed in cloud- hosted, on-premises, or hybrid environments.

[0020] The queries (105) are structured data constructs transmitted from the applications (102) to the orchestration layer (122) to initiate task execution. The queries (105) may include natural language input, structured prompts, and taskspecific instructions. Metadata, such as session identifiers, user context, and application state may be included. The queries (105) are processed to determine task types, select the foundational models, and retrieve relevant data.

[0021] The responses (108) are structured outputs transmitted from the orchestration layer (122) to the applications (102) following task execution. The responses (108) may include natural language text, structured data, visualizations, summaries, and recommendations. Metadata such as task identifiers, confidence scores, and source references may be included in the responses (108). The responses (108) are formatted for compatibility with the application interfaces and used to complete workflows or support decision-making.

[0022] The orchestration layer (122) is a centralized system architecture that controls routing, execution, and coordination of the tasks (130) responsive to the queries (105). The orchestration layer (122) interfaces with the applications (102),80844624. v8 6IS24.1152-WO-PCT the foundational models, and the data sources. The orchestration layer (122) may include logic for interpreting query content, selecting the orchestration agents (128), and invoking the programs (131) and the prompts (132). The orche station layer (122) is a single point of access to the private data stores (135), the public data stores (138), the private foundational models (162), and the public foundational models (165).

[0023] The orchestration agents (128) are modular processing entities within the orchestration layer (122) that execute the tasks (130) responsive to the queries (105). One of the orchestration agents (128) may perform multiple tasks (130). The orchestration agents (128) interpret query content, decompose the queries (105) into executable tasks, and execute logic for retrieval, analysis, transformation, and summarization to generate the responses (108). Internal structures within the orchestration agents (128) may include the tasks (130), the programs (131), and the prompts (132). The orchestration agents (128) may be instantiated dynamically and configured to maintain task state, track execution progress, and generate structured outputs.

[0024] The tasks (130) are discrete operational units executed by the orchestration agents (128), which may be defined in a set of task instructions. The tasks (130) define operations such as retrieval, analysis, transformation, summarization, and classification. Metadata for execution tracking, dependency resolution, and output formatting may be included. One of the tasks (130) may utilize multiple programs (131) and multiple prompts (132) that may be performed in a specified order, which may be sequential or in parallel as defined the task. The tasks (130) may be organized into sequences or hierarchies and processed using internal logic and associated programs (131) and prompts (132).

[0025] The programs (131) are executable components executed by the orchestration agents (128) to perform operations defined by the tasks (130). The80844624. v8 7IS24.1152-WO-PCT programs (131) may include modular scripts, functions, or procedural logic. Parameters, execution rules, and control structures specify data access and processing. The programs (131) may be stored in repositories and versioned for traceability. The programs (131) may interact with the prompts (132), the foundational models (162), and the data sources to generate outputs used to form the response (108).

[0026] The prompts (132) are structured textual inputs generated by the orchestration agents (128) for interaction with the foundational models during task execution. The prompts (132) may include instructions, contextual data, constraints, and examples. Selection and composition of the prompts (132) may be based on queiy content, agent configuration, and model capabilities. Embedded variables and dynamically generated content in the prompts (132) may reflect task state and context. The prompts (132) may be stored in libraries and versioned for reproducibility.

[0027] The private data store (135) is a structured repository configured to retain user-specific, application-specific, and session-specific information. Storage may include structured records, unstructured documents, embeddings, metadata, logs, and configuration parameters. As an example, the private data store (135) may include energy data, which may include reservoir measurements, pressure readings, production rates, fluid composition logs, seismic results, drilling parameters, geospatial coordinates, and carbon intensity values, etc. The private data store (135) may utilize access control, encryption, and audit logging for confidentiality and traceability.

[0028] The public data store (138) is a structured repository configured to retain non-private, externally sourced, and publicly accessible information. Storage may include structured datasets, documents, embeddings, metadata, etc. The public data store (138) may utilize indexing and segmentation for efficient retrieval.80844624. v8 8IS24.1152-WO-PCT

[0029] The foundational model hub (152) is a centralized interface layer that controls access to foundational models, including the private foundational models (162) and the public foundational models (165). The foundational model hub (152) abstracts model access, organizes metadata, and coordinates selection across private and public repositories for the foundational models. The foundational model hub (152) may include logic for indexing, cataloging, and retrieving the foundational models.

[0030] The model registry (155) is a structured catalog maintained by the foundational model hub (152) to organize and reference available foundational models, including the private foundational models (162) and the public foundational models (165). Metadata within the model registry (155) may include version identifiers, performance metrics, domain applicability, input-output specifications, and operational constraints.

[0031] The private foundational models (162) are computational models maintained within private infrastructure and trained on proprietary datasets. Architectures may include transformer-based, autoregressive, and encoder-decoder structures. Invocation of the private foundational models (162) may be through the foundational model hub (152) using standardized protocols.

[0032] The public foundational models (165) are computational models maintained in publicly accessible infrastructure and trained on publicly available datasets. Architectures may include transformer-based, autoregressive, and encoderdecoder structures. Invocation of the private foundational models (162) may be through the foundational model hub (152) using standardized protocols.

[0033] FIG. 2 shows a flowchart of a method for implementing an integrated generative artificial intelligence platform. 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.80844624. v8 9IS24.1152-WO-PCTThe 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.

[0034] Turning to FIG. 2, the method (200) uses an orchestration agent to process a query and generate a query response. The process (200) may include multiple steps (e.g., Block 202 through Block 212) that may execute on the components described in the other figures, including those of FIG. 1 and FIG. 11.

[0035] Block 202 involves routing a query from an application to an orchestration agent corresponding to the application. To perform the routing, several distinct actions are executed, including identifying the application context, selecting the orchestration agent, preprocessing the query, executing routing logic, and enriching the query with contextual information. Each of the actions contributes to the accurate and efficient delivery of the query to the appropriate orchestration agent for further processing.

[0036] Identifying the application context includes extracting metadata from the query to determine the source and domain of the query. Metadata may include application identifiers, user roles, and domain types such as drilling, seismic, or production. The orchestration layer analyzes the metadata to determine the application type, such as Petrel assistant, simulation assistant, or wellbore analysis assistant. The determination enables the orchestration layer to select the orchestration agent that corresponds to the application type and domain. The80844624. v8 10IS24.1152-WO-PCT orchestration layer may use predefined mappings or classification logic to associate metadata with specific orchestration agents.

[0037] Selecting the orchestration agent includes matching the query to a domainspecific orchestration agent using a registry or mapping table. The orchestration layer may instantiate or activate the orchestration agent if the orchestration agent is not already running. Agent-specific configurations are loaded, including task templates, prompt formats, and model preferences. The configurations are retrieved from a configuration store or registry and applied to the orchestration agent to prepare the orchestration agent for task execution.

[0038] Preprocessing the query includes normalizing the query format for compatibility with downstream components. Normalization may involve converting natural language input into structured formats, such as javascript object notation (JSON) or extensible markup language (XML). The orchestration layer may tokenize and embed the query using embedding models to enable semantic matching with vector databases or prompt templates. Guardrails may be applied to sanitize or anonymize sensitive information contained in the queiy. Sanitization may include removing personally identifiable information or masking proprietary data.

[0039] Executing routing logic includes invoking routing functions within the orchestration layer to forward the query to the selected orchestration agent. The orchestration layer logs the routing event to maintain observability and traceability. Access control checks are applied to verify that the user and application are authorized to interact with the selected orchestration agent. Authorization may be determined using role-based access control or policy-based rules.

[0040] Contextual enrichment includes attaching session context to the query, such as previous queries, user preferences, and application state. Relevant data pointers80844624. v8 11IS24.1152-WO-PCT may be included, such as links to vector store entries or traditional database records. Prompt templates may be added from the prompt hub to guide the orchestration agent’s response generation. The orchestration layer compiles the contextual elements into a unified query package that forms an enriched query. The enriched query is then transmitted to the orchestration agent for task execution.

[0041] The process (200) may involve routing the query to the orchestration agent as a domain-specific agent to access the private data store and the private foundational model. To perform the routing, several actions may be executed, including identifying the domain context of the query, selecting the domainspecific orchestration agent, establishing access pathways to the private data store, establishing access pathways to the private foundational model, and verifying domain alignment across all components. Each action contributes to the delivery of the query to a domain-specific orchestration agent that is configured to interact with private resources in a secure and contextually appropriate manner.

[0042] Identifying the domain context of the query may include extracting domainspecific metadata such as application identifiers, operational parameters, user roles, and task descriptors. The orchestration layer analyzes the metadata using domain classification logic to determine whether the query pertains to a specialized domain such as drilling, seismic interpretation, reservoir modeling, or production optimization. The orchestration layer references a domain mapping table to associate the query with a corresponding domain-specific orchestration agent. The orchestration layer may also apply semantic filters or rule-based classifiers to refine the domain association.

[0043] Selecting the domain-specific orchestration agent may include referencing a registry of orchestration agents that are mapped to domain types. The orchestration layer activates the orchestration agent associated with the identified domain if the80844624. v8 12IS24.1152-WO-PCT orchestration agent is not already active. Domain-specific configurations are retrieved from a configuration store and applied to the orchestration agent to prepare the orchestration agent for task execution. Configurations may include prompt formats, model preferences, task templates, and access policies. The orchestration layer may also allocate compute resources and initialize runtime environments for the orchestration agent.

[0044] Establishing access pathways to the private data store may include retrieving access credentials, connection parameters, and data access policies associated with the domain-specific orchestration agent. The orchestration layer configures secure communication channels to the private data store using encrypted protocols such as transport layer security (TLS) and authenticated application programming interface (API) endpoints. The orchestration agent is granted scoped access to domain-relevant datasets stored in the private data store based on predefined access control rules. The orchestration layer may also perform data catalog lookups to identify relevant data assets and generate data pointers for query enrichment.

[0045] Establishing access pathways to the private foundational model may include selecting a foundational model from a model hub that is trained on domain-specific data. The orchestration layer retrieves model metadata from the model registry to confirm compatibility with the query and orchestration agent. The orchestration agent invokes the private foundational model using standardized interfaces such as representational state transfer (REST) or remote procedure calls (RPC) and passes domain-specific prompts for processing. Model invocation may include loading model weights, applying prompt templates, and configuring inference parameters. The orchestration layer may also apply model-specific guardrails to control output behavior and response formatting.80844624. v8 13IS24.1152-WO-PCT

[0046] Verifying domain alignment may include confirming that the query, orchestration agent, private data store, and private foundational model are each associated with the same domain classification. The orchestration layer performs consistency checks to validate that the selected components are interoperable and appropriate for the query. Validation may include schema matching, policy verification, and compatibility scoring. The orchestration agent proceeds with task execution after domain alignment is confirmed across the components.

[0047] Block 205 involves executing a set of tasks with the orchestration agent based on the quay using an orchestration layer as a single point of access to one or more of a private data store, a public data store, a private foundational model, and a public foundational model, in which executing the set of tasks may include executing a retrieval program and executing an analysis prompt. To perform the task execution, several actions may be executed, including interpreting the query to determine task specifications, selecting task execution pathways based on resource availability and domain alignment, invoking the orchestration agent to initiate task execution, accessing data and models through the orchestration layer as a unified interface, and generating and returning task outputs based on orchestration agent processing. Each action contributes to the coordinated execution of domain-specific tasks using a unified orchestration framework that integrates multiple data and model resources.

[0048] Interpreting the query to determine task specifications may include applying natural language processing and semantic parsing techniques to extract structured representations from the query. The orchestration layer analyzes the parsed query to identify task descriptors, domain indicators, data references, model references, and operational constraints. The extracted elements may be matched to predefined task templates stored in a task library within the orchestration layer. The orchestration layer may also apply rule-based logic or embedding-based similarity scoring to select the most appropriate task template for the query.80844624. v8 14IS24.1152-WO-PCT

[0049] Selecting task execution pathways based on resource availability and domain alignment may include evaluating the query context to determine whether private or public resources are to be utilized. The orchestration layer references access policies, domain mappings, and sensitivity classifications to identify eligible data stores and foundational models. Resource selection logic may prioritize private resources when domain-specific constraints, confidentiality specifications, or performance considerations are detected. Fallback mechanisms may be configured to allow use of public resources when private resources are unavailable or insufficient.

[0050] Invoking the orchestration agent to initiate task execution may include transmitting the enriched queiy and selected task template to the orchestration agent. The orchestration layer configures the orchestration agent with runtime parameters such as model selection, data access scope, execution priority, and output formatting rules. Task-specific modules within the orchestration agent are activated to perform subtasks such as data retrieval, model inference, and result aggregation. The orchestration layer may monitor execution progress and manage task state transitions during the execution lifecycle.

[0051] Accessing data and models through the orchestration layer as a unified interface may include routing data access requests to the appropriate private or public data store using secure APIs and credential management systems. Model invocation requests are routed to the selected private or public foundational model using standardized protocols such as REST or gRPC. The orchestration layer handles authentication, authorization, and protocol translation to enable seamless interaction with heterogeneous resources. Responses from data and model endpoints are aggregated into a unified result set for downstream processing by the orchestration agent.80844624. v8 15IS24.1152-WO-PCT

[0052] Generating and returning task outputs based on orchestration agent processing may include compiling intermediate results from data queries and model inferences. Post-processing logic is applied to the compiled results, including formatting, summarization, visualization, or transformation into application-specific output formats. The final output is returned to the application through the orchestration layer interface using a standardized response schema. The orchestration layer may also log the output event and update session context for future queries.

[0053] The process (200) may involve executing a simulation task of the set of tasks using a simulation agent invoked by the orchestration agent to operate a simulation tool through the orchestration layer and generate simulation data included in the queiy response. To perform the simulation task, several actions may be executed, including interpreting the query to determine simulation parameters, selecting the simulation agent and simulation tool, configuring the simulation environment through the orchestration layer, executing the simulation using the selected tool, and generating simulation data for inclusion in the query response. Each action contributes to the coordinated execution of a domain-specific simulation task using a unified orchestration framework that integrates simulation tools and computational resources.

[0054] Interpreting the query to determine simulation parameters may include applying semantic parsing and domain- specific language models to extract structured simulation descriptors. The orchestration layer analyzes the parsed query to identify simulation objectives, input variables, boundary conditions, and operational constraints. Extracted parameters are matched to simulation templates stored in a simulation task library. The orchestration layer may also apply rulebased logic or embedding-based similarity scoring to select the most appropriate simulation configuration.80844624. v8 16IS24.1152-WO-PCT

[0055] Selecting the simulation agent and simulation tool may include referencing a registry of simulation agents mapped to domain-specific simulation tools. The orchestration layer activates the simulation agent associated with the selected tool if the simulation agent is not already active. Tool-specific configurations are retrieved from a configuration store and applied to the simulation agent to prepare the simulation agent for task execution. Configurations may include solver settings, mesh parameters, time-step controls, and output formats. The orchestration layer may also allocate compute resources and initialize runtime environments for the simulation agent.

[0056] Configuring the simulation environment through the orchestration layer may include provisioning access to data inputs from private or public data stores. The orchestration layer establishes secure communication channels to the simulation tool using authenticated APIs and encrypted protocols. Simulation parameters are transmitted to the simulation agent along with data pointers and execution directives. The orchestration layer may also configure logging, monitoring, and checkpointing mechanisms to track simulation progress.

[0057] Executing the simulation using the selected tool may include invoking the simulation engine through the simulation agent with the configured parameters and input data. The simulation agent manages the execution lifecycle, including initialization, computation, and termination phases. Intermediate results may be stored in temporary buffers or streamed to the orchestration layer for real-time analysis. The orchestration layer may also apply runtime optimizations such as parallelization, caching, or adaptive refinement.

[0058] Generating simulation data for inclusion in the query response may include compiling output files, numerical results, and visualizations produced by the simulation tool. Post-processing logic is applied to format the simulation data according to application-specific specifications. The orchestration layer packages80844624. v8 17IS24.1152-WO-PCT the simulation data into a structured response format compatible with the application interface. The simulation data is transmitted to the application through the orchestration layer and may be logged for future reference or audit.

[0059] Block 208 involves executing a retrieval program of the orchestration agent to access one or more of the private data store and the public data store for a retrieval task of the set of tasks using the orchestration layer to generate retrieval data. To perform the retrieval task, several actions may be executed, including interpreting the query to identify retrieval objectives and data specifications, selecting the retrieval program and configuring the orchestration agent, establishing access to one or more of the private data store and public data store, executing the retrieval program through the orchestration layer, and preparing the retrieval data for foundational model processing. Each action contributes to the generation of structured and contextually enriched retrieval data that is compatible with downstream model processing workflows.

[0060] Interpreting the queiy to identify retrieval objectives and data specifications may include applying semantic parsing and domain- specific language models to extract structured descriptors from the query. The orchestration layer analyzes the parsed query to identify target entities, data types, temporal constraints, domain filters, and operational parameters. Extracted descriptors are matched to retrieval task templates stored in a retrieval task library within the orchestration layer. The orchestration layer may also apply rule-based logic or embedding-based similarity scoring to refine the selection of the retrieval task template.

[0061] Selecting the retrieval program and configuring the orchestration agent may include referencing a registry of retrieval programs mapped to domain-specific data access patterns. The orchestration layer activates the retrieval program associated with the identified domain if the retrieval program is not already active. Configuration parameters such as query templates, data schemas, access policies,80844624. v8 18IS24.1152-WO-PCT and filtering rules are retrieved from a configuration store. The orchestration layer applies the configuration parameters to the orchestration agent to prepare for execution of the retrieval task.

[0062] Establishing access to one or more of the private data store and public data store may include retrieving access credentials, connection parameters, and data access policies associated with the selected data sources. The orchestration layer configures secure communication channels to the data stores using encrypted protocols and authenticated endpoints. Access control rules are applied to scope the retrieval program to authorized datasets, data partitions, and query operations. The orchestration layer may also perform data catalog lookups to identify relevant data assets and generate data pointers for retrieval.

[0063] Executing the retrieval program through the orchestration layer may include transmitting the structured retrieval query to the orchestration agent along with contextual parameters and execution directives. The orchestration agent invokes the retrieval program to perform data lookups, filtering, and aggregation operations across the selected data stores. Retrieved data may be streamed or batched to the orchestration layer for further processing. The orchestration layer may also apply intermediate transformations, such as type casting, unit normalization, or schema alignment.

[0064] Preparing the retrieval data for foundational model processing may include applying post-processing logic to the retrieved data, including formatting, normalization, deduplication, summarization, and transformation. The orchestration layer structures the processed data according to input specifications utilized by the foundational model interface. Prompt templates, metadata, and contextual parameters are attached to guide the foundational model’s interpretation of the data. The prepared data package is transmitted to the foundational model through the orchestration layer for subsequent processing.80844624. v8 19IS24.1152-WO-PCT

[0065] The process (200) may involve logging, by the orchestration layer, access to the private data store and the public data store during execution of the retrieval program. To perform the logging, several actions may be executed, including initializing a logging context for the retrieval task, capturing access events during data store communication, applying access control metadata to each log entry, and storing log entries in a secure and queryable log repository. Each action contributes to the creation of a traceable and structured record of data access operations performed during retrieval program execution.

[0066] Initializing a logging context for the retrieval task may include generating a unique task identifier associated with the retrieval program execution. A logging session is created within the orchestration layer to capture access events related to interactions with data stores. Metadata, such as query identifiers, user roles, domain classifications, and timestamps are associated with the logging session. The orchestration layer may also allocate logging buffers and configure log formatting parameters.

[0067] Capturing access events during data store communication may include monitoring API calls, query executions, and data transfer operations initiated by the orchestration agent. Access details such as data store identifiers, accessed datasets, query parameters, and response statuses are recorded. Contextual information including access time, duration, and data volume is included in each log entry. The orchestration layer may also detect and log anomalies such as failed access attempts or latency spikes.

[0068] Applying access control metadata to each log entry may include annotating access events with attributes such as authorization level, policy scope, and credential source. Indicators of access type such as read-only, write-enabled, or restricted partition access are included. Access events are cross-referenced with policy definitions to support auditability and compliance tracking. The80844624. v8 20IS24.1152-WO-PCT orchestration layer may also tag log entries with domain-specific classifications for downstream analysis.

[0069] Storing log entries in a secure and queryable log repository may include transmitting structured log entries to a centralized logging service or distributed log store. Secure transmission protocols and authenticated endpoints are used to protect log integrity. Log entries are indexed by task identifier, data store, timestamp, and domain to support efficient retrieval and analysis. Retention schedules and encryption policies are applied according to data governance specifications.

[0070] Block 210 involves executing an analysis prompt of the orchestration agent to process the retrieval data with one of the private foundational model and the public foundational model accessed through a foundational model hub for an analysis task of the set of tasks using the orchestration layer to generate an analysis response. To perform the analysis task, several actions may be executed, including interpreting the query to identify analysis objectives and model specifications, selecting the analysis prompt and configuring the orchestration agent, accessing the foundational model through the foundational model hub, processing the retrieval data using the selected foundational model, and generating the analysis response for delivery to the application. Each action contributes to the structured execution of a domain-specific analysis task using foundational model capabilities integrated through the orchestration layer.

[0071] Interpreting the query to identify analysis objectives and model specifications may include applying semantic parsing and domain-specific language models to extract structured descriptors. The orchestration layer analyzes the parsed query to identify analytical goals, relevant data references, model preferences, and domain classifications. Extracted descriptors are matched to analysis task templates stored in the orchestration layer. The orchestration layer80844624. v8 21IS24.1152-WO-PCT may also apply rule-based logic or embedding-based similarity scoring to select the most appropriate analysis configuration.

[0072] Selecting the analysis prompt and configuring the orchestration agent may include referencing a prompt hub containing analysis prompts mapped to foundational models. The orchestration layer retrieves the selected analysis prompt along with configuration parameters such as input format, output structure, and model invocation settings. Configuration parameters are applied to the orchestration agent to prepare for model interaction. The orchestration layer may also allocate computational resources and initialize runtime environments for prompt execution.

[0073] Accessing the foundational model through the foundational model hub may include determining whether a private or public foundational model is appropriate based on domain classification and access policy. Model metadata is retrieved from the foundational model hub to confirm compatibility with the analysis prompt and retrieval data. Secure communication channels are established with the selected foundational model using standardized interfaces such as REST or gRPC. The orchestration layer may also configure model-specific guardrails and prompt formatting rules.

[0074] Processing the retrieval data using the selected foundational model may include transmitting the retrieval data and analysis prompt to the foundational model through the orchestration layer. Model-specific configurations such as token limits, temperature settings, and output constraints are applied. The foundational model performs analysis operations such as summarization, classification, prediction, or transformation based on the input data and prompt. Intermediate outputs may be streamed to the orchestration layer for monitoring or refinement.80844624. v8 22IS24.1152-WO-PCT

[0075] Generating the analysis response for delivery to the application may include compiling the output generated by the foundational model into a structured response format. Post-processing logic is applied to validate, format, and enrich the model output according to application specifications. The orchestration layer transmits the analysis response to the application using a standardized interface. The analysis event may also be logged for observability, traceability, and future reference.

[0076] The process (200) may involve invoking a validation agent by the orchestration agent to validate the analysis response prior to transmitting the query response. To perform the validation, several actions may be executed, including interpreting the analysis response to identify validation specifications, selecting the validation agent and configuring validation parameters, transmitting the analysis response to the validation agent through the orchestration layer, executing validation logic using the validation agent, and generating a validated output for transmission to the application. Each action contributes to the structured verification of the analysis response using domain-specific validation logic integrated through the orchestration framework.

[0077] Interpreting the analysis response to identify validation specifications may include applying semantic parsing and structural analysis to extract specific elements from the analysis response. The orchestration layer analyzes the extracted elements to identify domain classifications, output format indicators, logical structures, and compliance markers. Extracted elements are matched to validation templates stored in the orchestration layer. The orchestration layer may also apply rule-based logic or embedding-based similarity scoring to select the most appropriate validation configuration.

[0078] Selecting the validation agent and configuring validation parameters may include referencing a registry of validation agents mapped to domain-specific80844624. v8 23IS24.1152-WO-PCT validation tasks. The orchestration layer activates the validation agent associated with the analysis domain if the validation agent is not already active. Validation parameters such as rule sets, threshold values, output expectations, and audit flags are retrieved from a configuration store. The orchestration layer applies the validation parameters to the validation agent and may allocate computational resources for validation execution.

[0079] Transmitting the analysis response to the validation agent through the orchestration layer may include packaging the analysis response with contextual metadata such as query descriptors, domain indicators, and session identifiers. The orchestration layer sends the packaged data to the validation agent using secure and standardized communication protocols. Validation directives specifying the scope, depth, and method of validation are included in the transmission. The orchestration layer may also configure logging mechanisms to record validation events.

[0080] Executing validation logic using the validation agent may include performing rule-based, statistical, or model-assisted validation checks on the analysis response. The validation agent evaluates the response for accuracy, completeness, relevance, and compliance with domain-specific specifications. Validation results may include pass / fail indicators, error annotations, confidence scores, and exception flags. The orchestration layer may monitor validation progress and record validation outcomes for traceability.

[0081] Generating a validated output for transmission to the application may include compiling the validated analysis response along with validation metadata into a structured output format. Post- validation formatting and enrichment logic is applied based on application specifications. The orchestration layer transmits the validated output to the application using a standardized interface. The validation80844624. v8 24IS24.1152-WO-PCT event may also be logged in a secure repository for audit, observability, and future reference.

[0082] The process (200) may involve selecting, by the orchestration agent, the private foundational model to analyze the retrieval data and generate a private model response. To perform the model selection and analysis, several actions may be executed, including interpreting the retrieval data and query context to identify model selection specifications, referencing the foundational model registry to identify eligible private models, applying selection logic to finalize the private foundational model, analyzing the retrieval data using the selected private foundational model, and generating the private model response from the analyzed retrieval data. Each action contributes to the targeted execution of a domainspecific analysis using a private foundational model integrated through the orchestration layer.

[0083] Interpreting the retrieval data and query context to identify model selection specifications may include applying semantic parsing and domain-specific analysis to extract descriptors from the retrieval data and associated queiy. The orchestration layer analyzes the descriptors to identify domain classifications, analytical goals, data types, and performance constraints. The descriptors are matched to model selection templates stored in the orchestration layer. Rule-based logic or embedding-based similarity scoring may be applied to determine model selection parameters.

[0084] Referencing the foundational model registry to identify eligible private models may include accessing a registry of private foundational models indexed by domain, capability, and configuration metadata. Available models are filtered based on domain alignment, input compatibility, and access policy. Candidate models are ranked using scoring criteria such as relevance, latency, historical80844624. v8 25IS24.1152-WO-PCT performance, and compliance with organizational specifications. Models that do not meet minimum thresholds for accuracy or interpretability may be excluded.

[0085] Applying selection logic to finalize the private foundational model may include executing rule-based or embedding-based selection logic to identify the optimal model. The orchestration layer confirms that the selected model satisfies domain-specific constraints and application-level specifications. The orchestration agent is configured with the selected model’s parameters and prepared for model invocation. Computational resources may be allocated and runtime environments initialized for model execution.

[0086] Analyzing the retrieval data using the selected private foundational model may include transmitting the retrieval data and associated prompt to the selected model through the orchestration layer. Model-specific configurations such as input formatting, token limits, temperature settings, and output constraints are applied. The model performs analysis operations such as summarization, classification, prediction, or transformation based on the input data and prompt. Intermediate outputs may be sheamed to the orchestration layer for monitoring or refinement.

[0087] Generating the private model response from the analyzed retrieval data may include compiling the output generated by the private foundational model into a structured response format. Post-processing logic is applied to validate, format, and enrich the model output according to application specifications. The orchestration layer transmits the private model response to downstream components or the application using a standardized interface. The model response may also be logged for observability, traceability, and future reference.

[0088] The process (200) may involve selecting the public foundational model to process the private model response to generate the analysis response. To perform the model selection and processing, several actions may be executed, including interpreting the private model response and query context to identify processing80844624. v8 26IS24.1152-WO-PCT specifications, referencing the foundational model hub to identify eligible public models, applying selection logic to finalize the public foundational model, processing the private model response using the selected public foundational model, and generating the analysis response from the public model response. Each action contributes to the structured transformation of the private model response into a domain-refined analysis response using public foundational model capabilities integrated through the orchestration layer.

[0089] Interpreting the private model response and query context to identify processing specifications may include applying semantic parsing and structural analysis to extract descriptors from the private model response and associated query. The orchestration layer analyzes the descriptors to identify domain classifications, output formatting specifications, transformation goals, and model compatibility constraints. The descriptors are matched to processing templates stored in the orche station layer. Rule-based logic or embedding-based similarity scoring may be applied to determine processing parameters.

[0090] Referencing the foundational model hub to identify eligible public models may include accessing a registry of public foundational models indexed by domain, capability, and configuration metadata. Available models are filtered based on compatibility with the private model response, domain alignment, and access policy. Candidate models are ranked using scoring criteria such as relevance, latency, interpretability, and compliance with processing specifications. Models that do not meet minimum thresholds for contextual accuracy or output fidelity may be excluded.

[0091] Applying selection logic to finalize the public foundational model may include executing rule-based or embedding-based selection logic to identify the optimal public foundational model. The orchestration layer confirms that the selected model satisfies domain-specific constraints and application-level80844624. v8 27IS24.1152-WO-PCT specifications. The orchestration agent is configured with the selected model’s parameters and prepared for model invocation. Computational resources may be allocated and runtime environments initialized for model execution.

[0092] Processing the private model response using the selected public foundational model may include transmitting the private model response and associated prompt to the selected model through the orchestration layer. Model-specific configurations such as input formatting, token limits, temperature settings, and output constraints are applied. The model performs processing operations such as refinement, summarization, contextualization, or transformation based on the input data and prompt. A public model response is generated from the processed private model response.

[0093] Generating the analysis response from the public model response may include compiling the public model response into a structured analysis response format. Post-processing logic is applied to validate, format, and enrich the model output according to application specifications. The orchestration layer transmits the analysis response to downstream components or the application using a standardized interface. The processing event may also be logged for observability, traceability, and future reference.

[0094] The process (200) may involve executing a synthesis task of the set of tasks using a synthesis agent to combine the retrieval data and the analysis response into the query response. To perform the synthesis task, several actions may be executed, including preparing the synthesis context with retrieval data and analysis response, selecting the synthesis agent and configuring synthesis parameters, invoking the synthesis agent to perform data fusion, generating the query response from the synthesized output, and transmitting the query response to the application. Each action contributes to the structured integration of multiple data sources into a unified output using orchestration-driven synthesis logic.80844624. v8 28IS24.1152-WO-PCT

[0095] Preparing the synthesis context with retrieval data and analysis response may include aggregating structured outputs from the retrieval program and the foundational model. The orchestration layer aligns the data formats, normalizes schema representations, and applies domain-specific tagging. Metadata such as query identifiers, domain classifications, and task descriptors are attached to the synthesis context. The orchestration layer may also apply pre-synthesis filters to exclude irrelevant or redundant data elements.

[0096] Selecting the synthesis agent and configuring synthesis parameters may include referencing a registry of synthesis agents mapped to domain-specific fusion tasks. The orchestration layer activates the synthesis agent associated with the current domain if the synthesis agent is not already active. Synthesis parameters such as fusion-logic type, output format, confidence thresholds, and enrichment rules are retrieved from a configuration store. The orchestration layer applies the synthesis parameters to the synthesis agent and may allocate computational resources for synthesis execution.

[0097] Invoking the synthesis agent to perform data fusion may include transmitting the prepared synthesis context to the synthesis agent through the orchestration layer. The synthesis agent applies fusion logic such as rale-based merging, weighted aggregation, or model-assisted synthesis to combine the retrieval data and analysis response. Intermediate synthesis outputs may be generated and evaluated for consistency, completeness, domain alignment, etc. The orchestration layer may monitor synthesis progress and record synthesis events for traceability.

[0098] Generating the query response from the synthesized output may include compiling the final synthesis result into a structured response format. Postprocessing logic is applied to validate, format, and enrich the synthesized output according to application specifications. The orchestration layer may apply visualization templates, summary generators, or domain-specific annotations to80844624. v8 29IS24.1152-WO-PCT enhance the response. The query response is prepared for transmission using standardized schemas and interface protocols.

[0099] Transmitting the query response to the application may include sending the structured output through the orchestration layer using authenticated and encrypted channels. The orchestration layer may log the transmission event and update session context for future queries. The query response may also be stored in a response repository for audit, observability, and reuse.

[0100] The process (200) may involve executing a formatting task of the set of tasks using a formatting agent to structure the query response for display in the application. To perform the formatting task, several actions may be executed, including preparing the formatting context with the query response, selecting the formatting agent and configuring formatting parameters, invoking the formatting agent to apply structural transformations, generating the formatted output for application display, and transmitting the formatted output to the application interface. Each action contributes to the presentation of a structured and application-ready queiy response using formatting logic integrated through the orchestration layer.

[0101] Preparing the formatting context with the query response may include aggregating the synthesized output generated by the synthesis agent. The orchestration layer normalizes the data schema, applies domain-specific labels, and attaches metadata such as query identifiers, display targets, and formatting specifications. Formatting context may also include layout preferences, visualization directives, and user interface constraints retrieved from application configuration files. The orchestration layer may apply pre-formatting filters to remove extraneous content or harmonize data types.

[0102] Selecting the formatting agent and configuring formatting parameters may include referencing a registry of formatting agents mapped to application-specific80844624. v8 30IS24.1152-WO-PCT display requirements. The orchestration layer activates the formatting agent associated with the target application if the formatting agent is not already active. Formatting parameters such as layout templates, rendering styles, data grouping rules, and output formats are retrieved from a configuration store. The orchestration layer applies the formatting parameters to the formatting agent and may allocate rendering resources for formatting execution.

[0103] Invoking the formatting agent to apply structural transformations may include transmitting the prepared formatting context to the formatting agent through the orchestration layer. The formatting agent applies transformation logic such as hierarchical structuring, tabular arrangement, graphical embedding, or narrative sequencing. Intermediate formatting outputs may be evaluated for consistency, completeness, and alignment with application specifications. The orchestration layer may monitor formatting progress and record formatting events for traceability.

[0104] Generating the formatted output for application display may include compiling the transformed data into a structured output format compatible with the application interface. Post-formatting logic is applied to validate layout integrity, apply visual enhancements, and embed interactive elements. The orchestration layer may apply display-specific annotations, tooltips, or styling rules to enhance user comprehension. The formatted output is prepared for transmission using standardized schemas and rendering protocols.

[0105] Transmitting the formatted output to the application interface may include sending the structured display -ready content through the orchestration layer using authenticated and encrypted channels. The orchestration layer may log the transmission event and update session context for future display operations. The formatted output may also be stored in a presentation repository for audit, observability, and reuse.80844624. v8 31IS24.1152-WO-PCT

[0106] The process (200) may involve executing a model selection task of the set of tasks to identify the public foundational model from the foundational model hub based on the query. To perform the model selection task, several actions may be executed, including interpreting the query to identify model selection specifications, referencing the foundational model hub to identify eligible public models, retrieving model metadata and configuration parameters, applying selection logic to finalize the public foundational model, and registering the model selection event for traceability and downstream processing. Each action contributes to the identification of a suitable public foundational model for domain-specific analysis using orchestration-driven selection logic.

[0107] Interpreting the query to identify model selection specifications may include applying semantic parsing and domain-specific analysis to extract descriptors from the query. The orchestration layer analyzes the descriptors to identify analytical goals, domain classifications, input types, and performance constraints. Extracted descriptors are matched to model selection templates stored in the orchestration layer. Rule-based logic or embedding-based similarity scoring may be applied to determine model selection parameters.

[0108] Referencing the foundational model hub to identify eligible public models may include accessing a registry of public foundational models indexed by domain, capability, and configuration metadata. Available models are filtered based on domain alignment, input compatibility, and public access policy. Candidate models are ranked using scoring criteria such as relevance, latency, historical performance, and compliance with application specifications. Models that do not meet minimum thresholds for interpretability or operational reliability may be excluded.

[0109] Retrieving model metadata and configuration parameters may include accessing model metadata such as architecture type, supported input formats,80844624. v8 32IS24.1152-WO-PCT output structures, and operational limits. Configuration parameters such as token limits, temperature settings, prompt formatting rules, and output constraints are retrieved from a configuration store. Compatibility between the query context and the selected model’s input specifications is validated using schema matching and format verification logic. Model-specific guardrails and usage policies may also be retrieved and applied.

[0110] Applying selection logic to finalize the public foundational model may include executing rule-based or embedding-based selection logic to identify the optimal model. The orchestration layer confirms that the selected model satisfies domain-specific constraints and application-level specifications. The orchestration agent is configured with the selected model’s parameters and prepared for model invocation. Computational resources may be allocated and runtime environments initialized for model execution.

[0111] Registering the model selection event for traceability and downstream processing may include logging the model selection event with metadata such as model identifier, domain classification, queiy reference, and timestamp. The selected model is associated with the current task session to maintain continuity across orchestration operations. The orchestration layer updates the session context to reflect the selected model for subsequent invocation and response generation. The model selection event may also be recorded in a secure audit log for compliance and observability.

[0112] Block 212 involves transmitting a queiy response including the analysis response to the application responsive to the query. To perform the transmission, several actions may be executed, including preparing the query response for transmission, applying transmission protocols and security configurations, initiating transmission through the orchestration layer, logging the transmission event for observability and traceability, and updating session context to finalize80844624. v8 33IS24.1152-WO-PCT the response lifecycle. Each action contributes to the reliable and structured delivery of the query response using orchestration-managed communication pathways.

[0113] Preparing the query response for transmission may include aggregating the analysis response with any additional outputs such as retrieval data, synthesis results, or formatting elements. The orchestration layer normalizes the response structure to align with the application’s expected schema and interface specifications. Metadata such as query identifiers, session context, domain classification, and response type is attached to the response payload. Pretransmission validation may be applied to confirm completeness and structural integrity.

[0114] Applying transmission protocols and security configurations may include selecting communication protocols such as REST, gRPC, or WebSocket based on application integration specifications. Encryption settings, authentication tokens, and endpoint credentials are configured to protect data in transit. Transmission parameters are validated against access control policies and compliance specifications, defined in the orchestration layer. Secure routing logic may be applied to direct the response to the appropriate application endpoint.

[0115] Initiating transmission through the orchestration layer may include routing the query response to the application interface using the orchestration layer’s communication framework. Transmission status is monitored and mechanisms for retries, timeouts, or fallback routing are activated. Transmission metrics such as latency, payload size, and delivery confirmation are recorded. The orchestration layer may also trigger downstream workflows upon successful delivery.

[0116] Logging the transmission event for observability and traceability may include creating a log entry that captures transmission metadata such as timestamp, recipient endpoint, response type, and session reference. The log entry is annotated80844624. v8 34IS24.1152-WO-PCT with domain-specific tags and operational indicators to support downstream analysis. The log entry is stored in a secure and queryable repository for audit, monitoring, and compliance tracking. The orchestration layer may also generate alerts or reports based on transmission outcomes.

[0117] Updating session context to finalize the response lifecycle may include marking the query response as delivered within the orchestration layer’s session management system. Session records are updated to reflect completion of the response lifecycle and readiness for subsequent queries. Post-response workflows such as caching, archiving, or user notification may be triggered. The orchestration layer may also record session closure events for future reference.

[0118] The process (200) may involve collecting user feedback on the query response from the application to update the orchestration agent. A feedback collection interface may be initiated within the application by generating a feedback prompt that reflects the content and display specifications of the query response. Feedback options may be embedded into the interface, including rating scales, comment fields, selection menus, correction suggestions, etc. Metadata such as query identifiers, response type, and session context may be attached to the feedback interface for traceability and contextual relevance.

[0119] User feedback submitted through the application may be received and parsed by capturing both structured and unstructured data transmitted from the interface. Parsing logic may be applied to extract sentiment indicators, correction instructions, relevance scores, usability comments, etc. Feedback data formats may be normalized for compatibility with processing modules in the orchestration layer.

[0120] Validation and classification of feedback may be performed by applying rules that confirm authenticity, completeness, and relevance to the original query response. Feedback may be classified into categories such as accuracy, clarity,80844624. v8 35IS24.1152-WO-PCT completeness, formatting, domain alignment, etc. Domain-specific labels and operational flags may be tagged to feedback entries to facilitate targeted processing.

[0121] Orchestration agent parameters may be updated based on the classified feedback by modifying configurations such as prompt templates, model selection logic, formatting rules, response generation strategies, etc. Adjustments may be applied to task routing logic, domain mappings, and session context handling to reflect feedback-driven improvements. Updated parameters may be stored in the orchestration layer configuration registry to support future task executions.

[0122] The feedback event may be logged by recording metadata including timestamp, feedback type, queiy reference, agent update status, etc. The feedback log may be stored in a secure and queryable repository to support audit, monitoring, and continuous improvement. Session records may be updated to reflect feedback incorporation and readiness for subsequent queries.

[0123] Turning to FIG. 3 , the system (300) is an example of a generative Al platform that includes the application copilots (302), the generative Al infrastructure (312), and the domain foundational models (332). The system (300) may be used to create and execute intelligent workflows by coordinating user-facing copilots with orchestration logic, vector-based retrieval, foundational model access, and domain-specific model inference. The system (300) may perform task routing, data retrieval, prompt execution, and domain adaptation to generate responses tailored to energy sector applications.

[0124] The application copilots (302) are software interfaces that receive user inputs and transmit queries to the generative Al infrastructure (312). The application copilots (302) may be implemented as web applications, embedded assistants, or domain-specific user interfaces that operate within energy sector software systems. The application copilots (302) may include logic for formatting queries, managing80844624. v8 36IS24.1152-WO-PCT user sessions, and rendering responses received from the generative Al infrastructure (312). The application copilots (302) may transmit queries using standardized communication protocols and may receive structured outputs such as text, charts, visualizations, or recommendations.

[0125] The generative Al infrastructure (312) includes the orchestrator (315), the vector stores (318), and the foundational model hub (320). The orchestrator (315) is a coordination engine that operates as an orchestration layer to manage the flow of data and execution of tasks across the generative Al infrastructure (312). The orchestrator (315) may be implemented using orchestration frameworks such as LANGCHAIN® (which is a registered trademark of LangChain Inc., 2261 Market Street Suite 22961, San Francisco, CALIFORNIA, UNITED STATES 94114), LLM Mesh, etc., and may include logic for task decomposition, model selection, and prompt routing. The orchestrator (315) may receive queries from the application copilots (302) and determine the appropriate data sources and foundational models to invoke. The orchestrator (315) may transmit retrieval requests to the vector stores (318) and model invocation requests to the foundational model hub (320). The orchestrator (315) may also manage intermediate outputs, apply formatting logic, and transmit finalized responses to the application copilots (302).

[0126] The vector stores (318) are data repositories that store embeddings and enable semantic search operations. The vector stores (318) may be implemented using systems such as MILVUS® (which is a registered trademark of LF Projects, LLC, PMB 57274, 2810 N Church Street, Wilmington, DELAWARE, UNITED STATES 198024447) or PINECONE® (which is a registered trademark of Pinecone Systems, Inc., 1300 Note Dame Ave., Belmont, CALIFORNIA, UNITED STATES 94002) and may include logic for indexing, chunking, and similarity matching. The vector stores (318) may receive embedding queries from the orchestrator (315) and return relevant data chunks based on semantic80844624. v8 37IS24.1152-WO-PCT similarity. The vector stores (318) may store proprietary knowledge bases, technical documentation, operational records, and other domain-specific content in vectorized form. The vector stores (318) may interact with the foundational model hub (320) for contextual data for retrieval-augmented generation workflows.

[0127] The foundational model hub (320) is a centralized interface layer that manages access to foundational models used for content generation. The foundational model hub (320) may include publicly available models such as large language models, and may also include proprietary models hosted within the domain foundational models (332). The foundational model hub (320) may receive prompt execution requests from the orchestrator (315) and return generated outputs based on model inference. The foundational model hub (320) may include logic for model registration, versioning, performance tracking, and access control. The foundational model hub (320) may transmit model outputs to the orchestrator (315) for further processing and response synthesis.

[0128] The domain foundational models (332) are specialized models trained on domain-specific data relevant to the energy sector. The domain foundational models (332) may include log foundational models, seismic foundational models, and domain language models tailored to subsurface analysis, well log interpretation, and energy-specific terminology. The domain foundational models (332) may be accessed through the foundational model hub (320) and may be invoked by the orchestrator (315) for tasks utilizing domain expertise. The domain foundational models (332) may receive structured prompts and contextual data and return outputs such as anomaly detection results, data imputations, and scenario simulations. The domain foundational models (332) may be hosted within secure infrastructure and may include logic for model fine-tuning, adaptive learning, and compliance with energy industry specifications.80844624. v8 38IS24.1152-WO-PCT

[0129] The application copilots (302) are bidirectionally connected to the generative Al infrastructure (312) to transmit queries and receive responses. The orchestrator (315) is bidirectionally connected to the vector stores (318) and the foundational model hub (320) to coordinate data retrieval and model invocation. The vector stores (318) and the foundational model hub (320) are bidirectionally connected to enable retrieval-augmented generation workflows. The foundational model hub (320) is bidirectionally connected to the domain foundational models (332) to access specialized models for domain-specific tasks.

[0130] Turning to FIG. 4, the system (400) is an example of a generative Al platform that includes the domain application (402), the orchestration system (412), the prompt hub (415), the foundational model hub (418), the domain vector store (422), the observability system (425), the guardrail system (428), the foundation models (430), and the data pipelines (452). The system (400) may be used to construct and execute domain-specific generative Al workflows by coordinating user interfaces, orchestration logic, prompt management, model deployment, data ingestion, and monitoring components. The system (400) may perform workflow management, model invocation, prompt routing, embedding generation, semantic search, operational monitoring, and security filtering across interconnected software systems.

[0131] The domain application (402) is a software interface that contains logic and interacts with the orchestration system (412) to initiate generative Al tasks. The domain application (402) may be implemented using frameworks such as STREAMLIT® (which is a registered trademark of STREAMLIT LLC, 777 OAK STREET, SAN FRANCISCO, CALIFORNIA, UNITED STATES 94030) or DATAIKU® (which is a registered trademark of DATAIKU, SAS, 902 Broadway, 8th Floor, New York, NEW YORK, UNITED STATES 10010) and may include logic for user input handling, prompt selection, and result visualization. The domain application (402) may transmit prompt requests to the prompt hub (415)80844624. v8 39IS24.1152-WO-PCT and query requests to the orchestration system (412). The domain application (402) may also initiate fine-tuning workflows by transmitting model adaptation requests to the orchestration system (412). The domain application (402) may receive generated results from the orchestration system (412) and render outputs for user consumption.

[0132] The orchestration system (412) is a software system that operates as an orchestration layer using orchestration agents to manage generative Al workflows including fine-tuning, retrieval-augmented generation, embedding, generation, chat, caching, etc. The orchestration system (412) may receive queries and finetuning requests from the domain application (402) and determine the appropriate components to invoke. The orchestration system (412) may transmit prompt execution requests to the foundation models (430) and embedding requests to the domain vector store (422). The orchestration system (412) may retrieve prompt templates from the prompt hub (415) and deployment details from the foundational model hub (418). The orchestration system (412) may transmit generated results to the domain application (402) and the prompt hub (415). The orchestration system (412) may also transmit operational data to the observability system (425) and security-related data to the guardrail system (428).

[0133] The prompt hub (415) is a software system that manages prompt templates and implements a user interface for experimentation. The prompt hub (415) may receive prompt requests from the domain application (402) and transmit query requests to the orchestration system (412). The prompt hub (415) may retrieve deployment metadata from the foundational model hub (418) to assist in prompt selection and formatting. The prompt hub (415) may transmit prompt templates to the orchestration system (412) for execution and may receive generated results for display and analysis.80844624. v8 40IS24.1152-WO-PCT

[0134] The foundational model hub (418) is a software system that manages and deploys foundational models and embedding models. The foundational model hub (418) may onboard customer-specific foundational models and maintain deployment metadata. The foundational model hub provides a uniform interface to access multiple models. The foundational model hub (418) may receive deployment queries from the prompt hub (415) and the data pipelines (452). The foundational model hub (418) may transmit deployment details to the orchestration system (412) to facilitate model invocation and workflow execution.

[0135] The domain vector store (422) is a software system that performs preprocessing, embedding, chunking, indexing, and semantic searching. The domain vector store (422) may receive ingestion data from the data pipelines (452) and generate embeddings for storage and retrieval. The domain vector store (422) may receive embedding requests from the orchestration system (412) and return relevant data chunks based on semantic similarity. The domain vector store (422) may store domain- specific content such as technical documentation, operational records, and proprietary datasets.

[0136] The observability system (425) is a software system that may implement logging, tracing, and monitoring of orchestration workflows and model interactions. The observability system (425) may receive operational data from the orchestration system (412) and generate metrics, alerts, and audit trails. The observability system (425) may include logic for performance tracking, error detection, and compliance reporting.

[0137] The guardrail system (428) is a software system that performs prompt injection protection, anonymization, and deanonymization of sensitive data. The guardrail system (428) may receive prompt and query data from the orchestration system (412) and apply security filters and data transformation logic. The guardrail80844624. v8 41IS24.1152-WO-PCT system (428) may include rule-based and machine learning-based mechanisms for detecting and mitigating unsafe or non-compliant inputs.

[0138] The foundation models (430) are software systems used for inference and generation. The foundation models (430) may receive prompt execution requests from the orchestration system (412) and return generated outputs based on model inference. The foundation models (430) may include public models, proprietary models, and customer-specific models hosted within the foundational model hub (418).

[0139] The data pipelines (452) are software systems that ingest and transmit unstructured data to the domain vector store (422) for embedding and indexing. The data pipelines (452) may be implemented using systems such as AIRFLOW® (which is a registered trademark of Airosmith, Inc., 318 West Avenue, Saratoga Springs, NEW YORK, UNITED STATES 12866) or DATAIKU®’ and may include logic for data extraction, transformation, and loading. The data pipelines (452) may also transmit deployment queries to the foundational model hub (418) to retrieve model metadata for processing workflows.

[0140] The domain application (402) is connected to the prompt hub (415) to retrieve prompt templates. The domain application (402) is connected to the orchestration system (412) to transmit queries and fine-tuning requests and receive results. The orchestration system (412) is connected to the domain application (402), the prompt hub (415), the observability system (425), the guardrail system (428), and the foundation models (430). The prompt hub (415) is connected to the orchestration system (412) and the foundational model hub (418). The foundational model hub (418) is connected to the orchestration system (412) and the data pipelines (452). The domain vector store (422) is connected to the orchestration system (412) and the data pipelines (452).80844624. v8 42IS24.1152-WO-PCT

[0141] Turning to FIG. 5, the system (500) is an example of a system used to manage the lifecycle of machine learning models by coordinating the model registry (502), the model tools (505), the data stores (508), the model environments (510), and the model metrics (512). The system (500) may perform model registration, development, execution, and performance tracking across interconnected components. The system (500) may maintain authoritative records of model versions, facilitate model creation and deployment, deliver access to training and evaluation datasets, execute models in controlled runtime contexts, and quantify model performance for optimization workflows.

[0142] The model registry (502) is a centralized repository configured to store metadata, versioning information, and lifecycle attributes for machine learning models. The model registry (502) may include logic for model registration, update tracking, lineage management, and access control. The model registry (502) may transmit model metadata to the model tools (505), the data stores (508), and the model environments (510). The model registry (502) may receive updates from the model tools (505) and performance data derived from the model metrics (512).

[0143] The model tools (505) are software utilities configured to assist in model development, testing, packaging, and deployment. The model tools (505) may include interfaces for code editing, training configuration, hyperparameter tuning, and model export. The model tools (505) may retrieve model metadata from the model registry (502) and transmit updated model artifacts for registration. The model tools (505) may also interact with the model environments (510) to deploy models for execution and testing.

[0144] The data stores (508) are repositories configured to store training data, evaluation datasets, and other structured or unstructured data used in model workflows. The data stores (508) may include logic for data versioning, access control, and schema validation. The data stores (508) may transmit dataset80844624. v8 43IS24.1152-WO-PCT references to the model registry (502) and deliver data access to the model environments ( 10) during training and inference. The data stores (508) may also receive queries from the model tools (505) for data exploration and preprocessing.

[0145] The model environments (510) are execution platforms configured to run machine learning models using defined runtime configurations. The model environments (510) may include containers, virtual machines, or managed runtime systems with pre-installed dependencies. The model environments (510) may retrieve model artifacts and metadata from the model registry (502) and execute models using data from the data stores (508). The model environments (510) may generate the model metrics (512) based on model behavior, accuracy, latency, throughput, and other operational characteristics.

[0146] The model metrics (512) are quantitative indicators that measure the performance of models during training, evaluation, and production execution. The model metrics (512) may include values such as precision, recall, Fl score, loss, accuracy, inference time, and resource utilization. The model metrics (512) may be computed by the model environments (510) and transmitted to the model registry (502) for lifecycle tracking and optimization. The model metrics (512) may be referenced by the model tools (505) to guide decisions for model selection, tuning, retraining, etc.

[0147] The model registry (502) is connected to the model tools (505), the data stores (508), the model environments (510), and the model metrics (512). The model tools (505), the data stores (508), and the model environments (510) each interact with the model registry (502) to exchange metadata, artifacts, and performance data. The model environments (510) generate the model metrics (512) and transmit the model metrics (512) to the model registry (502) and the model tools (505).80844624. v8 44IS24.1152-WO-PCT

[0148] Turning to FIG. 6, the system (600) is an example of a system used to coordinate domain-specific agents and data sources for intelligent production workflows by integrating the main production agent (602), the data agent (612), the subject matter expert agent (615), the simulator agent (618), the public data store (622), the private data store (625), the real-time sensors (627), the historical data (628), the shared memory (635), the modeling tools (658), and the user feedback performance rating (682). The system (600) may be used to implement an orchestration agent, where the main production agent (602) may be implemented as the orchestration agent of an orchestration layer. The orchestration agent may manage task delegation, agent coordination, and result synthesis across the system (600). The system (600) may perform intelligent production tasks by coordinating specialized agents, retrieving and transforming data, executing domain-specific simulations, and incorporating user feedback.

[0149] The main production agent (602) may transmit task requests to the data agent (612), the subject matter expert agent (615), and the simulator agent (618). The main production agent (602) may receive performance ratings from the user feedback performance rating (682) and may use the ratings to adjust agent selection and workflow parameters.

[0150] The data agent (612) is configured to retrieve, transform, and transmit data from multiple sources including the public data store (622), the private data store (625), the real-time sensors (627), and the historical data (628). The data agent (612) may interact with the shared memory (635) to store and retrieve intermediate data representations. The data agent (612) may transmit data to the subject matter expert agent (615) for interpretation and to the simulator agent (618) for modeling input. The data agent (612) may exchange domain-specific knowledge with the subject matter expert agent (615) to refine data selection and contextual relevance.80844624. v8 45IS24.1152-WO-PCT

[0151] The subject matter expert agent (615) is configured to interpret domainspecific data, apply expert logic, and generate insights based on structured and unstructured inputs. The subject matter expert agent (615) may receive data from the data agent (612) and may transmit enriched data or domain annotations to the simulator agent (618). The subject matter expert agent (615) may interact with the shared memory (635) to store domain interpretations and retrieve contextual information. The subject matter expert agent (615) may exchange modeling parameters with the simulator agent (618) to guide simulation workflows.

[0152] The simulator agent (618) is configured to perform computational modeling tasks using domain-specific tools such as the flow modeling tools (660) and the electromechanical modeling tool (662). The simulator agent (618) may receive enriched data and modeling parameters from the subject matter expert agent (615) and the data agent (612). The simulator agent (618) may interact with the shared memory (635) to store simulation inputs and retrieve historical modeling results. The simulator agent (618) may invoke the flow modeling tools (660) and the electromechanical modeling tool (662) to perform simulations and generate predictive outputs.

[0153] The public data store (622) and the private data store (625) are repositories configured to store structured and unstructured data relevant to production workflows. The public data store (622) may contain open datasets, regulatory information, and third-party benchmarks. The private data store (625) may contain proprietary datasets, operational records, and internal documentation. The data agent (612) may retrieve data from the public data store (622) and the private data store (625) based on query specifications and workflow context.

[0154] The real-time sensors (627) are configured to transmit live operational data such as temperature, pressure, flow rate, and equipment status. The historical data (628) may include archived sensor readings, production logs, and simulation80844624. v8 46IS24.1152-WO-PCT results. The data agent (612) may retrieve data from the real-time sensors (627) and the historical data (628) to construct time-series inputs and trend analyses.

[0155] The shared memory (635) is a data exchange layer configured to store intermediate results, contextual metadata, and agent-generated outputs. The shared memory (635) may be accessed by the data agent (612), the subject matter expert agent (615), and the simulator agent (618) to coordinate data flow and maintain state across workflows.

[0156] The modeling tools (658) include the flow modeling tools (660) and the electromechanical modeling tool (662). The flow modeling tools (660) may be used to simulate fluid dynamics, pipeline behavior, and reservoir performance. The electromechanical modeling tool (662) may be used to simulate equipment behavior, electrical systems, and mechanical interactions. The simulator agent (618) may invoke the flow modeling tools (660) and the electromechanical modeling tool (662) to generate predictive outputs based on domain-specific inputs.

[0157] The user feedback performance rating (682) is configured to collect user evaluations of system outputs and agent performance. The user feedback performance rating (682) may transmit ratings to the main production agent (602) to influence agent selection, workflow tuning, and output prioritization.

[0158] The main production agent (602) is connected to the data agent (612), the subject matter expert agent (615), the simulator agent (618), and the user feedback performance rating (682). The data agent (612) is connected to the public data store (622), the private data store (625), the real-time sensors (627), the historical data (628), and the shared memory (635). The subject matter expert agent (615) is connected to the shared memory (635) and the simulator agent (618). The simulator agent (618) is connected to the shared memoiy (635), the flow modeling tools (660), and the electromechanical modeling tool (662).80844624. v8 47IS24.1152-WO-PCT

[0159] Turning to FIG. 7, an example of a workflow (700) for intelligent production decision-making that may be performed with a set of steps. The workflow (700) may be implemented as part of an orchestration layer by a system that performs data acquisition, domain-specific analysis, simulation modeling, optimization logic, recommendation synthesis, and user evaluation in a structured sequence. The workflow (700) may transform raw operational data into actionable insights through coordinated processing stages.

[0160] The data collection step (702) gathers relevant data from sources such as realtime sensors, historical databases, external feeds, etc., by extracting, transforming, and normalizing the data using ingestion pipelines, schema mapping, and statistical preprocessing techniques to generate a structured dataset. The structured dataset may contain time-series measurements, categorical labels, noimalized values, etc., that are aligned with domain specifications.

[0161] The analysis step (705) applies domain-specific logic to the structured dataset by classifying, filtering, and enriching the data using rule-based systems, statistical models, reference datasets, etc., to generate interpreted data. The interpreted data may include annotated features, derived metrics, contextual relationships, etc., that reflect meaningful patterns and anomalies.

[0162] The simulation step (708) executes computational models using the interpreted data by applying numerical solvers, predictive algorithms, scenario evaluation techniques, etc., such as parameter sweeps or probabilistic simulations to generate simulation results. The simulation results may represent modeled system behavior under varying operational conditions and may include predicted outputs, performance curves, scenario comparisons, etc.

[0163] The optimization step (710) applies optimization logic to the simulation results by evaluating constraints, scoring performance, selecting configurations, etc., using mathematical programming, heuristic search, or rule-based decision80844624. v8 48IS24.1152-WO-PCT logic to generate optimized outputs. The optimized outputs may identify actions, settings, or strategies based on defined objectives and operational goals.

[0164] The recommendation generation step (712) synthesizes actionable recommendations from the optimized outputs by formatting, prioritizing, contextualizing, etc., the results using display logic, ranking algorithms, expert templates, etc., to generate a set of recommendations. The recommendations may include structured guidance, visual summaries, domain-specific instructions, etc., tailored to user roles.

[0165] The user review and feedback step (715) collects evaluations of the recommendations by capturing ratings, comments, feedback, etc., using interactive interfaces, form fields, and logging mechanisms to generate user input. The user input may include numerical scores, qualitative remarks, and structured feedback used to refine future iterations of the workflow (700).

[0166] Turning to FIG. 8, the workflow (800) is an example of a structured orchestration process for intelligent energy task execution using modular agents and domain-specific foundational models. The workflow (800) begins with the energy task (802), which represents a user-submitted query or operational objective related to energy exploration, production, or analysis. The energy task (802) is received by the task decomposition engine (805), which parses the task into discrete subtasks by applying rule-based logic, semantic parsing techniques, and domain-specific templates. The subtasks are routed to the dynamic model selection (808), which evaluates the nature of each subtask and selects appropriate foundational models based on domain relevance, input specifications, computational specifications, etc.

[0167] The selected subtasks proceed to the task execution (810), where execution logic coordinates the retrieval and processing of data. The task execution (810) routes subtasks to the agent store (822), which includes the subsurface assistant80844624. v8 49IS24.1152-WO-PCT(825), the wellbore assistant (828), the simulation assistant (830), etc. Each assistant within the agent store (822) executes domain-specific programs to retrieve relevant data from structured data stores, sensor feeds, historical repositories, etc., using query logic, data access protocols, and transformation routines. The retrieved data is routed to the domain foundational models (852), which include the seismic foundational model (855), the log foundational model (858), the language model for energy (860), etc. The foundational models processes the data using trained neural architectures, statistical inference methods, and domain-specific embeddings to generate analytical outputs such as anomaly maps, interpreted logs, predictive simulations, etc.

[0168] The outputs from the domain foundational models (852) and the agent store (822) are routed to the result aggregation and analysis (882). The result aggregation and analysis (882) combines the outputs using fusion algorithms, comparative metrics, and contextual alignment techniques to generate a unified result set. The unified result set includes synthesized insights, performance comparisons, and structured visualizations aligned with the original task specifications.

[0169] The finalized output (885) is generated from the result aggregation and analysis (882). The finalized output (885) formats the results using display logic, domain-specific templates, and ranking algorithms to produce a structured recommendation. The structured recommendation includes visual summaries, operational guidance, and prioritized actions tailored to the energy domain.

[0170] The user feedback (888) captures evaluations of the finalized output (885) using interactive interfaces, comment fields, and rating mechanisms. The user feedback (888) is routed to the task decomposition engine (805) to refine future task parsing, improve model selection accuracy, and enhance agent coordination.80844624. v8 50IS24.1152-WO-PCTThe feedback loop supports iterative improvement of the workflow (800) by incorporating user input into subsequent executions.

[0171] Turning to FIG. 9, the system (900) is an example architecture for executing domain-specific queries using a generative Al copilot integrated with orchestrated model and data infrastructure. The system (900) includes the application copilot (902), the generative Al infrastructure (922), and the domain foundational models (972). The application copilot (902) receives a user query (905) that specifies a domain-specific analytical task. The user query (905) includes a request to identify the most common reasons for stuck pipe incidents in wells drilled by a specific company and to use a drilling database to generate an accurate distribution of contributing factors.

[0172] The application copilot (902) transmits the user query (905) to the generative Al infrastructure (922). The generative Al infrastructure (922) includes the orchestrator (932), the data stores (952), and the foundational model hub (962). The orchestrator (932) parses the user query (905) using semantic analysis, task decomposition logic, and routing protocols to determine the appropriate data sources and model capabilities. The orchestrator (932) initiates data retrieval operations by querying the data stores (952). The data stores (952) include vector databases and traditional relational databases that store structured and unstructured drilling data. The data stores (952) are accessed using an embedding-based search, scripted query language (SQL) queries, and schema-aware retrieval logic to extract relevant records associated with stuck pipe incidents.

[0173] The retrieved data is transmitted to the foundational model hub (962). The foundational model hub (962) is used to access public foundational models, and private foundational models, including the domain foundational models (972). The public foundational models and private foundational models may include general- purpose language models and models that are trained or fine-tuned for energy-80844624. v8 51IS24.1152-WO-PCT specific domains. The foundational model hub (962) coordinates access to the domain foundational models (972) using model selection logic, API routing, and context-aware invocation protocols.

[0174] The domain foundational models (972) process the retrieved data using classification logic, distribution modeling, and causal inference techniques to identify contributing factors and quantify the relative impact. The domain foundational models (972) may include public models and private models that are trained or fine-tuned using domain- specific corpora, structured datasets, and operational metadata. The domain foundational models (972) generate analytical outputs such as ranked factor distributions, annotated summaries, and visual representations.

[0175] The processed results are transmitted back to the application copilot (902). The application copilot (902) formats the output (988) using visual summarization logic, chart generation routines, and domain-specific templates. The output (988) includes a pie chart showing the distribution of contributing factors, with differential sticking identified as the highest contributor at 36%, followed by tight hole at 25%, other mechanisms at 21%, and hole cleaning at 18%. The output (988) is presented to the user through the application copilot (902) interface.

[0176] Turning to FIG. 10, the system (1000) is an example generative Al architecture for retrieving and presenting geoscientific data in response to a domain-specific user query. The system (1000) includes the application copilot (1002), the generative Al infrastructure (1022), and the domain foundational models (1072). The application copilot (1002) includes the user query (1005) and the generated output (1088). The generative Al infrastructure (1022) includes the orchestrator (1032), the data stores (1052), and the foundational model hub (1062).

[0177] The application copilot (1002) receives the user query (1005), which includes a request to display a well log and seismic section through one of the anomalous80844624. v8 52IS24.1152-WO-PCT zones in the well closest to a planned well. The user query (1005) includes spatial and geological specifications that define the scope and relevance of the requested data. The application copilot (1002) transmits the user query (1005) to the generative Al infrastructure (1022) for processing.

[0178] The orchestrator (1032) receives the user query (1005) and performs semantic decomposition and spatial reasoning to identify relevant data sources and model pathways. The orchestrator (1032) applies parsing logic, spatial filters, and task routing rules to determine which data stores and models are appropriate for the query. The orchestrator (1032) initiates data retrieval by issuing structured queries to the data stores (1052).

[0179] The data stores (1052) include vector databases and traditional databases that contain structured geoscientific data such as well logs, seismic volumes, and anomaly annotations. The data stores (1052) are queried using embedding-based similarity search, spatial indexing, and schema-aware query logic to locate the well closest to the planned well and identify associated anomalous zones. The retrieved data includes well log records, seismic slices, and metadata aligned with the spatial and geological parameters of the user query (1005).

[0180] The retrieved data is routed to the foundational model hub (1062), which manages access to public and private foundational models. The foundational model hub (1062) includes model selection logic, API routing mechanisms, and context-aware invocation protocols. The foundational model hub (1062) coordinates access to the domain foundational models (1072) based on the content and structure of the retrieved data.

[0181] The domain foundational models (1072) receive the retrieved data and apply spatial correlation logic, geological pattern recognition, and visualization synthesis techniques. The domain foundational models (1072) process the data to generate80844624. v8 53IS24.1152-WO-PCT outputs such as seismic sections, well log curves, and annotated cross-sections that satisfy the specifications of the user query (1005).

[0182] The processed outputs are transmitted from the domain foundational models (1072) to the application copilot (1002). The application copilot (1002) formats the generated output (1088) using domain-specific visualization templates and display logic. The generated output (1088) includes a seismic section and well logs from the identified project area and is presented to the user through the application copilot (1002) interface.

[0183] Turning to Fig. 11, an example method 1100 is illustrated that may be implemented by the systems and methods described in the other figures. The method 1100 uses a generative Al platform to respond to an input.

[0184] At 1102, the method 1100 includes receiving, at a generative artificial intelligence (Al) platform, an input for the energy sector.

[0185] At 1104, the method 1100 includes accessing, by the generative Al platform, data from data sources to use in responding to the input. The data may be energy data and the data sources may include energy data sources, such as ProSource® (of Schlumberger Technology Corporation MD 23, 300 Schlumberger Drive, Sugar Land, TEXAS UNITED STATES 77478) and OSDU® (of The Open Group Limited, Apex Tower, Forbury Road, Reading Berkshire UNITED KINGDOM RG11AZ).

[0186] At 1106, the method 1100 includes accessing, by the generative Al platform, foundational models to generate content using the data.

[0187] At 1108, the method 1100 includes generating, by the generative Al platform, a response to the input using the data and the foundational models.

[0188] At 1110, the method 1100 includes displaying, on a display, the response to the input.80844624. v8 54IS24.1152-WO-PCT

[0189] Turning to Fig. 12 components are illustrated that may be included within a computer system (1200). One or more computer systems (1200) may be used to implement the various methods, devices, components, and / or systems described herein.

[0190] The computer system (1200) includes a processor (1201). The processor (1201) 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 graphics processing unit (GPU), a microcontroller, a programmable gate array, etc. The processor (1201) may be referred to as a central processing unit (CPU). Although just a single processor (1201) is shown in the computer system (1200) of Fig. 12, in an alternative configuration, a combination of processors (e.g., an ARM and DSP) could be used.

[0191] The computer system (1200) also includes memory (1203) in electronic communication with the processor (1201). The memory (1203) may be any electronic component capable of storing electronic information. For example, the memory (1203) may be embodied as random access memory (RAM), read-only memory (ROM), magnetic disk storage mediums, optical storage mediums, 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) memory, registers, and so forth, including combinations thereof.

[0192] Instructions (1205) and data (1207) maybe stored in the memory (1203). The instructions (1205) may be executable by the processor (1201) to implement some or all of the functionality disclosed herein. Executing the instructions (1205) may involve the use of the data (1207) that is stored in the memory (1203). Any of the various examples of modules and components described herein may be80844624. v8 55IS24.1152-WO-PCT implemented, partially or wholly, as instructions (1205) stored in memory (1203) and executed by the processor (1201). Any of the various examples of data described herein may be among the data (1207) that is stored in memory (1203) and used during execution of the instructions (1205) by the processor (1201).

[0193] A computer system (1200) may also include one or more communication interfaces (1209) for communicating with other electronic devices. The communication interface(s) (1209) may be based on wired communication technology, wireless communication technology, or both. Some examples of communication interfaces (1209) 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) 802.11 wireless communication protocol, a Bluetooth wireless communication adapter, and an infrared (IR) communication port.

[0194] A computer system (1200) may also include one or more input devices (1211) and one or more output devices (1213). Some examples of input devices (1211) include a keyboard, mouse, microphone, remote control device, button, joystick, trackball, touchpad, and light pen. Some examples of output devices (1213) include a speaker and a printer. One specific type of output device that is typically included in a computer system (1200) is a display device (1215). Display devices (1215) 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 (1217) may also be provided, for converting data (1207) stored in the memory (1203) into text, graphics, and / or moving images (as appropriate) shown on the display device (1215).

[0195] The various components of the computer system (1200) may be coupled together by one or more buses, which may include a power bus, a control signal80844624. v8 56IS24.1152-WO-PCT bus, a status signal bus, a data bus, etc. For the sake of clarity, the various buses are illustrated in Fig. 12 as a bus system (1219).

[0196] In some implementations, the various components of the computer system (1200) are implemented as one device. For example, the various components of the computer system (1200) are implemented in a mobile phone or tablet. Another example includes the various components of the computer system (1200) implemented in a personal computer. Another example includes the various components of the computer system (1200) implemented in the cloud. Another example includes the various components of the computer system (1200) implemented on an edge device.

[0197] As illustrated in the foregoing discussion, the present disclosure utilizes a variety of terms to describe features and advantages of the model evaluation system. Additional detail is now provided regarding the meaning of such terms. For example, as used herein, a “machine learning model” refers to a computer algorithm or model (e.g., a classification model, a clustering model, a regression model, a language model, an object detection model, a probabilistic graphical model) that can be tuned e.g., trained) based on training input to approximate unknown functions. For example, a machine learning model may refer to a neural network (e.g, a convolutional neural network (CNN), deep neural network (DNN), recunent neural network (RNN), generative adversarial networks (GANs)), or other machine learning algorithm or architecture that learns and approximates complex functions and generates outputs based on a plurality of inputs provided to the machine learning model. As used herein, a “machine learning system” may refer to one or multiple machine learning models that cooperatively generate one or more outputs based on corresponding inputs. For example, a machine learning system may refer to any system architecture having multiple discrete machine learning components that consider different kinds of information or inputs.80844624. v8 57IS24.1152-WO-PCT

[0198] The techniques described herein may be implemented in hardware, software, firmware, or any combination thereof, unless specifically described as being implemented in a specific manner. Any features described as modules, components, or the like may also be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be realized at least in part by a non-transitory processor-readable storage medium comprising instructions that, when executed by at least one processor, perform one or more of the methods described herein. The instructions may be organized into routines, programs, objects, components, data structures, etc., which may perform particular tasks and / or implement particular data types, and which may be combined or distributed as desired in various implementations.

[0199] Computer-readable mediums may be any available media that can be accessed by a general purpose or special purpose computer system. Computer- readable mediums that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable mediums that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, implementations of the disclosure can comprise at least two distinctly different kinds of computer-readable mediums: non-transitory computer-readable storage media (devices) and transmission media.

[0200] As used herein, non-transitory computer-readable storage mediums (devices) may include RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g., based on RAM), Flash memory, phase-change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.80844624. v8 58IS24.1152-WO-PCT

[0201] 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.

[0202] 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.

[0203] 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.

[0204] 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” may include any combination of the items with any number of each item, unless expressly stated otherwise.

[0205] 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 practiced80844624. v8 59IS24.1152-WO-PCT 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.80844624. v8 60

Claims

IS24.1152-WO-PCTCLAIMSWhat is claimed is:

1. A method comprising: routing a query from an application to an orchestration agent corresponding to the application; executing a set of tasks with the orchestration agent based on the query using an orchestration layer as a single point of access to a private data store, a public data store, a private foundational model, and a public foundational model, wherein executing the set of tasks comprises: executing a retrieval program of the orchestration agent to access one or more of the private data store and the public data store for a retrieval task of the set of tasks using the orchestration layer to generate retrieval data, and executing an analysis prompt of the orchestration agent to process the retrieval data with one of the private foundational model and the public foundational model accessed through a foundational model hub for an analysis task of the set of tasks using the orchestration layer to generate an analysis response; and transmitting a query response comprising the analysis response to the application responsive to the query.

2. The method of claim 1, further comprising: executing a simulation task of the set of tasks using a simulation agent invoked by the orchestration agent to operate a simulation tool through the orchestration layer and generate simulation data included in the query response.

3. The method of claim 1, further comprising: routing the query to the orchestration agent as a domain-specific agent to access the private data store and the private foundational model.80844624. v8 61IS24.1152-WO-PCT4. The method of claim 1, further comprising: invoking a validation agent by the orchestration agent to validate the analysis response prior to transmitting the query response.

5. The method of claim 1, further comprising: logging, by the orchestration layer, access to the private data store and the public data store during execution of the retrieval program.

6. The method of claim 1, further comprising: selecting, by the orchestration agent, the private foundational model to analyze the retrieval data and generate a private model response; and selecting the public foundational model to process the private model response to generate the analysis response.

7. The method of claim 1, further comprising: executing a synthesis task of the set of tasks using a synthesis agent to combine the retrieval data and the analysis response into the query response.

8. The method of claim 1, further comprising: executing a formatting task of the set of tasks using a formatting agent to structure the query response for display in the application.

9. The method of claim 1, further comprising: collecting user feedback on the query response from the application to update the orchestration agent.

10. The method of claim 1, further comprising: executing a model selection task of the set of tasks to identify the public foundational model from the foundational model hub based on the query.80844624. v8 62IS24.1152-WO-PCT11. A system comprising: a computer processor; and an application that, when executing on the computer processor, performs operations comprising: routing a query from an application to an orchestration agent corresponding to the application, executing a set of tasks with the orchestration agent based on the query using an orchestration layer as a single point of access to a private data store, a public data store, a private foundational model, and a public foundational model, wherein executing the set of tasks comprises: executing a retrieval program of the orchestration agent to access one or more of the private data store and the public data store for a retrieval task of the set of tasks using the orchestration layer to generate retrieval data, and executing an analysis prompt of the orchestration agent to process the retrieval data with one of the private foundational model and the public foundational model accessed through a foundational model hub for an analysis task of the set of tasks using the orchestration layer to generate an analysis response, and transmitting a query response comprising the analysis response to the application responsive to the query.

12. The system of claim 11, wherein the application performs operations further comprising: executing a simulation task of the set of tasks using a simulation agent invoked by the orchestration agent to operate a simulation tool through the orchestration layer and generate simulation data included in the query response.80844624. v8 63IS24.1152-WO-PCT13. The system of claim 11, wherein the application performs operations further comprising: routing the queiy to the orchestration agent as a domain-specific agent to access the private data store and the private foundational model.

14. The system of claim 11, wherein the application performs operations further comprising: invoking a validation agent by the orchestration agent to validate the analysis response prior to transmitting the query response.

15. The system of claim 11, wherein the application performs operations further comprising: logging, by the orchestration layer, access to the private data store and the public data store during execution of the retrieval program.

16. The system of claim 11, wherein the application performs operations further comprising: selecting, by the orchestration agent, the private foundational model to analyze the retrieval data and generate a private model response; and selecting the public foundational model to process the private model response to generate the analysis response.

17. The system of claim 11, wherein the application performs operations further comprising: executing a synthesis task of the set of tasks using a synthesis agent to combine the retrieval data and the analysis response into the query response.80844624. v8 64IS24.1152-WO-PCT18. The system of claim 11, wherein the application performs operations further comprising: executing a formatting task of the set of tasks using a formatting agent to structure the query response for display in the application.

19. The system of claim 11, wherein the application performs operations further comprising: collecting user feedback on the query response from the application to update the orchestration agent.

20. A non-transitory computer-readable medium comprising instructions executable by a computer processor to perform: routing a query from an application to an orchestration agent corresponding to the application; executing a set of tasks with the orchestration agent based on the query using an orchestration layer as a single point of access to a private data store, a public data store, a private foundational model, and a public foundational model, wherein executing the set of tasks comprises: executing a retrieval program of the orchestration agent to access one or more of the private data store and the public data store for a retrieval task of the set of tasks using the orchestration layer to generate retrieval data, and executing an analysis prompt of the orchestration agent to process the retrieval data with one of the private foundational model and the public foundational model accessed through a foundational model hub for an analysis task of the set of tasks using the orchestration layer to generate an analysis response; and transmitting a queiy response comprising the analysis response to the application responsive to the query.80844624. v8 65

Citation Information

Patent Citations

  • Bot network orchestration to provide enriched service request responses

    US20190044829A1

  • Enhancing agent's efficiency in a contact center by using a multi-agent to multi-contact routing orchestration

    US20220103689A1

  • Conversational large language model-based user tenant orchestration

    US20240296177A1

  • Multi-omics based techniques for product target discovery

    WO2023238042A1

  • Enterprise generative artificial intelligence architecture

    WO2024130219A1