Agent health scoring for agent-based automation

Abstract

This disclosure relates to agent health scoring for agent-based automation. A method is provided. The method is performed by a hyperautomation system that performs agent-based automation. The hyperautomation system includes memory for storing agent-based automation and for generating agent health scores. The hyperautomation system includes at least one processor that executes computer code to cause the method to optimize agent-based automation. The method includes generating a set of standardized metrics for application to the agent performing agent-based automation. The method includes performing an evaluation on the agent performing agent-based automation, which determines performance metrics by measuring success rate, error frequency, and execution efficiency across different use cases or business processes. The method includes comparing performance metrics for the agent across different use cases or business processes. The method includes generating an agent health score based on comparing performance metrics and an agent health score definition.

Description

Cross-references to related applications

[0001] This application claims priority to IN application No. 202511035107, filed April 10, 2025; IN application No. 202511035224, filed April 10, 2025; and IN application No. 202511035258, filed April 10, 2025, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0002] This invention generally relates to agency automation, and more specifically, to agency health scoring for agency automation. Background Technology

[0003] Conventional automation technologies have problems and flaws. For example, these problems and flaws may include the illusion of automation, a lack of standardized metrics for assessing the readiness of automated production, difficulty in comparing automation performance across different use cases, insufficient visibility into runtime behavior and inadequate early detection of potential problems, complex compliance and security requirements for automation decision-making processes, and limited ability to measure and optimize the impact of automation on business outcomes.

[0004] Therefore, improved and / or alternative methods may be beneficial. Summary of the Invention

[0005] Certain embodiments of the present invention may provide alternatives or solutions to problems and needs that have not yet been fully identified, understood, or resolved by the prior art, and / or provide useful alternatives. For example, some embodiments of the present invention relate to agent-based automation with feedback operations for completing verification, agent accuracy assessment, and agent health score generation.

[0006] According to one or more embodiments, a method is provided. The method is performed by a hyperautomation system that performs one or more agent-based automata. The hyperautomation system includes memory for storing the one or more agent-based automata and for generating agent health scores. The hyperautomation system includes at least one processor that executes computer code to cause the method to optimize the one or more agent-based automata. The method includes generating a set of standardized metrics to apply to agents performing the one or more agent-based automata. The method includes performing an evaluation on the agents performing the one or more agent-based automata, the evaluation determining performance metrics by measuring success rate, error frequency, and execution efficiency of two or more different use cases or business processes. The method includes comparing performance metrics for the agent between two or more different use cases or business processes. The method includes generating one or more agent health scores based on comparing performance metrics and one or more agent health score definitions.

[0007] According to one or more embodiments, a method is provided. The method is performed by a hyperautomation system that performs one or more agent-based automata. The hyperautomation system includes a memory storing computer code for the one or more agent-based automata, for one or more evaluation sets, and for generating and enhancing agent health scores. The hyperautomation system includes at least one processor that executes the computer code to cause the method to refine and improve the one or more evaluation sets over time. The method includes determining whether an evaluation set in the one or more evaluation sets is acceptable for the agent. The method includes: when the evaluation set is determined to be acceptable, performing the evaluation set on the agent. The method includes: when the evaluation set is determined to be unacceptable, iteratively improving the evaluation set for the agent through sufficiency determination or health score evaluation until the evaluation set is acceptable.

[0008] According to one or more embodiments, a method is provided. The method is performed by a hyperautomation system that performs one or more agent-based automations. The hyperautomation system includes a memory storing computer code for the one or more agent-based automations, for one or more evaluation sets, and for generating and enhancing evaluation scores. The hyperautomation system includes at least one processor that executes the computer code to cause the method to refine and improve the one or more evaluation sets over time. The method includes determining whether an evaluation set in the one or more evaluation sets is acceptable for the agent. The method includes running the evaluation sets in the one or more evaluation sets on the agent. The method includes generating evaluation scores based on the running of the evaluation sets. The method includes: marking the agent as production-ready when the evaluation scores are determined to be acceptable; the method includes: when the evaluation scores are determined to be unacceptable, iteratively: performing multi-touch attribution to assign which factors led to the low evaluation scores, determining optimizations for these factors, and implementing these optimizations and rerunning the evaluation sets until the evaluation scores are acceptable.

[0009] According to one or more embodiments, the method can be implemented as a system, computer program product, device, etc. Attached Figure Description

[0010] To facilitate understanding of the advantages of certain embodiments of the invention, a more specific description of the invention, which has been briefly described above, will be presented with reference to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only exemplary embodiments of the invention and should not be construed as limiting its scope. The invention will be described and explained with additional features and details using the drawings, wherein:

[0011] Figure 1 This is an architectural diagram illustrating a hyperautomation system configured to perform intelligent agent-style automation and orchestration according to one or more embodiments.

[0012] Figure 2 The illustration shows some combined capabilities of artificial intelligence (AI) agents and robotic process automation (RPA) robots according to one or more embodiments.

[0013] Figure 3 The illustration depicts a pool of AI agents, RPA robots, agent orchestration processes (AOP), and applications according to one or more embodiments.

[0014] Figure 4 The illustration shows an example AI agent service interface according to one or more embodiments.

[0015] Figure 5The illustration shows an example AOP development interface according to one or more embodiments.

[0016] Figure 6 The illustration shows an example RPA development interface according to one or more embodiments.

[0017] Figure 7 The illustration depicts an end-to-end AI agent, RPA robot, and AOP development and deployment system according to one or more embodiments.

[0018] Figure 8 This is an architecture diagram of an intelligent human automation and RPA system according to one or more embodiments.

[0019] Figure 9 This is an illustration of the architecture of a deployed RPA system according to one or more embodiments.

[0020] Figure 10 This is an architecture diagram illustrating the relationships between designers, activities, and drivers according to one or more embodiments.

[0021] Figure 11 This is an architectural diagram illustrating a computing system configured to perform intelligent agent-based automation and orchestration according to one or more embodiments.

[0022] Figure 12A The illustration shows an example of a neural network that has been trained to perform intelligent agent automation and orchestration according to one or more embodiments.

[0023] Figure 12B An example of a neuron according to one or more embodiments is illustrated.

[0024] Figure 13 This is an architecture diagram illustrating a reference architecture of a generative AI model according to one or more embodiments.

[0025] Figure 14 This is a flowchart illustrating a process for training one or more AI / ML models according to one or more embodiments.

[0026] Figure 15 This is a flowchart illustrating a process according to one or more embodiments.

[0027] Figure 16 This is a flowchart illustrating a process according to one or more embodiments.

[0028] Unless otherwise stated, similar reference numerals in all figures always denote corresponding features. Detailed Implementation

[0029] The disclosure in this article relates to intelligent body automation, and more specifically, to agent health scoring for intelligent body automation.

[0030] According to one or more embodiments, a hyperautomation system performs agent-based automation, including feedback operations with completion verification, agent accuracy assessment, and agent health score generation. The feedback operation with completion verification of the hyperautomation system may include real-time feedback loop performance checks on agents performing actions or tasks within a workflow and their corresponding outputs. The agent accuracy assessment of the hyperautomation system may include evaluating the quality, efficiency, and effectiveness of agents performing actions or tasks within the workflow and their corresponding outputs using prompts and / or agent patterns from a valid tracking dataset. The agent health score generation of the hyperautomation system may include defining and calculating the agent health score based on the performance, reliability, compliance, and business impact of agents performing actions or tasks within the workflow and their corresponding outputs. Based on one or more advantages, technical effects, and benefits, the agent health score (with completion verification and agent accuracy assessment) aims to address the challenges of conventional automation technologies by providing a comprehensive, standardized metric reflecting the overall health and readiness of agents.

[0031] Feedback operations that generate completion verification, agent accuracy assessment, and agent health scores can leverage context grouding and output or proactively implement suggestions, enabling agent-based automation to handle complex automation scenarios. Therefore, feedback operations that generate completion verification, agent accuracy assessment, and agent health scores provide control over agent-based automation to achieve the following technical effects, benefits, and advantages: avoiding limiting agent-based automation to robotic process automation (RPA) operations and preventing illusions created by the Large Language Model (LLM) or other AI models used in agent-based automation. Thus, feedback operations that generate completion verification, agent accuracy assessment, and agent health scores in hyperautomation systems create more intelligent and context-aware hyperautomation systems and improve the overall computational resource performance and efficiency of hyperautomation systems.

[0032] Figure 1This is an architectural diagram illustrating a hyperautomation system 100 configured to perform agent-based automation and orchestration according to one or more embodiments. As used herein, “hyperautomation” refers to an automation system that combines components of process automation, agent-based automation, integrated tools, and technologies that enhance the capabilities of automation. Examples of components include, but are not limited to, artificial intelligence (AI) agents, agent orchestration (AOP), and robotic process automation (RPA) robots.

[0033] Generally, as used herein, an "AI agent" is an AI-enhanced probabilistic automation that involves independent, dynamic, decision-making, executive, and adaptive actions. In some cases, AI agents operate accordingly due to the use of large language models (LLMs) or other AI models, which are typically probabilistic in nature. According to one or more embodiments, and as described herein, one or more AI agents may implement context-based technologies (e.g., retrieval augmented generation (RAG), extraction, and semantic storage), advanced agent search (semantic search and retrieval, hybrid search, and broad search with reordering), tethering (including autotethering), and query decomposition.

[0034] Generally speaking, as used in this article, "AOP" combines probabilistic and deterministic approaches into dynamic and predictable automation. In some cases, AOP is automation that allows users to describe entire business processes. Users are, but are not limited to, anyone with access to the system performing the automation (e.g., developers, engineers, customers, etc.). AOP can be created using interfaces that allow the creation of business process diagrams, which are described in a Business Process Model and Symbol (BPMN), a Business Process Model and Symbol that is an Extensible Markup Language (XML) description of the business process (e.g., see [link to relevant documentation]). Figure 5 ).

[0035] Generally speaking, as used in this article, "RPA robot" is a rule-based deterministic automation that acts predictably and makes deterministic decisions.

[0036] For example, in some embodiments, one or more RPAs can be used at the core of the hyperautomation system, and in others, automation capabilities can be extended through AI / machine learning (ML), process mining, analytics, agent-based automation, and / or other advanced tools. For instance, as the hyperautomation system learns processes, trains AI / ML models, and employs analytics, more and more knowledge work can be automated, and computing systems within an organization, such as personally used and autonomously running systems, can participate in the hyperautomation process. Some embodiments of the hyperautomation system allow users and organizations to efficiently and effectively discover, understand, and scale automation.

[0037] In this type of implementation, AI agents coexist in series with RPA robots that perform RPA and AOP. As mentioned in this paper, AI agents are automated, enhanced with AI skills, and can act independently, make dynamic decisions, perform actions, and adapt to their performance. AI agents can dynamically utilize tools available through these RPA robots to perform document processing (e.g., see U.S. Patent Application Publication No. 2021 / 0097274), user interface (UI) automation (e.g., see U.S. Patent Nos. 10,654,166, 10,990,876, 11,080,548, 11,507,259, 11,733,668, and 11,748,069), semantic copying and pasting between source and target (e.g., see U.S. Patent No. 12,124,806 and U.S. Patent Application Publications Nos. 2023 / 0107316, 2023 / 0415338, and 2024 / 0220581), etc. The AI ​​agent can dynamically select these tools and execute them in a pipeline.

[0038] Generally, intelligent agent automation is probabilistic automation performed by one or more AI agents. It focuses not only on individual tasks but also on the entire end-to-end process, thus expanding an organization's automation potential. AI agent-guided RPA bots and / or AOP teams can enable one employee to do the work of many. Intelligent agent automation, enabled by AI agents and / or AOP, provides managers with guidance space, doctors with more time to care for patients, developers with the ability to fine-tune their work, engineers with the freedom to innovate, and customers with seamless, personalized experiences.

[0039] Various technical effects, benefits, and advantages can be achieved through intelligent agent automation. Intelligent agent automation improves memory utilization by reducing data storage requirements and processor efficiency by reducing the number of calls and actions. Intelligent agent automation also potentially provides the ability to process gigabytes, terabytes, petabytes, or more of data, which is impossible with human-implemented processes, whether mental or manual. Intelligent agent automation also potentially uses fewer triggers and models through dynamic decision support. While conventional software automation itself may require one hundred (100) actions in the example scenario, intelligent agent automation can significantly reduce the required actions (e.g., to fifteen (15) actions) in the same example scenario. Intelligent agent automation can also improve the efficiency of LLM or AI models by employing a context-based approach that tethers AI agents to desired contexts that “constrain” LLM or AI models to relevant contexts.

[0040] AI agents can possess agency memory, which evolves and stores user interactions, feedback, corrections, and solutions (e.g., dynamic and / or direct user input from human-in-the-loop operations). As used herein, human-in-the-loop operations, or "human-in-the-loop," can include AI agents and RPA robots that collaborate with users to receive dynamic and / or direct user input. As agency memory grows, AI agents can become increasingly autonomous, reducing their reliance on dynamic and / or direct user input and increasing efficiency. AI agents can also learn more effectively based on agency memory if more efficient solutions are contained within or derived from it. For example, AI agents can periodically process agency memory to analyze patterns for greater autonomy.

[0041] As used in this article, an "intelligent agent memory" is a dynamic cache (i.e., storage) system for managing upgrades and tool calls. Through an example operation, when an AI agent encounters a problem at runtime, it can prompt or otherwise request one or more user interactions or feedback regarding overcoming the problem, store / cachise one or more of these interactions or feedback, and learn from them to reduce the need for repetitive user input. Based on one or more technical effects, benefits, and advantages, intelligent agent memories provide enhanced efficiency by storing solutions to common problems and minimizing potentially costly tool calls. The collaborative operation of the AI ​​agent and intelligent agent memory has a potentially "bent curve," meaning that as the AI ​​agent learns continuously via the intelligent agent memory, the need for user interaction decreases.

[0042] Generally, agent orchestration is implemented by an orchestrator application to implement one or more AOPs and / or AI agents, thereby orchestrating AI agents (e.g., UiPath Agents™), third-party agents, RPA bots (e.g., UiPath Robots™), AOPs, and users performing workflows (e.g., if user interaction is required or requested). Agent orchestration supports agent-based automation, modeling, and monitoring of complex business processes from start to finish. Agent orchestration also provides unique capabilities to orchestrate RPA bots, AI agents, AOPs, third-party agents, and users across end-to-end workflows. Agent orchestration contributes to the successful scaling of agent-based automation.

[0043] AI agents for agent-based automation are based on AI models, as discussed in this paper, enabling them to work independently of the user and implement these agent-based automata. AI agents are also goal-oriented, using context for probabilistic decision-making. Furthermore, AI agents are well-suited for specialized tasks requiring high adaptability. AI agents learn how tasks are performed and improve over time. AI agents can use and select various tools to complete tasks, gather context, and take actions (typically via RPA bots used by the AI ​​agent). In some embodiments, AI agents can build workflows and generate automations for execution by RPA bots and / or other AI agents, such as by leveraging UiPath Autopilot™ for developers or another application that helps developers accelerate the creation and testing of agent-based automations. For example, an AI agent can leverage a designer application via API to generate another AI agent or RPA bot to perform a part of a workflow and to escalate workflow issues by triggering actions in a human-machine loop. If correct, the workflow can deploy the AI ​​agent. AI agents can also have varying degrees of autonomy, which is managed by agent orchestration.

[0044] By executing "agent loops," AI agents generate dynamic plans to achieve goals according to instructions, using provided tools and context. Once a dynamic plan is generated, the AI ​​agent utilizes its efficient execution path. If a dynamic plan has two or more steps that can be executed in parallel, the AI ​​agent will execute these two or more steps in parallel based on available resources. After each step is completed, the AI ​​agent retrieves the output of that step and regenerates the next one or more steps. Thus, the agent loop continues until the goal is achieved. The parallel execution of dynamic plan steps and the use of ecosystem tools and contextual foundations are advanced capabilities of agent orchestration.

[0045] As described in this article, RPA bots are rule-based automations whose actions are predictable and who make deterministic decisions. RPA bots are highly reliable and efficient, making them well-suited for performing routine tasks. Both RPA bots and AI agents can manage anomalies using actions within a human-machine loop. According to one or more embodiments, AI agents are more flexible, abstract, and capricious than RPA bots and AOPs. Furthermore, RPA bots are more stable, concrete, and easier to manage than AI agents and AOPs. Additionally, AOP processes fall between the flexibility / stability, abstraction / concreteness, and capriciousness / controllability of AI agents and RPA bots, respectively.

[0046] As this article is about Figure 3Furthermore, AI agents, AOP, and RPA bots can potentially find and use each other as tools to accomplish tasks. AI agents, AOP, and RPA bots can also access and use various applications (e.g., via application programming interfaces (APIs)). Tools can be manually configured by developers for automation, and / or AI agents and RPA bots can discover and use tools at runtime.

