Systems and methods for organizational general intelligence

Abstract

Certain aspects described herein relate to a method by a project manager agent to support model-agnostic collaboration among artificial intelligence (AI) agents. The method includes decomposing a task request into a first and second sub-task; transmitting: a first request for the first sub-task to a first AI agent; and a second request for the second sub-task to a second AI agent, wherein the first request and the second request are formatted according to a model-agnostic message schema; receiving in response: a first response from the first AI agent and a second response from the second AI agent; detecting, in the first response, a first tool invocation command; routing the first tool invocation command to the third AI agent; receiving, from the third AI agent, a first result; and providing an integrated output that is generated based on the first response, the second response, and the first result.

Description

SYSTEMS AND METHODS FOR ORGANIZATIONAL GENERAL INTELLIGENCE CROSS-REFERENCE TO RELATED APPLICATION(S)

[0001] The present Application for Patent claims benefit of and priority to U.S. Provisional Application No. 63 / 780,084, filed March 28, 2025, which is herein incorporated by reference in its entirety.BACKGROUNDField

[0002] Aspects of the present disclosure relate to agentic artificial intelligence (Al).Description of Related Art

[0003] Generative artificial intelligence (GenAI) refers to machine learning models capable of creating new content based on patterns, insights, information (e.g., facts and knowledge), and / or model parameter weights learned from training, in combination with user-provided prompts. In some cases, the user-provided prompts may provide instructions to a machine learning model on what new content to generate and / or how to generate that new content.

[0004] GenAI models are able to generate new content in many different forms, including text, image, audio, and video. For example, to facilitate text generation, some GenAI models are configured as language models (LMs). An LM may refer to a type of machine learning model that is designed to understand, generate, and manipulate human language. More specifically, an LM may comprise a probabilistic framework that determines the likelihood of a sequence of tokens. For example, at its core, an LM attempts to predict the probability of the next token in a sequence of tokens when given the sequence of tokens as input. The LM estimates this probability based on the patterns it learned during training. In the context of LMs, “tokens” may refer to units of text that the models process and generate. Tokens can represent individual characters, words, subwords, or even larger linguistic units, depending on the specific tokenization (e.g., segmentation of text into meaningful units to capture its semantic and syntactic structure) approach used. Tokens act as a bridge between text data and the numerical representations with which language models are able to use.

[0005] LMs are useful in natural language processing (NLP) and computational linguistics for performing a range of tasks involving human language. For example, LMs have a wideD&S Ref. No.: NKB0003WOarray of applications, including: text generation (e.g., producing coherent and contextually appropriate text); machine translation (e.g., converting text from one language to another); speech recognition (e.g., converting spoken language into text); text summarization (e.g., condensing a long piece of text into a shorter summary); sentiment analysis (e.g., determining the sentiment expressed in a piece of text); and question answering (e.g., automatically providing answers to questions posed in natural language).SUMMARY

[0006] Some aspects provide a method by a project manager agent to support modelagnostic collaboration among a plurality of artificial intelligence (Al) agents. The method includes decomposing a task request into at least a first sub-task and a second sub-task; transmitting: a first request that corresponds to the first sub-task to a first Al agent of the plurality of Al agents; and a second request that corresponds to the second sub-task to a second Al agent of the plurality of Al agents, wherein the first request and the second request are formatted according to a first model-agnostic message schema; receiving: a first response to the first request from the first Al agent; and a second response to the second request from the second Al agent; detecting, in the first response, a first tool invocation command that indicates a request to invoke a third Al agent of the plurality of Al agents; routing the first tool invocation command to a first endpoint associated with the third Al agent; receiving, from the third Al agent, a first result responsive to the first tool invocation command; and providing an integrated output to a user or client application that submitted the task request, wherein the integrated output is generated based on the first response, the second response, and the first result.

[0007] Other aspects provide processing systems configured to perform the aforementioned methods as well as those described herein; non-transitory, computer-readable media comprising instructions that, when executed by a processor of a processing system, cause the processing system to perform the aforementioned methods as well as those described herein; a computer program product embodied on a computer-readable storage medium comprising code for performing the aforementioned methods as well as those further described herein; and a processing system comprising means for performing the aforementioned methods as well as those further described herein.

[0008] The following description and the related drawings set forth in detail certain illustrative features of one or more aspects.D&S Ref. No.: NKB0003WODESCRIPTION OF THE DRAWINGS

[0009] The appended figures depict certain aspects and are therefore not to be considered limiting of the scope of this disclosure.

[0010] FIG. 1 depicts a process component diagram for facilitating model-agnostic collaboration among a plurality of artificial intelligence (Al) agents.

[0011] FIG. 2 depicts a high-level component diagram for facilitating organizational general intelligence.

[0012] FIG. 3 depicts a process diagram for facilitating organizational general intelligence.

[0013] FIG. 4 depicts a detailed component diagram for facilitating organizational general intelligence.

[0014] FIG. 5 depicts a method for model-agnostic collaboration among a plurality of Al agents.

[0015] FIG. 6 depicts an example processing system with which aspects of the present disclosure can be performed.

[0016] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the drawings. It is contemplated that elements and features of one embodiment may be beneficially incorporated in other embodiments without further recitation.DETAILED DESCRIPTION

[0017] Agentic Al systems refer to Al systems that incorporate one or more Al agents capable of autonomously acting within an environment to achieve specific goals. For example, different from more passive Al systems that simply respond to queries or perform specific isolated tasks, agentic Al systems perceive their environment, including available Al tools, available resources, and task requests, and make decisions to take certain actions towards completing the task requests without further user input. As used herein, a “task request” may refer to an input that specifies a task to be carried out, an objective to be achieved, and / or an operation to be performed by an agentic Al system.

[0018] Agentic Al systems usually comprise an observation module, a planning engine, a tool library, and an action executor. The observation module receives inputs from the environment, such as user queries, sensory data, and / or application programming interfaceD&S Ref. No.: NKB0003WO(API) responses, and processes these inputs for downstream components. The planning engine behaves like the “brain” of the agentic Al system and determines certain actions it should take based on the inputs. The tool library is a collection of Al tools that the agentic Al system can access, such as web searches, code execution, database queries, or machine learning models. The action executor carries out the actions determined by the planning engine, such as by using Al tools identified from the tool library.

[0019] In other words, the agentic Al system receives instructions from a user, which are then broken down into actionable steps. The planning engine determines which Al tools to use to perform each actionable step, observes the result from taking a respective actionable step, and updates the plan based on the result. An example benefit of agentic Al systems is that the user does not have to update the plan manually or provide further instruction, such as reprompting a machine learning model of the agentic Al system. Instead, the agentic Al system is able to dynamically determine the steps needed to accomplish the end goal of the instructions submitted by the user and iteratively and recursively uses different Al tools until the agentic Al system determines that the goal has been accomplished.

[0020] However, even though agentic Al systems can accomplish complex tasks, such systems also experience technical problems with message handling and task execution between different Al tools. Multi-agent Al systems may be used to solve complex tasks by dividing problem domains among multiple Al agents or modules. In conventional designs, each agent may be tied closely to a specific machine learning model or data source, which can limit flexibility and make the system dependent on the strengths and weaknesses of a particular machine learning model. As a result, integrating new agents or updating existing agents may involve extensive reconfiguration of the underlying system architecture.

[0021] Further, existing solutions frequently rely on ad-hoc communication protocols, typically designed around the capabilities of one or two machine learning models. To incorporate new machine learning models, developers may replace entire systems to accommodate differences in input and output formatting, contextual understanding, and processing constraints. This approach can slow the adoption of diverse machine learning models.

[0022] Moreover, since some Al agents (e.g., of some agentic Al systems) lack standardized interfaces to invoke shared Al tools or specialized services. For example, invoking an Al agent or tool provided by an Al agent may require custom wrappers or adapters.D&S Ref. No.: NKB0003WOThe use of custom wrappers or adapters may lead to additional maintenance overhead and potential conflicts between system components.

[0023] By contrast, aspects described herein are directed to methods and systems for enabling model-agnostic collaboration among multiple Al agents, such as in real time. In certain implementations, multiple Al agents of a system collectively form what is referred to herein as “organizational general intelligence” (OGI), wherein each Al agent may operate utilizing distinct LMs (or algorithms) while communicating and coordinating using a standardized protocol. Accordingly, the system can incorporate new Al models and specialized Al tools with reduced modifications. As used herein, in some cases this system may be referred to as an “OGI system.”

[0024] In one aspect, a central project manager agent receives task requests from users or external systems. Based on an advertised set of capabilities, the central project manager agent can delegate sub-tasks to the most appropriate Al agents. Because each Al agent adheres to uniform message protocols, the system avoids the complexities associated with custom-built integration layers and enables concurrent execution by different Al agents, models, and services.

