1. A method (300) for determining optimal software license allocation through a multi-agent framework, the method (300) comprising: receiving (302), by a computing device (102), consolidated license data for each license of a current license allocation in an enterprise, wherein the consolidated license data comprises contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history; generating (304), by the computing device (102) via a Large Language Model (LLM) (216), historical usage data and constraint information for the license based on the consolidated license data; predicting (306), by the computing device (102), a future license demand based on the historical usage data through a future usage agent; generating (314), by the computing device (102) via the LLM (216), a set of boundary constraints for license allocation based on the constraint information through a constraint agent; generating (320), by the computing device (102), a first license allocation for the enterprise and a justification for the first license allocation through a set of optimal usage agents using a set of heuristic rules; generating (322), by the computing device (102) via the LLM (216), a second license allocation for the enterprise through a generic LLM agent using iterative generation and refinement of meta-prompts encoding allocation objectives, the historical usage data, and the constraint information; and providing (324), by the computing device (102), a final license allocation from the first license allocation and the second license allocation based on a predefined priority-based criteria, wherein the final license allocation corresponds to at least one of the current license allocation, a redistribution of the current license allocation, one or more new licenses added to the current license allocation, or one or more current licenses removed from the current license allocation.

2. The method (300) as claimed in claim 1, wherein predicting the future license demand for the license comprises: receiving (308), via the future usage agent, the historical usage data from the LLM (216); identifying (310), via the future usage agent, usage patterns and a potential usage deviation of the license from the historical usage data; and predicting (312), via the future usage agent, the future license demand based on the usage patterns and the potential usage deviation .

3. The method (300) as claimed in claim 1, wherein the constraint information comprises contractual limitations of the license and policy rules of the enterprise, and wherein generating the set of boundary constraints for allocation of the license comprises: receiving (316), via the constraint agent, the constraint information from the LLM (216); and generating (318), via the constraint agent, the set of boundary constraints based on the contractual limitations and the policy rules.

4. The method (300) as claimed in claim 1, wherein the set of heuristic rules comprises Central Processing Unit (CPU) usage-based rules, application usage-based rules, and demand-based rules, and wherein the set of optimal usage agents comprises a CPU usage agent, an application usage agent, and a demand-based agent.

5. The method (300) as claimed in claim 4, wherein generating the first license allocation for the enterprise and the justification for the first license allocation through the CPU usage agent comprises: calculating (402), via the CPU usage agent, an optimal range for optimal CPU usage based on the future license demand and the set of boundary constraints, wherein the optimal range comprises a minimum threshold value and a maximum threshold value, wherein the future license demand comprises a forecasted CPU usage, and wherein the set of boundary constraints comprises a set of contractual CPU limits; and comparing (404), via the CPU usage agent, the forecasted CPU usage and a current CPU usage with the optimal range; and, one of: when the current CPU usage and the forecasted CPU usage are within the optimal range, generating (406), via the CPU usage agent, a current license allocation maintenance recommendation and the justification associated therewith; when the current CPU usage and the forecasted CPU usage are less than the minimum threshold value, generating (408), via the CPU usage agent, a license release recommendation and the justification associated therewith; or when the current CPU usage and the forecasted CPU usage are more than the maximum threshold value, generating (410), via the CPU usage agent, a license procurement recommendation and the justification associated therewith.

6. The method (300) as claimed in claim 4, wherein generating the first license allocation for the enterprise and the justification for the first license allocation through the application usage agent comprises: identifying (502), via the application usage agent, a user and an application associated with each license in a current license allocation of the enterprise; determining (504), via the application usage agent, an inactivity period of the user with respect to the application; determining (506), via the application usage agent, a future application usage of the user from the future license demand; when the inactivity period is more than a predefined threshold value and the future application usage is indicative of a continued inactivity, checking (508), via the application usage agent, whether a floating license is available corresponding to the license; when the floating license is available, generating (510), via the application usage agent, a floating license reallocation recommendation, a target user for reallocation, and the justification associated therewith; and when the floating license is unavailable, generating (512), via the application usage agent, the license release recommendation for the user and the justification associated therewith; when the inactivity period is more than the predefined threshold value and the future application usage is indicative of an increased activity, generating (514), via the application usage agent, a license retention recommendation and the justification associated therewith; and when the inactivity period is less than the predefined threshold value, generating (516), via the application usage agent, the license allocation maintenance recommendation and the justification associated therewith.

7. The method (300) as claimed in claim 4, wherein generating the first license allocation for the enterprise and the justification for the first license allocation through the demand-based agent comprises: comparing (602), via the demand-based agent, a current system usage of the license and a forecasted system usage of the enterprise with a predefined threshold demand level, wherein the forecasted system usage is a part of the future license demand; when the current system usage and the forecasted system are within the predefined threshold demand level, generating (604), via the demand-based agent, the current license allocation maintenance recommendation and the justification associated therewith; when one of the current system usage or the forecasted system usage is above the predefined threshold demand level, searching (606), via the demand-based agent, for a cost-effective license type compared to the license type of the plurality of currently allocated licenses based on a set of procurement/release constraints of the set of boundary constraints; and based on the comparison and the searching, generating (608), via the demand-based agent, the license procurement recommendation for one or more new licenses and the justification associated therewith, wherein the license type of each of the one or more new licenses is one of the cost-effective license type or the license type of one of the current license allocation; and when one of the current system usage or the forecasted system is below the predefined threshold demand level, searching (610), via the demand-based agent, for the cost-effective license type compared to the license type of the plurality of currently allocated licenses based on the set of procurement/release constraints of the set of boundary constraints; and based on the comparison and the searching, generating (612), via the demand-based agent, one of a license switching recommendation or the license release recommendation for one or more licenses of the current allocation, and the justification associated therewith, wherein the license switching recommendation is an actionable insight indicating switching the one or more licenses of the current allocation to one or more new licenses, each having the license type as the cost-effective license type.

8. The method (300) as claimed in claim 1, wherein generating, via the LLM (216), the second license allocation for the enterprise through the generic LLM agent comprises: inputting (702), via the generic LLM (216) agent, a set of rules, policies, and constraints from the constraint information to the LLM (216); for each iteration until one of a predefined number of iterations is completed or a predefined criteria is successfully attained, generating (704), via the LLM (216), a set of candidate license allocations based on the set of rules, policies, and constraints; calculating (706), via the LLM (216), a score for each of the set of candidate license allocations with respect to the set of rules, policies, and constraints; and updating (708), via the LLM (216), a meta prompt using one or more of the set of candidate license allocations selected based on the score; and inputting (710), via the generic LLM agent, the meta prompt to the LLM (216) for generating a next set of candidate license allocations; and generating (712), via the LLM (216), the second license allocation for the enterprise selected from a plurality of candidate license allocations.

9. A system (100) for determining optimal software license allocation through a multi-agent framework, the system (100) comprising: a processor (104); and a memory (106) communicatively coupled to the processor (104), wherein the memory (106) stores processor instructions, which when executed by the processor (104), cause the processor (104) to: receive (302) consolidated license data for each license of a current license allocation in an enterprise, wherein the consolidated license data comprises contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history; generate (304), via a Large Language Model (LLM) (216), historical usage data and constraint information for the license based on the consolidated license data; predict (306) a future license demand based on the historical usage data through a future usage agent; generate (314), via the LLM (216), a set of boundary constraints for license allocation based on the constraint information through a constraint agent; generate (320) a first license allocation for the enterprise and a justification for the first license allocation through a set of optimal usage agents using a set of heuristic rules; generate (322), via the LLM (216), a second license allocation for the enterprise through a generic LLM agent using iterative generation and refinement of meta-prompts encoding allocation objectives, the historical usage data, and the constraint information; and provide (324) a final license allocation from the first license allocation and the second license allocation based on a predefined priority-based criteria, wherein the final license allocation corresponds to at least one of the current license allocation, a redistribution of the current license allocation, one or more new licenses added to the current license allocation, or one or more current licenses removed from the current license allocation.

10. The system (100) as claimed in claim 9, wherein to predict the future license demand for the license, the processor instructions, on execution, cause the processor (104) to: receive (308), via the future usage agent, the historical usage data from the LLM (216); identify (310), via the future usage agent, usage patterns and a potential usage deviation of the license from the historical usage data; and predict (312), via the future usage agent, the future license demand based on the usage patterns and the potential usage deviation.

11. The system (100) as claimed in claim 9, wherein the constraint information comprises contractual limitations of the license and policy rules of the enterprise, and wherein to generate the set of boundary constraints for allocation of the license, the processor instructions, on execution, cause the processor (104) to: receive (316), via the constraint agent, the constraint information from the LLM (216); and generate (318), via the constraint agent, the set of boundary constraints based on the contractual limitations and the policy rules.

12. The system (100) as claimed in claim 9, wherein the set of heuristic rules comprises Central Processing Unit (CPU) usage-based rules, application usage-based rules, and demand-based rules, and wherein the set of optimal usage agents comprises a CPU usage agent, an application usage agent, and a demand-based agent.

13. The system (100) as claimed in claim 12, wherein to generate the first license allocation for the enterprise and the justification for the first license allocation through the CPU usage agent, the processor instructions, on execution, cause the processor (104) to: calculate (402), via the CPU usage agent, an optimal range for optimal CPU usage based on the future license demand and the set of boundary constraints, wherein the optimal range comprises a minimum threshold value and a maximum threshold value, wherein the future license demand comprises a forecasted CPU usage, and wherein the set of boundary constraints comprises a set of contractual CPU limits; and compare (404), via the CPU usage agent, the forecasted CPU usage and a current CPU usage with the optimal range; and, one of: when the current CPU usage and the forecasted CPU usage are within the optimal range, generate (406), via the CPU usage agent, a current license allocation maintenance recommendation and the justification associated therewith; when the current CPU usage and the forecasted CPU usage are less than the minimum threshold value, generate (408), via the CPU usage agent, a license release recommendation and the justification associated therewith; or when the current CPU usage and the forecasted CPU usage are more than the maximum threshold value, generate (410), via the CPU usage agent, a license procurement recommendation and the justification associated therewith.