[0047] According to some embodiments, AI agents, AOPs, and RPA robots can work collaboratively with users (e.g., in human-robot loops), enabling them to make faster, more consistent, and more informed decisions. Furthermore, the use of AI agents, AOPs, and RPA robots allows users to accomplish more tasks because they can take on additional repetitive, mundane, and special tasks on a scale impossible for humans to perform. Users can make decisions when AI agents, AOPs, or RPA robots encounter anomalies. Therefore, users can be elevated and focus on becoming regulators, decision-makers, and organizational leaders.

[0048] AI models provide AI agents with the ability to reason, plan, create, and make autonomous decisions. AI models can also be used by RPA robots for task-specific activities, such as processing documents or analyzing data. AI models can be enhanced with business-specific content and context (e.g., a collection of context stores from the enterprise), thereby improving the accuracy and results of the AI ​​models. AI models can be applied individually or simultaneously, depending on the complexity of the task. AI model selection can come from the model library of RPA vendors, third-party models, and Bring Your Own Model (BYOM) options (e.g., see U.S. Patent Nos. 11,738,453 and 11,748,479).

[0049] The hyper-automation system 100 includes user computing systems such as desktop computers 102, tablets 104, and smartphones 106. However, any desired user computing system may be used without departing from the scope of this disclosure, including but not limited to smartwatches, laptops, servers, Internet of Things (IoT) devices, etc. Furthermore, although... Figure 1 Three user computing systems are shown, but any suitable number of user computing systems may be used without departing from the scope of this disclosure. For example, in some embodiments, dozens, hundreds, thousands, or even millions of user computing systems may be used. The user computing systems may be actively used by users or automatically run by AI agents, AOP, and / or RPA robots without much or any user input.

[0050] As disclosed herein, in some embodiments there are three types of automation: (1) agent-based automation implemented by a corresponding AI agent; (2) RPA implemented by a corresponding RPA robot; and (3) composite automation that accomplishes a more complex overall task through a combination of AI agents (one or more) and RPA robots (one or more). Automation 110, 112, 114 may include, but is not limited to, those performed by RPA robots and / or AI agents, whether performed individually or to achieve greater composite automation. Other processes, such as listeners, may also be implemented. These processes may be standalone applications, subprocesses of another application, part of an operating system, any other suitable software and / or hardware, or any combination thereof, without departing from the scope of this disclosure. Indeed, in some embodiments, the logical portion or entirely of the process (one or more) is implemented via physical hardware.

[0051] Each user computing system 102, 104, 106 has a corresponding automation 110, 112, 114 running thereon, such as those implemented by RPA robots, AI agents, AOP, etc. In some embodiments, automation 110, 112, 114 may be remotely stored (e.g., within a core hyperautomation system 120 including a server 130 with one or more AI / ML models 132, or within a database 140 of the core hyperautomation system 120, and accessible via a network 119) and loaded by RPA robots and / or AI agents to implement automation 110, 112, 114.

[0052] Database 140 can store structured and / or unstructured data, although RPA typically requires the former. RPA automation can exist as scripts (e.g., Extensible Markup Language (XML), Extensible Application Markup Language (XAML), etc.) or be compiled into machine-readable code (e.g., as a digital link library). For example, in the case of AI agents, agent-based automation can be generated based on a plain text description of the desired goal.

[0053] The listener monitors and records data related to user interactions with the corresponding computing system and / or the operation of the unattended computing system, and transmits the data to the core hyper-automation system 120 via a network (e.g., a local area network (LAN), mobile communication network, satellite communication network, the Internet, any combination thereof, etc.). The data may include, but is not limited to, which buttons were clicked, where the mouse moved, text entered in fields, one window being minimized and another opened, applications associated with the windows, etc. In some embodiments, data from the listener may be sent periodically as part of a heartbeat message. In some embodiments, once a predetermined amount of data has been collected, after a predetermined time period has elapsed, or in both cases, the data may be sent to the core hyper-automation system 120. One or more servers, such as server 130, receive the data from the listener and store it in a database, such as database 140.

[0054] In the case of automations 110, 112, and 114 being RPA, automations 110, 112, and 114 can execute the logic developed in the workflow during design. A workflow can include a set of steps, defined herein as "activities," which are executed sequentially or through some other logical flow. Each activity can include actions such as clicking a button, reading a document, writing to a log panel, etc. In some embodiments, workflows can be nested or embedded.

[0055] In some embodiments, long-running RPA workflows are the main project supporting service orchestration, human-robot loops, and long-running transactions in unattended environments. For example, see U.S. Patent No. 10,860,905, the entire contents of which are incorporated herein by reference. Human-robot loops come into play when certain processes require user input (e.g., dynamic and / or direct user input) to handle exceptions, approvals, or verifications before proceeding to the next step of an activity. In this case, process execution is paused, releasing the RPA robot until the human-robot portion of the task is completed.

[0056] Long-running workflows can support workflow segmentation via continuous activities and can be combined with invoking processes and non-user interactive activities to orchestrate operations in a human-machine loop through RPA bot task orchestration. In some embodiments, multiple or many computing systems can participate in executing the logic of a long-running workflow. Long-running workflows can run in a single session to accelerate execution. In some embodiments, long-running workflows can orchestrate background processes that may contain activities that perform API calls and run within the long-running workflow session. In some embodiments, these activities may be invoked by invoking process activities. Processes with user interactive activities running in a user session can be invoked by starting a job from an orchestrator activity (the orchestrator, which will be described in more detail later). In some embodiments, the user can interact with a task that requires completing a form in the orchestrator. Activities may be included that cause the RPA bot to wait for the form task to complete before resuming the long-running workflow.

[0057] One or more of automation systems 110, 112, and 114 communicate with the core hyperautomation system 120. In some embodiments, the core hyperautomation system 120 may run an AI trust layer on one or more servers, such as server 130, for managing automation systems 110, 112, and 114. According to one or more embodiments, as... Figure 14 and Figure 15 The AI ​​trust layer described and illustrated is configured to provide trust, transparency, and control over the automated operation of one or more intelligent agents.

[0058] In some embodiments, the core hyperautomation system 120 may run an orchestrator application on one or more servers (e.g., server 130). While a server 130 is illustrated for illustrative purposes, multiple or many servers may be employed in close proximity to each other or in a distributed architecture without departing from the scope of the invention. For example, one or more servers may be provided for orchestrator functionality, AI / ML model services, authentication, governance, and / or any other suitable functionality without departing from the scope of the invention. In some embodiments, the core hyperautomation system 120 may be incorporated into, or be part of, a public cloud architecture, a private cloud architecture, a hybrid cloud architecture, etc. In some embodiments, the core hyperautomation system 120 may host multiple software-based servers on one or more computing systems such as server 130. In some embodiments, one or more servers of the core hyperautomation system 120, such as server 130, may be implemented via one or more virtual machines (VMs).

[0059] In some embodiments, one or more of the automations 110, 112, and 114 can invoke one or more AI / ML models 132, which are deployed on or accessible by the core hyper-automation system 120 and trained to perform various tasks. For example, AI / ML model 132 may include models trained to find various application versions, perform computer vision (CV), perform optical character recognition (OCR), generate user interface (UI) descriptors, provide suggestions for the next activity or sequence of activities in a workflow, perform semantic matching, perform natural language processing (NLP), generate or modify code and / or workflows, etc. The AI / ML model can be trained using labeled data, including but not limited to elements from data sources (e.g., web pages, forms, scanned documents, APIs, screens, etc.), previously created workflows, screenshots of various application screens for various versions and their corresponding UI elements, libraries of UI objects, etc. AI / ML model 132 can be trained to achieve a desired confidence threshold without overfitting the given training dataset. Generally, UI elements, UI descriptors, applications, and application screens can be considered UI objects.

[0060] Without departing from the scope of the invention, the AI / ML model 132 can be trained for any suitable purpose, as will be discussed in more detail below. In some embodiments, two or more AI / ML models 132 can be linked (e.g., in series, in parallel, or a combination thereof) such that they collectively provide collaborative output (one or more). The AI / ML model 132 can perform or assist in CV, OCR, document processing and / or understanding, semantic learning and / or analysis, analytical prediction, process discovery, task mining, testing, automated workflow generation, sequence extraction, cluster detection, audio-to-text translation, NLP, semantic matching, and any combination thereof. However, any desired number and / or type (one or more) of AI / ML models can be used without departing from the scope of the invention. For example, using multiple AI / ML models can allow the system to develop a global picture of what is happening on a given computing system. For example, one AI / ML model can perform OCR, another AI / ML model can detect buttons, another AI / ML model can compare sequences, and so on. Patterns can be determined individually by the AI / ML models or jointly by multiple AI / ML models. In some embodiments, one or more AI / ML models are locally deployed on at least one of the computing systems 102, 104, 106.

[0061] In some embodiments, multiple AI / ML models 132 may be used. Each AI / ML model 132 is an algorithm (or model) that runs on data, and the AI / ML model itself may be, for example, a deep learning neural network (DLNN) of trained artificial “neurons” trained on training data. In some embodiments, the AI / ML model 132 may have multiple layers performing various functions, such as statistical modeling (e.g., Hidden Markov Model (HMM)) and utilizing deep learning techniques (e.g., Long Short-Term Memory (LSTM) deep learning, encoding of previous hidden states, etc.) to perform the desired functionality.