[0025] In some aspects, Al tools, such as for an Al agent, may be defined via a structured schema that includes unique identifiers, descriptive text, and input-output specifications. The system can recognize Al agent-generated commands that invoke Al tools to validate parameter inputs and expected data outputs. In some aspects, the framework allows an Al agent to be treated as a callable “Al tool,” such that the system can perform nested or recursive interactions among multiple Al agents.

[0026] Certain implementations further incorporate a reasoning framework that utilizes problem-solving capabilities of advanced LMs (e.g., 3.5 Sonnet®, Gemini 2®, etc.). Current LMs and similar Al systems may be limited by a fixed context window (e.g., a fixed amount of tokens or input an LM or Al system can process at a given time, which may also be referred to as a “token limit” or “input limit”) that processes user queries and generates responses. For example, in many Al architectures, there is a hard limit on how many tokens can be included in a single prompt or output. Once the hard limit is reached, the Al architecture may truncate the conversation, start a new prompt, or otherwise break continuity. Thus, existing agentic Al systems may restrict an Al agent’s output to one pass within a token or fixed context window and rely on repeated re-prompting for more elaborate tasks. In contrast, aspects of the systemsD&S Ref. No.: NKB0003WOdescribed herein may enable an Al agent to continue iterating until the Al agent satisfies a user’s objectives. By simulating chain-of-thought reasoning (e.g., a prompting technique that breaks complex, multi-step tasks into smaller, intermediate logical tasks and / or steps) across multiple interactions, the Al agent can generate refined responses without incurring the computational costs of repeatedly instantiating short or segmented prompts. This approach could enable reasoning behaviors for LMs that are both state-of-the-art and non-state-of-the-art to use enhanced reasoning behaviors.

[0027] The systems and methods described herein provide additional technical benefits over conventional and state-of-the-art agentic Al systems. For example, existing agentic Al systems operate using workflows with defined execution paths that depend on instructions and embedded conditional logic. Beneficially, the systems and methods described herein provide a meta- framework where Al agents can independently determine collaboration patterns and tool usage based on dynamically determined context. These independently configured Al agents are able to make decisions about which Al agents and Al tools to involve based on evolving task requirements.

[0028] As another example, existing agentic Al systems may be implemented with fixed relationships between Al agents and Al tools, such that only certain Al agents can interact with certain Al tools and not others. Different from existing agentic Al systems, the systems described herein implement a model-agnostic message schema that enables any Al agent to dynamically discover and collaborate with any other available Al agent or tool, creating capabilities beyond what an individual Al agent may be able to accomplish.

[0029] Additionally, existing agentic Al systems typically operate in linear sequences with limited feedback loops. Different from existing agentic Al systems, the systems described herein are directed to recursive agent interactions, where Al agents can call other Al agents, who can in turn call additional Al agents, thereby creating multi-step reasoning chains that persist beyond fixed context window limitations. By facilitating independent and recursive Al agent interaction, the systems described herein do not need precise instructions on how to solve problems or provide a response to a user-provided prompt (e.g., a task request). Instead, the user or a client application can submit the user prompt and allow the system to work out not only the solution, but also how to generate the solution.D&S Ref. No.: NKB0003WOModel-Agnostic Collaboration Among Multiple Al Agents

[0030] FIG. 1 depicts a process component diagram for model-agnostic collaboration among multiple Al agents of a system 100. For example, as shown in FIG. 1, system 100 includes a plurality of Al agents, such as, agent 104A, agent 104B, agent 104C, agent 104D, and agent 104E (e.g., collectively referred to herein as “agents 104”), that are in communication with each other and a project manager 102.

[0031] Each of agent 104 A, agent 104B, agent 104C, agent 104D, and agent 104E is an autonomous entity that includes an assigned name, role, and set of capabilities. The agents 104 are designed to process information, make decisions, and engage in complex reasoning based on their respective domain expertise. In some aspects, one or more of the agents 104 are configured as a combination of an LM, a persona, and access parameters to a particular set of Al tools. As used herein, “Al tools” (also simply referred to as “tools”) may refer to executable functions that are configured to perform specific tasks, like creating files, retrieving weather forecasts, integrating or adding calendar events, or performing calculations, among others. Al tools can be invoked by different Al agents to accomplish discrete tasks. Some Al tools may be universally available to any Al agent, while other Al tools are only accessible by Al agents with specific permissions or capacities to access and utilize these Al tools.

[0032] In some aspects, one or more of the agents 104 operate using different machine learning models, such as LMs, multi-modal generative models, computational models, or other task-specific machine learning models. LMs may be configured as small or large LMs (LLMs). For example, as shown in FIG. 1, agent 104A operates using a model 108A, agent 104B operates using a model 108B, agent 104C operates using a model 108C, agent 104D operates using a model 108D, and agent 104E operates using a model 108E. In some aspects, agent 104A, agent 104B, agent 104C, agent 104D, and / or agent 104E may interface with, invoke, or otherwise communicate with one or more ML models. For example, agent 104A may interface with, invoke, or otherwise communicate with model 108A. In some aspects, agent 104A, agent 104B, agent 104C, agent 104D, and / or agent 104E may include an ML model and one or more Al tools configured to operate with that ML model. The Al tool(s) may be specific to that ML model and not universally available to any agent 104 of system 100. For example, agent 104B may comprise model 108B and tool 120 (e.g., an example Al tool), where tool 120 is specific to model 108B, and is not universally available to other agents 104A, 104C, 104D, and 104E.D&S Ref. No.: NKB0003WO

[0033] In some aspects, the project manager 102 is an Al agent that is configured to receive a task request 110, such as from a user or a client application, and parse the task request 110 into a plurality of sub-tasks that can be routed to one or more of the agents 104. Beneficially, in some aspects, the sub-tasks are formatted according to a model-agnostic message schema so that the sub-tasks can be understood and used by any of agent 104A, agent 104B, agent 104C, and agent 104D. Additional details related to task request processing, by the project manager 102, are provided below with respect to FIG. 4 (e.g., also referred to herein as “message processing 404”).

[0034] As used herein, a “task request,” such as task request 110, may refer to an input that specifies a task to be carried out, an objective to be achieved, and / or an operation to be performed by system 100. For example, task request 110 may request generation of a report or generation of a response to a user-provided prompt (e.g., answering of a user query). As used herein, a “sub-task” may refer to a discrete portion of a task request, such as task request 110, that is configured for separate processing by one or more Al agents and / or using one or more Al tools. For example, sub-tasks may include retrieving source data, analyzing content, or generating a portion of a response for task request 110. Further, as used herein, a “schema” may refer to a structured format that defines how message content, inputs, or outputs are represented for interpretation by different Al agents. More specifically, a “model-agnostic message schema” may refer to a standardized message format that can be used by the different agents 104 regardless of the particular ML models employed by those agents 104. For example, a model-agnostic message schema may define a standardized message structure for communicating a task, associated input data, and a requested output.

[0035] In some aspects, the model-agnostic message schema is formatted as:<agent_manager>"type": "[agentld] -protocol","message": "hello world","Status": "[status.result]","threadld": "[threadld]"< / agent_manager>Specifically, in some aspects, the model-agnostic message schema may include a type field, a message field, a status field, and a thread identifier (ID) field. This standardized format enablesD&S Ref. No.: NKB0003WOcommunication between agents 104 employing different ML models while maintaining state persistence across message exchanges.

[0036] In some aspects, after decomposing task request 110 into multiple sub-tasks, the project manager 102 identifies one or more agents 104 for performance of one or more of the sub-tasks. The project manager 102 may identify the one or more agents 104 based on a correspondence (e.g., a matching) between the content of the task request 110 and attributes associated with the one or more agents 104, including respective task completion capabilities (e.g., characteristic(s), function(s), resource(s), permission(s), or processing ability(ies) that enable an agent 104 to perform, contribute to, or complete a given task or sub-task). In some aspects, the agent(s) 104 are identified based on advertised capability descriptors and other metadata available to the project manager 102. In particular, in some aspects, project manager 102 is configured to access metadata 112, which may include metadata for one or more agents 104. For example, as shown in FIG. 1, metadata 112 includes metadata for agent 104A, agent 104B, agent 104C, agent 104D, and agent 104E. After receiving task request 110 and identifying a set of sub-tasks for generating a completed response to task request 110, project manager 102 accesses metadata 112 and identifies, from among agents 104 (e.g., available agents), a set of agents for assignment to the respective sub-tasks. As an illustrative example, in FIG. 1, project manager 102 may select agent 104A, agent 104B, agent 104C, and an agent team 106 comprising both agent 104D and agent 104E, to complete the various sub-tasks. As used herein, an “agent team” may refer to a group of two or more agents 104 selected to work in a coordinated manner to perform a task, a sub-task, or a set of related sub-tasks. In some aspects, an agent team 106 may be treated by project manager 102 as a collective resource, even though the individual agents 104 of the agent team 106 may have different respective capabilities, ML models, Al tools, and / or roles.