14. The system (100) as claimed in claim 12, wherein to generate the first license allocation for the enterprise and the justification for the first license allocation through the application usage agent, the processor instructions, on execution, cause the processor (104) to: identify (502), via the application usage agent, a user and an application associated with each license in a current license allocation of the enterprise; determine (504), via the application usage agent, an inactivity period of the user with respect to the application; determine (506), via the application usage agent, a future application usage of the user from the future license demand; when the inactivity period is more than a predefined threshold value and the future application usage is indicative of a continued inactivity, check (508), via the application usage agent, whether a floating license is available corresponding to the license; when the floating license is available, generate (510), via the application usage agent, a floating license reallocation recommendation, a target user for reallocation, and the justification associated therewith; and when the floating license is unavailable, generate (512), via the application usage agent, the license release recommendation for the user and the justification associated therewith; when the inactivity period is more than the predefined threshold value and the future application usage is indicative of an increased activity, generate (514), via the application usage agent, a license retention recommendation and the justification associated therewith; and when the inactivity period is less than the predefined threshold value, generate (516), via the application usage agent, the license allocation maintenance recommendation and the justification associated therewith.

15. The system (100) as claimed in claim 12, wherein to generate the first license allocation for the enterprise and the justification for the first license allocation through the demand-based agent, the processor instructions, on execution, cause the processor (104) to: compare (602), via the demand-based agent, a current system usage of the license and a forecasted system usage of the enterprise with a predefined threshold demand level, wherein the forecasted system usage is a part of the future license demand; when the current system usage and the forecasted system are within the predefined threshold demand level, generate (604), via the demand-based agent, the current license allocation maintenance recommendation and the justification associated therewith; when one of the current system usage or the forecasted system usage is above the predefined threshold demand level, search (606), via the demand-based agent, for a cost-effective license type compared to the license type of the plurality of currently allocated licenses based on a set of procurement/release constraints of the set of boundary constraints; and based on the comparison and the searching, generate (608), via the demand-based agent, the license procurement recommendation for one or more new licenses and the justification associated therewith, wherein the license type of each of the one or more new licenses is one of the cost-effective license type or the license type of one of the current license allocation; and when one of the current system usage or the forecasted system is below the predefined threshold demand level, search (610), via the demand-based agent, for the cost-effective license type compared to the license type of the plurality of currently allocated licenses based on the set of procurement/release constraints of the set of boundary constraints; and based on the comparison and the searching, generate (612), via the demand-based agent, one of a license switching recommendation or the license release recommendation for one or more licenses of the current allocation, and the justification associated therewith, wherein the license switching recommendation is an actionable insight indicating switching the one or more licenses of the current allocation to one or more new licenses, each having the license type as the cost-effective license type.

16. The system (100) as claimed in claim 9, wherein to generate, via the LLM (216), the second license allocation for the enterprise through the generic LLM agent, the processor instructions, on execution, cause the processor (104) to: input (702), via the generic LLM agent, a set of rules, policies, and constraints from the constraint information to the LLM (216); for each iteration until one of a predefined number of iterations is completed or a predefined criteria is successfully attained, generate (704), via the LLM (216), a set of candidate license allocations based on the set of rules, policies, and constraints; calculate (706), via the LLM (216), a score for each of the set of candidate license allocations with respect to the set of rules, policies, and constraints; and update (708), via the LLM (216), a meta prompt using one or more of the set of candidate license allocations selected based on the score; and input (710), via the generic LLM agent, the meta prompt to the LLM (216) for generating a next set of candidate license allocations; and generating (712), by the LLM (216), the second license allocation for the enterprise selected from a plurality of candidate license allocations.