[0062] In some embodiments, the hyper-automation system 100 may provide four main sets of functionalities: (1) discovery; (2) building automation; (3) management; and (4) collaboration. For example, in some embodiments, automation (e.g., running on a user's computing system, server, etc.) may be performed by an RPA robot, AOP, or AI agent and may provide any of the functionalities described herein. By way of example, an RPA robot may include a manned robot, an unmanaged robot, and / or a test robot. A manned robot assists the user in completing a task (e.g., via UiPathAssistant™). An unmanaged robot works independently of the user and may potentially run in the background without the user's knowledge. A test robot runs test cases against an application or workflow. In some embodiments, a test robot may run in parallel on multiple computing systems.

[0063] Discovery functionality can identify different opportunities for business process automation and provide automated recommendations. Such functionality can be implemented by one or more servers, such as server 130. In some embodiments, discovery functionality may include providing an automation hub, process mining, task mining, and / or task capture. An automation hub (e.g., UiPath AutomationHub™) can provide a mechanism for managing automation showcases with visibility and control. For example, automation ideas can be crowdsourced from employees via form submissions. Feasibility and ROI calculations for automating these ideas can be provided, documentation for future automations can be collected, and collaboration can be provided to accelerate the transition from automation discovery to implementation.

[0064] Process mining (e.g., via UiPath Automation Cloud™ and / or UiPath AI Center™) refers to the collection and analysis of data from applications (e.g., Enterprise Resource Planning (ERP) applications, Customer Relationship Management (CRM) applications, email applications, call center applications, etc.) to identify which end-to-end processes exist within an organization and how to effectively automate them, as well as indicating the impact of automation. This data may be collected from user computing systems 102, 104, 106 by, for example, listeners, and processed by servers such as server 130. In some embodiments, one or more AI / ML models 132 may be employed for this purpose. This information may be exported to an automation center to accelerate implementation and avoid manual information transfer. The goal of process mining can be to increase business value by automating processes within an organization. Some examples of process mining goals include, but are not limited to, increasing profits, improving customer satisfaction, regulatory and / or contractual compliance, and improving employee productivity.

[0065] Task mining (e.g., via UiPath Automation Cloud™ and / or UiPath AI Center™) identifies and aggregates workflows (e.g., employee workflows), then applies AI to reveal patterns and variations in daily tasks, scoring these tasks for automation and potential savings (e.g., time and / or cost savings). One or more AI / ML models 132 can be employed to reveal repetitive task patterns in the data. Repetitive tasks suitable for automation can then be identified. In some embodiments, this information may initially be provided by a listener and analyzed on a server (e.g., server 130) of the core hyper-automation system 120. The results of task mining (e.g., XAML process data) can be exported to process documents or designer applications such as UiPath Studio™ for faster creation and deployment of automation. In some embodiments, task mining may include taking screenshots of user actions (e.g., mouse click locations, keyboard inputs, application windows and graphical elements that the user is interacting with, timestamps of interactions, etc.), collecting statistics (e.g., execution time, number of actions, text entries, etc.), editing and annotating screenshots, specifying the types of actions to be recorded, etc.

[0066] Task capture (e.g., via UiPath Automation Cloud™ and / or UiPath AI Center™) automatically records engaged processes while users are working, or provides a framework for unattended processes. This type of documentation can include Process Definition Documents (PDDs), framework workflows, actions captured for each part of the process, recorded user actions, and automatically generated comprehensive workflow diagrams including details about each step, as well as Microsoft Word documents. ® Desired tasks to be automated can be in the form of documents, XAML documents, etc. In some embodiments, build-ready workflows can be exported directly to designer applications, such as UiPath Studio™. Task capture can simplify the requirements gathering process for subject matter experts who interpret the process and members of Centers of Excellence (CoEs) that provide production-level automation.

[0067] Building automation can be achieved through designer applications such as UiPath Studio™, UiPath StudioX™, or UiPathStudio Web™. For example, developers at RPA Developer Facility 150 can use designer application 154 of computing system 152 to build and test for various applications and environments, such as web, mobile, and SAP. ® Intelligent agent-based automation (and virtual desktops), RPA, AOP, and / or composite automation. Developers can also build AOP. For example, developers can create automations executed by RPA bots, AI agents, AOP, combinations thereof, etc., providing API integration for various applications, technologies, and platforms. Predefined activities, drag-and-drop modeling, and workflow loggers make automation easier with minimal coding. Document understanding functionality can be provided via drag-and-drop AI skills for calling one or more AI / ML models132 for data extraction and interpretation. This type of automation can handle virtually any document type and format, including tables, checkboxes, signatures, and handwriting. When data is validated or anomalies are handled, this information can be used to retrain the corresponding AI / ML models, improving their accuracy over time.

[0068] Designer application 152 may be designed to invoke one or more trained AI / ML models 132 on server 130 and / or generative AI models 172 in a cloud environment via network 120 (e.g., local area network (LAN), mobile communication network, satellite communication network, Internet, any combination thereof, etc.) to assist in automating the development process. In some embodiments, one or more AI / ML models may be packaged together with designer application 152 or otherwise stored locally on computing system 150.

[0069] In some embodiments, the designer application 152 and one or more AI / ML models 132 may be configured to use an object store stored in the database 140. See, for example, U.S. Patent No. 11,748,069, the entire contents of which are incorporated herein by reference. Generally, an object store is a storage mechanism used for the automation of images, text, semantic data, classification associations, ontology associations, UI objects, etc. For example, an object store may include a library of UI objects that can be used to develop workflows via the designer application 152. The object store can be used for activities that add UI descriptors to the workflow of the designer application 152 for UI automation. In some embodiments, one or more AI / ML models in the AI / ML models 132 may generate new UI descriptors and add them to the object store in the database 140.

[0070] After automation is completed in the designer application 152, it can be published to server 130 and pushed to computing systems 102, 104, 106, etc. For example, when creating new UI descriptors and / or modifying existing UI descriptors, a global repository of UI objects can be built, which can be shared and collaborated on by all automations. Regarding the object repository, taxonomy and ontology can be used. Taxonomy is a hierarchical structure of subcategories. Ontology is a formal representation of a knowledge domain, including concepts, attributes, and the relationships between them. In ontology, the relationships between categories are not necessarily hierarchical, and ontological relationships can span multiple screens of the application.

[0071] For example, integration services allow developers to seamlessly combine UI automation with API automation. Automation can be built that requires APIs or traverses both API and non-API applications and systems, such as any of the types described herein. Repositories (e.g., UiPath Object Repository™) or marketplaces (e.g., UiPath Marketplace™) for pre-built automation templates and solutions can be provided to allow developers to automate a wide variety of processes more quickly. Therefore, when building automation, the HyperAutomation System 100 can provide a user interface, development environment, API integration, pre-built and / or custom-built AI / ML models, development templates, an integrated development environment (IDE), and advanced AI capabilities. In some embodiments, the HyperAutomation System 100 enables the development, deployment, management, configuration, monitoring, debugging, and maintenance of RPA bots, AOPs, and AI agents, which provides automation for the HyperAutomation System 100.

[0072] In some embodiments, components of the hyperautomation system 100, such as designer applications (one or more) and / or external rules engines, support governance policies for managing and implementing various functionalities provided by the hyperautomation system 100. Governance is the ability of an organization to place policies in place to prevent users from developing automations (e.g., RPA bots, AOPs, and / or AI agents) capable of taking actions that could harm the organization, such as violating the EU General Data Protection Regulation (GDPR), the US Health Insurance Portability and Accountability Act (HIPAA), third-party application terms of service, etc. Because developers can otherwise create automations that violate privacy laws, terms of service, etc., when performing their automations, some embodiments implement access controls and governance restrictions at the bot and / or bot design application level. In some embodiments, this provides an additional level of security and compliance by preventing developers from relying on unapproved software libraries to develop pipelines for automated processes, which could introduce security risks or operate in a manner that violates policies, regulations, privacy laws, and / or privacy policies. See, for example, US Patent No. 11,733,668, the entire contents of which are incorporated herein by reference.

[0073] Management functionality can provide automated management, deployment, and optimization across the organization. In some embodiments, management functionality may include orchestration, test management, AI functionality, and / or insights. The management functionality of the hyper-automation system 100 can also serve as an integration point for third-party solutions and applications for automation applications and / or RPA robots. The management capabilities of the hyper-automation system 100 may include, but are not limited to, facilitating the provisioning, deployment, configuration, queuing, monitoring, logging, and interconnection of RPA robots, AOP, and / or AI agents.

[0074] An orchestrator application, such as UiPath Orchestrator™ (in some embodiments, it may be provided as part of UiPath Automation Cloud™, or deployed on-premises, in a VM, in a private or public cloud, in a Linux™ VM, or via UiPath Automation Suite™ as a cloud-native single-container suite), provides orchestration capabilities to deploy, monitor, optimize, scale, and secure the deployment of RPA bots, AOPs, and / or AI agents. A test suite (e.g., UiPath Test Suite™) provides test management to monitor the quality of deployed automation. The test suite facilitates test planning and execution, meets requirements, and ensures defect traceability. The test suite may include comprehensive test reports.

[0075] Analytics software (such as UiPath Insights™) tracks, measures, and manages the performance of deployed automation. It can link automated operations to an organization's specific key performance indicators (KPIs) and strategic outcomes. The results can be presented in dashboard formats for better user understanding.

[0076] For example, data services (e.g., UiPath Data Service™) can be stored in database 140, and data can be placed into a single, scalable, secure location via a drag-and-drop storage interface. Some embodiments can provide low-code or no-code data modeling and storage to automation, ensuring seamless data access, enterprise-grade security, and scalability. AI functionality can be provided by an AI center (e.g., UiPath AI Center™), which facilitates the integration of AI / ML models into automation. Pre-built AI / ML models, model templates, and various deployment options even allow non-data scientists to use these functionalities. Deployed automations (e.g., RPA bots, AOP, and AI agents) can invoke AI / ML models, such as AI / ML model 132, from the AI ​​center. The performance of AI / ML models can be monitored, trained, and improved using user-verified data, such as data provided by data review center 160. Users acting as reviewers can provide tagged data to the core hyper-automation system 120 via review application 152 on computing system 154. For example, a reviewer can verify that the predictions of AI / ML model 132 and / or generative AI model 172 are accurate, or otherwise provide corrections. Users acting as reviewers can also provide dynamic and / or direct user inputs to the AI ​​agent (e.g., within the scope of human-machine loop operations), and these dynamic and / or direct user inputs (e.g., responses and corrections provided by the reviewer) can be used to train the AI ​​agent to use one or more LLMs more accurately. In other words, dynamic and / or direct user inputs can be saved as training data for retraining AI / ML model 132 and / or generative AI model 172, and can be stored in a database such as database 140. The AI ​​center can then schedule and execute training jobs to train new versions of the AI / ML models using the training data. Positive and negative samples can be stored and used for the retraining of AI / ML model 132 and / or generative AI model 172.

[0077] Collaborative functionality brings automation and users together as a team to seamlessly collaborate on desired processes. Low-code applications can be built (e.g., via UiPath Apps™) to connect browser tabs and legacy software, even in implementations lacking APIs. For example, applications can be quickly created using a web browser with a rich library of drag-and-drop controls. Applications can be connected to one or more automations.

[0078] Action centers (such as UiPath Action Center™) provide a direct and efficient mechanism for delegating processes from automation to users and vice versa. Users can provide approvals or escalations, make exceptions, etc. Automation can then perform the automatic functionality of a given workflow.

[0079] A local assistant can be provided as a launch panel for users to initiate automations (e.g., UiPath Autopilot™). Such assistants may also provide semantic cut and paste functionality (e.g., UiPath Clipboard AI™). See, for example, U.S. Patent No. 12,124,806 and U.S. Patent Application Publications Nos. 2023 / 0107316, 2023 / 0415338, and 2024 / 0220581. This functionality may be provided in the system tray by the operating system and allow users to interact with RPA bots, AOPs, and AI agents, as well as automation-driven applications on their computing system. Interfaces can be listed as automations approved by a given user and allow the user to run them. These can include off-the-shelf automations from automation marketplaces, internal automation storage from automation hubs, etc. When automations run, they can run as local instances in parallel with other processes on the computing system, allowing the user to utilize the computing system while the automation performs its actions. In some embodiments, the assistant is integrated with task capture functionality, allowing users to record processes they are about to automate from the assistant's launch panel.

[0080] In some embodiments, the HyperAutomation System 100 can provide end-to-end measurement and control of automation programs of any scale. Based on the foregoing, analytics can be employed to understand the performance of automation (e.g., via UiPath Insights™). Data modeling and analysis using any combination of available business metrics and operational insights can be used for a wide range of automation processes. Custom-designed, pre-built dashboards allow visualization of data across desired metrics, discovery of new analytical insights, tracking of performance metrics, discovery of automation ROI, performance of telemetry monitoring on user computing systems, detection of errors and anomalies, and debugging of automation. An automation management console (e.g., UiPath Automation Ops™) can be provided to manage the entire lifecycle of automation. Organizations can control how automation is built, what users can do with it, and which automations users can access.

[0081] In some embodiments, the hyper-automation system 100 provides an iterative platform. Processes can be discovered, automation can be built, tested, and deployed, performance can be measured, automation can be easily provided to users, feedback can be obtained, AI / ML models can be trained and retrained, and the process can repeat itself. This facilitates more robust and efficient automation suites.

[0082] In some embodiments, generative AI models 172 are used in accordance with the foregoing. For example, the AI ​​agent utilizes a generative AI model. Generative AI model 172 can generate various types of content, such as text, images, audio, and synthetic data. Various types of generative AI models can be used, including but not limited to LLMs, generative adversarial networks (GANs), diffusion models, stream-based models, variational autoencoders (VAEs), transformers, etc. In the case of LLMs, for example, NLP models such as word2vec, BERT, GPT-3, ChatGPT, etc., can be used in some embodiments to facilitate semantic understanding and provide more accurate and human-like answers. These models can be part of the AI / ML model 132 hosted on server 130. For example, generative AI model 172 can be trained on a large corpus of textual information to perform semantic understanding, understand the nature of content presented on a screen from text, automatically generate code, etc. The AI ​​agent can use such generative AI models 172. In some embodiments, models can be adopted and trained by existing cloud ML service providers (such as OpenAI). ® Google ® Amazon ® Microsoft ® IBM ® Nvidia ® Meta ®Generative AI models 172 provided by companies such as [list of companies] can offer this type of functionality. In generative AI embodiments where generative AI models (one or more) 172 are remotely hosted, server 130 can be configured to integrate with third-party APIs. This allows server 130 to send requests to generative AI models (one or more) 172 including necessary input information and receive returned responses (e.g., semantic matching of fields between application versions, classification of application types on screen, responses to natural language queries from users, etc.). Such embodiments can provide a more advanced and sophisticated user experience, as well as access to state-of-the-art NLP and other ML capabilities offered by these companies.

[0083] In some embodiments, one aspect of the generative AI model 172 is the use of transfer learning. In transfer learning, a pre-trained generative AI model, such as an LLM, is fine-tuned for a specific task or domain. This allows the LLM to leverage knowledge already learned during initial training and adapt it to a specific application. In the case of an LLM, the pre-training phase involves training the LLM on a large text corpus, typically consisting of billions of words. During this phase, the LLM learns relationships between words and phrases, enabling it to generate coherent and human-like responses to text-based input. The output of this pre-training phase is the LLM, which possesses a high level of understanding of the underlying patterns in natural language.

[0084] During the fine-tuning phase, the pre-trained LLM is adapted to a specific task or domain by training it on a smaller, task-specific dataset. For example, in some embodiments, the LLM can be trained to analyze one or more types of data sources to improve its accuracy regarding their content. This data can include, but is not limited to, cue word tuning or instruction tuning, where the model is specifically trained to better understand and follow specific types of instructions or cue words, thereby improving its ability to perform a specific task when given appropriate instructions. This type of information can be provided as part of the training data, and the LLM can learn to focus on these areas and more accurately identify the data elements within them. Fine-tuning allows the LLM to learn the nuances of the task or domain, such as the specific vocabulary and grammar used in that domain, without requiring as much data as would be needed to train the LLM from scratch. By leveraging the knowledge learned in the pre-training phase, a fine-tuned LLM can achieve state-of-the-art performance on a specific task with a relatively small amount of training data.

[0085] LLM can utilize vector databases. Vector databases index, store, and provide access to structured or unstructured data (e.g., text, images, time-series data, etc.) and their vector embeddings. Data such as text can be tokenized, where individual letters, words, or sequences of words are parsed from the text into tokens. These tokens are then "embedded" into vector embeddings, which are numerical representations of the data. Vector databases enable LLM to quickly and massively find and retrieve similar objects in production environments, something impossible through manual processes.

[0086] AI and ML allow for the digital representation of unstructured data without losing its semantics in vector embeddings. A vector embedding is a long string of numbers, each describing a feature of the data object it represents. Similar objects are grouped together in a vector space. In other words, the more similar the objects, the closer their vector embeddings are. Similar objects can be found using vector search, similarity search, or semantic search and retrieval. The distance between vector embeddings can be calculated using various techniques, including but not limited to squared Euclidean or L2 squared distance, Manhattan or L1 distance, cosine similarity, dot product, Hamming distance, etc. Choosing the same metric for training AI / ML models can be beneficial.

[0087] Vector indexing can be used to organize vector embeddings for efficient data retrieval. With a large number of data points, calculating the distance between a vector embedding and all other vector embeddings in a vector database using the k-nearest neighbor (kNN) algorithm can be computationally expensive, as the required computation increases linearly (O(n)) with the dimensionality and number of data points. Finding similar objects is more efficient using the approximate nearest neighbor (ANN) method. The distances between vector embeddings are pre-computed, and similar vectors are organized and stored close to each other (e.g., in clusters or graphs). Similar objects can be found much faster. This process is called "vector indexing." ANN algorithms that can be used in some embodiments include, but are not limited to, cluster-based indexing, proximity graph-based indexing, tree-based indexing, hash-based indexing, compression-based indexing, etc.

[0088] Figure 2The illustration shows some combined capabilities 200 of an AI agent 210 and an RPA robot 220 according to one or more embodiments. The AI ​​agent 210 is configured to process natural language instructions and thereby achieve a desired goal 231; execute through dynamic decision-making or dynamic flow control with self-healing capabilities 233; store information in long-term memory and evaluate its own execution performance 235; and learn from human-machine loop interactions and its own performance during execution 237. AI agent 210 can utilize RPA robot 220 to respond to triggers 241 (e.g., an orchestrator application from UiPath Orchestrator™), respond based on context 243 (i.e., RPA robot 220 can retrieve information from the context to perform deterministic steps, such as updating a document based on information retrieved from the context; alternatively, agent 210 can use the retrieved context to update a dynamic plan and execute subsequent steps to achieve the goal as instructed), utilize models 245 (e.g., CV models, document processing models, speech-to-text models, OCR models, AI models, etc.), utilize tools 247 (e.g., utilize tools available in the RPA ecosystem, such as full automation, workflows within automation, integration service connector calls for third-party and first-party services, RPA designer application activities, LLM calls, automation, etc.); and perform actions 249 that RPA robot 220 can take based on input from AI agent 210 (i.e., using RPA robot 220 as a tool).

[0089] As discussed above, intelligent agent automation achieves a variety of technical effects, benefits, and advantages. Intelligent agent automation improves memory utilization by reducing data storage requirements and processor efficiency by reducing the number of calls and operations. Intelligent agent automation provides the ability to process gigabytes, terabytes, petabytes, or more of data, which is impossible with human-implemented processes, whether mental or manual. Intelligent agent automation supports the use of fewer triggers and models through dynamic decision support. For example, as discussed in this paper, while conventional software automation itself may require one hundred (100) actions in the example scenario, intelligent agent automation can significantly reduce the required actions in the same example scenario (e.g., to fifteen (15) actions). Intelligent agent automation can also improve the efficiency of LLM by employing a context-based approach to tether the AI ​​agent 210 to a desired context that “constrains” the LLM to the relevant context.

[0090] As used herein, “context-based” refers to a method of improving models (such as LLMs) by combining enterprise-specific information with pre-trained knowledge, enabling accurate responses to specific or recent queries. In some embodiments, context-based approaches use external data to enhance LLM responses and obtain responses that the LLM itself is unaware of, answering queries on top of the provided context. By way of example, because unique industry terminology and complex document structures pose challenges in ensuring effective retrieval and semantic matching, context-based approaches address these challenges by providing precise document chunking to ensure that relevant information (e.g., from unique industry terminology and complex document structures) is delivered to the LLM without noise. As another example, context-based approaches offer enhanced extraction and search techniques tailored to different industry and application domains (e.g., tailored for unique industry terminology and complex document structures), which improves LLM responses.

[0091] Figure 3 Figure 300 depicts an AOP, AI agent, RPA robot, and application according to one or more embodiments.

[0092] AOP pool 310 includes AOP that implements business processes. As mentioned above, AOP can be implemented as a BPMN, which is executed by an AOP execution engine (such as Temporal). ® AOP can leverage AI agents and / or RPA robots to execute parts of business processes.

[0093] AI Agent Pool 320 includes AI agents They have been trained to perform various tasks, such as investigating claims, seeking solutions with employees, and summarizing strategies and technical specifications. The RPA robot pool 330 includes RPA robots. They perform various forms of automation, such as UI automation, semantic matching automation, and form filling automation.

[0094] Application pool 340 includes applications that AI agents and / or RPA robots can interact with. For example, applications may include CRM applications, invoice applications, payroll applications, banking applications, web applications, legacy system applications, word processing applications, spreadsheet applications, email applications, etc. AI agents, RPA robots, and applications may reside on a single computing system or on multiple or many computing systems. In some embodiments, AOP is typically located in the cloud or on a server and may reside on one or more of the same computing systems as the orchestrator application 350.

[0095] AOP can trigger or invoke AI agents and RPA robots via the orchestrator application 350. AI agents and RPA robots can also trigger or invoke each other via the orchestrator application. For example, to invoke an RPA robot, an AI agent can make a "Start Job" call in the orchestrator application 350. It should be noted that the RPA robot is deployed as an automation controlled by the orchestrator application 350. AI agents, AOP, and RPA robots can also trigger or invoke certain applications. For example, using information collected from human-machine loop operations, an AI agent can dynamically learn which RPA robot, other AI agents, and / or applications to trigger or invoke to complete a task. For example, an AI agent can learn to trigger an RPA robot via the orchestrator application 350 to fill out and submit web forms. An AI agent can also learn to open Microsoft Excel. ® It also inputs form information into appropriate labels, opens and updates the payroll application, etc. The AI ​​agent can also learn to invoke or trigger emails via the orchestrator application 350 to resolve issues; if a problem occurs, the orchestrator application 350 contacts the bank's customer service representative. In some embodiments, the technical effects, benefits, and advantages can be similar to those described above. Figure 1 and Figure 2 Those that are discussed.

[0096] To enable AI agents, AOPs, and RPA bots to find each other, AI agents can belong to a single tenant. The designer application can invoke the orchestrator to obtain a list of available RPAs. In some embodiments, there are three ways to obtain automation capabilities: (1) when a workflow is created in the designer application, the user provides a description of what the automation does; (2) the AI ​​agent and ML technology are used to generate a summary of what a given workflow does; or (3) the developer can describe what the automation does in the designer application. The orchestrator application can also list the applications available for a given AI agent and RPA bot. In other words, the descriptions of available AI agents, RPA bots, and / or applications are derived or specified by the AI ​​agent, ML technology, or the user.

[0097] Figure 4 An example intelligent agent service interface 400 according to one or more embodiments is illustrated. Figure 4As shown, the agent answers questions about the policy document provided in the context. The agent instruction pane 410 includes a natural language description, entered by the user, of what the AI ​​agent intends to do. If needed, user prompts 420 allow developers to enter the content of the user prompts in the content field 422. The tools dropdown menu 430 allows developers to select tools that the AI ​​agent will utilize, such as using an API for the application, invoking an RPA bot to perform RPA, etc.

[0098] The context dropdown menu 440 allows developers to configure the context base for the AI ​​agent. In this example, the context configuration pane 442 allows developers to provide a description via the description field 444 and a Flexible Common Schema (ECS) index for specific policy documents containing information such as contracts, agreements, and what to do via the ECS index field 446. Developers can also add context 450 to further supplement the context base. User upgrade options can be configured via the upgrade dropdown menu 460. The query field 470 allows users to provide a query that the AI ​​agent will respond to. When the user clicks the run button 480, the AI ​​agent runs the query. The results during the AI ​​agent's execution are then displayed in the execution pane 490 as the AI ​​agent retrieves and outputs them.

[0099] Figure 5 The illustration depicts an example AOP development interface 500 according to one or more embodiments. The AOP development interface 500 includes AOP 510, AI agent 520, and RPA robot 530 that a user can select when developing a business process. These can be selected by the AI ​​agent, AOP, or the developer developing the AOP and dragged onto a canvas 540. In this example, a credit check 541 is performed upon a credit check request 542 by retrieving customer data 543 from a database 545. Next, the AI ​​agent 546 is invoked to determine the customer type (e.g., likely to pay, likely to miss payments, frequent transactions, etc.) by analyzing the customer data in the database 545. This type is then provided to the RPA robot 547, which considers this information when performing the credit check and generating a credit check result 549. Alternatively, the AI ​​agent, AOP, or developer can provide a description of the business process in field 550 and select a generate button 560. This description is provided to an LLM (Local Management System), which attempts to understand the business process and automatically create the AOP. AI agents, AOPs, or developers can edit AOPs.

[0100] Figure 6An example RPA development interface 600 according to one or more embodiments is illustrated. The RPA development interface 600 includes a component 610 that an AI agent, AOP, or developer can select when developing a workflow for an RPA bot. The AI ​​agent, AOP, or developer can be selected and dragged onto a canvas 620. Alternatively, the AI ​​agent, AOP, or developer can provide a description of the workflow in field 630 and select a generate button 640. This description is provided to an LLM, which attempts to understand the workflow and automatically create the RPA bot. The AI ​​agent, AOP, or developer can then edit the workflow of the RPA bot. It should be noted that in some embodiments, regarding... Figure 4 , Figure 5 and Figure 6 The functionality illustrated and described can be provided in a single designer application.

[0101] Figure 7 The illustration depicts an end-to-end AI agent, RPA bot, and AOP development and deployment system 700 according to one or more embodiments. A designer application 710 allows AI agents, AOPs, and developers to design workflows for subsequent automation (e.g., AOPs, AI agents, and / or RPA bots). Once these subsequent AOPs, AI agents, and / or RPA bots have been tested and validated, the validated and tested AOPs, AI agents, and / or RPA bots are packaged and published to the automation database 720.

[0102] The orchestrator application 730 manages the deployment of these packaged and released automata. When software process 732 requests to run automation, the orchestrator application 730 sends a start job command to the AOP engine 740, which selects from AOP 742 and begins the automation. While executing AOP 742, steps may be encountered that are implemented by AI agent 750 and / or RPA robot 760. In some cases, the AOP engine 740 suspends the executing AOP 742 and sends a request to the orchestrator application 730 to send a start job request to the appropriate AI agent 750 or RPA robot 760 to execute the step.

[0103] Upon requesting an AI agent, the orchestrator application 730 sends a job initiation request to the appropriate AI agent 750. This request may include natural language text or other information provided to the orchestrator application 730 by the AOP engine 740. The AI ​​agent 750 then assists in performing the task by executing LLM 752. The AI ​​agent 750 then sends task-related information (e.g., the requested information, indications that the step has been completed, indications that the step failed, etc.) to the orchestrator 730, which provides this information to the AOP engine 740. The AOP engine 740 then resumes its operation.

[0104] In the event of a requested RPA robot, the orchestrator application 730 sends a job start request to the appropriate RPA robot 760. The RPA robot 760 then executes the requested RPA 762. The RPA robot 760 then sends task-related information (e.g., requested information, indications of completed steps, indications of failed steps, etc.) to the orchestrator application 730, which provides this information to the AOP engine 740. The AOP engine 740 then resumes operation.

[0105] According to one or more embodiments, AOP 742, AI agent 750, or RPA 762 may require user operation. In this case, AOP engine 740, AI agent 750, or RPA robot 760 contacts user 770 to perform a human-machine loop operation that facilitates automation. After user 770 provides a user action, AOP engine 740, AI agent 750, or RPA robot 760 resumes automation.

[0106] Figure 8 This is an architectural diagram illustrating an intelligent human automation and RPA system 800 according to one or more embodiments. In some embodiments, the intelligent human automation and RPA system 800 is... Figure 1 This is part of the hyper-automation system 100. The intelligent agent-based automation and RPA system 800 includes a designer 810, which allows AI agents, AOP, or developers to design automation (e.g., workflows, natural language instructions for AI agents and AOP, contextual basis, tool configuration, RPA bots, AOP, AI agents, etc.). The designer 810 can provide solutions for application integration and automation of third-party applications, managing information technology (IT) tasks, and business IT processes. The designer 810 facilitates the development of automation projects, which are graphical representations of business processes. The designer 810 facilitates the development and deployment of automation (as indicated by arrow 811). The designer 810 can be an application running on a user's desktop, an application running remotely in a VM, a web application, etc.

[0107] Automation projects automate rules-based processes by granting AI agents, AOPs, or developers control over the execution order and interrelationships of a set of custom steps developed within a workflow (i.e., "activities" as described herein). A business example of an embodiment of Designer 810 is UiPath Studio™. Each activity may include actions such as clicking a button, reading a document, writing to a log panel, etc. In some embodiments, workflows may be nested or embedded.

[0108] Certain types of workflows may include, but are not limited to, sequences, flowcharts, finite state machines (FSMs), and / or global exception handlers. Sequences are particularly well-suited for linear processes, enabling flow from one activity to another without making the workflow chaotic. Flowcharts are particularly well-suited for more complex business logic, implementing the integration of decisions and the connection of activities in more diverse ways through multiple branching logic operators. FSMs are particularly well-suited for large workflows. FSMs can use a finite number of states in their execution, triggered by conditions (i.e., transitions) or activities. Global exception handlers are particularly well-suited for determining workflow behavior and debugging processes when execution errors are encountered.

[0109] Once automation is developed in Designer 810, the execution of the business process is orchestrated by Orchestrator 820. Orchestrator 820 orchestrates one or more robots 830, one or more AI agents 850, and / or one or more AOPs 870 to execute the workflow developed in Designer 810. A business example of an embodiment of Orchestrator 820 is UiPath Orchestrator™. Orchestrator 820 facilitates the creation, monitoring, and deployment of resources in the management environment. Orchestrator 820 can act as an integration point with third-party solutions and applications. As described above, in some embodiments, Orchestrator 820 may be... Figure 1 The core of the hyper-automation system 120.

[0110] It should be noted that the RPA robot 830 can operate independently for deterministic processes. The AI ​​agent 850 and AOP 870 can also operate independently (e.g., for non-deterministic processes), or utilize one or more RPA robots 830s or other AI agents 850s as tools to complete part of their agent-based automation. The AI ​​agent 850 can drive composite automation utilizing both the RPA robot 830 and the AI ​​agent 850, or vice versa, and AOP 870 can include such composite automation.

[0111] Orchestrator 820 manages a fleet of RPA robots 830 and AI agents 850, connecting and executing (as indicated by arrow 881) the RPA robots 830 and AI agents 850 from a central point (as required by an AOP engine implementing AOP). The types of RPA robots 830 that can be managed include, but are not limited to, manned robots, unattended robots, development robots (similar to unattended robots but used for development and testing purposes), and non-production robots (similar to manned robots but used for development and testing purposes). Manned robots are triggered by user events and work alongside the user on the same computing system. Manned robots can be used with orchestrator 820 for centralized process deployment and recording media. Manned robots can assist users in completing various tasks and can be triggered by user events. In some embodiments, processes cannot be started from orchestrator 820 on this type of robot, and / or they cannot run under a locked screen. In some embodiments, managed robots can only be started from a robot tray or from a command prompt. In some embodiments, manned robots should operate under user supervision.

[0112] Unattended robots operate unattended in virtual environments, automating numerous processes. They can handle remote execution, monitoring, scheduling, and support for work queues. In some embodiments, debugging for all robot types can be performed in Designer 810. Both manned and unattended robots can automate various systems and applications, including but not limited to mainframes, web applications, VMs, and enterprise applications (e.g., those developed by SAP). ® Salesforce ® Oracle ® Applications produced by manufacturers (such as desktop and laptop applications, mobile device applications, wearable computer applications, etc.) and computing system applications (such as desktop and laptop applications, mobile device applications, wearable computer applications, etc.).

[0113] Orchestrator 820 may have various capabilities (as indicated by arrow 882), including but not limited to provisioning, deployment, configuration, queuing, monitoring, logging, and / or providing interconnectivity. Provisioning may include creating and maintaining connections between RPA bots 830, AI agents 850, and / or AOP 870 and orchestrator 820 (e.g., web applications). Deployment may include ensuring that package versions are correctly delivered to designated RPA bots 830, AI agents 850, and / or AOP 870 for execution. Configuration may include maintaining and delivering the environment and process configurations for RPA bots and AI agents. Queuing may include providing management of queues and queue items. Monitoring may include tracking bot and AI agent identification data and maintaining user permissions. Logging may include storing and indexing logs to a database (e.g., a Structured Query Language (SQL) database or a "not just" SQL (NoSQL) database) and / or another storage mechanism (e.g., ElasticSearch, which provides the ability to store and quickly query large datasets). ® The orchestrator 820 can provide interconnectivity by acting as a centralized communication point for third-party solutions and / or applications.

[0114] The RPA robot 830 is an executive agent that implements the workflow built into the designer 810. A business example of some embodiments of the RPA robot 830 is UiPath Robots™. In some embodiments, the RPA robot 830 is pre-installed with Windows. ® Services managed by the Service Control Manager (SCM). As a result, this type of RPA robot 830 can open interactive Windows applications under the local system account. ® Session, and has Windows ® Service permissions.

[0115] In some embodiments, the RPA robot 830 can be installed in user mode. For this type of RPA robot 830, this means that it has the same permissions as the user who installed the given RPA robot 830. This feature can also be used for high-density (HD) robots, ensuring that the maximum potential of each machine is fully utilized. In some embodiments, any type of RPA robot 830 can be configured in an HD environment.

[0116] In some embodiments, the RPA robot 830 is divided into several components, each dedicated to a specific automation task. Robot components in some embodiments include, but are not limited to, SCM-managed robot services, user-mode robot services, actuators, agents, and command lines. SCM-managed robot services manage and monitor Windows... ®The session acts as an agent between the orchestrator 820 and the execution host (i.e., the computing system on which the RPA robot 830 executes). These services are trusted and manage the credentials of the RPA robot 830. The SCM launch console application is located on the local system.

[0117] In some embodiments, user-mode robot service management and monitoring Windows ® The session acts as an intelligent agent between the orchestrator 820 and the execution host. The user-mode robot service can be trusted and manages the credentials of the RPA robot 830. If the SCM-managed robot service is not installed, Windows... ® The application can start automatically.

[0118] The actuator can be used in Windows ® A given job runs within a session (i.e., they execute workflows). The executor can know the dots per inch (DPI) setting for each monitor. The AI ​​Agent 850 can be a Windows system tray window that displays available jobs. ® Demonstrates the basic (WPF) application. Note that these agents are different from AI Agent 850. AI Agent 850 can be a client of the service and can request to start or stop a job and change settings. The command line is the client of the service. The command line is a console application that can request to start a job and wait for its output.

[0119] As described above, breaking down the RPA robot 830 into components helps developers, support users, and computing systems more easily run, identify, and track what each component is performing. This allows for the configuration of specific behaviors for each component, such as setting different firewall rules for executors and services. In some embodiments, the executor can always know the DPI setting of each monitor. As a result, workflows can execute at any DPI, regardless of the configuration of the computing system that created them. In some embodiments, projects from the designer 810 can also be independent of the browser scaling level. For applications that do not know the DPI or are intentionally marked as not knowing it, DPI can be disabled in some embodiments.

[0120] The intelligent human automation and RPA system 800 in this embodiment is part of a hyper-automation system, such as Figure 1The hyper-automation system 100. Developers can use designer 810 to build and test RPA, AOP, and AI agents that utilize AI / ML models deployed in the core hyper-automation system 840 (e.g., as part of its AI hub). Such RPA robots can send inputs to execute one or more AI / ML models and receive outputs from them via the core hyper-automation system 840.

[0121] As described above, one or more RPA robots 830 can be listeners. These listeners can provide the core hyperautomation system 840 with information about what users are doing while using their computing systems. This information can then be used by the core hyperautomation system for process mining, task mining, task capture, etc.

[0122] The assistant / chatbot (of the orchestrator 820) can be set up on the user's computing system to allow the user to launch a local RPA bot. For example, the assistant / chatbot can be located in the system tray. The chatbot can have a user interface so that the user can see the text in the chatbot. Alternatively, the chatbot can have no user interface and run in the background, using the computing system's microphone to listen to the user's voice.

[0123] In some embodiments, data annotation can be performed by a user of the computing system on which the RPA robot or AI agent executes, or on another computing system on which the robot or AI agent provides information. For example, if the robot invokes an AI / ML model to perform CV on an image for a VM user, but the AI / ML model does not correctly label buttons on the screen, the user can draw rectangles around incorrectly labeled or unlabeled parts, potentially providing text with correct labeling. This information can be provided to the core hyper-automation system 540 and then later used to train a new version of the AI / ML model.

[0124] Figure 9 This is an architectural diagram illustrating a deployed RPA system 900 according to one or more embodiments. In some embodiments, the RPA system 900 may be... Figure 8 Intelligent human automation and RPA systems 800 and / or Figure 1 This is part of a hyper-automated system 100. It should be noted that in some embodiments, the architecture of the deployed RPA system 900 may not be used. The deployed RPA system 900 can be a cloud-based system, an on-premises system, a desktop-based system, etc., providing enterprise-level, user-level, or device-level automation solutions for automating different computing processes.

[0125] It should be noted that client 901, server 902, or both may include any desired number of computing systems without departing from the scope of the invention. In client 901, robot application 910 includes actuator 912, executive agent 914, and designer 916. However, in some embodiments, designer 916 may not run on the same computing system as actuator 912 and executive agent 914. Actuator 912 is running a process. Several business items can run simultaneously. In this embodiment, executive agent 914 (e.g., Windows...) ® The service is the single point of contact for all actuators 912. The executing agent 914 is also responsible for sending the robot's status (e.g., periodically sending "heartbeat" messages indicating that the robot is still running) and downloading the required version of the package to be executed.

[0126] Listener 930 monitors and records data related to user interactions with the manned computing system and / or unattended computing system where it resides. Without departing from the scope of the invention, listener 930 may be an RPA robot, AOP, AI agent, part of an operating system, a downloadable application for the corresponding computing system, or any other software and / or hardware. In fact, in some embodiments, the logic portion of the listener may be implemented entirely via physical hardware.

[0127] On the server side 902, a presentation layer 933, a service layer 934, and a persistence layer 935, as well as an orchestrator 940, are provided. Furthermore, the presentation layer 933 includes a web application 942, an Open Data Protocol (oData) representation state transfer (REST) ​​application programming interface (API) endpoint 944, and notification and monitoring 946, and the service layer 934 includes API implementations / business logic 948. Therefore, as... Figure 9 As shown, orchestrator 940 includes a web application 942, an oData REST API endpoint 944, notifications and monitoring 946, and API implementation / business logic 948. The persistence layer 935 includes a database server 950, an AI / ML server 960, and an indexer server 970.

[0128] In some embodiments, communication between the executive agent 914 and the orchestrator 940 is always initiated by the executive agent 914. In a notification scenario, the executive agent 914 may open a WebSocket channel that the orchestrator 940 will later use to send commands (e.g., start, stop, etc.) to the RPA robot. It should be noted that, although in order to reduce... Figure 9 The chaos within is not illustrated in this article, but the AI ​​agent can also interact with the orchestrator 940, for example, as mentioned above. Figure 1 and Figure 8The programmable controller 940 can program the operations of AI agents, AOPs, and RPA robots.

[0129] In this embodiment, all message records are stored in orchestrator 940, which further processes them via database server 950, AI / ML server 960, indexer server 970, or any combination thereof. As discussed herein and referenced... Figure 8 Actuator 912 can be a robot component.

[0130] In some embodiments, an RPA robot represents an association between a machine name and a username. A robot can manage multiple actuators simultaneously. This is possible on computing systems that support running multiple interactive sessions concurrently (e.g., Windows). ® On Server 2012, multiple RPA bots can run simultaneously, each using a unique username on a separate Windows machine. ® Runs in the session.

[0131] The orchestrator 940 can also facilitate interaction between AI agents and AI / ML models via the AI / ML server 960, which can store and / or facilitate the processing of generative AI models (e.g., Figure 1 Access to the generative AI model 172.

[0132] In some embodiments, most actions performed by the user in the interface of orchestrator 940 (e.g., via browser 981) are performed by calling various APIs. Such actions may include, but are not limited to, starting jobs on robots, adding / removing data from queues, scheduling jobs for unattended operation, etc., without departing from the scope of the invention. Web application 942 is the visual layer of the server platform. In this embodiment, web application 942 uses Hypertext Markup Language (HTML) and JavaScript (JS). However, any desired markup language, scripting language, or any other format may be used without departing from the scope of the invention. In this embodiment, the user interacts with a webpage from web application 942 via browser 941 to perform various actions to control orchestrator 940. For example, the user can create RPA robot groups, assign packages to RPA robots, analyze logs for each RPA robot and / or each process, start and stop RPA robots, etc.

[0133] In addition to the web application 942, the orchestrator 940 also includes a service layer that exposes the oData REST API endpoint 944. However, other endpoints may be included without departing from the scope of the invention. The REST API is consumed by the web application 942 and the executive agent 914. In this embodiment, the executive agent 914 is the supervisor of one or more robots on the client computer.

[0134] The REST API in this embodiment covers configuration, logging, monitoring, and queuing functionality. In some embodiments, the configuration endpoint can be used to define and configure application users, licenses, bots, assets, versions, and environments. For example, the logging REST endpoint can be used to log various information, such as errors, explicit messages sent by the bot, and other environment-specific information. The bot can use the deployment REST endpoint to query the package version that should be executed when using the start job command in the orchestrator 940. The queuing REST endpoint can be responsible for queue and queue item management, such as adding data to the queue, retrieving transactions from the queue, and setting the status of transactions.

[0135] The monitoring REST endpoint can monitor the web application 942 and the executive agent 914. The notification and monitoring API 946 can be a REST endpoint used to register the executive agent 914, deliver configuration settings to the executive agent 914, and send / receive notifications from the server and the executive agent 914. In some embodiments, the notification and monitoring API 946 can also use WebSocket communication. Figure 9 As shown, one or more activities / actions described in this article are represented by arrow 949.

[0136] In some embodiments, the API in service layer 934 can be accessed by configuring an appropriate API access path, for example, based on whether orchestrator 940 and the entire hyper-automation system have an on-premises deployment type or a cloud-based deployment type. The API for orchestrator 940 can provide customized methods for querying statistics about various entities registered in orchestrator 940. In some embodiments, each logical resource can be an oData entity. In such entities, components such as robots, processes, and queues can have attributes, relationships, and operations. In some embodiments, the API of orchestrator 940 can be consumed by web application 942 and / or executive agent 914 in two ways: (1) by obtaining API access information from orchestrator 940; or (2) by using an oAuth flow through registration with an external application.

[0137] In this embodiment, the persistence layer 935 includes three servers: a database server 950 (e.g., an SQL server), an AI / ML server 960 (e.g., a server providing AI / ML model services, such as AI hub functionality), and an indexer server 970. In this embodiment, the database server 950 stores configurations of robots and AI agents, robot and AI agent groups, AOPs, associated processes, users, roles, schedules, etc. In some embodiments, this information is managed via a web application 942. The database server 950 can manage queues and queue items. In some embodiments, the database server 950 can store messages recorded by robots and AI agents (in addition to or instead of the indexer server 970). The database server 950 can also store, for example, process mining, task mining, and / or task capture related data received from a listener 930 installed on a client. Although no arrow is shown between the listener 930 and the database 950, it should be understood that in some embodiments, the listener 930 is capable of communicating with the database 950, and vice versa. This data can be stored in the form of PDDs, images, XAML documents, etc. It should be noted that structured and / or unstructured data can be stored. Listener 930 can be configured to intercept user actions, processes, tasks, and performance metrics on the corresponding computing system where it resides. For example, listener 930 can record user actions (e.g., clicks, typed characters, locations, applications, active elements, times, etc.) on its corresponding computing system and then convert these into a suitable format for provision to database server 950 and storage therein.

[0138] The AI / ML Server 960 facilitates the integration of AI / ML models into automation systems. Pre-built AI / ML models, model templates, and various deployment options make these functionalities accessible even to non-data scientists. Deployed automation (e.g., RPA bots and / or AI agents) can invoke AI / ML models from the AI / ML Server 960. The performance of AI / ML models can be monitored, trained, and improved using user-verified data. The AI / ML Server 960 can schedule and execute training jobs to train new versions of AI / ML models. The AI / ML model server can also store and / or access generative AI models.

[0139] The AI / ML Server 960 can store data related to AI / ML models and ML packages, enabling the configuration of various ML skills for users during development. As used herein, ML skills are pre-built and trained ML models used in processes that can be automated, for example. The AI / ML Server 960 can also store data on document understanding technologies and frameworks, algorithms, and software packages for various AI / ML capabilities, including but not limited to intent analysis, NLP, speech analysis, and different types of AI / ML models.

[0140] Indexer server 970, optional in some embodiments, stores and indexes information recorded by the robot. In some embodiments, indexer server 970 can be disabled via configuration settings. In some embodiments, indexer server 970 uses ElasticSearch. ® It is an open-source full-text search engine project. Messages recorded by the bot (e.g., using activities like log messages or writing lines) can be sent to indexer server 970 via logging REST endpoints (one or more), where they are indexed for future use.

[0141] Figure 10 This is an architecture diagram illustrating the relationship 1000 between a designer 1010, activities 1020, 1030, 1040, 1050, a driver 1060, an API 1070, and an AI / ML model 1080, according to one or more embodiments. As described above, AI agents, AOPs, or developers use the designer 1010 to develop automated workflows (e.g., workflows executed by RPA robots, AI agents, and AOPs).

[0142] AI agents, AOPs, or developers can design and configure workflows 1092, design and configure agent-based automation for AI agents 1094 (e.g., providing natural language descriptions, context, tools, etc. for AI agents), and design and configure AOPs 1096 (see also...). Figure 4 , Figure 5 and Figure 6In some embodiments, various types of activities can be displayed to the developer. The designer 1010 can be accessed locally or remotely on the user's computing system (e.g., via a VM or a local web browser interacting with a remote network server). The RPA robot's workflow can include user-defined activities 1020, API-driven activities 1030, AI / ML activities 1040, and / or UI automation activities 1050. User-defined activities 1020 and API-driven activities 1040 interact with the application via their APIs. In some embodiments, user-defined activities 1020 and / or AI / ML activities 1040 can invoke one or more AI / ML models 1080, which can be located locally and / or remotely on the computing system on which the robot operates.

[0143] Some embodiments are capable of identifying non-textual visual parts in an image, referred to herein as CV. However, it should be noted that in some embodiments, CV is combined with OCR. CV can be performed at least in part by one or more AI / ML models 1080. Some CV activities associated with these parts may include, but are not limited to, extracting text from segmented label data using OCR, fuzzy text matching, cropping segmented label data using ML, comparing text extracted from label data with basic fact data, etc. In some embodiments, there may be hundreds or even thousands of activities that can be implemented in user-defined activities 1020. However, any number and / or type of activities may be used without departing from the scope of the invention.

[0144] UI automation activities 1050 are a subset of specific low-level activities written in low-level code and designed for easy interaction with the screen. UI automation activities 1050 facilitate these interactions via drivers 1060, which allow the robot to interact with desired software. For example, drivers 1060 may include operating system (OS) drivers 1062, browser drivers 1064, VM ​​drivers 1066, enterprise application drivers 1068, etc. In some embodiments, UI automation activities 1050 may use one or more AI / ML models 1080 to perform interactions with the computing system. In some embodiments, AI / ML models 1080 may enhance drivers 1060 or completely replace them. In fact, in some embodiments, drivers 1060 are not included.

[0145] Driver 1060 can interact with the OS at a lower level via OS driver 1062, searching for hooks, monitoring keys, etc. Driver 1060 can facilitate integration with Chrome. ® IE ® Citrix ® SAP ®Integration of features such as "click" actions. For example, the "click" activity performs the same role in these different applications via driver 1060.

[0146] Figure 11 This is an architectural diagram illustrating a computing system 1100 configured to perform agent-style automation according to one or more embodiments. In some embodiments, computing system 1100 may be one or more computing systems described herein. In some embodiments, computing system 1100 may be one or more computing systems depicted and / or described herein. In some embodiments, computing system 1100 may be part of a hyper-automation system, such as... Figure 1 and Figure 8 As shown. The computing system 1100 includes a bus 1105 or other communication mechanism for transmitting information, and processors (one or more) 1110 coupled to the bus (one or more) 1105 for processing information. The processors (one or more) 1110 can be any type of general-purpose or special-purpose processor, including a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a graphics processing unit (GPU), multiple instances thereof, and / or any combination thereof. The processors (one or more) 1110 may also have multiple processing cores, and at least some cores may be configured to perform specific functions. In some embodiments, multi-parallel processing may be used. In some embodiments, at least one of the processors (one or more) 1110 may be a neuromorphic circuit that includes processing elements that simulate biological neurons. In some embodiments, the neuromorphic circuit may not require typical components of a von Neumann computing architecture.

[0147] The computing system 1100 also includes a memory 1115 for storing information and instructions to be executed by a processor (one or more) 1110. The memory 1115 may consist of any combination of random access memory (RAM), read-only memory (ROM), flash memory, cache, static memory such as a disk or optical disk, or any other type of non-transitory computer-readable medium or combinations thereof. The non-transitory computer-readable medium may be any available medium accessible by the processor (one or more) 1110 and may include volatile media, non-volatile media, or both. The medium may also be removable, non-removable, or both. The computing system 1100 includes a communication device 1120, such as a transceiver, to provide access to a communication network via wireless and / or wired connections. In some embodiments, the communication device 1120 may include one or more antennas that are single, arrayed, phased, switched, beamformed, beamcontrolled, combinations thereof, and / or any other antenna configuration without departing from the scope of the invention.

[0148] Processors (one or more) 1110 are also coupled to a display 1125 via a bus 1105. Any suitable display device and tactile I / O can be used without departing from the scope of the invention. A keyboard 1130 and a cursor control device 1135, such as a computer mouse, touchpad, etc., are further coupled to the bus 1105 to enable user interaction with the computing system 1100. However, in some embodiments, a physical keyboard and mouse may be absent, and the user may interact with the device solely through the display 1125 and / or a touchpad (not shown). Any type and combination of input devices can be used, depending on design choice. In some embodiments, no physical input device and / or display is present. For example, a user may interact remotely with the computing system 1100 via another computing system with which it communicates, or the computing system 1100 may operate autonomously.

[0149] Memory 1115 stores software modules that provide functionality when executed by processor(s) 1110. These modules include the operating system 1140 of computing system 1100.

[0150] These modules also include module 1145, which is configured to perform all or part of the processes described herein or their derivatives. Module 1145 includes feedback operations as described herein, including completion verification, agent accuracy assessment, and agent health score generation. Module 1145 can address problems that conventional automation techniques cannot solve. For example, module 1145 generates and stores agent health score definitions and agent health scores. Agent health scores are metrics that measure agent performance and can be used to identify problems and improve the experience. Agent health scores can be any alphanumeric value along a range (e.g., from 0 to 100 or from 0.00 to 1.00) and can be represented as percentages, currency, numbers, etc. Agent health score definitions can describe how alphanumeric values ​​are identified, which factors contribute to the alphanumeric values, and the weight of each factor's contribution. According to one or more embodiments, agent health score definitions can be based on performance (e.g., latency and average response time), reliability (e.g., error rate), compliance (e.g., throughput), and business impact (e.g., processor usage and memory usage) corresponding to this set of standardized metrics. In addition, one or more agent health score definitions may include, but are not limited to, assessing infrastructure, runtime performance, developer experience, security and compliance, and business impact.

[0151] According to one or more embodiments, Module 1145 may include core functional requirements and features for agent health assessment. Module 1145 may include standardized metrics for defining and calculating health scores based on performance, reliability, compliance, and business impact, and providing customizable weights for these metrics to align with organizational priorities. Module 1145 may include performance assessment operations that measure success rates, error frequencies, and execution efficiency in real-time and simulated environments, and compare performance across different use cases or business processes. Module 1145 may include behavioral monitoring that records and analyzes runtime behavior to detect anomalies, slowdowns, or deviations from expected patterns, and provides actionable insights into failures and edge cases. Module 1145 may include compliance and security insight operations to ensure adherence to organizational and regulatory standards, and to flag potential risks such as data privacy violations or unapproved process deviations. Module 1145 may include business impact measurement operations that can correlate agent activities with KPIs such as cost savings, task throughput, and customer satisfaction. Module 1145 may include integration and reporting operations that seamlessly integrate with applications and analytics tools, and generate visual dashboards and exportable reports for stakeholders.

[0152] According to one or more embodiments, module 1145 can implement agent health scoring operations including metric calculation and aggregation, behavioral analysis, system integration, and feedback loops for optimization. Metric calculation and aggregation define health score components. Health score components can include performance, reliability, behavioral consistency, compliance and security, and business impact. Performance can include task success rate, average execution time, and error frequency. Reliability can include availability, downtime metrics, and retry rate. Behavioral consistency can include alignment with expected runtime patterns. Compliance and security can include adherence to rules and data protection standards. Business impact can include impact on KPIs, such as SLA compliance, cost reduction, and efficiency. For flexibility, a weighted scoring model with configurable parameters is used. Behavioral analysis can employ machine learning to identify anomalies in runtime logs and process execution. Heuristics and feedback loops are used to predict potential failures. System integration can provide plug-ins for the UiPath environment to capture task-level and process-level metrics. REST API support for external data ingestion and health score evaluation is enabled. Feedback loops for optimization can include periodically recalibrating scores based on user feedback, performance trends, and new compliance requirements.

[0153] The module also includes an intelligent agent memory module 1147, which is configured to execute all or part of the processes described herein or derivatives thereof, including but not limited to executing an intelligent agent memory that stores contextual bases and other results for automation. By way of example, the intelligent agent memory module 1147 is configured to dynamically cache (i.e., store) upgrades, tool invocations, user interactions (once or multiple times) or feedback, contextual bases, etc., to provide enhanced efficiency and minimize invocations.

[0154] The computing system 1100 may include one or more additional functional modules 1150, which include additional functions. As an example, the one or more additional functional modules 1150 may include an extraction and search module configured to perform context anchoring within advanced agent extraction and search automation.

[0155] Those skilled in the art will understand that, without departing from the scope of this invention, the "computing system" can be implemented as a server, embedded computing system, personal computer, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartwatch, quantum computing system, or any other suitable computing device, or a combination of such devices. Presenting the foregoing functionality as being performed by a "system" is not intended to limit the scope of the invention in any way, but rather to provide an example of one of many embodiments of the invention. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in a localized and distributed manner consistent with computing technologies, including cloud computing systems. The computing system may be part of or accessible from a LAN, mobile communication network, satellite communication network, the Internet, public or private cloud, hybrid cloud, server cluster, any combination thereof, etc. Any localized or distributed architecture may be used without departing from the scope of this invention.

[0156] It should be noted that some of the system features described in this specification are presented as modules to more specifically emphasize their implementation independence. For example, modules can be implemented as hardware circuits, including custom-designed very large-scale integrated circuits (VLSI) or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Modules can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0157] Modules can also be implemented, at least partially, in software and executed by various types of processors. Identifying units of executable code can include, for example, one or more physical or logical blocks of computer instructions, which can be organized, for example, into objects, procedures, or functions. However, the executable code of the identified module does not need to be physically located together, but can include different instructions stored in different locations that, when logically combined, constitute the module and perform its intended purpose. Furthermore, without departing from the scope of the invention, modules can be stored on computer-readable media, such as hard disk drives, flash memory devices, RAM, magnetic tape, and / or any other such non-transitory computer-readable media for storing data.

[0158] In practice, an executable code module can be a single instruction or multiple instructions, and may even be distributed across multiple different code segments, different programs, and multiple memory devices. Similarly, operational data can be identified and illustrated within the module, and can be materialized in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset, or it can be distributed across different locations, including different storage devices, and can exist at least in part simply as electronic signals on a system or network.

[0159] Various types of AI / ML models can be trained and deployed without departing from the scope of this invention. For example, Figure 12A An example of a neural network 1200 according to one or more embodiments is illustrated. This neural network 1200 has been trained to receive inputs (as shown in column 1210) from input layer “neurons” 1 to 1 (as shown in column 1220). The neural network 1200 includes multiple hidden layers (as shown in columns 1230 and 1240). DLNNs and shallow learning neural networks (SLNNs) typically have multiple layers, although SLNNs may have only one or two layers in some cases, and are generally fewer than DLNNs. Typically, a neural network architecture includes an input layer, multiple intermediate layers (e.g., hidden layers), and an output layer (as shown in output layer 1250), as in the case of neural network 1200.

[0160] DLNNs typically have many layers (e.g., 10, 50, 200, etc.), and subsequent layers often reuse features from previous layers to compute more complex general functions. SLNNs, on the other hand, tend to have only a few layers and are relatively fast to train because expert features are created beforehand from the original data samples. However, feature extraction is laborious. DLNNs, on the other hand, generally do not require expert features but often require longer training times and more layers.

[0161] For both methods, layers are trained simultaneously on the training set, and overfitting is typically checked on isolated cross-validation sets. Both techniques produce excellent results, and there is considerable enthusiasm for both approaches. The optimal size, shape, and number of layers vary depending on the problem the corresponding neural network is addressing.

[0162] Back Figure 12A Inputs from various industries and application areas, unique industry terminology, complex document structures, and enterprise-specific information with pre-trained knowledge are provided as input layers and fed as input to J neurons in hidden layer 1. Various other inputs are possible, including but not limited to computational system state information, published automation rules, business rules, information about what workflows and / or tasks are related, initial definitions of automation, process automation documents, etc. All these inputs are fed into each neuron. In this example, various architectures that can be used individually or in combination are possible, including but not limited to feedforward networks, radial basis function networks, deep feedforward networks, deep convolutional inverse graph networks, convolutional neural networks, recurrent neural networks, artificial neural networks, long-term / short-term memory networks, gated recurrent unit networks, generative adversarial networks, liquid state machines, autoencoders, variational autoencoders, denoising autoencoders, sparse autoencoders, extreme learning machines, echo state networks, Markov chains, Hopfield networks, Boltzmann machines, restricted Boltzmann machines, deep residual networks, Kohonen networks, deep belief networks, deep convolutional networks, support vector machines, neural Turing machines, or any other suitable type or combination of neural networks, without departing from the scope of the invention.

[0163] Hidden layer 2 (1240) receives input from hidden layer 1 (1230), hidden layer 3 receives input from hidden layer 2 (1240), and so on for all hidden layers until the last hidden layer (as shown by ellipsis 1255) uses its output as input to the output layer. While multiple suggestions are illustrated as outputs here, in some embodiments, only a single output suggestion is provided. In some embodiments, the suggestions are ranked based on confidence scores. In this embodiment, the output may be an accurate response to a specific or recent query.

[0164] It should be noted that the number of neurons I, J, K, and L are not necessarily equal. Therefore, any desired number of layers can be used for a given layer of the neural network 1200 without departing from the scope of the invention. In fact, in some embodiments, the types of neurons in a given layer may not be exactly the same.

[0165] The neural network 1200 is trained to assign confidence scores (one or more) to appropriate outputs. To reduce inaccurate predictions, in some embodiments, only those results whose confidence scores meet or exceed a confidence threshold may be provided. For example, if the confidence threshold is 80%, outputs with confidence scores exceeding that amount may be used, while the remaining outputs are ignored. According to one or more embodiments, the output layer 1250 indicates that two text fields (as shown in outputs 1261 and 1262), a text label (as shown in output 1263), and a submit button (as shown in output 1265) have been found. The neural network 1200 can provide the location, size, image, and / or confidence scores of these elements without departing from the scope of one or more embodiments herein, which may then be used by an RPA bot or another automation that uses the output for a given purpose.

[0166] Neural networks are probabilistic constructs that typically have confidence scores (one or more). These scores can be learned by an AI / ML model based on the frequency with which similar inputs are correctly identified during training. Some common types of confidence scores include decimal numbers between 0 and 1 (which can also be interpreted as confidence percentages), numbers between negative ∞ and positive ∞, a set of expressions (e.g., "low," "medium," and "high"), etc. Various post-processing calibration techniques can also be employed to attempt to obtain more accurate confidence scores, such as temperature scaling, batch normalization, weight decay, negative log-likelihood (NLL), etc.

[0167] In neural networks, "neurons" are implemented as mathematical functions through algorithms, typically based on the functionalization of biological neurons. Neurons receive weighted inputs and have activation functions that sum and control whether they pass their output to the next layer. This activation function can be a non-linear threshold activity function, where nothing happens if the value is below a threshold, but the function responds linearly above the threshold (i.e., corrected linear unit (ReLU) non-linearity). Summation and ReLU functions are used in deep learning because real neurons can have approximately similar activity functions. Information can be subtracted, added, etc., via linear transformations. Essentially, neurons act as gating functions, passing output to the next layer, governed by their underlying mathematical functions. In some embodiments, different functions can be used for at least some neurons.

[0168] Figure 12B The diagram illustrates an example of neuron 1295. Input from the previous layer. Assigned corresponding weights Therefore, the collective input from the previous neuron 1 is These weighted inputs are used for neuron summation functions modified by bias, such as: (1)

[0169] The sum and the activation function Comparisons are made to determine whether neurons are "activated." For example, It can be given by the following formula: (2)

[0170] Therefore, the output of neuron 1295 y It can be given by the following formula: (3)

[0171] In this case, neuron 1295 is a single-layer perceptron. However, any suitable neuron type or combination of neuron types can be used without departing from the scope of the invention. It should also be noted that, in some embodiments, the ranges of weight values ​​and / or the output values ​​(one or more) of the activation function may differ without departing from the scope of the invention.

[0172] A goal, or "reward function," is often employed. The reward function explores intermediate transitions and steps with short-term and long-term rewards to guide the search of the state space and attempt to achieve the goal (e.g., finding the most accurate answer to a user query based on associated metrics). During training, various labeled data are fed through the neural network. Successful labels strengthen the weights of the neuron inputs, while unsuccessful labels weaken them. Cost functions such as the error of variance (MSE) or gradient descent can be used to penalize slightly incorrect predictions that are much smaller than very incorrect predictions. If the performance of the AI / ML model does not improve after a certain number of training iterations, data scientists can modify the reward function to provide corrections for incorrect predictions, etc.

[0173] Backpropagation is a technique for optimizing synaptic weights in a feedforward neural network. It can be used to "open" the hidden layers of a neural network to see how much loss each node is responsible for, and then update the weights to minimize the loss by giving lower weights to nodes with higher error rates, and vice versa. In other words, backpropagation allows data scientists to iteratively adjust the weights to minimize the difference between the actual and expected outputs.

[0174] The mathematical foundation of the backpropagation algorithm is optimization theory. In supervised learning, training data with known outputs is passed through a neural network, and the error is calculated using a cost function derived from the known target output; this gives the error for backpropagation. The error is then calculated at the output and converted into correction values ​​for the network weights to minimize the error.

[0175] In the context of supervised learning, an example of backpropagation is provided below. Column vector input. xThrough each layer of the network A series of N One nonlinear activity function The process involves multiplying the output of a given layer by a synaptic matrix. And add a bias vector Network output o It is given by the following formula (4)

[0176] In some embodiments, o With target output t Comparison can lead to errors. This is the expectation that is minimized.

[0177] Optimization in the form of gradient descent can be used to modify the synaptic weights of each layer. To minimize the error. The gradient descent procedure requires, given a known target output... t Input x Calculate the output under the following circumstances o And it produces errors. o -- t This global error is then propagated backward, giving the local error for the weight update, the calculation of which is similar to, but not exactly the same as, the calculation used for forward propagation. In particular, the backpropagation step typically requires the form: The activity function, where It is a layer j Network activities at the location (i.e., ),in and apostrophe Represents the activity function f The derivative of .

[0178] Weight updates can be calculated using the following formula: (5) (6) (7) (8) (9)

[0179] in This represents the Hadamard product (i.e., the element-wise product of two vectors). T This represents the matrix transpose, and express ,in Here, learning rate The choice was based on considerations related to machine learning. Below, This relates to the neural Hebbian learning mechanism used in neural implementations. Note the synapse. W and b These can be combined into a large synaptic matrix, where it is assumed that the input vector has additional synapses, and represents... b The extra column for synapses is categorized into W .

[0180] The AI / ML model can be trained over multiple epochs until it reaches a good level of accuracy (e.g., 97% or better after approximately 2000 epochs using an F2 or F4 threshold). In some embodiments, this level of accuracy can be determined using F1 scoring, F2 scoring, F4 scoring, or any other suitable technique without departing from the scope of the invention. Once trained on the training data, the AI / ML model can be tested on a set of evaluation data that the AI / ML model has not previously encountered. This facilitates ensuring that the AI / ML model does not "overfit," resulting in good performance on the training data but poor performance on other data.

[0181] In some embodiments, the achievable accuracy level of the AI / ML model may be unknown. Therefore, if the accuracy of the AI / ML model begins to decline when analyzing evaluation data (i.e., the model performs well on training data but starts to perform poorly on evaluation data), the AI / ML model may undergo more training iterations on the training data (and / or new training data). In some embodiments, an AI / ML model is deployed only if a certain level of accuracy is achieved or the accuracy of the trained AI / ML model is superior to that of existing deployed AI / ML models. In some embodiments, a collection of trained AI / ML models can be used to perform a task. For example, one AI / ML model may be trained to recognize images, another to recognize text, and yet another to recognize semantics and / or ontology associations, etc.

[0182] It should be noted that, in addition to or instead of neural networks, some implementations may use transformer networks such as SentenceTransformers™, a Python™ framework for state-of-the-art sentence, text, and image embeddings. These transformer networks learn associations between words and phrases with high and low scores. This trains AI / ML models to determine what is close to the input and what is not. Transformer networks can use not only pairs of words / phrases but also field length and field type.

[0183] In some embodiments, NLP models such as word2vec, BERT, GPT-3, ChatGPT, and other LLMs can be used to facilitate semantic understanding and provide more accurate and human-like answers. Other techniques, such as clustering algorithms, can be used to find similarities between groups of elements. Clustering algorithms can include, but are not limited to, density-based algorithms, distribution-based algorithms, centroid-based algorithms, and hierarchical algorithms. Examples include k-valued clustering, DBSCAN clustering, Gaussian mixture model (GMM) algorithms, balanced iterative reduction, and hierarchical clustering (BIRCH) algorithms. These techniques can also aid in classification.

[0184] Figure 13 This is an architecture diagram illustrating a reference architecture 1300 for a generative AI model according to one or more embodiments. The architecture consists of several layers: an API plugin, a cue dictionary, vector data source ingestion, access processing control, a model training pipeline, an evaluation layer for evaluating illusions / telemetry / evaluation, a BYOM embedding layer, and an LLM orchestration layer. There are also retrieval plugins, access control plugins, and API plugins integrated into enterprise systems.

[0185] Reference Architecture 1300 has three main processes.

[0186] Process 1: Ingestion can include data ingestion and training processes. For example, data is read from multiple data stores, preprocessed, chunked, and trained using embedding models (e.g., RAG and training pipelines (i.e., fine-tuning)). Vector databases store chunked document embeddings (e.g., vector embeddings), which allows for better semantic, similarity-based data retrieval.

[0187] Process 2: Retrieval may include on-the-fly enhancements to the data retrieval process. For example, once a user query reaches the API layer, a suggestion is selected, and then data retrieval is performed through a vector database or API plugin to obtain the correct contextual data before passing the suggestion to the LLM layer.

[0188] Process 3: Inference may include an LLM inference process. For example, a general base model or a self-hosted base model can be used here. A fine-tuned model can be used when tailored to a specific task or use case. Evaluate the accuracy of the response and other metrics, including hallucinations.

[0189] It should be noted that in some embodiments, generative AI models with multiple "heads" may be used. A head refers to the output layer of a generative AI model. Generative AI models, such as... Figure 1 Generative AI models172 typically have a series of layers, and each head usually shares the first few layers of the model before branching into its own different layers.

[0190] Figure 14 This is a flowchart illustrating process 1400 for training one or more AI / ML models (or more) according to one or more embodiments. In some embodiments, as described above, the AI / ML model (or more) may be a generative AI model. In the case of neural networks, the architecture typically includes multiple layers of neurons, including input, output, and hidden layers. See, for example, [link to documentation]. Figure 12A and 12B The hidden layers in the middle process the input data and generate intermediate representations of the input used to generate the output. These hidden layers can include various types of neurons, such as convolutional neurons, recurrent neurons, and / or transform neurons. Generative AI models can also have different layers.

[0191] According to one or more embodiments, Figure 14 The process 1400 executed in the document can be performed through automation implemented in a computer program as described herein. The computer program can be implemented on a non-transitory computer-readable medium. Computer-readable media can be, but is not limited to, hard disk drives, flash memory devices, RAM, magnetic tape, and / or any other such media or combinations thereof used for storing data. The computer program can include functions for controlling a computing system (e.g., see...). Figure 11 The processor (one or more) is used to implement Figure 14 The encoded instructions of all or part of the process 1400 described herein may also be stored on a computer-readable medium.

[0192] In some embodiments, the training process begins in box 1410 with data from different industries and application domains, unique industry terminology, complex document structures, and enterprise-specific information with pre-trained knowledge, whether or not labeled. In the case of generative AI models that are typically trained in general, the training process can be skipped unless fine-tuning of the model is desired, as discussed in more detail below. The AI / ML model is then trained over multiple epochs in box 1420, and the results are examined in box 1430. While various types of AI / ML models can be used, LLMs and other generative AI models are typically trained (fine-tuned) using a process called “supervised learning,” which has also been discussed above. Supervised learning involves providing the model with a large dataset that it uses to learn the relationship between inputs and outputs. In the training process, the model adjusts the weights and biases of neurons in the neural network to minimize the difference between the predicted outputs and the actual outputs in the training dataset.

[0193] In some embodiments, one aspect of the model is the use of transfer learning. For example, transfer learning can leverage a pre-trained model, such as ChatGPT, which is fine-tuned for a specific task or domain in box 1420. This allows the model to utilize knowledge already learned from the pre-training phase and adapt it to a specific application via the training phase of box 1420.

[0194] The pre-training phase involves training the model on a more general initial training dataset. During this phase, the model learns relationships within the data. In the fine-tuning phase (e.g., if the pre-trained model is used as the initial basis for the final model, and in some embodiments, is performed during box 1420 in addition to or instead of the initial training phase), the pre-trained model is adapted to a specific task or domain by training it on a smaller, task-specific dataset. For example, in some embodiments, the model may focus on certain types (one or more) of data sources. This can help the model identify data elements more accurately than a generative AI model pre-trained alone. Fine-tuning allows the model to learn nuances in the sources, such as specific vocabulary and grammar, certain graphical features, certain data formats, etc., without requiring as much data as it would need to train the model from scratch. By leveraging the knowledge learned in the pre-training phase, a fine-tuned model can achieve state-of-the-art performance on a specific task with relatively little additional training data.

[0195] In some embodiments, if the AI / ML model fails to meet the expected confidence threshold at decision box 1440, process 1400 proceeds to box 1450 (as indicated by the "No" arrow). At box 1450, supplementary training data and / or modification of the reward function are performed to help the AI / ML model better achieve its objective, and process 1400 returns to box 1420.

[0196] If the AI / ML model meets the confidence threshold at decision box 1440, process 1400 proceeds to box 1460 (as indicated by the "Yes" arrow). At box 1460, the AI / ML model is tested on evaluation data to ensure that it generalizes well and does not overfit relative to the training data. The evaluation data includes information that the AI / ML model has not previously processed.

[0197] If the data evaluation at decision box 1470 meets the confidence threshold, process 1400 proceeds to box 1480 (as indicated by the "Yes" arrow). The AI / ML model is deployed at 1480. If not, process 1400 returns to box 1450 (as indicated by the "No" arrow), and the AI / ML model is trained further.

[0198] Now go to Figure 15A flowchart illustrating process 1500 is provided according to one or more embodiments. Process 1500 is executed in a hyper-automation system (e.g., hyper-automation system 100) implemented in a computer program according to one or more embodiments, as described herein. The computer code may include one or more agent-based automation and agent health score generation. The computer program may be implemented on a non-transitory computer-readable medium. The computer program may include methods for controlling a computing system (e.g., see...). Figure 11 (one or more) processors to implement all or part of the coded instructions of the described process 1500.

[0199] Typically, the hyperautomation system's process 1500 operates one or more agents and agent-based automation based on agent health score generation. For example, agent health score generation in a hyperautomation system may include defining and calculating agent health scores based on the performance, reliability, compliance, and business impact of agents performing one or more agent-based automata (e.g., actions or tasks within a workflow), and their corresponding outputs. According to one or more embodiments, the hyperautomation system performs autopilot operations for agent evaluation and agent health scoring, which include a mix of metrics, performance testing, business impact, and reporting. The hyperautomation system can then provide clear goals and objectives before developing agents (e.g., critical for accurately defining agent objectives and desired outcomes) by clarifying specific measurable targets, understanding the environment in which the agent operates, identifying key performance metrics, and establishing clear success criteria. Furthermore, agents can predict the next step in agent-based automation. Using this prediction, agents can provide multiple suggestions for performing the next step based on each agent health score for each agent and multiple suggested thresholds.

[0200] Process 1500 begins at box 1510, where the hyperautomation system generates a set of standardized metrics. The hyperautomation system can generate a set of standardized metrics for application to one or more agent-based automations (e.g., actions or tasks within a workflow), one or more agents, and their respective outputs. Agents can be one of AI agents, RPA robots, and AOP (e.g., LLM agents). According to one or more embodiments, this set of standardized metrics can include error rate, throughput, processor usage, memory usage, latency, and average response time. Error rate can include the percentage of failed requests compared to the total number of requests from the agent. Error rate can indicate a bug, connectivity problem, or system overload. Throughput can include the number of requests or transactions that the agent can process within a given time frame. Throughput can improve performance and scalability. Processor usage can include the amount of CPU resources used by the agent and can indicate agent responsiveness. Memory usage can include the amount of memory resources used by the agent. Latency can include the amount of request processing time. Average response time can include the average time it takes for the agent to respond to a request.

[0201] In subframe 1512, the hyper-automated system generates an agent health score definition. An agent health score is a metric that measures how well an agent performs and can be used to identify problems and improve the experience. According to one or more embodiments, the agent health score definition may be based on performance (e.g., latency and average response time), reliability (e.g., error rate), compliance (e.g., throughput), and business impact (e.g., processor usage and memory usage) corresponding to this set of standardized metrics. Furthermore, one or more agent health score definitions may include, but are not limited to, assessing one or more of infrastructure, runtime performance, developer experience, security and compliance, and business impact.

[0202] The assessment infrastructure may also include, but is not limited to, one or more of the following sub-definitions: development debugging, trace integrity, LLM call visibility (input / output / embedding), tool execution tracing, context window tracing, memory / state management visibility, debug interface quality, interactive playback functionality, step-through debugging, visual tracing analysis, comparison tools, tracing analysis, performance metrics, token usage, cost analysis, latency decomposition, test framework, assessment coverage, functional testing, performance testing, security testing, compliance testing, benchmark management, baseline metrics, performance thresholds, regression testing, cross-version comparison, A / B testing infrastructure, test configuration, statistical significance, performance differences, cost impact analysis, dataset management, data quality, coverage metrics, diversity metrics, relevance scoring, freshness tracking, data manipulation, input / output capabilities, synthetic data generation, anonymization validity, version control, feedback integration, manual verification workflow, ground truth, and quality assurance metrics.

[0203] Runtime performance may also include, but is not limited to, one or more of the following sub-definitions: operation monitoring, system health, response latency, error rate, resource utilization, tool integration stability, anomaly detection, pattern recognition, threshold violations, trend analysis, alert accuracy, tracking clustering, performance patterns, error grouping, usage patterns, optimization opportunities, model behavior, output quality, task completion rate, accuracy measurement, consistency score, edge case handling, AI health indicators, model drift detection, cue word injection resistance, illusion rate, bias measurement, performance optimization, resource efficiency, computational optimization, memory usage, token optimization, cache effectiveness, cost management, API cost tracking, resource cost analysis, optimization suggestions, and ROI measurement.

[0204] Developer experience may also include, but is not limited to, one or more of the following sub-definitions: productivity metrics, development speed, deployment time, issue resolution time, feature implementation speed, testing efficiency, tool effectiveness, debugging tool usage, tracing and analysis time, issue identification speed, resolution accuracy, documentation quality, coverage completeness, update frequency, usage examples, troubleshooting guides, code quality, static analysis, code standards, best practices, security checks, performance reviews, dynamic analysis, runtime behavior, error handling, resource usage, integration testing, developer satisfaction, usage metrics, tool adoption rate, feature utilization, documentation access, support tickets, feedback metrics, satisfaction ratings, feature requests, vulnerability reports, and enhancement suggestions.

[0205] Security and compliance may also include, but are not limited to, one or more of the following sub-definitions: security controls, authentication / authorization, data protection, vulnerability assessment, penetration testing, compliance framework, privacy requirements, data sovereignty, audit readiness, regulatory alignment, risk management, threat modeling, impact assessment, incident response and recovery planning.

[0206] Business impact may also include, but is not limited to, one or more of the following sub-definitions: value delivery, value time, cost savings, process improvement, customer satisfaction, operational efficiency, resource optimization, process automation, support requirements, maintenance costs, innovation impact, feature adoption, capability expansion, integration breadth, and market differentiation.

[0207] At subframe 1516, the hyper-automation system provides customizable weights for this set of standardized metrics to align with organizational priorities. Organizational priorities can provide customizable weights. Customizable weights can be of any scale. Examples of customizable weights could be from zero (0) to one hundred (100) or from zero (0.0) to one (1.0). According to one or more embodiments, the scoring criterion for the agent health score defined for each agent health score can be expressed as a percentage of both design time and runtime, from zero (0) to one hundred (100).

[0208] In box 1530, the hyperautomation system performs an evaluation of one or more agent-based automations and / or one or more agents. The evaluation can be performed by agents. According to one or more embodiments, "agent health," represented by an agent health score, is a way to evaluate agent quality by considering several different criteria. Agent health scores facilitate best practices for agent building and agent updating.

[0209] Based on one or more technological effects, advantages, and benefits, hyperautomation systems can evaluate agents starting with agent tasks and existing workflows. For example, developing effective LLM agents is achieved through a strategic approach to hyperautomation systems built upon existing organizational workflows. Automation of technology sales, engineering, and development can be performed by hyperautomation systems to audit current processes, identify repetitive, rule-based tasks, and other automations that serve as primary candidates for agent transformation. Furthermore, the strategic approach of hyperautomation systems minimizes risk and allows for the incremental building of skills in agent design.

[0210] According to one or more embodiments, a hyperautomation system can perform detailed workflow mapping, in which each step of an existing process is documented. Documenting each step may include recording decision points, input dependencies, and expected outputs. The hyperautomation system can choose workflows with well-defined, structured steps and well-defined success criteria. Examples include, but are not limited to, one or more of customer support ticket routing, preliminary sales qualification, and standard compliance checks. Based on one or more technical effects, advantages, and benefits, a hyperautomation system can start at a small scale to create a controlled environment for learning agent behavior, understanding nuances of immediate cues, and establishing evaluation frameworks. Based on one or more technical effects, advantages, and benefits, the hyperautomation system performs this methodological approach to create automation confidence in agent capabilities while demonstrating tangible value through incremental improvements in automation efficiency.

[0211] For example, the evaluation may include the operations in sub-boxes 1532, 1534, and 1536 to determine an agent health score. At sub-box 1532, the hyperautomation system measures the performance (e.g., success rate, error frequency, and execution efficiency) of one or more agents performing an agent task. The hyperautomation system also measures the agent's performance relative to other agent-based automations. The hyperautomation system repeats performance measurements for multiple agent tasks across different use cases or business processes. Measurements of success rate, error frequency, and execution efficiency can be performed in a real-world environment. Measurements of success rate, error frequency, and execution efficiency can also be performed in a sandbox or simulation environment. The agent's performance relative to the agent task is composited with this set of standardized metrics.

[0212] In subframe 1534, the performance of the hyperautomation system is assessed against the capabilities of the agents. Performance comparisons can be made across different use cases or business processes that utilize one or more agents for automation.

[0213] In subframe 1536, the hyperautomated system generates agent health scores (as defined previously in this document). The hyperautomated system generates agent health scores based on performance comparisons in subframe 1534. When generating agent health scores, the hyperautomated system uses customizable weights of a standardized metric to align with organizational priorities.

[0214] In box 1550, the hyperautomated system performs behavior monitoring. The object of behavior monitoring can be one or more agents and one or more agent-based automata. Behavior monitoring via the hyperautomated system can be an evaluation of agents with breadth and depth. Behavior monitoring by the hyperautomated system can include reviewing traces and trace logs. Traces can provide a comprehensive view of agent operation, what happens at each step in the loop, and provide mechanisms for inspection, enabling the examination of agent outputs, evaluation of agent plans, and ultimately iteration of agent structure (e.g., agent-based prompts, tools, context used, etc.). Trace logs can provide agents with critical diagnostic tools. Trace logs can provide detailed step-by-step execution breakdowns, visibility into decision-making processes, and identification of potential failure points or inefficiencies. One or more technical effects, benefits, and advantages of periodic trace reviews performed via the hyperautomated system include: considering agent evolution as needs change, considering unexpected behavior over time, enabling performance optimization through continuous analysis, providing tool effectiveness in light of degradation or obsolescence, and identifying key review focus areas (e.g., tool usage patterns, error rates, and recovery mechanisms).

[0215] For example, behavior monitoring may include the operations of subframes 1552, 1554, and 1556 to determine an agent’s health score.

[0216] In subframe 1552, while one or more agents are performing one or more agent-based automations, the hyperautomation system records the runtime behavior of the one or more agents. In subframe 1554, the hyperautomation system analyzes the runtime behavior. While analyzing the runtime behavior, the hyperautomation system detects anomalies, decelerations, or deviations from expected patterns. Expected patterns are how one or more agent-based automations should perform when the agents execute. In subframe 1556, the hyperautomation system generates actionable insights into failures and edge cases in the runtime behavior.

[0217] In box 1560, the hyper-automated system generates compliance and security insights. These insights can be protective measures based on actionable insights into runtime behavior and edge cases. As an example, implementing compliance and security insights may include the operations in sub-boxes 1562 and 1564.

[0218] In subframe 1562, the hyperautomation system ensures compliance with organizational and regulatory standards by reviewing and comparing organizational policies, regulations, privacy laws, and / or privacy policies with one or more intelligent agent automations. In subframe 1564, the hyperautomation system flags potential risks within one or more intelligent agent automations based on such comparisons. Examples of potential risks include, but are not limited to, data privacy violations or unapproved process deviations.

[0219] In box 1570, the hyperautomation system generates business impact metrics. According to one or more embodiments, the hyperautomation system correlates agent activities with an organization's KPIs and / or policy outcomes. Examples of KPIs and / or policy outcomes include, but are not limited to, one or more of cost savings, task throughput, and customer satisfaction.

[0220] In box 1580, the hyper-automated system performs integration and reporting. As an example, integration and reporting may include the operations in sub-boxes 1582 and 1584.

[0221] At subframe 1582, the hyperautomation system integrates seamlessly with one or more applications, designer applications, and analytics tools (e.g., UiPath Studio and Orchestrator). According to one or more embodiments, the hyperautomation system associates descriptive, concise names for tools. Each tool's name does not contain special characters or spaces and is accurately referenced within an agent-style prompt (e.g., lowercase alphanumeric characters without spaces or special characters (az, 0-9)). Furthermore, the name can be interpreted by the LLM or an agent using the LLM, so the agent knows when to invoke the tool and how to use it during runtime. The name should directly reflect the tool's functionality. Example tools include, but are not limited to, web_search for internet queries, code_interpreter for running code, document_analysis for parsing documents, and data_visualization for creating charts.

[0222] In subframe 1584, the hyper-automated system generates visual dashboards and exportable reports for stakeholders.

[0223] In box 1590, the hyperautomated system updates the agent's health score. This hyperautomated system can use behavioral monitoring, compliance and security insights, business impact measurement, and integration and reporting to update the agent's health score.

[0224] In box 1595, hyperautomation systems can further update the agents themselves. That is, hyperautomation systems provide a modular agent architecture design mechanism to create flexible, composable agent architectures capable of rapid skill integration and specialized task processing. In this respect, hyperautomation systems can design agents and agent-based automation with clear separation of concerns, plug-and-play technology modules, standardized interface protocols, and dynamic configuration capabilities.

[0225] According to one or more embodiments, a hyper-automated system can test one or more updated agents using one or more agent-based automation. That is, by embedding the evaluation process within a broader automated environment, the hyper-automated system can move beyond isolated agent testing. Therefore, the hyper-automated system can create agents and place them into agent activities that can run within an automated workflow, ensuring that the agent executes reliably when interconnected with other systems, thereby handling real-world complexity and interdependencies. One or more testing strategies for the hyper-automated system include, but are not limited to, end-to-end workflow simulation, integration point stress testing, cross-system communication verification, performance testing under variable load conditions, and one or more of failure mode and recovery mechanism evaluations. The hyper-automated system can also implement testing strategies using test suites (e.g., UiPath Test Suite™).

[0226] According to one or more embodiments, a hyper-automated system can use one or more agent-based automations to test one or more updated agents relative to success criteria. Success criteria may include, but are not limited to, quantitative metrics, qualitative metrics, and evaluation techniques. Quantitative metrics may include health score accuracy, problem identification, and performance benchmarks. For example, health score accuracy may include achieving a greater than 95% (>95%) alignment between agent health scores and observed agent performance. Problem identification may include reducing the average time to detect problems by 30% (30%) through agent health score insights. Performance benchmarks are capable of comparisons where the score difference between use cases is less than 5% (<5%). Qualitative metrics may include determining high satisfaction among developers and the COE team with score transparency and usability. Evaluation techniques may include piloting health scores between different use cases to confirm the reliability of the scores, as well as conducting surveys with developers, COE administrators, and business users.

[0227] Now go to Figure 16 A flowchart illustrating process 1600 is provided according to one or more embodiments. Process 1600 is executed in a hyperautomation system (e.g., hyperautomation system 100) described herein, implemented in a computer program according to one or more embodiments. The computer code may include one or more agent-based automation, agent health score generation, and evaluation score generation. The computer program may be implemented on a non-transitory computer-readable medium. The computer program may include methods for controlling a computing system (e.g., see...). Figure 11 One or more processors are used to implement all or part of the coded instructions of the described process 1600. Typically, process 1600 of a hyper-automated system operates one or more agents and agent-based automation for use in designing time-based agent health monitoring.

[0228] Process 1600 begins at box 1601, where the hyper-automated system begins execution. At box 1605, the hyper-automated system performs code linting. Typically, code linting is an automated process of the hyper-automated system that analyzes the code of one or more agents to identify potential errors, style issues, vulnerabilities, and questionable structures. More specifically, at box 1610, the hyper-automated system generates an agent code linting score based on information from one or more boxes 1611, 1613, 1615, 1617, and 1619. The agent code linting score is a rating / measurement of the agent design in terms of size and complexity.

[0229] At box 1611, the hyperautomated system provides a "single-mindedness" factor to the agent code inspection score generation. The single-mindedness factor emphasizes that agents should be optimized to combine multiple agents into a single, more efficient unit or to break down larger agents into smaller, more focused units. The "single-mindedness" factor allows agents to be neither too complex nor too simple, thus providing the technical effects, benefits, and advantages that allow for better performance and easier management. As an example, when creating an agent, it can be provided with various inputs whose quality is critical to the agent's performance (e.g., agent-style prompts, goals, and descriptions of arguments).

[0230] In box 1613, the hyperautomation system provides agent-style prompts for agent code checking and scoring generation. The prompts allow the agent to input received content or guide actions. Agent-style prompts must follow established guidelines to be effective. For example, a prompt for a tool for “converting $ to GBP” must be clear, as GBP is identified as a currency rather than a measure of weight. Furthermore, if the developer describes a tool for “converting $ to GBP”, it must be concise, as $ is identified by a symbol rather than the word “dollar,” while “pound” can be more concisely represented as £.

[0231] According to one or more embodiments, hyperautomation systems are capable of creating and iterating upon well-structured agent-like prompts. Typically, prompt engineering is an iterative process requiring rigorous experimentation and fine-tuning. Hyperautomation systems can provide a play-field environment (e.g., in the Agent Builder of UiPath Studio) to test and iterate on prompts and their structures. Agent prompts go beyond conventional single-turn LLM interactions (conventional automation techniques) by incorporating complex sets of instructions that guide the agent through multi-step reasoning and task decomposition. Furthermore, unlike basic prompts that request direct output, agent prompts provide a comprehensive framework for problem-solving, including context setting, role definition, step-by-step instructions, and explicit reasoning requirements. Well-structured agent-like prompts may include, but are not limited to, explicit roles and role definitions, explicit task decomposition, inference method instructions, error handling and self-correction mechanisms, output formatting requirements, and contextual background information. Well-structured agent prompts may implement one or more techniques, including but not limited to thought chain prompts (e.g., where the agent is explicitly requested to express procedural reasoning). Creating well-structured agent prompts through hyperautomation systems increases transparency, allows for more accurate error tracking, and enables the execution of more complex tasks. For example, instead of simply asking "Summarize this document," an agent-style prompt could specify: "You are a professional research analyst. Break down this complex technical document into key sections. For each section, provide a two-sentence summary and identify potential areas for further research. Explain your reasoning for your section division and summary methods." Effective iteration of a hyperautomated system can include systemic changes to the prompt component. The prompt component can include, but is not limited to, adjusting role instructions, modifying task decomposition strategies, experimenting with reasoning frameworks, testing different output formatting requirements, and introducing one or more additional contextual details. Therefore, hyperautomated systems attempt to discover the minimum set of instructions that consistently produces high-quality, reliable agent behavior, while recording the results of each iteration and tracking qualitative and quantitative metrics (e.g., response accuracy, completeness, and compliance with specified constraints).

[0232] In box 1615, the hyperautomated system provides parameter descriptions to the agent code inspection score generation. Parameter descriptions can define the agent's inputs and outputs. Typically, conventional automation techniques include cluttered or poorly filled descriptions that lead to performance problems, especially when multiple agents coordinate tasks.

[0233] In box 1617, the hyperautomated system provides tool descriptions for agent code inspection and scoring generation. These tool descriptions can define rich contextual descriptions of tools used to enhance agent performance.

[0234] In box 1619, the hyperautomation system provides a context description to the agent code inspection score generation. The context description defines the context in which the agent operates (effectively). For example, the context description provides a detailed description of what the context index contains (e.g., policy documents, related data) and the type of problem or task that can be solved using that context. Note that inappropriate (e.g., unacceptable) context descriptions in conventional automation techniques lead to misinterpretations and inefficiencies in agent performance.

[0235] In box 1620, the hyperautomated system provides one or more evaluation sets for enhancing agent health scores. That is, after code review, each agent includes an evaluation set for evaluating and generating an agent health score.

[0236] According to one or more embodiments, hyperautomated systems create robust evaluation sets. Note that agent evaluation requires a broad and representative dataset that challenges the system across multiple dimensions. A broad and representative dataset simulates real-world complexity, including input complexity, contextual nuances, domain-specific challenges, and variations in potential edge cases and failure scenarios. A broad and representative dataset for hyperautomated systems is essential for effective dataset development, involving consulting domain experts, analyzing historical interaction logs, systematically generating synthetic test cases, incorporating adversarial examples to ensure statistical diversity, and focusing on creating datasets that test not only successful paths but also error handling, adaptability, and appropriate degradation under challenging conditions.

[0237] At box 1625, the hyperautomated system can determine the agent's evaluation set. The agent displays the evaluation settings as acceptable. The operation at box 1625 can be considered the first step in a four-step process. Proceeding to decision box 1630, the hyperautomated system determines whether the evaluation set is acceptable. For example, the hyperautomated system evaluates multiple characteristics of the agent to determine whether the evaluation set is acceptable, going beyond simple precision measurements of conventional automation techniques. This hyperautomated system evaluates multiple characteristics of the agent by developing a holistic evaluation framework that considers, but is not limited to, one or more of technical performance metrics, qualitative response characteristics, behavioral consistency, domain-specific success criteria, and ethical and safety compliance. Additional evaluation dimensions for multiple characteristics include, but are not limited to, one or more of the following: accuracy and factual correctness, reasoning transparency, response creativity, context relevance, and the creation of robust evaluation methods using automated evaluation tools and human-in-the-loop verification. According to one or more embodiments, the term "acceptable" used for the determination by the hyper-automated system may refer to an evaluation set comprising a list of expected scenarios that the agent must perform / execute, derived from an agent description document (e.g., if a loan processing agent description comprises ten (10) steps, then the evaluation set must comprise ten (10) steps to be determined as acceptable). Note that the list of expected scenarios may include both required and optional scenarios of the hyper-automated system, provided that the evaluation set in the list has at least the required scenarios (e.g., if a new employee recruitment agent description comprises twenty (20) steps, of which five (5) steps are optional branches from one (1) of the fifteen (15) required steps, then the evaluation set must comprise fifteen (15) required steps to be determined as acceptable).

[0238] If the hyper-automation system determines that the evaluation set is unacceptable in decision box 1630, then process 1600 proceeds (as shown by arrow 1631) to box 1635.

[0239] In box 1635, the hyperautomated system enhances one or more evaluation sets. For example, during the design phase of agent development, the hyperautomated system ensures that the agent has a robust evaluation set.

[0240] According to one or more embodiments, the hyperautomation system enhances one or more evaluation sets by determining the sufficiency of each evaluation set. Since an agent must have an acceptable (e.g., adequate) evaluation set to effectively perform a task, sufficiency is a measure of ensuring that the agent has enough instances to learn from. For example, if the agent has only two emails to learn from, and the agent is expected to handle various complex email tasks, then these two emails can be determined as insufficient by the hyperautomation system. Conversely, if the agent has two hundred emails to learn from, and the agent is expected to handle various complex email tasks, then these two hundred emails can be determined as sufficient by the hyperautomation system.

[0241] According to one or more embodiments, the hyperautomated system enhances one or more evaluation sets by performing health score assessments. As discussed herein, an agent's health score reflects the agent's readiness and ability to perform its intended functions. By performing a health score assessment, the hyperautomated system determines whether the agent's health score is an acceptable (e.g., sufficient) value. For example, if the evaluation set is small in number or narrow in scope (i.e., a set of emails with narrow topics), the agent may receive a low agent health score, and the hyperautomated system will determine that the agent is insufficient (e.g., unacceptable). According to one or more embodiments, acceptability and sufficiency, as defined herein, can be terms where the evaluation set and / or the agent's health score meets or exceeds requirements, which includes at least all required steps or a value equal to or greater than a threshold.

[0242] According to one or more embodiments, this hyper-automated system enhances one or more evaluation sets by performing code inspection and optimization. Process 1600 includes evaluating code inspection scores, which assess the quality of the agent design. If the code inspection results are poor, the health score is negatively affected. Optimization tools and suggestions are employed to improve the agent design and evaluation sets.

[0243] According to one or more embodiments, the hyper-automated system enhances one or more evaluation sets by performing iterative improvements using any one of the above-described adequacy determination, health score assessment, and code inspection and optimization. In box 1635, the evaluation set can be enhanced by iteratively improving the score based on information from one or more boxes 1642, 1644, 1646, and 1648.

[0244] In box 1642, the hyper-automated system provides manual evaluation for evaluating set enhancements. In box 1644, the hyper-automated system provides evaluation from the tracing used for evaluating set enhancements. Manual evaluation and evaluation from the tracing can include evaluations performed by the automation developer. In box 1646, the hyper-automated system provides synthetic evaluation. In box 1648, the hyper-automated system executes an optimizer for evaluating set enhancements. Synthetic evaluation and optimizer can be automated steps of the hyper-automated system.

[0245] Returning to decision box 1630, if the hyper-automation system determines that the evaluation set is acceptable, process 1600 proceeds (as shown by arrow 1659) to box 1660.

[0246] In Box 1660, the hyperautomated system performs an evaluation run using an evaluation set for one or more agents. More specifically, in Box 1665, the hyperautomated system can generate an evaluation score based on the evaluation set. The evaluation score can be a metric that measures how well the evaluation settings are performed and can be used to identify problems and improve the experience. Furthermore, the evaluation score represents the desired sensitivity and characteristics of the agent while synthesizing information (e.g., the evaluation score is not just about the quality of the output). The evaluation score can be any alphanumeric value along, for example, a range from 0 to 100 or from 0.00 to 1.00, and can be represented as a percentage, currency, number, etc. The operation in Box 1665 can be considered as the second step in a four-step process.

[0247] According to one or more embodiments, after enhancing the evaluation set in box 1620, the hyperautomated system performs an evaluation run using one or more agents and the evaluation set (in box 1665) to output an evaluation score. In box 1667, the hyperautomated system provides a mokcing tool for efficiency during the execution of the evaluation run. The mokcing tool can accelerate the evaluation process, especially when processing a large number of evaluations (e.g., 100 or more evaluations). Therefore, the ability to simulate certain tools is introduced through the hyperautomation engine, which allows for faster testing and evaluation beyond human capabilities during the design phase.

[0248] Proceeding to decision box 1670, the hyperautomation system determines whether the evaluation score is acceptable (e.g., a low evaluation score). According to one or more embodiments, the term "acceptable" used for this determination by the hyperautomation system may indicate that the evaluation score does not meet a threshold performance value. At decision box 1670, if the hyperautomation system determines the evaluation score is unacceptable, process 1600 continues (as indicated by arrow 1671) to box 1675 because the corresponding agent is considered unready.

[0249] In Box 1675, the hyperautomation system provides multi-touch attribution to assign which factors contributed to unacceptable evaluation scores (e.g., cue words, parameter descriptions, tool descriptions, tool accuracy). The operation of Box 1675 can be considered the third step in a four-step process. For example, if the evaluation score is low, multi-touch attribute analysis is performed to identify factors contributing to poor performance. Multi-touch attribution analysis may include, but is not limited to, one or more of the following: examining poor cue words, examining inaccurate descriptions of tools and parameters, examining the overall accuracy of the tools used, and examining one or more agents and their corresponding agent health scores.

[0250] In box 1680, the hyperautomated system suggests optimization factors that can be improved. The operation of box 1680 can be considered the fourth step in a four-step process. Optimization factors can be provided by content contribution analysis, an evaluation process that assesses how different components of an agent contribute to its performance and agent health score. Content contribution analysis enables the hyperautomated system to identify specific areas that need improvement. Boxes 1675 and 1680 can be performed loop-wise or iteratively, as... Figure 16 As shown. For example, iterative optimization can be performed after identifying the problem. At this point, the hyper-automated system performs optimization and reruns the evaluation until the agent obtains an acceptable or acceptable agent health score. Based on this, an optimized scheme is proposed and implemented. Then, in box 1665, the evaluation set is rerun until an acceptable evaluation score is obtained. This continuous feedback loop ensures that the agent is refined and improved over time, which has technical effectiveness, advantages, and benefits compared to conventional automation techniques.

[0251] Returning to decision box 1670, if the hyper-automated system determines that the evaluation score is acceptable, process 1600 continues (as indicated by arrow 1689) to box 1695, because the corresponding agent is considered ready. According to one or more embodiments, the hyper-automated system can provide an iterative runtime monitoring process in which feedback and tracking data are continuously analyzed to enhance agent performance. The agent learns from its experience, allowing for optimization and adaptation to real-world scenarios.

[0252] According to one or more embodiments, the hyper-automated system can execute any of the processes or procedures described herein regarding runtime agent health monitoring. Runtime agent health monitoring may include an implemented thumb-up / thumb-down feedback mechanism, where feedback on agent performance can be received using thumbs-up (e.g., indicating good performance) or thumbs-down (e.g., indicating poor performance) interface icons. Thumbs-up / thumb-down feedback can be collected on the instance management page of the hyper-automated system. In addition to thumbs-up / thumb-down feedback, text input may also be received to explain what should have happened versus what actually happened. Thumbs-up / thumb-down feedback and text input can be considered essential qualitative feedback for understanding the context of agent performance.

[0253] According to one or more embodiments, a hyper-automated system can provide tracking data collection. Tracking data collection can include health data acquisition and performance evaluation. For example, health data acquisition can include runtime tracking designed to collect specific health data about agent performance. Health data about agent performance is crucial for identifying problems and areas for improvement. Furthermore, performance evaluation can include when the agent receives negative feedback (indicating poor agent performance) and using this feedback to inform optimizations and enhancements to agent functionality.

[0254] According to one or more embodiments, a hyperautomated system can provide self-improving tracking data and feedback specificity. Examples of self-improving tracking data regarding path evaluation include specifying that the agent should take a more direct path, thus taking into account real-world system conditions. Feedback specificity can include providing detailed feedback on why a particular path is not optimal, such as mentioning that a particular system is offline. This hyperautomated system makes granular-level detail critical for refining the agent's decision-making process and unavailable in conventional automation techniques.

[0255] According to one or more embodiments, the hyperautomated system can provide improved modes. One or more improvements may include, but are not limited to, offline optimization, online learning, and test-time learning operational modes for improving agent performance during runtime. Offline optimization may include, after collecting feedback, the agent undergoing offline optimization that analyzes the collected feedback and adjusts the agent to improve agent performance in future runs. Online learning may include the ability to learn in real-time based on immediate feedback when utilizing the agent. For example, as the agent performs a task, it can dynamically adapt and improve performance, thereby enhancing the effectiveness of subsequent operations. Test-time learning may include enabling the agent to evaluate agent actions and determine which actions are appropriate during execution. Test-time learning allows the agent to perform tutorial corrections in real-time before completing a task. For example, if a task takes five (5) to ten (10) minutes to complete, the agent can adjust its approach based on feedback received during that time and improve runtime performance to less than five (5) minutes.

[0256] According to one or more embodiments, the hyper-automated system can provide a user experience design interface. The user experience design interface may include a health dashboard with an overview pane displaying the total score of all agents in a folder, along with trend lines and benchmarks. The health dashboard may include detailed views allowing in-depth viewing of individual agent scores on key metrics such as performance and reliability. The health dashboard may include alerts and recommendations that provide proactive alerts for low scores and actionable improvement suggestions. The user experience design interface may include wireframes. Wireframes may include dashboard views that provide comparative health scores between agents and processes, along with customizable filters for metrics and timeframes. Wireframes may include agent detail pages that provide score breakdowns based on performance, compliance, and business impact, as well as a visual timeline for runtime behavior analysis. The user experience design interface may include interactive models that allow users to simulate the impact of weight adjustments on health scores, and support historical trend analysis to track improvements or regressions. The user experience design interface may include strategic considerations such as scalability, regulatory alignment, and cross-team usability. Scalability supports enterprise-scale deployments with hundreds of agents. Regulatory alignment includes flexible compliance modules for various industries (e.g., GDPR, HIPAA). Cross-team usability provides availability among developers, COE administrators, and business analysts.

[0257] Computer programs can be implemented in hardware, software, or a hybrid approach. A computer program can consist of modules that are operatively communicable with each other and is designed to transmit information or instructions to a display. A computer program can be configured to run on a general-purpose computer, an ASIC, or any other suitable device.

[0258] It is readily understood that, as generally described and illustrated in the figures herein, the components of various embodiments of the invention can be arranged and designed in many different configurations. Therefore, as shown in the accompanying drawings, the detailed description of embodiments of the invention is not intended to limit the scope of the claimed invention, but is merely representative of selected embodiments of the invention.

[0259] The features, structures, or characteristics of the invention described herein can be combined in any suitable manner in one or more embodiments. For example, throughout the specification, references to "certain embodiments," "some embodiments," or similar language mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. Therefore, the phrases "in some embodiments," "in some embodiments," "in other embodiments," or similar language appearing throughout the specification do not necessarily refer to the same set of embodiments, and the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0260] It should be noted that references to features, advantages, or similar language in this specification do not imply that all features and advantages achievable with the invention should be included in any single embodiment of the invention. Rather, language relating to features and advantages is to be understood as indicating that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the invention. Therefore, the discussion of features and advantages throughout this specification, as well as similar language, may refer to, but do not necessarily refer to the same embodiment.