[0037] In some aspects, a first sub-task (e.g., among the multiple sub-tasks) is transmitted to agent 104 A. In response to receiving the first sub-task, agent 104A obtains one or more responses corresponding to the first sub-task and routes the one or more responses back to the project manager 102. In some aspects, the agents 104 may communicate with one another without mediation by the project manager 102. In such aspects, an agent, such as agent 104 A, may be configured to detect tool invocation command(s) in a received sub-task and route the tool invocation command(s) directly to other agent(s) 104.

[0038] As used herein, a “tool invocation command” may refer to a command or structured instruction configured to cause invocation of a particular Al tool and / or to initiateD&S Ref. No.: NKB0003WOcommunication with another agent 104. In some aspects, a tool invocation command may include data identifying the Al tool and / or agent 104 to be invoked and one or more associated parameters for the invocation. In some implementations, execution of the tool invocation command may be conditioned on the requested Al tool being present in a tool registry, availability of the requested Al tool and / or agent 104, proper formatting of the tool invocation command, and / or access rights associated with the requesting agent 104.

[0039] In some aspects, agent 104A generates one or more responses to the first sub-task, which may be transmitted to the project manager 102. In some aspects, the project manager 102 detects, in at least one of those responses received from agent 104A, a tool invocation command. The tool invocation command may indicate a request to invoke another agent 104 (e.g., a second agent 104), such as agent 104B.

[0040] In some aspects, the project manager 102 routes the tool invocation command to an endpoint of the agent 104 associated with the tool invocation command. For example, project manager 102 may route the tool invocation command, indicating a request to invoke agent 104B, to agent 104B. Agent 104B may process the tool invocation command and generate a corresponding result, which is then retrieved by the project manager 102. Beneficially, in some aspects, outputs and results generated by agents 104 and received by project manager 102 conform to the same model-agnostic schema used for the sub-tasks transmitted to the agents 104. As a result, both inputs to and outputs from the agents 104 may follow a common structural format, thereby enabling the system 100 to use uniform mechanisms for state management, context preservation, persistent storage, and data retrieval across agent interactions.

[0041] In some aspects, as described above, the project manager 102 acts as an intermediary agent between one or more agents 104. In some aspects, interactions between the one or more agents 104 and the project manager 102 may be recorded in a corresponding conversation thread, thereby enabling human review and comprehension of intermediate interactions before generating the final output.

[0042] The project manager 102 may aggregate outputs (e.g., such as results) from agent 104A and agent 104B into an integrated output 114. The integrated output 114 may be provided to the user or client application that submitted the original task request 110. Beneficially, in some aspects, the integrated output 114 constitutes a complete response to the task request 110 (e.g., such as after full completion of all sub-tasks associated with the task request 110).D&S Ref. No.: NKB0003WO

[0043] In another example, in system 100, project manager 102 divides the task request 110 into multiple sub-tasks and transmits the multiple sub-tasks to different agents 104, such as agent 104A and agent 104B. More specifically, a first sub-task may be transmitted from project manager 102 to agent 104A, and a second sub-task may be transmitted from project manager 102 to agent 104B. Beneficially, in some aspects, agent 104A and agent 104B may process their respective received sub-tasks in parallel. After processing their respective subtasks, agent 104A and agent 104B may each generate one or more corresponding responses and transmit the one or more corresponding responses to the project manager 102. In some aspects, the project manager 102 detects a tool invocation command based on at least one response from either agent 104 A or agent 104B. The tool invocation command may indicate a request to invoke another agent 104 (e.g., a third agent 104), such as agent 104C. The project manager 102 may route the tool invocation command to an endpoint associated with agent 104C. Agent 104C may receive the tool invocation command and, based on the tool invocation command, perform a requested operation, such as invoking or using a tool associated with agent 104C, executing model-based processing via model 108C, and / or generating corresponding one or more results, which may be provided to the project manager 102. In some aspects, the project manager 102 is configured to aggregate the result(s) from agent 104C and responses (e.g., in some cases including outputs) from agent 104A and agent 104B into an integrated output. The integrated output may be provided to the user or client application.

[0044] While agents 104 are able to communicate directly, by routing tool invocation commands to respective endpoints associated with other agents 104 in system 100. Even in implementations that support such direct communication, the project manager 102 may facilitate the coordination of communications within system 100, for example, by managing task flow, tracking exchanges between agents 104, and integrating corresponding outputs.

[0045] In some aspects, the endpoints associated with agents 104 may implement standardized communication protocols, such as representational state transfer (REST)-based protocols or other network communication standards, whether at the local level or the domain API. Endpoints may also support authentication, security layers, cross-environment communication, and clear service boundaries within system 100.

[0046] In some aspects, the project manager 102 monitors partial outputs from at least two agents 104 and aggregates the partial outputs from each agent 104 into an aggregated intermediate state. In some aspects, project manager 102 dynamically generates additional sub-D&S Ref. No.: NKB0003WOtasks, and assigns these additional sub-tasks to one or more agents 104, based on the aggregated intermediate state before providing an output, such as to a user or client application.

[0047] In some aspects, when agents 104 are interacting among themselves and with the project manager 102, the corresponding interactions may be captured and recorded as human-readable text. Accordingly, system 100 may provide not only an integrated output responsive to the task request 110, but also contextual information (e.g., “context”) that enables a user or client application that submitted task request 110 to understand how the integrated output was generated. In some aspects, this context may be recorded in a thread associated with the task request 110, such that the user or client application is able to review, via the recorded context, how the task request 110 was divided into sub-tasks, how the sub-tasks were distributed among agent(s) 104, agent team(s) 106, or Al tools (e.g., such as tool 120), what intermediate interactions occurred between agents 104, and how intermediate outputs were aggregated to generate the integrated output. This is an improvement over other agentic Al systems, which may provide outputs (e.g., final responses) without any context or information about how the agentic Al systems were able to produce the outputs. For example, interpretability of the output (e.g., integrated output) may be improved.

[0048] FIG. 2 depicts a high-level diagram for facilitating model-agnostic collaboration among multiple Al agents, such as agent 104A, agent 104B, agent 104C, agent 104D, and agent 104E depicted in FIG. 1. For example, FIG. 2 depicts a service orchestration layer 202 in communication with a tool definition layer 204. The service orchestration layer 202 acts as a central orchestrator for multiple Al agent communication. In some aspects, the service orchestration layer 202 manages a continuous conversation thread with a universally unique identification (UUID).

[0049] Unlike existing agentic Al systems which only present the final output, the systems (e.g., OGI systems) described herein record and present a collaborative process from initiation to completion in human-readable form. By utilizing thread ID-based organization and recording, the recorded interactions associated with a task request may be maintained across different machine learning models, including those machine learning models that are not natively configured to track interactions. In this manner, users and client applications may observe sub-task delegation, intermediate interactions and problem-solving between agents, and generation of intermediate outputs, thereby providing transparency into the generation process of the final output.D&S Ref. No.: NKB0003WO

[0050] In some aspects, the service orchestration layer 202 implements a publishersubscriber pattern for asynchronous message handling. In some aspects, the publishersubscriber pattern includes one or more message producers, such as users or Al agents, which publish messages to a centralized message queue. Subscriber components then route these messages to appropriate destinations. This allows any entity to reference any Al agent. In some aspects, intelligent batching for related messages (i.e., those targeting the same agent) may be utilized, while providing specialized handling for tool invocation commands. This implementation enables concurrent processing or distinct operations, reducing potential bottlenecks while maintaining message integrity. A publisher-subscriber implementation provides more flexibility and increased efficiency in message distribution over existing point-to-point communication architectures.

[0051] As used herein, “asynchronous message handling” refers to a communication pattern where a sender, such as project manager 102 of FIG. 1, dispatches messages (e.g., related to sub-tasks, tool invocation commands, etc.) without waiting for an immediate response, allowing both the sender and the receiver, such as agent 104A of FIG. 1, to operate independently on their own timelines. This enables non-blocking operations, better resource utilization, and increased system resilience in distributed applications, such as system 100 supporting model-agnostic collaboration as described herein. In some aspects, the service orchestration layer 202 provides real-time client-side state management, such as displaying typing indicators within a user interface, updating a message processing status, and performing error handling. As used herein, “client-side state” may refer to information maintained at a client side, such as for presentation to a user or a client application.