Description:DESCRIPTION
Technical Field
[0001] This disclosure relates generally to software license allocation, and more particularly to method and system for determining optimal software license allocation through a multi-agent framework.
Background
[0002] Software may form the backbone of modern business operations, enabling everything from customer relationship management to supply chain logistics. The deployment and use of the software may be governed by licensing agreements. The licensing agreements may define how an organization may use the software and the approved budget for its usage. The licenses may not be uniform. The licenses may vary widely, often based on metrics such as the processing power consumed (CPU/GPU usage), the number of individuals accessing the software, or the volume of transactions processed.
[0003] Modern enterprises may face significant challenges in software license cost management due to complexity of contractual agreements and inefficient license usage. The inefficiency may result in substantial financial waste from over-provisioning and critical operational risks including service degradation and non-compliance penalties from under-provisioning.
[0004] Thus, the present invention is directed to overcome one or more limitations stated above or any other limitations associated with the known arts.
SUMMARY
[0005] In one embodiment, a method for determining optimal software license allocation through a multi-agent framework is disclosed. In one example, the method may include receiving consolidated license data for each license of a current license allocation in an enterprise. The consolidated license data may include contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history. The method may further include generating, via a Large Language Model (LLM), historical usage data and constraint information for the license based on the consolidated license data. The method may further include predicting a future license demand based on the historical usage data through a future usage agent. The method may further include generating, via the LLM, a set of boundary constraints for license allocation based on the constraint information through a constraint agent. The method may further include generating a first license allocation for the enterprise and a justification for the first license allocation through a set of optimal usage agents using a set of heuristic rules. The method may further include generating, via the LLM, a second license allocation for the enterprise through a generic LLM agent using iterative generation and refinement of meta-prompts encoding allocation objectives, the historical usage data, and the constraint information. The method may further include providing a final license allocation from the first license allocation and the second license allocation based on a predefined priority-based criteria. The final license allocation corresponds to at least one of the current license allocation, a redistribution of the current license allocation, one or more new licenses added to the current license allocation, or one or more current licenses removed from the current license allocation.
[0006] In one embodiment, a system for determining optimal software license allocation through a multi-agent framework is disclosed. In one example, the system may include a processor and a computer-readable medium communicatively coupled to the processor. In one example, the computer-readable medium may store processor-executable instructions, which, on execution, may cause the processor to receive consolidated license data for each license of a current license allocation in an enterprise. The consolidated license data may include contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history. The processor-executable instructions, on execution, may further cause the processor to generate, via a LLM, historical usage data and constraint information for the license based on the consolidated license data. The processor-executable instructions, on execution, may further cause the processor predict a future license demand based on the historical usage data through a future usage agent. The processor-executable instructions, on execution, may further cause the processor to generate, via the LLM, a set of boundary constraints for license allocation based on the constraint information through a constraint agent. The processor-executable instructions, on execution, may further cause the processor to generate a first license allocation for the enterprise and a justification for the first license allocation through a set of optimal usage agents using a set of heuristic rules. The processor-executable instructions, on execution, may further cause the processor to generate, via the LLM, a second license allocation for the enterprise through a generic LLM agent using iterative generation and refinement of meta-prompts encoding allocation objectives, the historical usage data, and the constraint information. The processor-executable instructions, on execution, may further cause the processor to provide a final license allocation from the first license allocation and the second license allocation based on a predefined priority-based criteria. The final license allocation corresponds to at least one of the current license allocation, a redistribution of the current license allocation, one or more new licenses added to the current license allocation, or one or more current licenses removed from the current license allocation.
[0007] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles.
[0009] FIG. 1 is a block diagram of an exemplary system for determining optimal software license allocation through a multi-agent framework, in accordance with some embodiments.
[0010] FIG. 2 illustrates a functional block diagram of a system determining optimal software license allocation through a multi-agent framework, in accordance with some embodiments.
[0011] FIG. 3 illustrates a flow diagram of an exemplary process for determining optimal software license allocation through a multi-agent framework, in accordance with some embodiments.
[0012] FIGS. 4 illustrates a flow diagram of an exemplary process for generating the first license allocation for the enterprise and the justification for the first license allocation through the CPU usage agent, in accordance with an embodiment.
[0013] FIGS. 5 illustrates a flow diagram of an exemplary process for generating the first license allocation for the enterprise and the justification for the first license allocation through the application usage agent, in accordance with an embodiment.
[0014] FIGS. 6 illustrates a flow diagram of an exemplary process for generating the first license allocation for the enterprise and the justification for the first license allocation through the demand-based agent, in accordance with some embodiments.
[0015] FIG. 7 illustrates a flow diagram of an exemplary process for generating the second license allocation for the enterprise through the generic LLM agent, in accordance with some embodiments.
[0016] FIG. 8 illustrates a block diagram of a multi-agent license optimization system for determining optimal software license allocation through a multi-agent framework, in accordance with an embodiment.
[0017] FIG. 9A illustrates an optimized license allocation chart depicting license allocation by department, in accordance with an embodiment.
[0018] FIG. 9B illustrates a budget comparison chart comparing budget versus license plans, in accordance with an embodiment.
[0019] FIG. 10 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.
DETAILED DESCRIPTION
[0020] Exemplary embodiments are described with reference to the accompanying drawings. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
[0021] Referring now to FIG. 1, an exemplary system 100 for determining optimal software license allocation through a multi-agent framework is illustrated, in accordance with some embodiments. The system 100 may include a computing device 102 (for example, a server, a desktop, a laptop, a notebook, a netbook, a tablet, a smartphone, a mobile phone, or any other computing device), in accordance with some embodiments. The computing device 102 may determine optimal software licensing allocation through an Artificial Intelligence (AI)-driven system using the multi-agent framework. The multi-agent framework may use a Large Language Model (LLM) based optimization. By way of an example, the LLM may be, but may not be limited to, Generative Pre-trained Transformer (GPT)-3, GPT-3.5, GPT-4, Language Model for Dialogue Applications (LaMDA), Pathways Language Model (PaLM), Gemini, Claude, BigScience Large Open-science Open-access Multilingual Language Model (BLOOM), Large Language Model Meta AI (Llama), Mistral 7B, Mixtral 8x7B, Mixtral 8x22B, or the like.
[0022] As will be described in greater detail in conjunction with FIGS. 2 – 10, the computing device 102 may receive consolidated license data for each license of a current license allocation in an enterprise. The consolidated license data may include contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history. The computing device 102 may further generate, via the LLM, historical usage data and constraint information for the license based on the consolidated license data. The computing device 102 may further predict a future license demand based on the historical usage data through a future usage agent. The computing device 102 may further generate, via the LLM, a set of boundary constraints for license allocation based on the constraint information through a constraint agent. The computing device 102 may further generate a first license allocation for the enterprise and a justification for the first license allocation through a set of optimal usage agents using a set of heuristic rules. The computing device 102 may further generate, via the LLM, a second license allocation for the enterprise through a generic LLM agent using iterative generation and refinement of meta-prompts encoding allocation objectives, the historical usage data, and the constraint information. The computing device 102 may provide a final license allocation from the first license allocation and the second license allocation based on a predefined priority-based criteria. The final license allocation corresponds to at least one of the current license allocation, a redistribution of the current license allocation, one or more new licenses added to the current license allocation, or one or more current licenses removed from the current license allocation.
[0023] In some embodiments, the computing device 102 may include one or more processors 104 and a memory 106. The memory 106 may include a cache memory. The memory 106 may store instructions that, when executed by the one or more processors 104, may cause the one or more processors 104 to determine optimal software license allocation through a multi-agent framework, in accordance with aspects of the present disclosure. The memory 106 may also store various data (for example, consolidated license data, historical usage data, constraint information, a set of boundary constraints, and the like) that may be captured, processed, and/or required by the system 100.
[0024] The system 100 may further include a display 108. The system 100 may interact with a user via a user interface 110 accessible via the display 108. The system 100 may also include one or more external devices 112. In some embodiments, the computing device 102 may interact with the one or more external devices 112 over a communication network 114 for sending or receiving various data. The external devices 112 may include, but may not be limited to, a remote server, a digital device, or another computing system.
[0025] Referring now to FIG. 2, a functional block diagram of a system 200 for determining optimal software license allocation through a multi-agent framework is illustrated, in accordance with some embodiments. FIG. 2 is explained in conjunction with FIG. 1. The system 200 may be analogous to the system 100. The system 200 may include, within the memory 106, a data generating module 202, a future license demand predicting module 204, a boundary constraint generating module 206, a first license allocation generating module 208, a second license allocation generating module 210, a final license allocation providing module 212, a Large Language Model (LLM) module 214, and an agent module 218. The LLM module 214 may include an LLM 216. The agent module 218 may include a future usage agent, a constraint agent, a set of optimal usage agents, and a generic LLM agent (explained in greater detail in conjunction with FIG. 8).
[0026] Initially, the data generating module 202 may receive consolidated license data 220 for each license of a current license allocation in an enterprise. The consolidated license data may include contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history. Further, the future license demand predicting module 204 may generate, via the LLM 216, historical usage data and constraint information for the license based on the consolidated license data. The constraint information may include contractual limitations of a license and policy rules of an enterprise. Further, the future license demand predicting module 204 may predict a future license demand based on the historical usage data through the future usage agent. To predict the future license demand for the license, the future license demand predicting module 204 may receive, via the future usage agent, the historical usage data from the LLM 216. Further, the future license demand predicting module 204 may identify, via the future usage agent, usage patterns and a potential usage deviation of the license from the historical usage data. Further, the future license demand predicting module 204 may predict, via the future usage agent, the future license demand based on the usage patterns and the potential usage deviation.
[0027] Further, the boundary constraint generating module 206 may generate, via the LLM 216, a set of boundary constraints for license allocation based on the constraint information through the constraint agent. To generate the set of boundary constraints for allocation of the license, the boundary constraint generating module 206 may receive, via the constraint agent, the constraint information from the LLM 216. The boundary constraint generating module 206 may further generate, via the constraint agent, the set of boundary constraints based on the contractual limitations and the policy rules.
[0028] Further, the first license allocation generating module 208 may generate a first license allocation for the enterprise and a justification for the first license allocation through a set of optimal usage agents using a set of heuristic rules. The set of heuristic rules may include Central Processing Unit (CPU) usage-based rules, application usage-based rules, and demand-based rules. The set of optimal usage agents may include a CPU usage agent, an application usage agent, and a demand-based agent. To generate the license allocation for the enterprise and the justification for the first license allocation through the CPU usage agent, the first license allocation generating module 208 may calculate, via the CPU usage agent, an optimal range for optimal CPU usage based on the future license demand and the set of boundary constraints. The optimal range may include a minimum threshold value and a maximum threshold value. The future license demand may include a forecasted CPU usage. The set of boundary constraints may include a set of contractual CPU limits. The first license allocation generating module 208 may further compare, via the CPU usage agent, the forecasted CPU usage and a current CPU usage with the optimal range. When the current CPU usage and the forecasted CPU usage are within the optimal range, the first license allocation generating module 208 may generate, via the CPU usage agent, a current license allocation maintenance recommendation and the justification associated therewith. When the current CPU usage and the forecasted CPU usage are less than the minimum threshold value, the first license allocation generating module 208 may generate, via the CPU usage agent, a license release recommendation and the justification associated therewith. When the current CPU usage and the forecasted CPU usage are more than the maximum threshold value, the first license allocation generating module 208 may generate, via the CPU usage agent, a license procurement recommendation and the justification associated therewith.
[0029] To generate the first license allocation for the enterprise and the justification for the first license allocation through the application usage agent, the first license allocation generating module 208 may identify, via the application usage agent, a user and an application associated with each license in a current license allocation of the enterprise. The first license allocation generating module 208 may further determine, via the application usage agent, an inactivity period of the user with respect to the application. The first license allocation generating module 208 may further determine, via the application usage agent, a future application usage of the user from the future license demand. When the inactivity period is more than a predefined threshold value and the future application usage is indicative of a continued inactivity, the first license allocation generating module 208 may check, via the application usage agent, whether a floating license is available corresponding to the license. When the floating license is available, the first license allocation generating module 208 may generate, via the application usage agent, a floating license reallocation recommendation, a target user for reallocation, and the justification associated therewith. When the floating license is unavailable, the first license allocation generating module 208 may generate, via the application usage agent, the license release recommendation for the user and the justification associated therewith. When the inactivity period is more than the predefined threshold value and the future application usage is indicative of an increased activity, the first license allocation generating module 208 may generate, via the application usage agent, a license retention recommendation and the justification associated therewith. When the inactivity period is less than the predefined threshold value, the first license allocation generating module 208 may generate, via the application usage agent, the license allocation maintenance recommendation and the justification associated therewith.
[0030] To generate the first license allocation for the enterprise and the justification for the first license allocation through the demand-based agent, the first license allocation generating module 208 may compare, via the demand-based agent, a current system usage of the license and a forecasted system usage of the enterprise with a predefined threshold demand level. The forecasted system usage is a part of the future license demand. When the current system usage and the forecasted system are within the predefined threshold demand level, the first license allocation generating module 208 may generate, via the demand-based agent, the current license allocation maintenance recommendation and the justification associated therewith. When one of the current system usage or the forecasted system usage is above the predefined threshold demand level, the first license allocation generating module 208 may search, via the demand-based agent, for a cost-effective license type compared to the license type of the plurality of currently allocated licenses based on a set of procurement/release constraints of the set of boundary constraints. Based on the comparison and the searching, the first license allocation generating module 208 may generate, via the demand-based agent, the license procurement recommendation for one or more new licenses and the justification associated therewith. The license type of each of the one or more new licenses is one of the cost-effective license type or the license type of one of the current license allocation.
[0031] When one of the current system usage or the forecasted system is below the predefined threshold demand level, the first license allocation generating module 208 may search, via the demand-based agent, for the cost-effective license type compared to the license type of the plurality of currently allocated licenses based on the set of procurement/release constraints of the set of boundary constraints. Based on the comparison and the searching, the first license allocation generating module 208 may generate, via the demand-based agent, one of a license switching recommendation or the license release recommendation for one or more licenses of the current allocation, and the justification associated therewith. The license switching recommendation is an actionable insight indicating switching the one or more licenses of the current allocation to one or more new licenses, each having the license type as the cost-effective license type.
[0032] Further, the second license allocation generating module 210 may generate, via the LLM 216, a second license allocation for the enterprise through a generic LLM agent using iterative generation and refinement of meta-prompts encoding allocation objectives, the historical usage data, and the constraint information. To generate, via the LLM 216, the second license allocation for the enterprise through the generic LLM agent, the second license allocation generating module 210 may input, via the generic LLM agent, a set of rules, policies, and constraints from the constraint information to the LLM. For each iteration until one of a predefined number of iterations is completed or a predefined criteria is successfully attained, the second license allocation generating module 210 may generate, via the LLM 216, a set of candidate license allocations based on the set of rules, policies, and constraints. Further, the second license allocation generating module 210 may calculate, via the LLM 216, a score for each of the set of candidate license allocations with respect to the set of rules, policies, and constraints. Further, the second license allocation generating module 210 may update, via the LLM 216, a meta prompt using one or more of the set of candidate license allocations selected based on the score. Further, the second license allocation generating module 210 may input, via the generic LLM agent, the meta prompt to the LLM 216 for generating a next set of candidate license allocations. Further, the second license allocation generating module 210 may generate, by the LLM 216, the second license allocation for the enterprise selected from a plurality of candidate license allocations.
[0033] Finally, the final license allocation providing module 212 may provide a final license allocation 222 from the first license allocation and the second license allocation based on a predefined priority-based criteria. The final license allocation 222 corresponds to at least one of the current license allocation, a redistribution of the current license allocation, one or more new licenses added to the current license allocation, or one or more current licenses removed from the current license allocation.
[0034] It should be noted that all such aforementioned modules 202 – 218 may be represented as a single module or a combination of different modules. Further, as will be appreciated by those skilled in the art, each of the modules 202 – 218 may reside, in whole or in parts, on one device or multiple devices in communication with each other. In some embodiments, each of the modules 202 – 218 may be implemented as dedicated hardware circuit comprising custom application-specific integrated circuit (ASIC) or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Each of the modules 202 – 218 may also be implemented in a programmable hardware device such as a field programmable gate array (FPGA), programmable array logic, programmable logic device, and so forth. Alternatively, each of the modules 202 – 218 may be implemented in software for execution by various types of processors (e.g., processor 104). An identified module of executable code may, for instance, include one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, function, or other construct. Nevertheless, the executables of an identified module or component need not be physically located together, but may include disparate instructions stored in different locations which, when joined logically together, include the module and achieve the stated purpose of the module. Indeed, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different applications, and across several memory devices.
[0035] As will be appreciated by one skilled in the art, a variety of processes may be employed for determining optimal software license allocation through a multi-agent framework. For example, the exemplary system 100 and the associated computing device 102 may determine optimal software license allocation through a multi-agent framework by the processes discussed herein. In particular, as will be appreciated by those of ordinary skill in the art, control logic and/or automated routines for performing the techniques and steps described herein may be implemented by the system 100 and the associated computing device 102 either by hardware, software, or combinations of hardware and software. For example, suitable code may be accessed and executed by the one or more processors on the system 100 to perform some or all of the techniques described herein. Similarly, application specific integrated circuits (ASICs) configured to perform some or all of the processes described herein may be included in the one or more processors on the system 100.
[0036] Referring now to FIG. 3, an exemplary process 300 for determining optimal software license allocation through a multi-agent framework is depicted via a flowchart, in accordance with some embodiments. FIG. 3 is explained in conjunction with FIGS. 1 and 2. The process 300 may be implemented by the computing device 102 of the system 100. The process 300 may include receiving, by a data generating module (for example, the data generating module 202), consolidated license data (for example, the consolidated license data 220) for each license of a current license allocation in an enterprise, at step 302. The consolidated license data may include contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history. Further, the process 300 may include generating, by the data generating module via a Large Language Model (LLM) (for example, a LLM 216), historical usage data and constraint information for the license based on the consolidated license data, at step 304. The constraint information may include contractual limitations of a license and policy rules of an enterprise.
[0037] Further, the process 300 may include predicting, by a future license demand predicting module (for example, the future license demand predicting module 204), a future license demand based on the historical usage data through a future usage agent, at step 306. The step 306 may include step 308, step 310, and step 312. To predict the future license demand for the license, the process 300 may include receiving, by the future license demand predicting module via the future usage agent, the historical usage data from the LLM, at step 308. Further, the process 300 may include identifying, by the future license demand predicting module via the future usage agent, usage patterns and a potential usage deviation of the license from the historical usage data, at step 310. Further, the process 300 may include predicting, by the future license demand predicting module via the future usage agent, the future license demand based on the usage patterns and the potential usage deviation, at step 312.
[0038] Further, the process 300 may include generating, by a boundary constraint generating module (for example, the boundary constraint generating module 206) via the LLM, a set of boundary constraints for license allocation based on the constraint information through a constraint agent, at step 314. The step 314 may include step 316 and step 318. To generate the set of boundary constraints for allocation of the license, the process 300 may include receiving, by the boundary constraint generating module via the constraint agent, the constraint information from the LLM, at step 316. Further, the process 300 may include generating, by the boundary constraint generating module via the constraint agent, the set of boundary constraints based on the contractual limitations and the policy rules, at step 318.
[0039] Further, the process 300 may include generating, by a first license allocation generating module (for example, the first license allocation generating module 208), a first license allocation for the enterprise and a justification for the first license allocation through a set of optimal usage agents using a set of heuristic rules, at step 320. The set of heuristic rules may include Central Processing Unit (CPU) usage-based rules, application usage-based rules, and demand-based rules. The set of optimal usage agents may include a CPU usage agent, an application usage agent, and a demand-based agent. Further, the process 300 may include generating, by a second license allocation generating module (for the second license allocation generating module 210) via the LLM, a second license allocation for the enterprise through a generic LLM agent using iterative generation and refinement of meta-prompts encoding allocation objectives, the historical usage data, and the constraint information, at step 322. Further, the process 300 may provide, by a final license allocation providing module (for example, the final license allocation providing module 212), a final license allocation from the first license allocation and the second license allocation based on a predefined priority-based criteria, at step 324. The final license allocation corresponds to at least one of the current license allocation, a redistribution of the current license allocation, one or more new licenses added to the current license allocation, or one or more current licenses removed from the current license allocation.
[0040] Referring now to FIG. 4, a flow diagram of an exemplary process 400 for generating the first license allocation for the enterprise and the justification for the first license allocation through the CPU usage agent is depicted via a flowchart, in accordance with an embodiment. FIG. 4 is explained in conjunction with FIGS. 1, 2, and 3. The process 400 may be implemented by the computing device 102 of the system 100. The process 400 may include generating, by a first license allocation generating module (for example, the first license allocation generating module 208), a first license allocation for the enterprise and a justification for the first license allocation through a CPU usage agent, at step 320. The step 320 may include step 402, step 404, step 406, step 408, and step 410.
[0041] To generate the first license allocation, the process 400 may include calculating, by the first license allocation generating module via the CPU usage agent, an optimal range for optimal CPU usage based on the future license demand and the set of boundary constraints, at step 402. The optimal range may include a minimum threshold value and a maximum threshold value. The future license demand may include a forecasted CPU usage. The set of boundary constraints may include a set of contractual CPU limits. Further, the process 400 may include comparing, by the first license allocation generating module via the CPU usage agent, the forecasted CPU usage and a current CPU usage with the optimal range, at step 404.
[0042] When the current CPU usage and the forecasted CPU usage are within the optimal range, the process 400 may include generating, by the first license allocation generating module via the CPU usage agent, a current license allocation maintenance recommendation and the justification associated therewith, at step 406. When the current CPU usage and the forecasted CPU usage are less than the minimum threshold value, the process 400 may include generating, by the first license allocation generating module via the CPU usage agent, a license release recommendation and the justification associated therewith, at step 408. When the current CPU usage and the forecasted CPU usage are more than the maximum threshold value, the process 400 may include generating, by the first license allocation generating module via the CPU usage agent, a license procurement recommendation and the justification associated therewith, at step 410.
[0043] Referring now to FIG. 5, an exemplary process 500 for generating the first license allocation for the enterprise and the justification for the first license allocation through the application usage agent is depicted via a flow chart, in accordance with an embodiment. FIG. 5 is explained in conjunction with FIGS. 1 – 4. The process 500 may be implemented by the computing device 102 of the system 100. The process 500 may include generating, by a first license allocation generating module (for example, the first license allocation generating module 208) the first license allocation for the enterprise and the justification for the first license allocation through an application usage agent, at step 320. The step 320 may include step 502, step 504, step 506, step 508, step 510, step 512, step 514, and step 516.
[0044] To generate the first license allocation, the process 500 may include identifying, by the first license allocation generating module via the application usage agent, a user and an application associated with each license in a current license allocation of the enterprise, at step 502. Further, the process 500 may include determining, by the first license allocation generating module via the application usage agent, an inactivity period of the user with respect to the application, at step 504. Further, the process 500 may include determining, by the first license allocation generating module via the application usage agent, a future application usage of the user from the future license demand, at step 506.
[0045] When the inactivity period is more than a predefined threshold value and the future application usage is indicative of a continued inactivity, the process 500 may include checking, by the first license allocation generating module via the application usage agent, whether a floating license is available corresponding to the license, at step 508. When the floating license is available, the process 500 may include generating, by the first license allocation generating module via the application usage agent, a floating license reallocation recommendation, a target user for reallocation, and the justification associated therewith, at step 510. When the floating license is unavailable, the process 500 may include generating, by the first license allocation generating module via the application usage agent, the license release recommendation for the user and the justification associated therewith, at step 512. When the inactivity period is more than the predefined threshold value and the future application usage is indicative of an increased activity, the process 500 may include generating, by the first license allocation generating module via the application usage agent, a license retention recommendation and the justification associated therewith, at step 514. When the inactivity period is less than the predefined threshold value, the process 500 may include generating, by the first license allocation generating module via the application usage agent, the license allocation maintenance recommendation and the justification associated therewith, at step 516.
[0046] Referring now to FIGS. 6, an exemplary process 600 for generating the first license allocation for the enterprise and the justification for the first license allocation through the demand-based agent is depicted via a flow chart, in accordance with an embodiment. FIG. 6 is explained in conjunction with FIGS. 1 – 5. The process 600 may be implemented by the computing device 102 of the system 100. The process 600 may include generating, by a first license allocation generating module (for example, the first license allocation generating module 208), the first license allocation for the enterprise and the justification for the first license allocation through a demand-based agent, at step 320. The step 320 may include step 602, step 604, step 606, step 608, step 610, and step 612.
[0047] The process 600 may include comparing, by the first license allocation generating module via the demand-based agent, a current system usage of the license and a forecasted system usage of the enterprise with a predefined threshold demand level, at step 602. The forecasted system usage is a part of the future license demand. when the current system usage and the forecasted system are within the predefined threshold demand level, the process 600 may include generating, by the first license allocation generating module via the demand-based agent, the current license allocation maintenance recommendation and the justification associated therewith, at step 604.
[0048] When one of the current system usage or the forecasted system usage is above the predefined threshold demand level, the process 600 may include searching, by the first license allocation generating module via the demand-based agent, for a cost-effective license type compared to the license type of the plurality of currently allocated licenses based on a set of procurement/release constraints of the set of boundary constraints, at step 606. Based on the comparison and the searching, the process 600 may include generating, by the first license allocation generating module via the demand-based agent, the license procurement recommendation for one or more new licenses and the justification associated therewith, at step 608. The license type of each of the one or more new licenses is one of the cost-effective license type or the license type of one of the current license allocation.
[0049] When one of the current system usage or the forecasted system is below the predefined threshold demand level, the process 600 may include searching, by the first license allocation generating module via the demand-based agent, for the cost-effective license type compared to the license type of the plurality of currently allocated licenses based on the set of procurement/release constraints of the set of boundary constraints, at step 610. Based on the comparison and the searching, the process 600 may include generating, by the first license allocation generating module via the demand-based agent, one of a license switching recommendation or the license release recommendation for one or more licenses of the current allocation, and the justification associated therewith, at step 612. The license switching recommendation is an actionable insight indicating switching the one or more licenses of the current allocation to one or more new licenses, each having the license type as the cost-effective license type.
[0050] Referring now to FIG. 7, an exemplary process 700 for generating the second license allocation for the enterprise through the generic LLM agent is depicted via a flow chart, in accordance with an embodiment. FIG. 7 is explained in conjunction with FIGS. 1 – 6. The process 700 may be implemented by the computing device 102 of the system 100. The process 700 may include generating, by a second license allocation generating module (for example, the second license allocation generating module 210) via the LLM (for example, the LLM 216), the second license allocation for the enterprise through the generic LLM agent, at step 322. The step 322 may include step 702, step 704, step 706, step 708, step 710, and step 712.
[0051] To generate the second license allocation, the process 700 may include inputting, by the second license allocation generating module via the generic LLM agent, a set of rules, policies, and constraints from the constraint information to the LLM, at step 702. For each iteration until one of a predefined number of iterations is completed or a predefined criteria is successfully attained, the process 700 may include generating, by the second license allocation generating module via the LLM, a set of candidate license allocations based on the set of rules, policies, and constraints, at step 704. Further, the process 700 may include calculating, by the second license allocation generating module via the LLM, a score for each of the set of candidate license allocations with respect to the set of rules, policies, and constraints, at step 706. Further, the process 700 may include updating, by the second license allocation generating module via the LLM, a meta prompt using one or more of the set of candidate license allocations selected based on the score, at step 708. Further, the process 700 may include inputting, by the second license allocation generating module via the generic LLM agent, the meta prompt to the LLM for generating a next set of candidate license allocations, at step 710. Finally, the process 700 may include generating, by the second license allocation generating module via the LLM, the second license allocation for the enterprise selected from a plurality of candidate license allocations, at step 712.
[0052] Referring now to FIG. 8, a block diagram of a multi-agent license optimization system 800 for determining optimal software license allocation through a multi-agent framework is illustrated, in accordance with some embodiments. FIG. 8 is explained in conjunction with FIGS. 1 – 7. The multi-agent license optimization system 800 may include a license data hub 802. The license data hub 802 may serve as a centralized data source for consolidated license data 220. The license data hub 802 may aggregate license information from various sources within an enterprise, including contract management systems, usage monitoring tools, and compliance databases. The consolidated license data 220 may include contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history. The contract terms may include detailed software license agreements including licensing models, duration, costs, and terms of use. The usage logs may include historical and real-time data of consumption of licenses across a plurality of users, applications, and infrastructure components (for example, CPU, memory, software instances). The temporal spike history may include records of unusual usage patterns, underutilization, or any issues indicating sub-optimal license allocation. The temporal spike history may help to identify potential areas for optimization or immediate action.
[0053] The consolidated license data 220 from the license data hub 802 may be provided to an LLM interpreter 804 for processing. The LLM interpreter 804 may be powered by the LLM 216. The LLM interpreter 804 may process the incoming consolidated license data 220. The LLM interpreter 804 may interpret contract clauses, find usage patterns from logs, and understand nature of reported problems. The LLM interpreter 804 may further extract key insights and structured data relevant for subsequent agents. Further, the LLM interpreter 804 may generate historical usage data and constraint information. The historical data may include historical usage patterns, temporal trends, and usage statistics extracted from the consolidated license data 220. The constraint information may include contractual limitations, policy rules, budget constraints, and compliance requirements derived from the consolidated license data 220. The LLM interpreter 804 may utilize natural language processing capabilities to parse and structure the incoming data into formats suitable for downstream processing by specialized agents. The historical data generated by the LLM Interpreter 804 may be directed to a future usage agent 806 and a constraint agent 808 in the agent module 218. The future usage agent 806 may analyze the historic data to identify usage patterns and potential usage deviations. The future usage agent 806 may predict future license demand based on historical trends, seasonality, project growth, and other influencing factors for the enterprise. The future usage agent 806 may also provide projections enabling proactive procurement or release of licenses, ensuring resources are available when needed and released when not.
[0054] The constraint information generated by the LLM interpreter 804 may be directed at the constraint agent 808. The constraint information may include contractual limitations, policy rules, and defining boundaries. The contractual limitations may include limitations imposed by license contracts (for example, maximum concurrent users, specific hardware bindings, geographical restrictions). The policy rules may include internal organizational policies or compliance requirements related to license usage. The defining boundaries may include establishing the acceptable operational ranges for license usage, crucial for identifying optimal conditions. The constraint agent 808 may process the constraint information to generate a set of boundary constraints. The set of boundary constraints may define permissible license allocation parameters. The constraint agent 808 may manage all operational and financial constraints on license usage. The constraint agent 808 may apply defined contractual rules, including usage costs and caps, and may incorporate user-defined budgets, and dynamically adjusts for past violations and temporal spikes using a License-Aware Constraint Learning (LCL) mode.
[0055] The future usage agent 806 and the constraint agent 808 may provide the respective outputs to an optimal usage module 810. The optimal usage module 810 may include the set of optimal usage agents in the agent module 218. The set of optimal usage agents may include a CPU usage agent 812, an application usage agent 814, and a demand-based agent 816, and a language-based optimization agent 818. It should be noted that the set of optimal usage agents may use a set of heuristic rules. The set of heuristic rules may include Central Processing Unit (CPU) usage-based rules, application usage-based rules, and demand-based rules. The recommendations from the optimal usage module 810 may be provided to users and administrators to streamline license usage.
[0056] The CPU usage agent 812 may define an optimal range. To define the optimal range, the CPU usage agent 812 may calculate a dynamic lower and upper bound for optimal CPU usage based on forecast and constraint information (for example, IQR or percentiles). Further, the CPU usage agent 812 may incorporate the set of boundary constraints. To incorporate the set of boundary constraints, the CPU usage agent 812 may adjust the calculated optimal range or set hard boundaries based on contractual CPU limits received from the constraint agent (808) (for example, minimum required cores, maximum allocated capacity). Further, the CPU usage agent 812 may monitor current CPU utilization data. Further, the CPU usage agent 812 may evaluate the forecasted CPU usage from the future usage agent 806. The forecast may influence the decision (for example, if current usage is low but a significant spike is forecasted, a release might be delayed or adjusted).
[0057] When the current CPU usage may be less than the adjusted lower upper bound i.e., the minimum threshold value (and future forecasts don't contradict), the CPU usage agent 812 may recommend releasing licenses. When the current CPU usage may be more than the adjusted lower upper bound i.e., the minimum threshold value (and is not a temporary spike easily handled), the CPU usage agent 812 may recommend procuring licenses. When the CPU usage is within the optimal range i.e., the minimum threshold value, the CPU usage agent 812 may recommend maintaining the current license state. Further, the CPU usage agent 812 may provide the determined action and a detailed justification.
Pseudo Code:
Input: Current_CPU_Usage, Historical_CPU_Usage_Data, Optimal_Range_Definition_Method, Forecasted_CPU_Usage_Data, Contractual_CPU_Limits
Output: Recommended_Action (e.g., "RELEASE_LICENSE", "PROCURE_LICENSE", etc), Justification
1. CALCULATE_EFFECTIVE_CPU_RANGE:
a. (Statistical_Lower_Bound, Statistical_Upper_Bound) = DERIVE_STATISTICAL_RANGE (Historical_CPU_Usage_Data, Optimal_Range_Definition_Method)
b. Effective_Lower_Bound = MAX(Statistical_Lower_Bound, Contractual_CPU_Limits,-1)
c. Effective_Upper_Bound = MIN(Statistical_Upper_Bound, Contractual_CPU_Limits.+1)
2. DECIDE_LICENSE_ACTION:
a. If Current_CPU_Usage < Effective_Lower_Bound:
i. If Forecasted_CPU_Usage_Data.Next_Period_Spike_Expected:
1. Recommended_Action = "MONITOR_TEMPORARY_LOW "
ii. Else:
1. Recommended_Action = "RELEASE_LICENSE"
b. Else If Current_CPU_Usage > Effective_Upper_Bound:
i. If Forecasted_CPU_Usage_Data.Next_Period_Dip_Expected:
1.Recommended_Action = "MONITOR_TEMPORARY_HIGH"
ii. Else:
1. Recommended_Action = "PROCURE_LICENSE"
c. Else:
i. Recommended_Action = "MAINTAIN_CURRENT"
3. GENERATE_JUSTIFICATION: (Details based on Recommended_Action and input values)
4. Return (Recommended_Action, Justification)
[0058] Further, the application usage agent 814 may monitor individual application usage by users to identify under-utilized licenses, focusing on either prompting users or reallocating floating licenses, while respecting user activity forecasts and defined licensing policies. Further, the application usage agent 814 may identify the associated user and application for each assigned license. Further, the application usage agent 814 may determine the last activity timestamp. The application usage agent 814 may compare the inactivity period against a threshold and also consult from the future usage agent 806 if the user is forecasted to become active soon, defer action and monitor usage. The application usage agent 814 may consult user license policies from the constraint agent 808 to identify any licenses that are mandatory for specific roles or applications and cannot be released even if inactive.
[0059] When the inactivity period exceeds the predefined threshold (and no contradicting forecast/policy), the application usage agent 814 may check for floating license option. When the assigned license is dedicated and a floating license is available, the application usage agent 814 may recommend reallocating a floating license. Otherwise, the application usage agent 814 may recommend prompting the user for release or confirmation. Further, the application usage agent 814 may consult the future usage agent 806 to determine if the overall number of users for this application is expected to increase. If yes, the application usage agent 814 may retain the license as it may be needed soon even if currently unused. When the user is actively using the application or covered by an unchangeable policy, the application usage agent 814 may recommend no change. The application usage agent 814 may provide the determined action, a justification, and the specific license/user targeted.
Pseudo Code:
Input: User_App_Usage_Logs,List_of_Assigned_Licenses,Floating_License_Pool_Status (Available_Count),Inactivity_Threshold_Time,User_Activity_Forecasts (From Future Usage Agent), App_User_Count_Forecasts(From Future Usage Agent), User_License_Policies (From Constraint Agent)
Output: Recommended_Action,Justification,Target_License_ID,Target_User_ID
1. FOR_EACH_ASSIGNED_LICENSE:
a. Get User_ID, App_ID, Last_Usage_Timestamp, License_Type from Assigned_License.
b. If License_is_NON_RELEASEABLE_BY_POLICY(Assigned_License, User_License_Policies):
i. Set Action = "MAINTAIN_CURRENT", Justification = "Policy prevents release."
ii. Return action for this license and proceed to next.
c. If (Current_Timestamp - Last_Usage_Timestamp) > Inactivity_Threshold_Time:
i. If User_Activity_Forecasts.Predicts_Future_Activity(User_ID, App_ID):
1. Set Action = "MONITOR_FORECASTED_ACTIVITY", Justification = "User expected to be active soon"
ii. if App_User_Count_Forecasts.predicts_user_growth(App_ID):
1. Set Action = "MAINTAIN_CURRENT", Justification = "User inactive, but user count expected to increase for app", license.id, User_ID
iii. Else If License_Type == "Dedicated" AND Floating_License_Pool_Status.Available_Count > 0:
1. Set Action = "REALLOCATE_FLOATING"
iii. Else:
1. Set Action = "PROMPT_USER_RELEASE"
d. Else:
i. Set Action = "MAINTAIN_CURRENT"
2. GENERATE_JUSTIFICATION: (Details based on Action and input values)
3. Return (Action, Justification, Target_License_ID, Target_User_ID)
[0060] Further, the demand-based agent 816 may respond to overall system usage signals and seeks more cost-effective alternatives for license procurement or release, factoring in overall system demand forecasts and procurement/release constraints. The demand-based agent 816 may receive the current system usage signal (high/low/normal) and integrate overall system demand forecasts from the future usage agent 806 to determine the true underlying demand scenario. When demand is high (current usage high or high usage forecasted), the demand-based agent 816 may search for alternative, potentially cheaper license options that meet the increased demand. The demand-based agent 816 may further guide the search by procurement/release constraints (for example, budget caps, preferred vendors, allowable license types, compliance rules). When a cost-effective alternative is found that satisfies all constraints, the demand-based agent 816 may recommend the procurement. Otherwise, the demand-based agent 816 may recommend standard procurement.
[0061] When the demand is low (current usage low or low usage forecasted), the demand-based agent 816 may search for alternative, potentially cheaper ways to consolidate or downgrade existing licenses, respecting procurement/release constraints. When a cost-effective alternative is found, the demand-based agent 816 may recommend switching to or releasing based on that optimized approach. Otherwise, the demand-based agent 816 may recommend standard license release or consolidation. When demand is normal and stable, the demand-based agent 816 may recommend no change. When demand is normal and stable, the demand-based agent 816 may provide the determined action, a justification, and details of any proposed license changes.
Pseudo Code:
Input: System_Usage_Signal (e.g., "HIGH", "LOW", "NORMAL"), Overall_System_Demand_Forecast,Available_License_Alternatives_DB, Current_License_Portfolio, Procurement_Release_Constraints
Output: Recommended_Action,Justification,Target_License_ID,Target_User_ID
1. DETERMINE_TRUE_DEMAND_SCENARIO:
a. Adjusted_Demand_Scenario =
ADJUST_SIGNAL_WITH_FORECAST(System_Usage_Signal, Overall_System_Demand_Forecast)
2. SEARCH_FOR_OPTIMAL_ALTERNATIVE:
a. Function FIND_BEST_ALTERNATIVE(Scenario_Type, Current_Portfolio, Alternatives_DB, Constraints):
i. Filter Alternatives_DB for options that meet demand, are cheaper, and satisfy all Procurement_Release_Constraints.
ii. Select the most cost-effective compliant option.
iii. Return selected alternative or NULL.
3. DECIDE_AND_RECOMMEND_ACTION:
a. If Adjusted_Demand_Scenario == "HIGH_DEMAND":
i. Proposed_Alternative = FIND_BEST_ALTERNATIVE("PROCUREMENT", Current_License_Portfolio, Available_License_Alternatives_DB, Procurement_Release_Constraints)
ii. If Proposed_Alternative is not NULL: Action = "PROCURE_ALTERNATIVE"
iii. Else: Action = "PROCURE_STANDARD"
b. Else If Adjusted_Demand_Scenario == "LOW_DEMAND":
i. Proposed_Alternative = FIND_BEST_ALTERNATIVE("RELEASE", Current_License_Portfolio, Available_License_Alternatives_DB, Procurement_Release_Constraints)
ii. If Proposed_Alternative is not NULL: Action = "RELEASE_OPTIMIZED"
iii. Else: Action = "RELEASE_STANDARD"
c. Else ("NORMAL_DEMAND"):
i. Action = "MAINTAIN_CURRENT"
ii. Proposed_Alternative = NULL

4. GENERATE_JUSTIFICATION: (Details based on Action and Proposed_Alternative)
5. Return (Action, Justification, Proposed_Alternative)
[0062] The CPU usage agent 812, the application usage agent 814, and the demand-based agent 816 may generate the first license allocation i.e, a first optimized resource recommendation 820. The first optimized resource recommendation 820 may represent the recommended actions for license allocation and cost optimization determined by the optimal usage module 810, specifically aimed at mitigating identified problems and ensuring licenses are optimally utilized according to future forecasts and defined constraints.
[0063] The generic LLM agent based on LLM driven language-based optimization agent 818 may provide an alternative path for license cost optimization, leveraging the advanced reasoning and problem-solving capabilities of LLMs more broadly. The language-based optimization agent 818 may directly utilize the LLM 216 to perform comprehensive license cost optimization. Instead of relying on a series of specialized agents with predefined rules, the language-based optimization agent 818 may operate by defining the entire optimization problem, including complex rules and constraints, directly in natural language. The language-based optimization agent 818 may initially define the optimization problem by providing the LLM 216 a comprehensive set of rules, policies, and constraints in natural language including existing license terms, budget limitations, desired usage patterns, and any specific business requirements or objectives.
[0064] Based on the natural language instructions and constraints, the language-based optimization agent 818 may generate, via the LLM 216, various potential license allocation scenarios or solutions. The solutions may be effectively different "results" or proposals for optimizing costs. The language-based optimization agent 818 may evaluate, via the LLM 216 or a module guided by the LLM 216, the generated results. The language-based optimization agent 818 may assesses each proposed scenario against the defined objectives, rules, and constraints. A scoring mechanism, often facilitated by the analytical capabilities of the LLM 216 may assign a score to each result, indicating effectiveness and adherence to the optimization criteria. The language-based optimization agent 818 may use the best-performing results (those with the highest scores) to refine and update the "meta-prompt" given to the LLM for the next iteration. The meta-prompt may act as a feedback loop, guiding the LLM 216 to explore more promising solution spaces. The process of generation, evaluation, scoring, and meta-prompt update may be continued iteratively. The loop may persist until a predefined optimum level is reached (for example, a satisfactory cost reduction or resource utilization level) or a maximum number of iterations is exceeded, preventing endless computation.
[0065] The language-based optimization agent 818 may generate the second license allocation i.e, a second optimized resource recommendation 822. The second optimized resource recommendation 822 may represent a potentially broader or more novel set of recommendations for license allocation and cost management, directly derived from comprehensive analysis of the LLM 216 and optimized capabilities. Further, the first optimized resource recommendation 820 and the second optimized resource recommendation 822 may be evaluated on a predefined priority-based criteria and a best optimized explainable resource cost plan 824 may be generated. The best optimized explainable resource cost plan 824 may include the final license allocation along with justifications for the allocation decisions. In some cases, the final output may correspond to the current license allocation being maintained, a redistribution of the current license allocation, one or more new licenses being added to the current license allocation, or one or more current licenses being removed from the current license allocation.
[0066] By way of an example, the input may include license terms and business constraints. The license terms may be “Cost per user: $120/month”, “Maximum licenses: 100 (with 10% grace)”, “Fair usage: 160 hours/month/user”, “Extended license cost: +$170/month/user”, and “Multi-year discount: 15%”. The business constraints may be “The critical department (ABC, 25 users) must always be covered”, “Minimum licenses: 80”, “Annual budget: $130,000”, “Forecasted growth: 150 users”, and “Priority order: ABC > R&D > Finance > Sales > HR > Support”.
[0067] The initial usage data may be:
Department Users Avg Usage (hrs)
ABC 25 180
Finance 20 150
Sales 30 60
HR 15 30
R&D 30 120
Support 20 20

[0068] When all the users may be allocated licenses, the requirements may be a total of 140 licenses, exceeding the maximum limit of 100 along with an annual budget of $130,000.
Department Licenses needed Extended Standard Annual Cost
ABC 25 25 0 $51,000
R&D 30 0 30 $43,200
Finance 20 0 20 $28,800
Sales 30 0 30 $43,200
HR 15 0 15 $21,600
Support 20 0 20 $28,200
Total 140 25 115 $18400 (after discount)

[0069] The LLM 216 may iteratively reduce allocation while maintaining coverage for high-priority departments. The final allocation may be:
Department Licenses allocated Extended Standard Annual Cost
ABC 25 25 0 $51,000
R&D 30 0 30 $43,200
Finance 20 0 20 $28,800
Sales 20 0 20 $28,800
HR 0 0 0 $0
Support 0 0 0 $0
Total 95 25 70 $129,030 (after discount)

[0070] Referring now to FIGS. 9A, an optimized license allocation chart 900A depicting license allocation by department is illustrated, in accordance with an embodiment. FIG. 9A is explained in conjunction with FIGs. 1 – 8. The optimized license allocation chart 900A may display a bar chart representation showing the distribution of licenses across various departments within an enterprise. The vertical axis may represent the number of licenses allocated, while the horizontal axis may represent different departments such as ABC, R&D, Finance, Sales, HR, and Support. The optimized license allocation chart 900A may display multiple license types, such as standard licenses and extended licenses, using different visual indicators (for example, different colors or patterns) to distinguish between the license categories. The allocation quantities may vary across departments based on the optimization performed by the multi-agent license optimization system 800.
[0071] Referring now to FIG. 9B, a budget comparison chart 900B comparing budget versus license plans is illustrated, in accordance with an embodiments. FIG. 9B is explained in conjunction with FIGs. 1 – 9A. The budget comparison chart 900B may display a bar chart representation showing the annual cost comparison between different license allocation scenarios. The vertical axis may represent the annual cost in dollars, while the horizontal axis may show different categories including Budget Cap, Initial Plan, and Optimized Plan. A horizontal reference line may indicate the budget limit established by the enterprise. The budget comparison chart 900B may illustrate how an initial license allocation plan may exceed the budget limit, while the optimized plan generated by the multi-agent license optimization system 800 may remain within the budget constraint. The budget comparison chart 900B may provide a visual representation of the cost savings achieved through the license optimization process, demonstrating the effectiveness of the multi-agent framework in generating cost-effective license allocation recommendations that adhere to budgetary constraints
[0072] As will be also appreciated, the above-described techniques may take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, solid state drives, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
[0073] The disclosed methods and systems may be implemented on a conventional or a general-purpose computer system, such as a personal computer (PC) or server computer. Referring now to FIG. 10, an exemplary computing system 1000 that may be employed to implement processing functionality for various embodiments (e.g., as a SIMD device, client device, server device, one or more processors, or the like) is illustrated. Those skilled in the relevant art will also recognize how to implement the invention using other computer systems or architectures. The computing system 1000 may represent, for example, a user device such as a desktop, a laptop, a mobile phone, personal entertainment device, DVR, and so on, or any other type of special or general-purpose computing device as may be desirable or appropriate for a given application or environment. The computing system 1000 may include one or more processors, such as a processor 1002 that may be implemented using a general or special purpose processing engine such as, for example, a microprocessor, microcontroller or other control logic. In this example, the processor 1002 is connected to a bus 1004 or other communication medium. In some embodiments, the processor 1002 may be an Artificial Intelligence (AI) processor, which may be implemented as a Tensor Processing Unit (TPU), or a Graphical Processor Unit, or a Quantum Processing Unit (QPU), or a custom programmable solution Field-Programmable Gate Array (FPGA).
[0074] The computing system 1000 may also include a memory 1006 (main memory), for example, Random Access Memory (RAM) or other dynamic memory, for storing information and instructions to be executed by the processor 1002. The memory 1006 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor 1002. The computing system 1000 may likewise include a read only memory (“ROM”) or other static storage device coupled to bus 1004 for storing static information and instructions for the processor 1002.
[0075] The computing system 1000 may also include a storage devices 1008, which may include, for example, a media drive 1010 and a removable storage interface. The media drive 1010 may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an SD card port, a USB port, a micro USB, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive. A storage media 1012 may include, for example, a hard disk, magnetic tape, flash drive, or other fixed or removable medium that is read by and written to by the media drive 1010. As these examples illustrate, the storage media 1012 may include a computer-readable storage medium having stored therein particular computer software or data.
[0076] In alternative embodiments, the storage devices 1008 may include other similar instrumentalities for allowing computer programs or other instructions or data to be loaded into the computing system 1000. Such instrumentalities may include, for example, a removable storage unit 1014 and a storage unit interface 1016, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit 1014 to the computing system 1000.
[0077] The computing system 1000 may also include a communications interface 1018. The communications interface 1018 may be used to allow software and data to be transferred between the computing system 1000 and external devices. Examples of the communications interface 1018 may include a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a USB port, a micro USB port), Near field Communication (NFC), etc. Software and data transferred via the communications interface 1018 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by the communications interface 1018. These signals are provided to the communications interface 1018 via a channel 1020. The channel 1020 may carry signals and may be implemented using a wireless medium, wire or cable, fiber optics, or other communications medium. Some examples of the channel 1020 may include a phone line, a cellular phone link, an RF link, a Bluetooth link, a network interface, a local or wide area network, and other communications channels.
[0078] The computing system 1000 may further include Input/Output (I/O) devices 1022. Examples may include, but are not limited to a display, keypad, microphone, audio speakers, vibrating motor, LED lights, etc. The I/O devices 1022 may receive input from a user and also display an output of the computation performed by the processor 1002. In this document, the terms “computer program product” and “computer-readable medium” may be used generally to refer to media such as, for example, the memory 1006, the storage devices 1008, the removable storage unit 1014, or signal(s) on the channel 1020. These and other forms of computer-readable media may be involved in providing one or more sequences of one or more instructions to the processor 1002 for execution. Such instructions, generally referred to as “computer program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system 1000 to perform features or functions of embodiments of the present invention.
[0079] In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into the computing system 1000 using, for example, the removable storage unit 1014, the media drive 1010 or the communications interface 1018. The control logic (in this example, software instructions or computer program code), when executed by the processor 1002, causes the processor 1002 to perform the functions of the invention as described herein.
[0080] Thus, the disclosed method and system try to overcome the technical problem of determining optimal software license allocation through a multi-agent framework. The disclosed method and system may receive consolidated license data for each license of a current license allocation in an enterprise. The consolidated license data may include contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history. Further, the disclosed method and system may generate, via a LLM, historical usage data and constraint information for the license based on the consolidated license data. Further, the disclosed method and system may predict a future license demand based on the historical usage data through a future usage agent. Further, the disclosed method and system may generate, via the LLM, a set of boundary constraints for license allocation based on the constraint information through a constraint agent. Further, the disclosed method and system may generate a first license allocation for the enterprise and a justification for the first license allocation through a set of optimal usage agents using a set of heuristic rules. Further, the disclosed method and system may generate, via the LLM, a second license allocation for the enterprise through a generic LLM agent using iterative generation and refinement of meta-prompts encoding allocation objectives, the historical usage data, and the constraint information. Further, the disclosed method and system may provide a final license allocation from the first license allocation and the second license allocation based on a predefined priority-based criteria. The final license allocation corresponds to at least one of the current license allocation, a redistribution of the current license allocation, one or more new licenses added to the current license allocation, or one or more current licenses removed from the current license allocation.
[0081] As will be appreciated by those skilled in the art, the techniques described in the various embodiments discussed above are not routine, or conventional, or well understood in the art. The techniques may proactively align license allocation with real usage patterns, contractual terms, and future demand by combining accurate demand forecasting, dynamic constraint management, and hybrid optimization using both domain-specific heuristics and LLM-based reasoning. The techniques may result in substantial cost savings by eliminating over-provisioning, identifying underutilized licenses, and recommending cheaper compliant alternatives, while simultaneously reducing the risk of under-provisioning and non-compliance penalties. The techniques may use natural-language interpretation and explainable recommendations minimizing manual effort, improving decision transparency. The techniques may further enable organizations to adapt continuously to changing business needs, usage spikes, and evolving license agreements.
[0082] In light of the above-mentioned advantages and the technical advancements provided by the disclosed method and system, the claimed steps as discussed above are not routine, conventional, or well understood in the art, as the claimed steps enable the following solutions to the existing problems in conventional technologies. Further, the claimed steps clearly bring an improvement in the functioning of the device itself as the claimed steps provide a technical solution to a technical problem.
[0083] The specification has described method and system for determining optimal software license allocation through a multi-agent framework. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0084] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[0085] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims. , Claims:CLAIMS
I/WE CLAIM:
1. A method (300) for determining optimal software license allocation through a multi-agent framework, the method (300) comprising:
receiving (302), by a computing device (102), consolidated license data for each license of a current license allocation in an enterprise, wherein the consolidated license data comprises contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history;
generating (304), by the computing device (102) via a Large Language Model (LLM) (216), historical usage data and constraint information for the license based on the consolidated license data;
predicting (306), by the computing device (102), a future license demand based on the historical usage data through a future usage agent;
generating (314), by the computing device (102) via the LLM (216), a set of boundary constraints for license allocation based on the constraint information through a constraint agent;
generating (320), by the computing device (102), a first license allocation for the enterprise and a justification for the first license allocation through a set of optimal usage agents using a set of heuristic rules;
generating (322), by the computing device (102) via the LLM (216), a second license allocation for the enterprise through a generic LLM agent using iterative generation and refinement of meta-prompts encoding allocation objectives, the historical usage data, and the constraint information; and
providing (324), by the computing device (102), a final license allocation from the first license allocation and the second license allocation based on a predefined priority-based criteria, wherein the final license allocation corresponds to at least one of the current license allocation, a redistribution of the current license allocation, one or more new licenses added to the current license allocation, or one or more current licenses removed from the current license allocation.