[0261] Furthermore, the features, advantages, and characteristics described in this invention can be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize that this invention can be practiced without one or more specific features or advantages of a particular embodiment. In other instances, additional features and advantages that may not be present in all embodiments of the invention may be recognized in certain embodiments.

[0262] It will be readily understood by those skilled in the art that the present invention described above can be practiced through steps in a different order and / or with hardware elements different from those disclosed in the configuration. Therefore, although the invention has been described based on these preferred embodiments, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art while remaining within the spirit and scope of the invention. Therefore, reference should be made to the appended claims to define the scope of the invention.

Claims

1. A method for performing one or more agent-based automata in a hyperautomation system, the hyperautomation system including memory for storing the one or more agent-based automata and for generating agent health scores, and the hyperautomation system including at least one processor executing the computer code to cause the method to optimize the one or more agent-based automata, the method comprising: Generate a set of standardized metrics for use by agents performing one or more agent-based automations; An evaluation is performed on the agent performing the one or more agent-based automations, and the evaluation determines performance metrics by measuring the success rate, error frequency, and execution efficiency of two or more different use cases or business processes; Compare the performance metrics of the agent across the two or more different use cases or business processes; as well as One or more agent health scores are generated by comparing the performance metric with one or more agent health score definitions.

2. The method of claim 1, wherein the hyperautomation system identifies the agent used for generating the agent health score.