[0052] In some aspects, state management may include tracking multiple processing states, such as unknown, processing, success, error, or partial states. By providing state management in this manner, the systems described herein (e.g., OGI systems) may provide more granular control and visibility into message processing status than systems that rely on node correlations and threshold evaluations. In some aspects, message processing may include message batching and prioritization to improve resource utilization, such as during high-volume Al agent interactions. In some aspects, the systems described herein may also implement backpressure management and concurrency control to reduce the likelihood of system overload, thereby enabling more efficient handling of message surges while maintaining system stability.

[0053] In some aspects, message handling is performed by a designated project manager agent, where the designated project manager agent role may be assigned to any available AlD&S Ref. No.: NKB0003WOagent. Beneficially, the model-agnostic message schema and routing system enables different types of Al agents to collaborate effectively, regardless of which specific Al agent handles the orchestration and message handling functions. This allows for a flexible and dynamically configurable multiple Al agent network.

[0054] Furthermore, in some aspects, the systems described herein may implement error handling for communications and task execution occurring among a project manager, the service orchestration layer 202, and Al agents. For example, the system described herein may classify errors according to identified failure modes and apply corresponding recovery strategies for the identified failure modes. In this manner, the project manager and / or the service orchestration layer 202 may respond differently to different types of failures arising during delegation of sub-tasks, message processing, tool invocation via tool invocation commands, or aggregation of intermediate outputs, thereby improving reliability of generating the integrated output relative to generalized error handling protocols.

[0055] The tool definition layer 204, shown in FIG.2, provides a structured schema-based framework for defining Al tools. The structured schema-based framework may define interfaces for Al agent and Al tool interaction and may provide a uniform way to describe any Al tool or Al agent capability, thereby enabling dynamic discovery and selection based on task or sub-task requirements. When an API call is made, a schema associated with the structured schema-based framework may be included to inform Al agents about available Al tools, tool purposes, and usage parameters, creating a consistent tool interaction process across Al agent implementations. In some aspects, each Al tool includes three core elements: a name identifier, a descriptive text explaining its purpose (e.g., domain expertise metadata), and an input schema that strictly defines acceptable parameters. In some aspects, these elements are included in the advertised capability descriptors that are accessible to a project manager, such as project manager 102 of FIG. 1, or other Al agents, such as agents 104 of FIG. 1, for sub-task or tool invocation command routing. In particular, the advertised capability descriptors may provide the semantic information that enables appropriate Al agent selection based on task or sub-task requirements.

[0056] The structured schema-based framework may use a nested property structure that supports multiple data types, optional and required fields, enumerated values, and array-type inputs with defined item types. In some aspects, the nested property structure provides advantages over flat schemas. For example, a “filters” property may contain nested properties for file type, date range, wherein date range may contain additional nested properties. ThisD&S Ref. No.: NKB0003WOhierarchical organization enables logical grouping of related parameters through filters and sorting options and containment of complexity where each nesting level encapsulates its own validation rules. Further, the hierarchical organization enables recursive validation patterns where consistent rules can apply at any nesting depth, as well as improved readability for humans and Al agents. Additional benefits are achieved for improved extensibility where new properties may be added to appropriate nodes without needing to restructure existing portions of the nested property structure. In contrast, flat property structures would require more complex naming conventions (e.g., filter file type vs. file type) that may obscure relationships between properties when Al agents need to read and analyze the properties. Flat structures may also make validation more difficult, especially for conditional requirements across related fields.

[0057] In some aspects, the schema-based framework may provide for dynamic Al tool definition. As used herein, “dynamic Al tool definition” may refer to an architecture that permits Al tools to be flexibly registered, discovered, and utilized at runtime rather than requiring a fixed set of Al tools hardcoded into the system. Although certain implementations may use internal Al tools, the architecture may be designed to support an Al agent and Al tool marketplace through which additional Al agents and Al tools may be selected and integrated into the system. In some aspects, the marketplace comprises a tool registration protocol, runtime schema validation, discoverable tool registry, schema-based tool definition, and decoupled tool implementation.

[0058] For example, new Al tools and Al agents may be added to the system at any time through a standardized interface. A runtime schema validation may allow for the system to dynamically validate tool invocation commands when they are detected to determine if they meet a requested Al tool’s corresponding schema, thereby creating a verification and trust mechanism for integrating third-party Al tools and Al agents. In the discoverable Al tool registry, Al tools and Al agents are stored in a centralized registry that functions like a marketplace where Al agents can discover capabilities based on their current tasks. The schema-based tool definition can be used such that new Al tools and Al agents can be defined using just their schema definitions, enabling “plug-and-play” extension of system capabilities without needing to modify or update underlying source code. Finally, the decoupled Al tool implementation allows the implementation of an Al tool separate from its interface, allowing for future marketplace participants to provide new implementations while maintaining compatibility.D&S Ref. No.: NKB0003WO

[0059] Such an architecture is configured to support a distributed ecosystem where third parties are able to register their specialized Al agents and Al tools. A project manager, such as the project manager 102 of FIG. 1, then orchestrates this marketplace, wherein any authorized entity may register new capabilities. This allows the marketplace to evolve organically while maintaining consistency between new Al tools and Al agents.

[0060] In some aspects, the tool definition layer 204 is associated with an Al tool registry that stores a plurality of Al tool definitions. In such aspects, each Al tool definition comprises an input schema indicating parameters associated with a respective Al tool. For example, the tool definition layer 204 provides the blueprint, metadata, and interface specifications that describe what Al tools are available and how they are intended to be used. The tool definition layer 204 includes Al tool definitions, schemas, and specifications. In some aspects, the tool definition layer 204 is designed to be extensible, wherein it provides the base set of Al tools in the system that are immediately available when building new applications, but developers can also define their own Al tools in their applications without needing the master system to be updated.

[0061] FIG. 3 depicts a detailed component diagram of an OGI system 300 for facilitating organizational general intelligence. As shown in FIG. 3, OGI system 300 includes an OGI framework layer 302, multiple Al agent teams (e.g., such as team A 310, teamB 312, and team C 314), an OGI tool system 316, and a serverless infrastructure 324. In some aspects, the OGI framework layer 302 is comparable to the service orchestration layer 202 of FIG. 2.

[0062] An Al agent team, such as team A 310, team B 312, or team C 314, may include multiple Al agents organized to work together as a unit. In some aspects, these Al agents are designed to process information, make decisions, and engage in complex reasoning based on their respective domain expertise. In some aspects, an Al agent team is designed to be modular and flexible. In particular, an Al agent team may include a plurality of nested Al agents and corresponding Al tools. An Al agent team may be configured for a single domain, meaning that the Al agent team is dedicated to a particular domain, such as development or marketing. In some aspects, an Al agent team is configured as a cross-functional team, with each Al agent of the Al agent team having a unique domain that can collaborate with other Al agents on the same Al agent team but having different capabilities and domains. Beneficially, in some aspects, context sharing and recording in the corresponding thread-ID happens when Al agents are actively participating in the generation process. Idle Al agents may not contribute to context associated with a thread ID.D&S Ref. No.: NKB0003WO

[0063] In some aspects, the OGI framework layer 302 is configured to perform message handling 304 and tool management 306, which are described in more detail with respect to FIG. 4. In some aspects, message handling 304 and tool management 306 may be performed by a dedicated message handler or by a project manager, such as project manager 102 of FIG.1. The OGI framework layer 302 is also configured to perform state persistence 308. State persistence 308 refers to how the OGI system 300 manages contextual state transitions when Al agents communicate with users, client applications, and other Al agents. For example, when a first Al agent communicates with a second Al agent, the OGI system 300 is configured to dynamically rewrite the role identities so that in each Al agent-to-AI agent interaction, one Al agent temporarily assumes a user role relative to the other Al agent within the thread associated with the interaction. Context may be preserved by storing thread IDs, message histories, and interaction states, allowing an Al agent to transition between talking to human users and Al agents without missing context from previous interactions. The system 300 then coordinates state changes across multiple Al agents through message queue management and flow control, preventing race conditions or competing state updates. In this manner, critical data may persist across sessions and API calls, enabling continuous conversations even when the system 300 restarts or experiences temporary disconnections.

[0064] Thus, state persistence 308 is achieved by assigning Al agents names and roles instead of being generally referred to as an Al agent or other machine learning model. Al agents may respond based on being addressed by their respective names, which improves coherence in multiple Al agent conversations. This type of identity framework allows each Al agent to learn a purpose associated with their respective response generation. Technical benefits may be achieved relative to existing Al agent systems, which may experience failures during recursive interactions among multiple Al agents when the Al agents are unable to maintain coherence while interacting with other Al agents or other entities and transitioning between user roles and response-generator roles. By assigning roles and tracking interactions, the OGI system 300 may maintain consistent agent identities across recursive multi-agent interactions, thereby reducing interaction failures and incoherent responses.