2. The method (300) as claimed in claim 1, wherein predicting the future license demand for the license comprises:
receiving (308), via the future usage agent, the historical usage data from the LLM (216);
identifying (310), via the future usage agent, usage patterns and a potential usage deviation of the license from the historical usage data; and
predicting (312), via the future usage agent, the future license demand based on the usage patterns and the potential usage deviation .

3. The method (300) as claimed in claim 1, wherein the constraint information comprises contractual limitations of the license and policy rules of the enterprise, and wherein generating the set of boundary constraints for allocation of the license comprises:
receiving (316), via the constraint agent, the constraint information from the LLM (216); and
generating (318), via the constraint agent, the set of boundary constraints based on the contractual limitations and the policy rules.

4. The method (300) as claimed in claim 1, wherein the set of heuristic rules comprises Central Processing Unit (CPU) usage-based rules, application usage-based rules, and demand-based rules, and wherein the set of optimal usage agents comprises a CPU usage agent, an application usage agent, and a demand-based agent.

5. The method (300) as claimed in claim 4, wherein generating the first license allocation for the enterprise and the justification for the first license allocation through the CPU usage agent comprises:
calculating (402), via the CPU usage agent, an optimal range for optimal CPU usage based on the future license demand and the set of boundary constraints, wherein the optimal range comprises a minimum threshold value and a maximum threshold value, wherein the future license demand comprises a forecasted CPU usage, and wherein the set of boundary constraints comprises a set of contractual CPU limits; and
comparing (404), via the CPU usage agent, the forecasted CPU usage and a current CPU usage with the optimal range; and, one of:
when the current CPU usage and the forecasted CPU usage are within the optimal range, generating (406), via the CPU usage agent, a current license allocation maintenance recommendation and the justification associated therewith;
when the current CPU usage and the forecasted CPU usage are less than the minimum threshold value, generating (408), via the CPU usage agent, a license release recommendation and the justification associated therewith; or
when the current CPU usage and the forecasted CPU usage are more than the maximum threshold value, generating (410), via the CPU usage agent, a license procurement recommendation and the justification associated therewith.