3. The method of claim 1, wherein the hyperautomation system identifier is assigned to the agent within the one or more agent-automated workflow.

4. The method of claim 1, wherein the one or more agent health scores include a metric measuring the quality of the agent's performance of the one or more agent-based automations.

5. The method of claim 1, wherein the one or more agent health scores include a metric for measuring agent performance as the agent performs the one or more agent-based automations.

6. The method of claim 1, wherein the hyperautomation system generates the one or more agent health score definitions for measuring the success rate, the error frequency, and the execution efficiency.

7. The method of claim 6, wherein the definition of the one or more agent health scores includes assessing infrastructure, runtime performance, developer experience, security and compliance, and business impact.

8. The method of claim 1, wherein the performance metric is aligned with an organizational priority that provides customizable weights.

9. The method of claim 8, wherein the customizable weights comprise a scale from zero (0) to one hundred (100), wherein the scoring criteria are expressed as a percentage.

10. The method of claim 1, wherein the evaluation is performed by a second agent during design time or runtime.

11. A hyperautomation system that performs one or more agent-style automation, the hyperautomation system comprising: A memory for storing the one or more agent-based automation and agent health score generation; as well as At least one processor executes the computer code to cause the hyper-automation system to optimize the one or more intelligent agent-style automations by: Generate a set of standardized metrics for use by agents performing one or more agent-based automations; An evaluation is performed on the agents performing the one or more agent-based automations, and the evaluation determines performance metrics by measuring the success rate, error frequency, and execution efficiency of two or more different use cases or business processes; Compare the performance metrics of the agent across two or more different use cases or business processes; as well as One or more agent health scores are generated by comparing the performance metric with one or more agent health score definitions.

12. The hyperautomation system of claim 11, wherein the hyperautomation system identifies the agent used to generate the agent health score.

13. The hyperautomation system of claim 11, wherein the hyperautomation system identifies actions or tasks in the one or more agent-automated workflows assigned to the agent.

14. The hyperautomation system of claim 11, wherein the health score of the one or more agents includes a metric measuring the quality of the agent's performance of the one or more agent-based automation.

15. The hyperautomation system of claim 11, wherein the one or more agent health scores include a metric for measuring agent performance while the agent performs the one or more agent-based automations.

16. The hyperautomation system of claim 11, wherein the hyperautomation system generates the one or more agent health score definitions for measuring the success rate, the error frequency, and the execution efficiency.

17. The hyperautomated system of claim 16, wherein the health score of the one or more agents is defined to include assessments of infrastructure, runtime performance, developer experience, security and compliance, and business impact.

18. The hyperautomated system of claim 11, wherein the performance metric is aligned with organizational priorities that provide customizable weights.

19. The hyperautomated system of claim 18, wherein the customizable weights comprise a scale from zero (0) to one hundred (100), wherein the scoring criteria are expressed as a percentage.

20. The hyperautomated system of claim 11, wherein the evaluation is performed by a second agent during design time or runtime.

Images