[0065] In some aspects, the OGI tool system 316 comprises a file system 318, a network 320, and data processors 322. While the tool definition layer 204 of FIG. 2 focuses on the structured schema-based framework for defining Al tools, the OGI tool system 316 is configured as the implementation layer where the Al tools operate. The file system 318 refers to a set of Al tools that allow Al agents to perform file operations, such as creating, reading,D&S Ref. No.: NKB0003WOupdating, or deleting files. Thus, the file system 318 is configured to provide Al agents with the capability to interact with external files, such as on behalf of users. The network 320 is configured to facilitate communication between components, such as API requests and data transfers, and to access real-time data and services. The data processors 322 are configured for transformation, analysis, and computation. In some aspects, data processors 322 are configured to parse structured data, perform calculations, analyze text, extract information from external documents, or generate insights from external datasets.

[0066] In some aspects, the serverless infrastructure 324 may be implemented using a cloud computing architecture in which server resources are managed by a cloud provider rather than directly by a system operator. In such implementations, the cloud provider may dynamically allocate compute resources on demand and may charge based on actual execution time used. This ability to dynamically allocate compute resources is beneficial for the OGI system 300 to perform model-agnostic collaboration between different Al agents. In some aspects, the OGI system 300 is a server-based system, either locally or externally, configured to support communication with API endpoints, as described herein.

[0067] FIG. 4 depicts a process diagram for facilitating OGI. In some aspects, systems, such as system 300 of FIG. 3, for facilitating OGI operate in a cyclical process. For example, as shown in FIG. 4, a system may perform multiple process stages of a process cycle for message initiation 402, tool use detection 404, message processing 406, tool use handling 408, and response management 410.

[0068] Message initiation 402 refers to a processing stage in which user input (e.g., a task request) initiates a process cycle for facilitating OGI. Upon receiving the user input, the OGI system 300 may create a user message object based on the user input, add the user message object to a thread associated with the interaction, and activate a typing indicator in a user interface displayed to the user who submitted the input or task request.

[0069] Tool use detection 404 may implement regular expression (regex)-based pattern matching (e.g., such as regex-based JavaScript Object Notation (JSON) pattern matching) to detect, within a user message object or an Al agent-generated message object, content corresponding to a request to invoke an Al tool. In some aspects, tool use detection 404 may compare the detected content to one or more available tool definitions to identify a corresponding Al tool. In some aspects, a detected tool use request may be validated by determining whether the request includes required fields associated with the corresponding AlD&S Ref. No.: NKB0003WOtool. Tool use detection 404 may further evaluate message content for a predefined command structure used for communication between Al agents. Upon validation, the detected tool use request may be decoded into a structured object for routing to an endpoint associated with the identified Al tool or Al agent.

[0070] In some aspects, message initiation 402 and tool use detection 404 occur concurrently, such that when the user input (e.g., a task request) is received, available Al tools are immediately identified and packaged with the user message object as part of the same API call object. In some aspects, all available Al tools are attached to each user message object. This ensures that Al agents have access to the full range of Al tools. During Al tool use detection and in response to a tool invocation command, the system then employs filtering and validation to match the correct Al tool to the present task or sub-task. Once a potential Al tool is identified based on matching capabilities, the system validates the Al tool use command against the required fields for the Al tool. The validation process confirms whether the Al tool exists in the tool registry, whether the command has all required parameters properly formatted, and whether the parameter values match field constraints.

[0071] Message processing 406 may involve routing the user message object to a project manager agent, such as project manager 102 of FIG. 1. Available Al tools are then identified and attached to the user message object. OGI systems are able to maintain the conversation context via a thread ID. In some aspects, message processing 406 is performed by an Al agent, where the Al agent evaluates the user message object and available Al tools and determines its course of action. Based on the determined course of action, the Al agent also determines if and when it will need assistance from other Al agents or by invoking one or more Al tools to complete the task.

[0072] Tool use handling 408 may involve routing Al tool use requests to appropriate Al agent endpoints and managing Al agent message routing with source and destination tracking. Tool use handling 408 may also involve processing Al agent responses and creating and managing the routing Al tool result messages. In some aspects, tool use handling 408 is performed by the tool management component 306 of FIG. 3. Al agent responses refer to outputs generated by Al agents, such as agent 104A of FIG. 1, and contain natural language or structured content generated by an LM of the Al agent. The Al agent response may address a sub-task of the task request and can include reasoning, explanations, or follow-up questions. In some aspects, Al agent responses may include tool invocation commands. Al tool results are generated by the system after a corresponding Al tool has been executed. In some aspects,D&S Ref. No.: NKB0003WOAl tool results may include the structured output from a specific Al tool operation. An Al tool result may present data and, in some aspects, may be formatted according to a standardized format that corresponds to the Al tool that was used to generate the tool result.

[0073] For example, in some aspects, an Al agent may generate a response that includes a tool invocation command. The tool invocation command may be processed to invoke a respective Al tool, wherein the invoked respective Al tool executes the tool invocation command. An Al tool result is generated with the outcome of the executed Al tool. The Al tool result is then routed back to the project manager or may be incorporated into another Al agent response as the conversation between Al agents continues towards completing the task request.

[0074] Once the responses are generated and received from the one or more Al agents, the process stage for response management 410 begins. In some aspects, response management 410 may involve handling nested Al tool use scenarios recursively. In some aspects, response management 410 may involve maintaining message order and thread consistency (e.g., through the thread ID) during the recursive process. Recursive tool scenarios occur when a response from a particular Al agent is not sufficient to achieve the goal associated with its assigned subtask. In such aspects, the project manager and Al agents may continue to iterate and communicate with each other until each Al agent generates a satisfactory response (e.g., which is a partial output). The satisfactory responses (e.g., corresponding to each sub-task) from each Al agent are then aggregated into an integrated output.

[0075] In some aspects, Al agents are configured to explicitly signal task or sub-task completion with standardized completion markers in the generated responses. Thus, when all sub-tasks have received completion signals, the project manager knows the integrated response can be generated. In some aspects, the system utilizes the thread to analyze context and interactions between Al agents to determine what sub-tasks have been addressed and which sub-tasks remain. In some aspects, the project manager or one or more other Al agents assigned user roles may be configured to ask other Al agents (e.g., responder Al agents) verification questions like “does this address the requirement in the sub-task?” or “is this sufficient?”, thereby enabling the other Al agents to self-assess their responses.

[0076] In some aspects, the project manager maintains an internal representation of the task request and corresponding sub-tasks. The project manager then compares the collected responses against this representation to identify any remaining gaps. If response(s) from oneD&S Ref. No.: NKB0003WOor more Al agents are incomplete, the project manager may request clarification, request additional information, or request that a sub-task be repeated.

[0077] In some aspects, response management 410 involves performing error handling and recovery when one or more errors occur within the recursive response process. Aspects of error handling are directed to fault isolation, context-aware recovery, data persistence, error specialization, and proactive error types. In particular, the OGI systems are configured to compartmentalize Al agent interactions and responses so that problems with one Al agent do not cascade to other agents. Furthermore, if errors do occur or happen to propagate, the thread can be utilized to determine when the error occurred and how it was propagated by referring to the context history. The thread can also be used to recover non-errored results or states to reset back to a previous state or response. Additionally, error handling mechanisms are employed to analyze and verify responses and results. In some aspects, response management 410 is handled by the OGI framework layer 302 of FIG. 3 and may rely on state persistence 308, described with respect to FIG. 3, to maintain context across a recursive workflow.

[0078] In some aspects, a thread stores one or more of the following: a thread ID that serves as a primary reference key, user inputs in chronological order, messages in chronological order, Al agent responses, information associated with Al agent responses, such as including which Al agent generated each response, tool invocation commands, tool execution results, metadata about state changes and processing status, and relationships between messages. The thread functions as a shared external memory that Al agents can access, regardless of their respective internal context-tracking abilities.

[0079] For example, for state-of-the-art machine learning models that can track context natively, the thread serves as a supplementary system that extends a fixed context window beyond its built-in limits. This is because even state-of-the-art machine learning models have context window limits, wherein the thread allows the machine learning models to reference past interactions that would otherwise be unavailable. For non-state-of-the-art machine learning models that lack context tracking abilities, the thread acts as the primary context mechanism. When such machine learning models receive a new message, the system can include relevant parts of the thread history as context. This thread-based approach bridges the gap between machine learning models with different context tracking capabilities to ensure the system functions without breaking or losing context between recursive multi-agent interactions.D&S Ref. No.: NKB0003WO