6. The method (300) as claimed in claim 4, wherein generating the first license allocation for the enterprise and the justification for the first license allocation through the application usage agent comprises:
identifying (502), via the application usage agent, a user and an application associated with each license in a current license allocation of the enterprise;
determining (504), via the application usage agent, an inactivity period of the user with respect to the application;
determining (506), via the application usage agent, a future application usage of the user from the future license demand;
when the inactivity period is more than a predefined threshold value and the future application usage is indicative of a continued inactivity,
checking (508), via the application usage agent, whether a floating license is available corresponding to the license;
when the floating license is available, generating (510), via the application usage agent, a floating license reallocation recommendation, a target user for reallocation, and the justification associated therewith; and
when the floating license is unavailable, generating (512), via the application usage agent, the license release recommendation for the user and the justification associated therewith;
when the inactivity period is more than the predefined threshold value and the future application usage is indicative of an increased activity, generating (514), via the application usage agent, a license retention recommendation and the justification associated therewith; and
when the inactivity period is less than the predefined threshold value, generating (516), via the application usage agent, the license allocation maintenance recommendation and the justification associated therewith.

7. The method (300) as claimed in claim 4, wherein generating the first license allocation for the enterprise and the justification for the first license allocation through the demand-based agent comprises:
comparing (602), via the demand-based agent, a current system usage of the license and a forecasted system usage of the enterprise with a predefined threshold demand level, wherein the forecasted system usage is a part of the future license demand;
when the current system usage and the forecasted system are within the predefined threshold demand level, generating (604), via the demand-based agent, the current license allocation maintenance recommendation and the justification associated therewith;
when one of the current system usage or the forecasted system usage is above the predefined threshold demand level,
searching (606), via the demand-based agent, for a cost-effective license type compared to the license type of the plurality of currently allocated licenses based on a set of procurement/release constraints of the set of boundary constraints; and
based on the comparison and the searching, generating (608), via the demand-based agent, the license procurement recommendation for one or more new licenses and the justification associated therewith, wherein the license type of each of the one or more new licenses is one of the cost-effective license type or the license type of one of the current license allocation; and
when one of the current system usage or the forecasted system is below the predefined threshold demand level,
searching (610), via the demand-based agent, for the cost-effective license type compared to the license type of the plurality of currently allocated licenses based on the set of procurement/release constraints of the set of boundary constraints; and
based on the comparison and the searching, generating (612), via the demand-based agent, one of a license switching recommendation or the license release recommendation for one or more licenses of the current allocation, and the justification associated therewith, wherein the license switching recommendation is an actionable insight indicating switching the one or more licenses of the current allocation to one or more new licenses, each having the license type as the cost-effective license type.

8. The method (300) as claimed in claim 1, wherein generating, via the LLM (216), the second license allocation for the enterprise through the generic LLM agent comprises:
inputting (702), via the generic LLM (216) agent, a set of rules, policies, and constraints from the constraint information to the LLM (216);
for each iteration until one of a predefined number of iterations is completed or a predefined criteria is successfully attained,
generating (704), via the LLM (216), a set of candidate license allocations based on the set of rules, policies, and constraints;
calculating (706), via the LLM (216), a score for each of the set of candidate license allocations with respect to the set of rules, policies, and constraints; and
updating (708), via the LLM (216), a meta prompt using one or more of the set of candidate license allocations selected based on the score; and
inputting (710), via the generic LLM agent, the meta prompt to the LLM (216) for generating a next set of candidate license allocations; and
generating (712), via the LLM (216), the second license allocation for the enterprise selected from a plurality of candidate license allocations.

9. A system (100) for determining optimal software license allocation through a multi-agent framework, the system (100) comprising:
a processor (104); and
a memory (106) communicatively coupled to the processor (104), wherein the memory (106) stores processor instructions, which when executed by the processor (104), cause the processor (104) to:
receive (302) consolidated license data for each license of a current license allocation in an enterprise, wherein the consolidated license data comprises contract terms of the license, usage logs of the license in the enterprise, license type, and a license violation and temporal spike history;
generate (304), via a Large Language Model (LLM) (216), historical usage data and constraint information for the license based on the consolidated license data;
predict (306) a future license demand based on the historical usage data through a future usage agent;
generate (314), via the LLM (216), a set of boundary constraints for license allocation based on the constraint information through a constraint agent;
generate (320) a first license allocation for the enterprise and a justification for the first license allocation through a set of optimal usage agents using a set of heuristic rules;
generate (322), via the LLM (216), a second license allocation for the enterprise through a generic LLM agent using iterative generation and refinement of meta-prompts encoding allocation objectives, the historical usage data, and the constraint information; and
provide (324) a final license allocation from the first license allocation and the second license allocation based on a predefined priority-based criteria, wherein the final license allocation corresponds to at least one of the current license allocation, a redistribution of the current license allocation, one or more new licenses added to the current license allocation, or one or more current licenses removed from the current license allocation.