[0080] In some aspects, within a multi-agent workflow associated with a thread ID, a first Al agent may be configured with native context-tracking abilities, while a second Al agent may lack native context-tracking abilities. In such aspects, the first Al agent may maintain at least a portion of conversational state internally across multiple messages in the thread, and the thread may operate as a supplementary context source for the first Al agent. By contrast, for the second Al agent, the thread may operate as a primary context mechanism, such that the project manager agent provides at least a relevant portion of thread history, message history, or interaction state when submitting a request (e.g., for completing a second sub-task) to the second Al agent. In this manner, the project manager agent can preserve continuity across recursive or multi-step interactions even when different Al agents have different contexthandling capabilities.

[0081] Beneficially, by implementing response management in this manner, OGI systems, such as OGI system 300 of FIG. 3, are able to allow model-agnostic collaboration between Al agents, for example, operating based on leveraging LMs, to continue to iterate without reaching hard limits dictated by inherent context window maximums associated with the LMs.

[0082] In some aspects, response management 410 involves determining a message processing status (e.g., message received, response pending, response received) and updates a user interface (UI) state based on the message processing status while the user or client application is waiting on output (e.g., a final integrated output) that is responsive to its task request.Example Method for Supporting Model-Agnostic Collaboration

[0083] FIG. 5 depicts an example method 500 for supporting model-agnostic collaboration among a plurality of Al agents. In one aspect, method 500 can be implemented by the system 100 of FIG. 1 and / or processing system 600 of FIG. 6.

[0084] Method 500 begins at block 505 with decomposing a task request into at least a first sub-task and a second sub-task.

[0085] Method 500 then proceeds to block 510 with transmitting: a first request that corresponds to the first sub-task to a first Al agent of the plurality of Al agents; and a second request that corresponds to the second sub-task to a second Al agent of the plurality of Al agents, wherein the first request and the second request are formatted according to a first modelagnostic message schema.D&S Ref. No.: NKB0003WO

[0086] Method 500 then proceeds to block 515 with receiving: a first response to the first request from the first Al agent; and a second response to the second request from the second Al agent.

[0087] Method 500 then proceeds to block 520 with detecting, in the first response, a first tool invocation command that indicates a request to invoke a third Al agent of the plurality of Al agents.

[0088] Method 500 then proceeds to block 525 with routing the first tool invocation command to a first endpoint associated with the third Al agent.

[0089] Method 500 then proceeds to block 530 with receiving, from the third Al agent, a first result responsive to the first tool invocation command.

[0090] Method 500 then proceeds to block 535 with providing an integrated output to a user or client application that submitted the task request, wherein the integrated output is generated based on the first response, the second response, and the first result.

[0091] In some aspects, method 500 further includes identifying the first Al agent and the second Al agent based on: a first advertised capability descriptor associated with the first Al agent; a second advertised capability descriptor associated with the second Al agent; and the content of the task request.

[0092] In some aspects, at least one of the first advertised capability descriptor or the second advertised capability descriptor comprises at least one of: domain expertise metadata, or one or more expected input formats; or one or more expected output formats.

[0093] In some aspects, the first response comprises first output from a first machine learning model associated with the first Al agent and not associated with the second Al agent, the second response comprises second output from a second machine learning model associated with the second Al agent and not associated with the first Al agent, and the first machine learning model and the second machine learning model are different.

[0094] In some aspects, method 500 further includes, prior to decomposing the task request into at least the first sub-task and the second sub-task, attaching, to the task request, one or more tool definitions corresponding to one or more available tools, each respective tool definition, of the one or more tool definitions, indicating at least one of a tool identifier, a tool purpose, or one or more usage parameters, wherein block 505 includes generating the first sub-D&S Ref. No.: NKB0003WOtask and the second sub-task based at least in part on the one or more tool definitions, and wherein the first tool invocation command is based on the one or more tool definitions.

[0095] In some aspects, attaching the one or more tool definitions to the task request comprises applying regex-based pattern matching to the task request to identify the one or more available tools.

[0096] In some aspects, block 525 includes, prior to routing, at least one of: determining that the first tool invocation command satisfies a command structure for invoking the third Al agent, or determining that the first tool invocation command includes one or more required fields for invoking the third Al agent.

[0097] In some aspects, method 500 further includes, prior to routing the first tool invocation command to the first endpoint associated with the third Al agent, decoding the first tool invocation command to obtain a structured object.

[0098] In some aspects, method 500 further includes detecting, in the first result from the third Al agent, a nested tool invocation command.

[0099] In some aspects, method 500 further includes identifying a fourth Al agent, of the plurality of Al agents, based on the nested tool invocation command and an advertised capability descriptor associated with the fourth Al agent.

[0100] In some aspects, method 500 further includes recursively processing the nested tool invocation command based on routing the nested tool invocation command to a second endpoint associated with the fourth Al agent.

[0101] In some aspects, method 500 further includes receiving, from the fourth Al agent, a second result responsive to the nested tool invocation command, wherein the integrated output is further generated based on the second result.

[0102] In some aspects, method 500 further includes initiating a thread associated with a thread identifier.

[0103] In some aspects, method 500 further includes storing, in the thread, at least one of: the task request; the first request; the second request; the first response; the second response; the first tool invocation command; the first result; or the integrated output.

[0104] In some aspects, the first Al agent is configured with native context-tracking abilities, and wherein the thread operates as a primary context mechanism for the second Al agent, and the thread operates as a primary context mechanism for the second Al agent.D&S Ref. No.: NKB0003WO

[0105] Note that FIG. 5 is just one example of a method, and other methods including fewer, additional, or alternative operations are possible consistent with this disclosure.Example Processing System for Supporting Model-Agnostic Collaboration

[0106] FIG. 6 depicts an example processing system 600 configured to perform various aspects described herein, including, for example, method 500 as described above with respect to FIG. 5.

[0107] Processing system 600 is generally an example of an electronic device configured to execute computer-executable instructions, such as those derived from compiled computer code, including without limitation personal computers, tablet computers, servers, smartphones, smart devices, wearable devices, augmented and / or virtual reality devices, and others.

[0108] In the depicted example, processing system 600 includes one or more processors 602, one or more input / output devices 604, one or more display devices 606, one or more network interfaces 608 through which processing system 600 is connected to one or more networks (e.g., a local network, an intranet, the Internet, or any other group of processing systems communicatively connected to each other), and computer-readable medium 612. In the depicted example, the aforementioned components are coupled by a bus 610, which may generally be configured for data exchange amongst the components. Bus 610 may be representative of multiple buses, while only one is depicted for simplicity.

[0109] Processor(s) 602 are generally configured to retrieve and execute instructions stored in one or more memories, including local memories like computer- readable medium 612, as well as remote memories and data stores. Similarly, processor(s) 602 are configured to store application data residing in local memories like the computer-readable medium 612, as well as remote memories and data stores. More generally, bus 610 is configured to transmit programming instructions and application data among the processor(s) 602, display device(s) 606, network interface(s) 608, and / or computer-readable medium 612. In certain embodiments, processor(s) 602 are representative of one or more central processing units (CPUs), graphics processing units (GPUs), tensor processing units (TPUs), accelerators, and other processing devices.

[0110] Input / output device(s) 604 may include any device, mechanism, system, interactive display, and / or various other hardware and software components for communicating information between processing system 600 and a user of processing system 600. For example, input / output device(s) 604 may include input hardware, such as a keyboard, touch screen,D&S Ref. No.: NKB0003WObutton, microphone, speaker, and / or other device for receiving inputs from the user and sending outputs to the user.

[0111] Display device(s) 606 may generally include any sort of device configured to display data, information, graphics, user interface elements, and the like to a user. For example, display device(s) 606 may include internal and external displays such as an internal display of a tablet computer or an external display for a server computer or a projector. Display device(s) 606 may further include displays for devices, such as augmented, virtual, and / or extended reality devices. In various embodiments, display device(s) 606 may be configured to display a graphical user interface.

[0112] Network interface(s) 608 provide processing system 600 with access to external networks and thereby to external processing systems. Network interface(s) 608 can generally be any hardware and / or software capable of transmitting and / or receiving data via a wired or wireless network connection. Accordingly, network interface(s) 608 can include a communication transceiver for sending and / or receiving any wired and / or wireless communication.