10. The system (100) as claimed in claim 9, wherein to predict the future license demand for the license, the processor instructions, on execution, cause the processor (104) to:
receive (308), via the future usage agent, the historical usage data from the LLM (216);
identify (310), via the future usage agent, usage patterns and a potential usage deviation of the license from the historical usage data; and
predict (312), via the future usage agent, the future license demand based on the usage patterns and the potential usage deviation.

11. The system (100) as claimed in claim 9, wherein the constraint information comprises contractual limitations of the license and policy rules of the enterprise, and wherein to generate the set of boundary constraints for allocation of the license, the processor instructions, on execution, cause the processor (104) to:
receive (316), via the constraint agent, the constraint information from the LLM (216); and
generate (318), via the constraint agent, the set of boundary constraints based on the contractual limitations and the policy rules.

12. The system (100) as claimed in claim 9, wherein the set of heuristic rules comprises Central Processing Unit (CPU) usage-based rules, application usage-based rules, and demand-based rules, and wherein the set of optimal usage agents comprises a CPU usage agent, an application usage agent, and a demand-based agent.

13. The system (100) as claimed in claim 12, wherein to generate the first license allocation for the enterprise and the justification for the first license allocation through the CPU usage agent, the processor instructions, on execution, cause the processor (104) to:
calculate (402), via the CPU usage agent, an optimal range for optimal CPU usage based on the future license demand and the set of boundary constraints, wherein the optimal range comprises a minimum threshold value and a maximum threshold value, wherein the future license demand comprises a forecasted CPU usage, and wherein the set of boundary constraints comprises a set of contractual CPU limits; and
compare (404), via the CPU usage agent, the forecasted CPU usage and a current CPU usage with the optimal range; and, one of:
when the current CPU usage and the forecasted CPU usage are within the optimal range, generate (406), via the CPU usage agent, a current license allocation maintenance recommendation and the justification associated therewith;
when the current CPU usage and the forecasted CPU usage are less than the minimum threshold value, generate (408), via the CPU usage agent, a license release recommendation and the justification associated therewith; or
when the current CPU usage and the forecasted CPU usage are more than the maximum threshold value, generate (410), via the CPU usage agent, a license procurement recommendation and the justification associated therewith.

14. The system (100) as claimed in claim 12, wherein to generate the first license allocation for the enterprise and the justification for the first license allocation through the application usage agent, the processor instructions, on execution, cause the processor (104) to:
identify (502), via the application usage agent, a user and an application associated with each license in a current license allocation of the enterprise;
determine (504), via the application usage agent, an inactivity period of the user with respect to the application;
determine (506), via the application usage agent, a future application usage of the user from the future license demand;
when the inactivity period is more than a predefined threshold value and the future application usage is indicative of a continued inactivity,
check (508), via the application usage agent, whether a floating license is available corresponding to the license;
when the floating license is available, generate (510), via the application usage agent, a floating license reallocation recommendation, a target user for reallocation, and the justification associated therewith; and
when the floating license is unavailable, generate (512), via the application usage agent, the license release recommendation for the user and the justification associated therewith;
when the inactivity period is more than the predefined threshold value and the future application usage is indicative of an increased activity, generate (514), via the application usage agent, a license retention recommendation and the justification associated therewith; and
when the inactivity period is less than the predefined threshold value, generate (516), via the application usage agent, the license allocation maintenance recommendation and the justification associated therewith.
15. The system (100) as claimed in claim 12, wherein to generate the first license allocation for the enterprise and the justification for the first license allocation through the demand-based agent, the processor instructions, on execution, cause the processor (104) to:
compare (602), via the demand-based agent, a current system usage of the license and a forecasted system usage of the enterprise with a predefined threshold demand level, wherein the forecasted system usage is a part of the future license demand;
when the current system usage and the forecasted system are within the predefined threshold demand level, generate (604), via the demand-based agent, the current license allocation maintenance recommendation and the justification associated therewith;
when one of the current system usage or the forecasted system usage is above the predefined threshold demand level,
search (606), via the demand-based agent, for a cost-effective license type compared to the license type of the plurality of currently allocated licenses based on a set of procurement/release constraints of the set of boundary constraints; and
based on the comparison and the searching, generate (608), via the demand-based agent, the license procurement recommendation for one or more new licenses and the justification associated therewith, wherein the license type of each of the one or more new licenses is one of the cost-effective license type or the license type of one of the current license allocation; and
when one of the current system usage or the forecasted system is below the predefined threshold demand level,
search (610), via the demand-based agent, for the cost-effective license type compared to the license type of the plurality of currently allocated licenses based on the set of procurement/release constraints of the set of boundary constraints; and
based on the comparison and the searching, generate (612), via the demand-based agent, one of a license switching recommendation or the license release recommendation for one or more licenses of the current allocation, and the justification associated therewith, wherein the license switching recommendation is an actionable insight indicating switching the one or more licenses of the current allocation to one or more new licenses, each having the license type as the cost-effective license type.

16. The system (100) as claimed in claim 9, wherein to generate, via the LLM (216), the second license allocation for the enterprise through the generic LLM agent, the processor instructions, on execution, cause the processor (104) to:
input (702), via the generic LLM agent, a set of rules, policies, and constraints from the constraint information to the LLM (216);
for each iteration until one of a predefined number of iterations is completed or a predefined criteria is successfully attained,
generate (704), via the LLM (216), a set of candidate license allocations based on the set of rules, policies, and constraints;
calculate (706), via the LLM (216), a score for each of the set of candidate license allocations with respect to the set of rules, policies, and constraints; and
update (708), via the LLM (216), a meta prompt using one or more of the set of candidate license allocations selected based on the score; and
input (710), via the generic LLM agent, the meta prompt to the LLM (216) for generating a next set of candidate license allocations; and
generating (712), by the LLM (216), the second license allocation for the enterprise selected from a plurality of candidate license allocations.