[0113] Computer-readable medium 612 may be a volatile memory, such as a random access memory (RAM), or a nonvolatile memory, such as nonvolatile random access memory (NVRAM), or the like. Computer- readable medium 612 may include one or more non-transitory computer-readable media, such as RAM, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, compact disc read-only memory (CD-ROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store program code in the form of instructions or data structures and which can be accessed by processor(s) 602. In this example, computer-readable medium 612 includes decomposing component 614, transmitting component 616, receiving component 618, detecting component 620, routing component 622, providing component 624, identifying component 626, generating component 628, attaching component 630, applying component 632, determining component 634, decoding component 636, processing component 638, initiating component 640, and storing component 642.

[0114] In certain embodiments, decomposing component 614 is configured to decompose a task request into at least a first sub-task and a second sub-task, as described above in FIG. 5 with reference to block 505. In certain embodiments, transmitting component 616 is configuredD&S Ref. No.: NKB0003WOto transmit a first request that corresponds to the first sub-task to a first Al agent of the plurality of Al agents; and a second request that corresponds to the second sub-task to a second Al agent of the plurality of Al agents, wherein the first request and the second request are formatted according to a first model-agnostic message schema, as described above in FIG. 5 with reference to block 510. In certain embodiments, receiving component 618 is configured to receive a first response to the first request from the first Al agent; and a second response to the second request from the second Al agent, as described above in FIG. 5 with reference to block 515. In certain embodiments, detecting component 620 is configured to detect, in the first response, a first tool invocation command that indicates a request to invoke a third Al agent of the plurality of Al agents, as described above in FIG. 5 with reference to block 520. In certain embodiments, routing component 622 is configured to route the first tool invocation command to a first endpoint associated with the third Al agent, as described above in FIG. 5 with reference to block 525. In certain embodiments, receiving component 618 is configured to receive, from the third Al agent, a first result responsive to the first tool invocation command, as described above in FIG. 5 with reference to block 530. In certain embodiments, providing component 624 is configured to provide an integrated output to a user or client application that submitted the task request, wherein the integrated output is generated based on the first response, the second response, and the first result, as described above in FIG. 5 with reference to block 535.

[0115] Note that FIG. 6 is just one example of a processing system consistent with aspects described herein, and other processing systems having additional, alternative, or fewer components are possible consistent with this disclosure.

[0116] Thus, many technical benefits are achieved by OGI systems, such as processing system 600 described herein, such as recursive tool processing, flexible schema systems, asynchronous communication patterns, and context preservation. For example, OGI systems are able to handle nested tool uses within responses, maintain context across multiple Al agent interactions, and preserve message threading and ordering even in recursive response generation and management. The flexible schema system supports complex nested property structures, handles multiple data types and validation rules, and allows for dynamic Al tool definition.

[0117] By implementing asynchronous communication patterns, the OGI systems utilize client frameworks for reactive processing, maintaining system responsiveness during complex operations, and handling concurrent Al agent interactions. Additionally, context is preservedD&S Ref. No.: NKB0003WOby utilizing thread-ID based conversation tracking to allow for context tracking between machine learning models with different context tracking abilities. Additionally, context is preserved by utilizing a publisher-subscriber pattern, which dynamically assigns specific roles to the different Al agents. Overall, while existing systems are focused on selecting a single Al agent that may be best matched for a particular task, the OGI systems described herein provide a flexible, scalable framework for Al agents to interact with each other, and in some cases, other Al tools, while maintaining conversation context and ensuring proper message routing and handling to provide an improved completion of a task request.Example Clauses

[0118] Implementation examples are described in the following numbered clauses:

[0119] Clause 1: A method by a project manager agent to support model-agnostic collaboration among a plurality of Al agents, comprising: decomposing a task request into at least a first sub-task and a second sub-task; transmitting: a first request that corresponds to the first sub-task to a first Al agent of the plurality of Al agents; and a second request that corresponds to the second sub-task to a second Al agent of the plurality of Al agents, wherein the first request and the second request are formatted according to a first model-agnostic message schema; receiving: a first response to the first request from the first Al agent; and a second response to the second request from the second Al agent; detecting, in the first response, a first tool invocation command that indicates a request to invoke a third Al agent of the plurality of Al agents; routing the first tool invocation command to a first endpoint associated with the third Al agent; receiving, from the third Al agent, a first result responsive to the first tool invocation command; and providing an integrated output to a user or client application that submitted the task request, wherein the integrated output is generated based on the first response, the second response, and the first result.

[0120] Clause 2: The method of Clause 1, further comprising identifying the first Al agent and the second Al agent based on: a first advertised capability descriptor associated with the first Al agent; a second advertised capability descriptor associated with the second Al agent; and content of the task request.

[0121] Clause 3: The method of Clause 2, wherein at least one of the first advertised capability descriptor or the second advertised capability descriptor comprises at least one of: domain expertise metadata, or one or more expected input formats; or one or more expected output formats.D&S Ref. No.: NKB0003WO

[0122] Clause 4: The method of any one of Clauses 1-3, wherein: the first response comprises first output from a first machine learning model associated with the first Al agent and not associated with the second Al agent, the second response comprises second output from a second machine learning model associated with the second Al agent and not associated with the first Al agent, and the first machine learning model and the second machine learning model are different.

[0123] Clause 5: The method of any one of Clauses 1-4, further comprising: prior to decomposing the task request into the at least the first sub-task and the second sub-task, attaching, to the task request, one or more tool definitions corresponding to one or more available tools, each respective tool definition, of the one or more tool definitions, indicating at least one of a tool identifier, a tool purpose, or one or more usage parameters, wherein decomposing the task request comprises generating the first sub-task and the second sub-task based at least in part on the one or more tool definitions, and wherein the first tool invocation command is based on the one or more tool definitions.

[0124] Clause 6: The method of Clause 5, wherein attaching the one or more tool definitions to the task request comprises applying regex-based pattern matching to the task request to identify the one or more available tools.

[0125] Clause 7: The method of any one of Clauses 1-6, wherein routing the first tool invocation command to the first endpoint associated with the third Al agent comprises, prior to routing, at least one of: determining that the first tool invocation command satisfies a command structure for invoking the third Al agent, or determining that the first tool invocation command includes one or more required fields for invoking the third Al agent.

[0126] Clause 8: The method of Clause 7, further comprising prior to routing the first tool invocation command to the first endpoint associated with the third Al agent, decoding the first tool invocation command to obtain a structured object.

[0127] Clause 9: The method of any one of Clauses 1-8, further comprising: detecting, in the first result from the third Al agent, a nested tool invocation command; identifying a fourth Al agent, of the plurality of Al agents, based on the nested tool invocation command and an advertised capability descriptor associated with the fourth Al agent; recursively processing the nested tool invocation command based on routing the nested tool invocation command to a second endpoint associated with the fourth Al agent; and receiving, from the fourth Al agent,D&S Ref. No.: NKB0003WOa second result responsive to the nested tool invocation command, wherein the integrated output is further generated based on the second result.

[0128] Clause 10: The method of any one of Clauses 1-9, further comprising: initiating a thread associated with a thread identifier; and storing, in the thread, at least one of: the task request; the first request; the second request; the first response; the second response; the first tool invocation command; the first result; or the integrated output.

[0129] Clause 11 : The method of Clause 10, wherein: the first Al agent is configured with native context-tracking abilities, and wherein the thread operates as a primary context mechanism for the second Al agent, and the thread operates as a primary context mechanism for the second Al agent.

[0130] Clause 12: A system comprising: a project manager agent configured to support model-agnostic collaboration among a plurality of artificial intelligence (Al) agents; the plurality of Al agents; a communication interface configured to support communication between the project manager agent and the plurality of Al agents; and a processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to cause the project manager agent to perform a method in accordance with any one of Clauses 1-11.

[0131] Clause 13: The system of Clause 12, further comprising a concurrency coordinator configured to cause the first request and the second request to be processed in parallel by the first Al agent and the second Al agent.

[0132] Clause 14: An apparatus, comprising a processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to: perform a method in accordance with any one of Clauses 1-11.

[0133] Clause 15: A processing system, comprising means for performing a method in accordance with any one of Clauses 1-11.

[0134] Clause 16: A non-transitory computer-readable medium storing program code for causing a processing system to perform the steps of any one of Clauses 1-11.

[0135] Clause 17: A computer program product embodied on a computer-readable storage medium comprising code for performing a method in accordance with any one of Clauses 1-11..D&S Ref. No.: NKB0003WOAdditional Considerations

[0136] The preceding description is provided to enable any person skilled in the art to practice the various embodiments described herein. The examples discussed herein are not limiting of the scope, applicability, or embodiments set forth in the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments. For example, changes may be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. Various examples may omit, substitute, or add various procedures or components as appropriate. For instance, the methods described may be performed in an order different from that described, and various steps may be added, omitted, or combined. Also, features described with respect to some examples may be combined in some other examples. For example, an apparatus may be implemented, or a method may be practiced using any number of the aspects set forth herein. In addition, the scope of the disclosure is intended to cover such an apparatus or method that is practiced using other structure, functionality, or structure and functionality in addition to, or other than, the various aspects of the disclosure set forth herein. It should be understood that any aspect of the disclosure disclosed herein may be embodied by one or more elements of a claim.

[0137] As used herein, a phrase referring to “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiples of the same element (e.g., a-a, a-a-a, a-a-b, a-a-c, a-b-b, a-c-c, b-b, b-b-b, b-b-c, c-c, and c-c-c or any other ordering of a, b, and c).

[0138] As used herein, the term “determining” encompasses a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database, or another data structure), ascertaining and the like. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” may include resolving, selecting, choosing, establishing and the like.

[0139] The methods disclosed herein comprise one or more steps or actions for achieving the methods. The method steps and / or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and / or use of specific steps and / or actions may be modified withoutD&S Ref. No.: NKB0003WOdeparting from the scope of the claims. Further, the various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions. The means may include various hardware and / or software component(s) and / or module(s), including, but not limited to a circuit, an application specific integrated circuit (ASIC), or processor. Generally, where there are operations illustrated in figures, those operations may have corresponding counterpart means-plus-function components with similar numbering.

[0140] The following claims are not intended to be limited to the embodiments shown herein but are to be accorded the full scope consistent with the language of the claims. Within a claim, reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. No claim element is to be construed under the provisions of 35 U.S.C. §112(f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.” All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.

Claims

D&S Ref. No.: NKB0003WOWHAT IS CLAIMED IS:

1. A method by a project manager agent to support model-agnostic collaboration among a plurality of artificial intelligence (Al) agents, comprising:decomposing a task request into at least a first sub-task and a second sub-task; transmitting:a first request that corresponds to the first sub-task to a first Al agent of the plurality of Al agents; anda second request that corresponds to the second sub-task to a second Al agent of the plurality of Al agents, wherein the first request and the second request are formatted according to a first model-agnostic message schema;receiving:a first response to the first request from the first Al agent; and a second response to the second request from the second Al agent; detecting, in the first response, a first tool invocation command that indicates a request to invoke a third Al agent of the plurality of Al agents;routing the first tool invocation command to a first endpoint associated with the third Al agent;receiving, from the third Al agent, a first result responsive to the first tool invocation command; andproviding an integrated output to a user or client application that submitted the task request, wherein the integrated output is generated based on the first response, the second response, and the first result.

2. The method of Claim 1 , further comprising identifying the first Al agent and the second Al agent based on:a first advertised capability descriptor associated with the first Al agent;a second advertised capability descriptor associated with the second Al agent; and content of the task request.

3. The method of Claim 2, wherein at least one of the first advertised capability descriptor or the second advertised capability descriptor comprises at least one of:domain expertise metadata, orone or more expected input formats; orD&S Ref. No.: NKB0003WOone or more expected output formats.

4. The method of Claim 1 , wherein:the first response comprises first output from a first machine learning model associated with the first Al agent and not associated with the second Al agent,the second response comprises second output from a second machine learning model associated with the second Al agent and not associated with the first Al agent, andthe first machine learning model and the second machine learning model are different.

5. The method of Claim 1, further comprising:prior to decomposing the task request into at least the first sub-task and the second subtask, attaching, to the task request, one or more tool definitions corresponding to one or more available tools, each respective tool definition, of the one or more tool definitions, indicating at least one of a tool identifier, a tool purpose, or one or more usage parameters, wherein decomposing the task request comprises generating the first sub-task and the second sub-task based at least in part on the one or more tool definitions, andwherein the first tool invocation command is based on the one or more tool definitions.

6. The method of Claim 5, wherein attaching the one or more tool definitions to the task request comprises applying regular expression (regex)-based pattern matching to the task request to identify the one or more available tools.

7. The method of Claim 1, wherein routing the first tool invocation command to the first endpoint associated with the third Al agent comprises, prior to routing, at least one of:determining that the first tool invocation command satisfies a command structure for invoking the third Al agent, ordetermining that the first tool invocation command includes one or more required fields for invoking the third Al agent.

8. The method of Claim 7, further comprising, prior to routing the first tool invocation command to the first endpoint associated with the third Al agent, decoding the first tool invocation command to obtain a structured object.D&S Ref. No.: NKB0003WO9. The method of Claim 1, further comprising:detecting, in the first result from the third Al agent, a nested tool invocation command; identifying a fourth Al agent, of the plurality of Al agents, based on the nested tool invocation command and an advertised capability descriptor associated with the fourth Al agent;recursively processing the nested tool invocation command based on routing the nested tool invocation command to a second endpoint associated with the fourth Al agent; and receiving, from the fourth Al agent, a second result responsive to the nested tool invocation command,wherein the integrated output is further generated based on the second result.

10. The method of Claim 1, further comprising:initiating a thread associated with a thread identifier; andstoring, in the thread, at least one of:the task request;the first request;the second request;the first response;the second response;the first tool invocation command;the first result; orthe integrated output.

11. The method of claim 10, wherein:the first Al agent is configured with native context-tracking abilities, and wherein the thread operates as a primary context mechanism for the second Al agent, andthe thread operates as a primary context mechanism for the second Al agent.

12. A system comprising:a project manager agent configured to support model-agnostic collaboration among a plurality of artificial intelligence (Al) agents;the plurality of Al agents;a communication interface configured to support communication between the project manager agent and the plurality of Al agents; andD&S Ref. No.: NKB0003WOa processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system configured to cause the project manager agent to:decompose a task request into at least a first sub-task and a second sub-task; transmit:a first request that corresponds to the first sub-task to a first Al agent of the plurality of Al agents; anda second request that corresponds to the second sub-task to a second Al agent of the plurality of Al agents, wherein the first request and the second request are formatted according to a first model-agnostic message schema; receive:a first response to the first request from the first Al agent; and a second response to the second request from the second Al agent; detect, in the first response, a first tool invocation command that indicates a request to invoke a third Al agent of the plurality of Al agents;route the first tool invocation command to a first endpoint associated with the third Al agent;receive, from the third Al agent, a first result responsive to the first tool invocation command; andprovide an integrated output to a user or client application that submitted the task request, wherein the integrated output is generated based on the first response, the second response, and the first result.

13. The system of Claim 12, further comprising a concurrency coordinator configured to cause the first request and the second request to be processed in parallel by the first Al agent and the second Al agent.

14. The system of Claim 12, wherein the processing system is configured to cause the project manager agent to:aggregate the first response and the second response into an intermediate state; and generate an additional sub-task based on the intermediate state.D&S Ref. No.: NKB0003WO15. The system of Claim 12, wherein the processing system is configured to cause the project manager agent to identify the first Al agent and the second Al agent based on:a first advertised capability descriptor associated with the first Al agent;a second advertised capability descriptor associated with the second Al agent; and content of the task request.

16. The system of Claim 15, wherein at least one of the first advertised capability descriptor or the second advertised capability descriptor comprises at least one of:domain expertise metadata, orone or more expected input formats; orone or more expected output formats.

17. The system of Claim 12, wherein:the first response comprises first output from a first machine learning model associated with the first Al agent and not associated with the second Al agent,the second response comprises second output from a second machine learning model associated with the second Al agent and not associated with the first Al agent, andthe first machine learning model and the second machine learning model are different.

18. The system of Claim 12, wherein:the processing system is configured to cause the project manager agent to, prior to decomposition of the task request into at least the first sub-task and the second sub-task, attach, to the task request, one or more tool definitions that correspond to one or more available tools, each respective tool definition, of the one or more tool definitions, indicating at least one of a tool identifier, a tool purpose, or one or more usage parameters,wherein to cause the project manager agent to decompose the task request, the processing system is configured to cause the project manager agent to generate the first subtask and the second sub-task based at least in part on the one or more tool definitions, and wherein the first tool invocation command is based on the one or more tool definitions.

19. The system of Claim 18, wherein to cause the project manager agent to attach the one or more tool definitions to the task request, the processing system is configured to cause the project manager agent to apply regular expression (regex)-based pattern matching to the task request to identify the one or more available tools.D&S Ref. No.: NKB0003WO20. The system of Claim 12, wherein to cause the project manager agent to route the first tool invocation command to the first endpoint associated with the third Al agent, the processing system is configured to cause the project manager agent to, prior to routing, at least one of:determine that the first tool invocation command satisfies a command structure for invoking the third Al agent, ordetermine that the first tool invocation command includes one or more required fields for invoking the third Al agent.

Images