System and method for executable generation using language model-based agent modules in an application development environment
The method of creating functional element instances with associated agent modules in an application development environment addresses inefficiencies in LLM-based software frameworks by managing code configuration efficiently and ensuring transparent changes, thereby enhancing performance and compliance.
Patent Information
- Application Number
- PCT/IB2025/050970
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-01-31
- Filing Date
- 2025-01-29
- Publication Date
- 2025-08-07
AI Technical Summary
Existing software development frameworks using large language models (LLMs) face challenges in determining appropriate communication patterns between agents, leading to inefficiencies in decomposition and re-composition of tasks, which can invalidate tests and make it difficult to understand changes, thus affecting performance and compliance.
A method and system for executable generation in an application development environment that involves creating functional element instances with associated agent modules, where each agent module is configured to receive and execute actions, including change actions, to manage code configuration, and utilizes language models only when necessary to determine actions from messages.
This approach simplifies task management by limiting agent module actions to specific code blocks, reducing computational burden, and ensuring transparent and efficient code changes, while maintaining high performance and compliance.
Smart Images

Figure IB2025050970_07082025_PF_FP_ABST
Abstract
Description
[0001]SYSTEM AND METHOD FOR EXECUTABLE GENERATION USING LANGUAGE MODEL- BASED AGENT MODULES IN AN APPLICATION DEVELOPMENT ENVIRONMENT CROSS-REFERENCE(S) TO RELATED APPLICATIONS This application claims priority from United States provisional patent application number 63 / 627,569 filed on 31 January 2024, which is incorporated by reference herein. FIELD This disclosure relates generally to arrangements for software development and / or software engineering, including an application development environment for software design and / or the creation or generation of source code and / or executable code. More particularly, the disclosure relates to language model-based agent modules in an application development environment. The agent modules may be based on large language models (LLMs), such as generative pretrained transformers (GPTs) and the like. BACKGROUND Large language models (LLMs) are increasingly finding application in software application development. Copilot™ from GitHub™ for example is a cloud-based artificial intelligence tool which assists users of certain integrated development environments (IDEs) by autocompleting code. More recently, Microsoft™ has launched AutoGen™ which is described by Wu et al. in “AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation” as an open-source framework that allows developers to build LLM applications via multiple agents that can converse with each other to accomplish tasks. AutoGen agents are customizable, conversable, and can operate in various modes that employ combinations of LLMs, human inputs, and tools. Using AutoGen, developers can also flexibly define agent interaction behaviours. Both natural language and computer code can be used to program flexible conversation patterns for different applications. AutoGen serves as a generic framework for building diverse applications of various complexities and LLM capacities. Empirical studies demonstrate the effectiveness of the framework in many example applications, with domains ranging from mathematics, coding, question answering, operations research, online decision-making, entertainment, etc. However, there are challenges associated with such an architecture. For example, the appropriate topology, referring to communication patterns between agents, remains to be determined. The topology of the agents can affect performance criteria, such as effectiveness and / or speed. Further, it is felt that decomposition and re-composition of a problem to be solved by the agents remains to be addressed adequately. For example, being unable to decompose and recompose effectively can be challenging because of the need to regenerate more than is required, potentially invalidating tests and compliance (approval of previously built software) and potentially making it difficult to understanding what has changed and thus making reaching a consensus as to whether it is a good change or not more difficult and less transparent. There is accordingly scope for improvement. The preceding discussion of the background is intended only to facilitate an understanding of the present disclosure. It should be appreciated that the discussion is not an acknowledgment or admission that any of the material referred to was part of the common general knowledge in the art as at the priority date of the application. SUMMARY In accordance with an aspect of the disclosure there is provided a computer-implemented method for executable generation, the method conducted within an application development environment which comprises a library of functional element templates from which functional element instances can be created, the method comprising: creating a functional element instance from a functional element template and associating the functional element instance with one or more other functional element instances in the development environment, wherein the association defines a dependency between the functional element instance and at least one of the one or more other functional element instances, wherein each functional element instance represents a block of code and the functional element instances together represent a body of code for compiling into an executable; and, in response to creating the functional element instance, creating an agent module associated with the functional element instance, wherein the agent module is configured to: receive a message; obtain an action from the message; and, execute the action, wherein the action which the agent module is configured to execute includes a change action which effects a change to configuration of the functional element instance with which the agent module is associated, such that executing the change action includes changing configuration of the functional element instance and in turn the block of code represented by the functional element instance. The method may include the agent module obtaining the action from the message. Obtaining the action from the message may include processing the message to determine whether a language model is required to extract the action from the message. The language model may be configured to determine the action from the message. The method may include the agent module, in response to determining that the language model is not required, extracting the action from the message; or, in response to determining that the language model is required, inputting the message into the language model and receiving the action from the language model. Each of the one or more other functional element instances may be associated with an agent module created for and unique to that functional element instance. The agent modules may be associated with one another to define dependencies between the agent modules that mirror the dependencies defined by the associations of the functional element instances. The dependencies may be tree-like. The method may include the agent module receiving the message. Receiving the message may include receiving the message from a queue of messages. The message may be an update message generated by one of the one or more other functional element instances in response to a change made to the one of the one or more other functional element instances. The method may include the agent module extracting and executing a change action from the message. The agent module may be unique to the functional element instance with which it is associated and may persist for as long as the functional element instance with which it is associated persists. The association of the functional element instance to the one or more other functional element instances may be either that of: child; or parent. The functional element instance may be associated with the one or more other functional element instances by way of addresses such that the functional element instance either addresses or is addressable by one or more of the one or more other functional element instances. Receiving the message may include receiving the message from one of the one or more other functional element instance which is a parent of the functional element instance with which the agent module is associated. The action which the agent module is configured to execute may include a delegation action. The delegation action may include or be associated with an address of another functional element instance to which the message is to be rerouted. When the action is a delegation action, the method may include the agent module executing the action including rerouting the message to the other functional element instance based on the address. Rerouting the message may include restructuring the message to comply with a flow schema. The application development environment may provide a graphical user interface in which a visual representation of the functional element instance is output, and wherein, when the action is the change action, the method may include the agent module: executing the change action including changing configuration of the functional element instance; updating the visual representation of the functional element instance; and, outputting the updated visual representation of the functional element instance. The functional element templates may be grouped into types of functional elements, wherein each functional element type includes one or more functional element templates. The action which the agent module is configured to execute may be one of a set of actions which the agent module is configured to perform. Processing the message may include retrieving a state associated with the agent module, wherein the state includes a list of actions which the agent module is configured to perform. Processing the message may include passing the message through a flow associated with the instance of the functional element, wherein the flow is retrieved from the library. Processing the message may include performing a schema validation on the message. Processing the message to determine whether the language model is required may determine that the language model is required when the schema validation fails. Performing the schema validation may include using a schema associated with the functional element instance and which includes one or more fields from which the action can be extracted. The language model may be configured to determine the action from the message based on one-shot or few-shot learning, wherein the one-shot or few-shot learning may include prompt language specific to one or more of: a state associated with the agent module; the functional element instance; and the functional element-type. In accordance with a further aspect of the disclosure there is provided computing system for executable generation, the system hosting an application development environment comprising a library of functional element templates from which functional element instances can be created, the system comprising a non-transitory computer-readable storage medium and one or more processors coupled to the non-transitory computer-readable storage medium, wherein the non- transitory computer-readable storage medium comprises program instructions that, when executed on the one or more processors, cause the one or more processors to perform operations comprising: creating a functional element instance from a functional element template and associating the functional element instance with one or more other functional element instances in the development environment, wherein the association defines a dependency between the functional element instance and at least one of the one or more other functional element instances, wherein each functional element instance represents a block of code and the functional element instances together represent a body of code for compiling into an executable; and, in response to creating the functional element instance, creating an agent module associated with the functional element instance, wherein the agent module is configured to: receive a message; obtain an action from the message; and, execute the action, wherein the action which the agent module is configured to execute includes a change action which effects a change to configuration of the functional element instance with which the agent module is associated, such that executing the change action includes changing configuration of the functional element instance and in turn the block of code represented by the functional element instance. In accordance with a further aspect of the disclosure there is provided a computing system for executable generation, the system hosting an application development environment comprising a library of functional element templates from which functional element instances can be created, wherein creating a functional element instance from a functional element template includes creating an agent module associated with the functional element instance, the system comprising a processor and a memory configured to provide computer program instructions to the processor to execute functions of components; a message receiving component for receiving a message; an action obtaining component for obtaining an action from the message, including processing the message to determine whether a language model is required to extract the action from the message, wherein the language model is configured to determine the action from the message; an action extracting component for, in response to determining that the language model is not required, extracting the action from the message; and, an inputting component for, in response to determining that the language model is required, inputting the message into the language model and a receiving component for receiving the action from the language model; and, an executing component for executing the action, wherein each functional element instance represents a block of code and the functional element instances together represent a body of code for compiling into an executable, and wherein, when the action is the change action, executing the action includes changing configuration of the functional element instance and in turn the block of code represented by the functional element instance. In accordance with a further aspect of the disclosure there is provided an application development environment for executable generation, the application development environment comprising a library of functional element templates from which functional element instances can be created, wherein creating a functional element instance from a functional element template includes creating an agent module associated with the functional element instance, and wherein the agent module is configured to perform the operations of: receiving a message; obtaining an action from the message, including processing the message to determine whether a language model is required to extract the action from the message, wherein the language model is configured to determine the action from the message, wherein each functional element instance represents a block of code and the functional element instances together represent a body of code for compiling into an executable; in response to determining that the language model is not required, extracting the action from the message; or, in response to determining that the language model is required, inputting the message into the language model and receiving the action from the language model; and, executing the action, and wherein, when the action is the change action, executing the action includes changing configuration of the functional element instance and in turn the block of code represented by the functional element instance. In accordance with a further aspect of the disclosure there is provided a computer program product for executable generation comprising a computer-readable medium having stored computer-readable program code for performing, within an application development environment which comprises a library of functional element templates from which functional element instances can be created, the steps of: creating a functional element instance from a functional element template and associating the functional element instance with one or more other functional element instances in the development environment, wherein the association defines a dependency between the functional element instance and at least one of the one or more other functional element instances, wherein each functional element instance represents a block of code and the functional element instances together represent a body of code for compiling into an executable; and, in response to creating the functional element instance, creating an agent module associated with the functional element instance, wherein the agent module is configured to: receive a message; obtain an action from the message; and, execute the action, wherein the action which the agent module is configured to execute includes a change action which effects a change to configuration of the functional element instance with which the agent module is associated, such that executing the change action includes changing configuration of the functional element instance and in turn the block of code represented by the functional element instance. Further features provide for the computer-readable medium to be a non-transitory computer- readable medium and for the computer-readable program code to be executable by a processing circuit. In accordance with a further aspect of the disclosure there is provided a computer-implemented method for executable generation, the method conducted within an application development environment which comprises a plurality of functional element instances and a plurality of agent modules, wherein each agent module is associated with a functional element instance of the plurality of functional element instances and having been generated in response to creation of the associated functional element instance, and wherein each functional element instance represents a block of code such that the functional element instances together represent a body of code for compiling into an executable, the method comprising an agent module: receiving a message; obtaining an action from the message; and, executing the action, wherein when the action is a change action which effects a change to configuration of the functional element instance with which the agent module is associated, executing the change action includes changing configuration of the functional element instance and in turn the block of code represented by the functional element instance. Obtaining the action from the message may include processing the message to determine whether a language model is required to extract the action from the message. The language model may be configured to determine the action from the message. The method may include, in response to determining that the language model is not required, extracting the action from the message; or, in response to determining that the language model is required, inputting the message into the language model and receiving the action from the language model. Processing the message may include retrieving a state associated with the agent module, wherein the state may include a list or set of actions which the agent module is configured to perform. Processing the message may include passing the message through a flow associated with the instance of the functional element, wherein the flow is retrieved from the library. Processing the message may include performing a schema validation on the message. Processing the message to determine whether the language model is required may determine that the language model is required when the schema validation fails. Performing the schema validation may include using a schema associated with the functional element instance and which may include one or more fields from which the action can be extracted. The language model may be configured to determine the action from the message based on one-shot or few-shot learning, wherein the one- shot or few-shot learning may include prompt language specific to one or more of: a state associated with the agent module; the functional element instance; and the functional element- type. Receiving the message may include receiving the message from a queue of messages. The message may be an update message generated by one of the one or more other functional element instances in response to a change made to the one of the one or more other functional element instances, and wherein the method may include extracting and executing a change action from the message. The action which the agent module is configured to execute may include a delegation action, wherein the delegation action may include or is associated with an address of another functional element instance to which the message is to be rerouted, wherein, when the action is the delegation action, executing the action may include rerouting the message to the other functional element instance based on the address, and wherein rerouting the message may include restructuring the message to comply with a flow schema. In accordance with further aspects of the disclosure there are provided a computing system a computer program product for performing the steps of the method conducted by an agent module as defined above. Examples of the technology will now be described with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS In the drawings: Figure 1 is a schematic diagram which illustrates an example application development environment according to aspects of the present disclosure; Figure 2 is a schematic diagram which illustrates an example computing system on which the application development environment of Figure 1 may be hosted; Figure 3A is a flow diagram which illustrates an example method according to aspects of the present disclosure; Figure 3B is a flow diagram which illustrates an example method performed by an agent module associated with a functional element instance described herein; Figure 4A is a schematic diagram which illustrates an example message being processed by agent modules as described herein; Figure 4B is a continuation of the schematic diagram of Figure 4A; Figure 5A is a schematic diagram which illustrates another example message being processed by agent modules as described herein; Figure 5B is a continuation of the schematic diagram of Figure 5A; Figure 6A is a schematic diagram which illustrates an example message being processed by a first stage of agent modules as described herein; Figure 6B is a schematic diagram which illustrates the example message of Figure 6A being processed by a second stage of agent modules as described herein; Figure 6C is a schematic diagram which illustrates the example message of Figure 6A being processed by a third stage of agent modules as described herein; Figure 7 is a block diagram which illustrates exemplary components which may be provided by a system for application development according to aspects of the present disclosure; and, Figure 8 illustrates an example of a computing device in which various aspects of the disclosure may be implemented. DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS A system and method for executable generation using language model-based agent modules in an application development environment are provided. The application development environment described herein may build upon a low-code development platform described in the applicant’s US patent no.11,561,772 B2, the entire contents of which is incorporated herein for all purposes. The application development environment may include a library of functional element templates from which functional element instances can be created in a workspace. Each functional element instance represents a block of code, which may be generated based on the functional element instance when the functional element instance is created. The blocks of code may be blocks of source code, represented in a high-level language, assembly language or the like. The blocks of code together form a body of code, or a codebase, for compiling into an executable. The executable, which may also be termed executable code, an executable file or the like, may be provided for causing a computer to perform indicated tasks according to encoded instructions. The executable may for example be in the form of machine code for a processor, a file containing scripting instructions (such as bytecode), or the like. In some implementations, the executable may be provided in the form of one or more object files linked together to create the executable. When creating a functional element instance, it may be associated with one or more other functional element instances in the workspace. In this way, functional element instances can be created and joined to or associated with each other to build a body of code for compiling into an executable. A functional element instance can be configured when created, thereby configuring the underlying code which it represents. Configuration may be validated using schema validation and a schema associated with the functional element instance or template from which the functional element instance is created. Graphical representations of each of the functional element instances are rendered and output to a graphical user interface of the application development environment. In this manner a graphical representation of the instance of the functional element is output via a graphical user interface when it is created. Any association between the instance of the functional element and the other instances of the functional element or the instances of other functional elements is rendered graphically. Any configuration to the functional element instance may also be rendered graphically and output via the graphical user interface. The application development environment is configured to create an agent module for a functional element instance when the functional element instance is created. The agent module may be associated with or tied to the functional element instance for which it is created. The agent module may be long-lived and may persist for as long as the associated functional element instance is created. The agent module may be configured to perform one or more actions, for example including one or more of: a delegation (or reroute) action (in response to which a message is delegated or rerouted to another agent module or another functional element instance), a query action (in response to which a query is answered), and a change action, which may for example include one or more of: editing its own settings or configuration (or that of its associated functional element instance), generating a user interface component (or graphical representation) of its associated functional element instance, adding or deleting an associated functional element instance, or the like. In some cases, the list of actions which an agent module can perform is discrete and selectable from a list of actions associated with that agent module. The list of actions that the agent module can perform may be determined from the type of functional element with which the agent module is associated. In other words, the type of actions that the functional element instance can perform may be based on the type of functional element template from which the functional element instance is created. The agent module may be configured to perform an action in response to receiving a message instructing it to do so. The agent module may be able to receive messages addressed to the functional element instance or the agent module. The agent module may be able to obtain or determine an action from the message. Messages can be received from any one of human users, other functional element instances, other agent modules or the like. Messages may be unstructured, which can make it difficult for an agent module to obtain the action from a message. Obtaining the action from the message may include retrieving and using a state of the agent module. The state may for example include information specific to that agent module and / or instance of the functional element with which it is associated, such as configuration of the functional element instance; settings of the functional element instance; operation of the functional element instance; associations of the functional element instance (e.g. details of functional element instances to which the functional element instance is connected or associated, such as connected flows, connected actions, connected roles, etc.); information relating to actions which the agent module can perform; and other information. The state may be stored in a state machine of the functional element instance maintained in a portion of memory. Obtaining the action may include using the state retrieved for the agent module. Obtaining the action may include deciphering, determining or extracting the action from the message using the state as context. This may include using a flow that is retrieved for the functional element instance. The flow may be generalized (e.g. the same flow may be retrieved for all functional element instances created from a particular functional element template). Or the flow may be customized for the functional element instance. In some implementations, the flow includes a schema validation process which uses a schema to validate the message and extract the action (or actions) from the message. In some implementations, obtaining the action may include using a language model to extract or decipher the action from the message. A language model may for example be used when the schema validation fails, e.g. indicating that the message does not conform to a schema created for the functional element instance or template. Use of agent modules in this way allows for automated or semi-automated code generation. By providing an agent module for each functional element instance, the scope of tasks (or the actions) required to be performed by the agent module can be narrowed down into a limited number (e.g. up to four or five). This may simplify the role of the agent modules and may also allow for reliance on a language model to be limited to cases when actions cannot be readily discerned from messages. The relationship between the functional element instances, and in turn the agent modules, can facilitate the chunking down of a problem into simple and discrete steps. In the present disclosure, an agent module is created for each functional element instance that is created, resulting in a network of agent modules that mirrors a network of functional element instances. The functional element instances may be associated with each other in a way that defines a dependency between them. The dependency may for example be a tree-like or other type of dependency. For example, a given functional element instance may have one or more child functional element instances and one or more parent functional element instances. An originating, higher level functional element instance may be termed a root functional element instance and the lowest level functional element instances which have no functional element instances dependent on them may be termed leaf functional element instances. The agent modules may be arranged in a corresponding manner to mirror the dependencies of the functional element instances. For example, a given agent module may have one or more child agent modules and one or more parent agent modules. The network of agent modules and network of functional element instances may be separate from one another. In other words, they may exist independently. For example, it may be possible to deactivate the network of agent modules without impacting the network of functional element instances. In some examples, agent modules are a special type of functional element instance created from corresponding special types of functional element templates. In some examples, the agent modules are contained within a container mechanism, which may be an instance of a type of functional element template. Each agent module in the network of agent modules is associated with or linked to a functional element instance. This association or linking may be a one-to-one association such that the agent module is uniquely linked to the functional element instance. Messages may be propagated through the network and may be acted on by one or more of the agent modules. When an agent module receives a message, it extracts an action from that message and performs the action. As mentioned above, the actions may be one of: a delegation action, a query action or a change action. The query and change actions are limited to or relate only to the functional element instance with which the agent module is associated. In other words, an agent module can change configuration of only the functional element instance with which it is associated. Further, an agent module can have access to a specific type of language model or may be able to configure a language model specifically (e.g. based on prompt engineering) based on the functional element instance with which it is associated. This allows for very specific agent modules to act very specifically, which can lower the computational burden or complexity in obtaining or deciphering actions from messages. Further, because an agent module can only act on the functional element instance with which it is associated, it has a narrow scope of influence and internal validation mechanisms within the functional element instance act as a gate to limit the way in which the agent module can act. Figure 1 is a schematic diagram which illustrates an example application development environment (100) according to aspects of the present disclosure. The application development environment may include a library (102) of functional element templates (104, 106) from which functional element instances (108) can be created in a workspace (110). The library of functional element templates may be dynamic with new functional element templates being added and retired functional element templates being removed over time. The functional element templates may be grouped into different types of functional element templates (e.g. including “spaces”, “aspects”, “steps”, “roles”, “interactions” “flows” and “agents”). It follows that a functional element instance created from a functional element template will be of the same type as that of the template from which it is created. Although the illustrated example shows only a first group (104) and a second group (106) of functional element template types, a practical implementation may have a plurality of such groups. Each group of functional element types includes one or more functional element templates (e.g. there may be a plurality of functional element templates within a functional element type). There may for example be functional element templates for each of “spaces”, “aspects”, “steps”, “roles”, “interactions” “flows” and “agents”. In an example application development environment, spaces may provide a container mechanism that allows one to create (or initialize) servers, services and / or microservices. Spaces may represent a functional unit of an organization or a collection of system-specific components. Each space is the boundary of the infrastructure where all other components are housed. Interactions (actions or reactions) connect or point to process flows. Actions are grouped by roles and are used to trigger process flows. Interactions could be considered analogous to API endpoints. Users, other spaces, or external systems may connect to roles as agents. Many agents can connect to the same role and agents can be connected to multiple roles. Roles may limit rights to specific agents that take on that role. A role is what an agent authenticates against. Roles are used to manage authentication and permissions. Flows are process flows which contain steps. A flow may be a workflow which is triggered by an action and contains the logic of how steps are connected. Steps are the building blocks of flows and may be termed building block functions. A step may define a block or snippet of functional code that is run when that part of a flow is reached. A step may take inputs from previous steps in a flow and will often result in an output being returned. As mentioned, when a functional element instance is created (e.g. 108.1) from a functional element template, it can be associated with (or linked to) one or more other functional element instances (e.g.108.2-108.5) in the workspace. The association of the functional element instance (108.1) to the one or more other functional element instances (108.2-108.5) may be either that of: child; or parent. In this manner, the functional element instances may be arranged in a hierarchy. In one example, hierarchy may be determined at least in part by the type of functional element template, for example starting with a space, then one or more roles, then one or more interactions, then one or more flows and then one or more steps. The functional element instance (108.1) may be associated with an address which uniquely identifies it. Similarly, each of the one or more other functional element instances (108.2-108.5) are also associated with an address unique to that functional element instance. In this manner, the functional element instance may be associated with the one or more other functional element instances by way of addresses such that the functional element instance either addresses or is addressable by one or more of the one or more other functional element instances. Each functional element instance (108.1-108.5) represents a block of code which is generated when the functional element instance is created. The collection of functional element instances represent a body of code for compiling into an executable. Functional element instances are configurable thereby to configure the underlying code which they represent. Configuration may be validated using schema validation and a schema associated with the functional element instance or template from which the functional element instance is created. Furthermore, graphical representations of each of the functional element instances are rendered and output to a graphical user interface. In this manner a graphical representation of the instance of the functional element is output via a graphical user interface in which the association between the instance of the functional element and the other instances of the functional element or the instances of other functional elements is rendered graphically. Configuration of the functional element instances can be via the graphical representations thereof, or example by dragging them around, connecting them to other functional element instances, inputting configuration into graphically rendered fields, and the like. In some cases, configuration of the functional element instances may be via an agent module, via speech-to-text conversion, or the like. Referring now to Figure 2, the development environment may execute on a cloud or on-premises computing infrastructure (200), which may be made up of one or more nodes (202, 204, 206), each of which is provided by a computing device. Each functional element instance (e.g.108.1, 108.2) may be embodied by a process (210, 212) and each process may be replicated across the one or more nodes such that a plurality of each of the processes (210.1, 210.2, 210.3, 212.1, 212.2, 212.3) execute across the plurality of nodes. Each of the processes may be analogous to an actor implemented by a function in a multi-actor model. Each process is addressable by and can address the other processes with which it is associated for sending and receiving messages. Each of the processes may be configured to communicate with each other by sending and receiving messages. The messages may be received in a mailbox and stored in the order in which they are received. The messages may be stored until a receiving process takes them out to be read. In this manner, the processes implement asynchronous message passing. The processes described herein may be configured to share no state with each other. An estimated minimal overhead for each process is approximately 300 words, which means that many processes can be created without degrading performance. As the processes communicate using message passing instead of shared variables, any need for explicit locks may be obviated. In some examples, inter-process communication may work via a shared-nothing asynchronous message passing system. This may entail every process having a mailbox to define a queue of messages that have been sent by other processes and not yet consumed. A process may use a receive primitive to retrieve messages that match desired patterns. A message-handling routine may test messages in turn against each pattern, until one of them matches. When the message is consumed and removed from the mailbox the process resumes execution. A message may comprise any structure, including for example primitives (such as integers, floats, characters, atoms), tuples, lists, functions and the like. Each functional element instance (108.1, 108.2) may be allocated a portion of memory dedicated to the underlying process and which represents a state machine (214.1, 214.2) for the functional element instance. The memory (216) in which the portion of memory may be allocated may be provided by a distributed database management system (218) accessible by the one or more nodes. The state machine for a functional element instance may be updated in response to receiving a message from another process. The update may be based on content of the message. The updated state machine is accessible to the one or more nodes executing the process. The state machine may store contextual information usable by an associated agent module in processing messages to obtain actions. It follows that for each functional element instance (108.1) that is associated with one or more other functional element instances (108.2), the underlying process (210) of that functional element is associated with one or more other processes (212) based on the association between the functional element instances such that messages can be exchanged between the process and the other processes. Each functional element instance is associated with an agent module (110.1-110.5). The functional element instances may be provided in an instance network (225). The agent modules may be provided in an agent network (220). The application development environment is configured to create an agent module (e.g.110.1) associated with a functional element instance (e.g. 108.1) when the functional element instance is created from its corresponding functional element template. In this manner, each functional element instance has its own agent module. Each agent module is unique to the functional element instance for which it is created and persists for as long as the functional element instance persists. Each agent module may itself be a process which may execute on the one or more nodes. Agent modules may have access to one or more language models (232, 234). The language models may be large language models (LLMs). The language models may be provided by a model platform (230) and may for example be accessible via API or another interface. In some cases, bespoke language models are provided for agent modules of specific functional element types. In some examples, certain types of agent module have access to certain types of language models. For example, agent modules associated with higher level functional element instances may have access to more powerful, general purpose language models. Agent modules associated with lower-level functional element instances may have access to smaller, less powerful language models. In some cases, the functional element instances may have access to more specific language models, which may for example be specific to the functional element template from which the instance is created, the type of functional element template or the like. The language models may be configured to generate outputs in a schema validation-based format representing structured data. The agent modules described herein may serve various functions, including performing one or more actions. For example, they may aid a development team during the creation and refinement of the application by offering intelligent suggestions, thereby increasing efficiency and reducing potential errors. Secondly, they may interact with operational users, helping them navigate and make the most of the application’s functionalities. For instance, agent modules can take input from users, guide them through complex workflows, or provide them with relevant information as needed. Importantly, these agent modules are not transient or session-based; they may be long- living entities that exist for as long as the application itself. This constant presence of agent modules may help provide a persistent level of support and guidance for users and builders alike. The application development environment described herein may be distributed, fault-tolerant, real-time, highly available and configured for live updates to a block of code which can be propagated through other blocks of code automatically with little to no human intervention. Figure 3A is a flow diagram which illustrates an example method according to aspects of the present disclosure. The method may include creating or initializing (280) a functional element instance from a functional element template and associating (282) the functional element instance with one or more other functional element instances in the development environment. The association may define a dependency between the newly created functional element instance and at least one of the one or more other functional element instances. Creating or initializing the functional element instance may include initializing and replicating a process for the functional element instance across nodes of a computing system. The functional element instance may provide a schema for generating and updating a block of code. Creating the functional element instance may be in response to receiving an instruction to create the functional element instance from a participant, such as human end-user or an agent module. Creating the functional element instance may include generating (283) a block of code forming part of a codebase. Creating the functional element instance may include generating and outputting a graphical representation of the functional element instance to a low-code view displayed via a graphical user interface. The block of code may thus be represented by a functional element instance created from a functional element template. The functional element instance may be in the form of or provided by a schema validation-based file representing structured data. The schema validation-based file may for example define fields and associated validation rules for configuration of the file and in turn of the block of code. Input into the fields may be validated based on validation rules of the functional element instance and configuration values (such as JSON configuration values) may be generated based on validated data points. The configuration values may in turn be converted into configuration code based on the validated data points. The configuration code can be converted into the block of code based on components of a step macro forming part of the functional element instance, which are described in greater detail in the applicant’s above-mentioned U.S. patent. The method may include, in response to creating the functional element instance, creating or initializing (284) an agent module associated with the functional element instance. Creating or initializing the agent module may include initializing and replicating a process for the agent module across nodes of a computing system. The agent module may be configured to perform an action selected from the group of: a delegation action, a query action, and a change action. The change action may effect a change to configuration of the functional element instance with which the agent module is associated. The agent module may be created instantly in response to (e.g., immediately after) creation of the functional element instance. The block of code may therefore be uniquely associated with an agent module spawned for the functional element instance and configured to update the block of code by updating the associated functional element instance. The method may repeat (286) each time a new functional element instance is created such that each functional element instance is associated with its own agent module. Figure 3B is a flow diagram which illustrates an example method performed by an agent module (e.g.110.1) associated with a functional element instance (108.1) described herein. The method may include receiving (302) a message, for example from a queue of messages. In some cases, the message may be received from another functional element instance (e.g.108.3) which is a parent of the functional element instance (108.1) with which the agent module is associated. In some cases, the message is received from a mailbox of a process which embodies the functional element. The message may be structured (e.g., in compliance with a schema such as a flow schema) or unstructured (e.g., in natural language or the like). The method may include obtaining (303) an action from the message. Obtaining the action may include probabilistically determining the action based on message content and optionally other context (such as a state of the agent module and / or the functional element instance). The action may be one of a set of actions which the agent module is configured to perform. The action may for example be one of the following types of actions: a query action; a change action; or, a delegation action. A delegation action may include an address (or information which can be used to determine an address) of another functional element instance to which the message is to be rerouted. A query action may be a request to return information about (such as a status of) the functional element instance. A change action may be an instruction to change configuration of the functional element instance. Obtaining the action may include processing (304) the message to determine whether a language model (232) is required to extract an action from the message. Processing the message may include retrieving (306) a state associated with the agent module and / or the functional element instance. The state may be retrieved from a state machine (214.1) associated with the functional element instance with which the agent module is associated. Processing the message may include passing the message (and state) through a flow associated with the functional element instance. The flow may be a base flow and may be retrieved from the library. The flow may be in the form of a set of steps or instructions to be performed on the message to interpret and / or process it. For example, the base flow may be stored in the library in association with the group of functional elements of which the functional element instance is a part. In some examples, the flow includes a flow schema and associated flow schema validation rules for performing schema validation on the message to determine the action. Passing the message through the flow may include performing schema validation on the message using the flow schema and flow schema validation rules to obtain and output the action and / or associated information. The flow may for example include, at a first stage, determining (e.g., using schema validation) whether the action can be obtained from the message and executed without further processing. The flow may include, at a second stage, determining whether the message can be delegated to another functional element instance. In some examples, the flow includes one or more other stages, which may be customizable based on the functional element type with which the agent module is associated. Example steps that may be included in subsequent stages of a flow include querying a log file, querying a state, or the like. Performing the schema validation may for example include using a flow schema associated with the functional element instance and which includes one or more fields from which the action can be extracted. In some examples, processing the message to determine whether the language model is required determines that the language model is required when the schema validation fails. This may for example be when the message is unstructured, or when the message is structured in compliance with another schema (e.g., a flow schema of another agent / functional element instance type). Thus, if the necessary instructions are not provided to avoid using a language model to interpret them, the method may include switching to using a language model for interpretation. Otherwise, when the schema validation is successful, the action may be extracted from the message based on the schema. Schema validation may for example be used to determine whether the action can be obtained from the message and executed without further processing by validating an action entry in an action field of a message that conforms to the schema validation. The action entry may for example be in the form of data elements describing an action contained within the action field of the message. When the action entry is validated using the schema validation, then the action can be performed without further processing. Further, schema validation may be used to determine whether the message can be delegated to another functional element instance. This may for example include using the state to determine whether the message is relevant to the functional element instance in question or if it should be delegated to another functional element instance. For example, a mismatch between the state of the functional element instance and data elements contained within a state or related field of the message may indicate that delegation is required, and the message may be forwarded appropriately. The processing steps may be provided to prevent unnecessary calls to the language model. This may improve speed (e.g. because unpredictable delays associated with calling the language model can be avoided) and can also reduce costs associated with calling the language model. Obtaining the action may include, in response to determining that the language model is not required (308), extracting (310) the action from the message. Otherwise, obtaining the action may include, in response to determining that the language model is required (312), inputting (314) the message into the language model (232) and receiving (316) the action from the language model. Inputting the message may include inputting the message and other context into the language model (e.g. relating to the state of the functional element instance, obtained from the state machine). The language model may be configured to determine the action from the message (and any other context). In some examples, the language model is configured to restructure an unstructured input message into a structured output message. This may for example include converting an unstructured message into a structured message. The structured message may comply with a schema. In some examples, when the action is a delegation action, restructuring the message, or converting the message into a structured message, may include converting the message into a structure that complies with a flow schema associated with a functional element instance to which the message is to be delegated. For example, the language model may be configured to determine the action from the message and / or to structure or restructure messages based on one-shot or few-shot learning. The one-shot or few-shot learning may include prompt language specific to one or more of: the state associated with the agent module; the functional element instance; and the functional element-type. Inputting the message may thus include compiling a prompt for the language model which includes or is based on one or more of: the message; any other context; and, prompt template language created for the functional element instance or the functional element type. In some examples, the language model is fine-tuned for the type of functional element with which the agent module is associated, such that agent modules of different types of functional elements have access to different language models (232, 234). In some cases, different types of models are available to the agent module and the method includes, in response to determining that the language model is required, determining a type of language model required. For example, different models of different sizes, computational efficiency, latency and the like may be available, and the method may determine a model from those available based on one or more of: the message, the state and other factors. In some examples, the language model may be called based on an assignment of the agent module to the language model. In some examples, agent modules are associated based on a tree-like dependency and lower level (e.g. towards leaf-type) agent modules may have access to smaller language models while higher level (e.g. towards root-type) agent modules may have access to larger language models. The smaller language models may be special purpose language models trained based on the agent module or the functional element template with which the agent module is associated. A “smaller” language model may be a large language model which is quicker (e.g., provides an output in response to an input in a shorter period of time). The “smaller” model may cost less due to having fewer parameters and / or being based on less training data. In some examples, the method includes selecting a language model from a set of available language models. The selection may be based on one or more of: cost; availability; assignment; and, latency. As mentioned, obtaining the action may use contextual information relating to a state of the functional element instance. Agent modules of different functional element types might not need to know as much as others in this respect. However, the 'local' context will be useful in boosting the overall intelligence of each agent when performing its tasks. At least some of this contextual information may arrive along with a message and may be stored to be used later (e.g. to be retrieved from the state machine). The local context may for example include a type of breadcrumb data linking it to the primary effects it is involved with and optionally metadata to assist based on the step type. In some examples, a primary effect may refer to a primary goal of the space and may determine whether an effect is happening or not. The effect may be indirectly related to the associated block of code, but can still be inferred through processing. Once inferred, the effect may be stored in the agent module (e.g., in a state associated therewith) so that the agent model has context as to a purpose within a part of a bigger mechanism linked to a primary effect. Other metadata could include recent statistics on whether the agent module is being used successfully or not in the context of the goal or in general, and the like. Such information may assist when there is ambiguity or conflicting constraints, an agent module of a functional element instance may detect this and seek to address the functional element instance that represents the associated primary effects to gain clarity / understanding. If at this point the constraints still conflict, a human or alternate system could intervene and possibly rework the requirements (or improve the steps) to relieve the conflict which may only become apparent during composition. The method may include executing (318) the action. As mentioned, in some cases the action may be a delegation action. When the action is a delegation action, executing the action includes rerouting the message to the relevant functional element instance based on the address determined with the action. In this manner, actions may be promulgated down an arrangement of functional element instances until the appropriate functional element instance is identified. In some cases, the message may be an update message generated by another functional element instance in response to a change made to the other functional element instance. In such a case the agent module may extract and execute a change action from the message (e.g. to bring the functional element with which it is associated up to date with the other functional element instance with which it is associated). Further, as mentioned, the application development environment may provide a graphical user interface in which a visual representation of the functional element instances is output. When the action is a change action, executing the action may include changing configuration of the functional element instance and updating the visual representation of the functional element instance accordingly. Updating the visual representation of the functional element may be in real-time, i.e., immediately (within milliseconds) in response to the change. In some cases, executing the action may include prompting for user input, for example for user approval of the action to be executed or other input that might be required for the action to be performed. By providing discrete agent modules for each functional element instance, and by providing each agent module with access to a state machine of the functional element instance from which contextual information representing the state of the functional element instance, the scope of actions that each agent module is required to perform can be narrowed down significantly. This can simplify calls to the language models, reducing cost and time associated with such calls. Further, because changes to configuration of functional element instances are validated using a schema validation associated with the functional element instance, changes determined to be made by the agent modules are easily moderated. Furthermore, the topology provided by the hierarchy of functional element instances allows for messages to be easily routed to and actioned by the appropriate agent module. The systems and methods described herein may therefore provide a low-code application development environment in which agent modules enhanced by large language models are able to assist with application development, reducing requirements on human intervention and involvement. Figures 4A to 6C are flow diagrams which illustrate example operations performed by different agent modules associated with different functional element instances described herein based on different messages received by those agent modules. For example, referring to Figures 4A and 4B, a message (402) “Add a new field to the ABC Action on the XYZ Role, that will capture data DEF” is received at an agent module (404) associated with a “Roles Step” functional element instance. The Roles Step functional element instance may be a step which contains all individual Roles. The Roles Step agent module (404) obtains the action (406) “delegate to Role XYZ” from the message. This may include retrieving a state associated with the Roles Step functional element instance / agent module, which indicates that Role XYZ exists. An agent module (408) associated with XYZ Role Step receives a message from the Roles Step agent module (404). The XYZ Role Step agent module (408) obtains the action (410) “Delegate to Interaction ABC” from the message. This may include retrieving a state associated with the XYZ Role Step functional element instance / agent module which indicates that it is the XYZ Role and that the ABC Interaction exits. An agent module (412) associated with the ABC Action Step may then receive (414) a message from the XYZ Role Step agent module (408) and may then obtain (415) an action from the message. This may include retrieving or reading (416) a state (418) associated with the ABC Action Step functional element instance and / or the agent module (412). The state (418) may for example include one or more of: settings for the functional element instance; details as to a connected flow; and, other context. Obtaining the action may include running (420) a flow associated with the functional element instance and, if applicable, using base flow logic (422). This may, for example, include using state information (424) obtained from the state (418) and / or using a description (426) of available operations. Obtaining the action may include determining (428) whether a language model is required and using the language model when it is determined to be required. Once the action (429) is obtained (430), it is executed (432) (which may require input from a human, one or more other steps, delegation or the like). Referring now to Figures 5A and 5B, the agent module (404) associated with the Roles Step functional element instance may receive (452) a message (454) “Tell me about the XYZ Role”. The agent module (404) may then obtain (456) an action from the message. This may include retrieving or reading a state (458) associated with the Roles Step functional element instance and / or the agent module (404). The state (458) may for example include a list of all the current roles. Obtaining the action may include running a flow associated with the functional element instance and, if applicable, using base flow logic. This may for example include using state information (460) obtained from the state (458) and / or using a description (462) of available operations. Obtaining the action may include determining whether a language model is required and using the language model to determine the action when it is determined to be required. Once the action (464) is obtained (466), it is executed (468) which in this case includes delegating the original message (454) to the agent module (408) associated with the XYZ Role Step. The XYZ Role Step agent module (408) receives (470) the message “Tell me about the XYZ Role” and obtains (472) an action from the message. This may include retrieving or reading a state (474) associated with the XYZ Role Step functional element instance and / or the agent module (404). The state (474) may for example include one or more of: the role settings, a list of interactions and optionally other context. Obtaining the action may include running a flow associated with the functional element instance and, if applicable, using base flow logic. This may for example include using state information (476) obtained from the state (474) and / or using a description (478) of available operations. Obtaining the action may include determining whether a language model is required and using the language model to determine the action when it is determined to be required. Once the action (480) is obtained (482), it is executed (484) which in this case includes answering the query, for example generating and transmitting a response message including a response to the question of “Tell me about the XYZ Role”. The response may be obtained from the state (474). The response message may be addressed to an agent module, functional element instance, or human end-user having generated the message (454). Figures 6A to 6A illustrate example operations performed for an example query passed down from Roles to two individual Roles, to every Interaction of type Action, to every connected Flow, to every step of type Request for Response or Request for Effect (these are Role interaction steps) - to bring back data on how the roles relate to each other. At a first stage, the agent module (404) associated with the Roles Step functional element instance receives a message (502) “In what way do the XYZ Roles relate”. The agent module retrieves a state associated with the agent module / functional element instance and processes the message and contextual information (503) obtained from the state to obtain the actions “Delegate to Role XYZ” (504) and “Delegate to Role ABC” (506). Messages based on these actions are passed to the agent module (408) of the XYZ Role step and an agent module (510) of the ABC Role Step respectively to delegate the original message to these agent modules in accordance with the actions (504, 506). Each of the agent module (408) of the XYZ Role Step and the agent module (510) of the ABC Role Step then retrieves an associated state and processes the message and contextual information obtained from the state to obtain the action “Delegate to all Actions”. The message (502) is then delegated to agent modules (512, 514) of Action Steps associated with the XYZ Role Step and the ABC Role Step respectively, which in turn delegate the message to agent modules (516, 518) of their respective associated Flow Steps. Turning now to Figure 6B, an agent module (516) of a Flow Step functional element instance receives (550) the message (502) and obtains (552) an action from the message. This may include retrieving or reading a state (554) associated with the Flow Step functional element instance and / or the agent module (516). The state (554) may for example include a list of the Flow Steps and optionally other context. Obtaining the action may include running a flow associated with the functional element instance and, if applicable, using base flow logic. This may for example include using state information (556) obtained from the state (554) and / or using a description (558) of available operations. Obtaining the action may include determining whether a language model is required and using the language model to determine the action when it is determined to be required. Once the action (560) is obtained (562), it is executed (564) which in this case includes delegating the original message (502) to agent modules (566, 568) of all Request for Response and Request for Effect Steps. Turning now to Figure 6C, an agent module (566) of a Request for Response Step functional element instance receives (570) the message (502) and obtains (572) an action from the message. This may include retrieving or reading a state (574) associated with the Request for Response Step functional element instance and / or the agent module (566). The state (574) may for example include the Request for Response Step’s settings and optionally other context. Obtaining the action may include running a flow associated with the functional element instance and, if applicable, using base flow logic. This may for example include using state information (576) obtained from the state (574) and / or using a description (578) of available operations. Obtaining the action may include determining whether a language model is required and using the language model to determine the action when it is determined to be required. Once the action (580) is obtained (582), it is executed (584) which in this case includes answering the query, for example generating and transmitting a response message including a response to the question of “In what way do the XYZ and ABC Roles relate”. The response may be obtained from the state (574). The response message may be addressed to an agent module, functional element instance, or human end-user having generated the message (454). For example, in this case the response may be addressed to the agent module (404) of the Roles Step functional element instance for it to collate response messages from each of the agent modules (566, 568) of all Request for Response and Request for Effect Steps and to compile them into a single response to the query of the original message (502). Various components may be provided for implementing the method described above with reference to Figures 3 to 6C. Figure 7 is a block diagram which illustrates exemplary components which may be provided by a system (700) for application development according to aspects of the present disclosure. The system (700) may include a processor (702) for executing the functions of components described below, which may be provided by hardware or by software units executing on the system (700). The software units may be stored in a memory component (704) and instructions may be provided to the processor (702) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and / or process data on behalf of the system (700) may be provided remotely. The system (700) may include a message receiving component (706) arranged to receive a message. The system (700) may include an action obtaining component (708) arranged to obtain an action from the message. The action obtaining component may include a processing component arranged to process the message to determine whether a language model is required to extract the action from the message. The language model is configured to determine the action from the message. The system (700) may include an action extracting component (710) arranged, in response to determining that the language model is not required, to extract the action from the message. The system (700) may include an inputting component (712) arranged, in response to determining that the language model is required, to input the message into the language model. The system (700) may include a receiving component (714) arranged to receive the action from the language model. The system (700) may include an executing component (716) arranged to execute the action. An application development environment is described in which an agent module is created for each of a plurality of functional element instances. In this manner, the topology of the agent modules mirrors the topology of the product in a manner in which different 'branches' of the application can adapt / optimize according to what is being created. In the present application, agent modules which are individually in charge of composable modules are provided (instead of providing an agent that writes code as such). As one composes the functional element instances, the arrangement of the agent modules is composed as well (including their communication patterns). The application development environment is configured for building application software, which is composed of functions of functions, which pivot around primary goals. This allows the software to be decomposed and recomposed more easily due to this functional approach which hides and contains the “how” from the rest of the arrangement. By not requiring a singular agent writing all software, a full understanding of the entire arrangement is not required for the agent modules to operate, instead each functional element instance in the system arranges itself on the level of abstraction in which it finds itself. In the application development environment of the present disclosure, behaviour of each functional element instance is not developed at the same time as the generation of the solution by the corresponding agent module. Instead, the behaviour of a functional element instance is developed beforehand and can be rigorously tested and made deterministic, unlike ad hoc generated code (e.g. by way of the schema validation process described above). This may entail that correctness of the software may be more easily ascertained by analyzing the functional element instances and their settings, rather than conducting a full analysis of all the underlying compiled code. It is however anticipated that required functional element instances may be generated on the fly. However, such functional element instances may be marked as unpredictable, which can be factored into overall analysis and risk profile of the solution. Figure 8 illustrates an example of a computing device (800) in which various aspects of the disclosure may be implemented. The computing device (800) may be embodied as any form of data processing device including a personal computing device (e.g. laptop or desktop computer), a server computer (which may be self-contained, physically distributed over a number of locations), a client computer, or a communication device, such as a mobile phone (e.g. cellular telephone), satellite phone, tablet computer, personal digital assistant or the like. Different configuration of the computing device may dictate the inclusion or exclusion of various components or subsystems described below. The computing device (800) may be suitable for storing and executing computer program code. The various participants and elements in the previously described system diagrams may use any suitable number of subsystems or components of the computing device (800) to facilitate the functions described herein. The computing device (800) may include subsystems or components interconnected via a communication infrastructure (805) (for example, a communications bus, a network, etc.). The computing device (800) may include one or more processors (810) and at least one memory component in the form of computer-readable media. The one or more processors (810) may include one or more of: CPUs, graphical processing units (GPUs), microprocessors, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs) and the like. In some configurations, a number of processors may be provided and may be arranged to carry out calculations simultaneously. In some implementations various subsystems or components of the computing device (800) may be distributed over a number of physical locations (e.g. in a distributed, cluster or cloud-based computing configuration) and appropriate software units may be arranged to manage and / or process data on behalf of remote devices. The memory components may include system memory (815), which may include read only memory (ROM) and random access memory (RAM). A basic input / output system (BIOS) may be stored in ROM. System software may be stored in the system memory (815) including operating system software. The memory components may also include secondary memory (820). The secondary memory (820) may include a fixed disk (821), such as a hard disk drive, and, optionally, one or more storage interfaces (822) for interfacing with storage components (823), such as removable storage components (e.g. magnetic tape, optical disk, flash memory drive, external hard drive, removable memory chip, etc.), network attached storage components (e.g. NAS drives), remote storage components (e.g. cloud-based storage) or the like. The computing device (800) may include an external communications interface (830) for operation of the computing device (800) in a networked environment enabling transfer of data between multiple computing devices (800) and / or the Internet. Data transferred via the external communications interface (830) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal. The external communications interface (830) may enable communication of data between the computing device (800) and other computing devices including servers and external storage facilities. Web services may be accessible by and / or from the computing device (800) via the communications interface (830). The external communications interface (830) may be configured for connection to wireless communication channels (e.g., a cellular telephone network, wireless local area network (e.g. using Wi-Fi™), satellite-phone network, Satellite Internet Network, etc.) and may include an associated wireless transfer element, such as an antenna and associated circuitry. The computer-readable media in the form of the various memory components may provide storage of computer-executable instructions, data structures, program modules, software units and other data. A computer program product may be provided by a computer-readable medium having stored computer-readable program code executable by the central processor (810). A computer program product may be provided by a non-transient or non-transitory computer- readable medium, or may be provided via a signal or other transient or transitory means via the communications interface (830). Interconnection via the communication infrastructure (805) allows the one or more processors (810) to communicate with each subsystem or component and to control the execution of instructions from the memory components, as well as the exchange of information between subsystems or components. Peripherals (such as printers, scanners, cameras, or the like) and input / output (I / O) devices (such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like) may couple to or be integrally formed with the computing device (800) either directly or via an I / O controller (835). One or more displays (845) (which may be touch-sensitive displays) may be coupled to or integrally formed with the computing device (800) via a display or video adapter (840). The foregoing description has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure. Any of the steps, operations, components or processes described herein may be performed or implemented with one or more hardware or software units, alone or in combination with other devices. Components or devices configured or arranged to perform described functions or operations may be so arranged or configured through computer-implemented instructions which implement or carry out the described functions, algorithms, or methods. The computer- implemented instructions may be provided by hardware or software units. In one example, a software unit is implemented with a computer program product comprising a non-transient or non- transitory computer-readable medium containing computer program code, which can be executed by a processor for performing any or all of the steps, operations, or processes described. Software units or functions described in this application may be implemented as computer program code using any suitable computer language such as, for example, Java™, C++, or Perl™ using, for example, conventional or object-oriented techniques. The computer program code may be stored as a series of instructions, or commands on a non-transitory computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network. Flowchart illustrations and block diagrams of methods, systems, and computer program products according to examples are used herein. Each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, may provide functions which may be implemented by computer readable program instructions. In some alternative implementations, the functions identified by the blocks may take place in a different order to that shown in the flowchart illustrations. Some portions of this description describe the examples in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations, such as accompanying flow diagrams, are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. The described operations may be embodied in software, firmware, hardware, or any combinations thereof. The language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that are issued on an application based hereon. Accordingly, the disclosure of the examples is intended to be illustrative, but not limiting, of the scope of the invention set forth in any accompanying claims. Finally, throughout the specification and any accompanying claims, unless the context requires otherwise, the word ‘comprise’ or variations such as ‘comprises’ or ‘comprising’ will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.
Claims
CLAIMS:
1. A computer-implemented method for executable generation, the method conducted within an application development environment which comprises a library of functional element templates from which functional element instances can be created, the method comprising: creating a functional element instance from a functional element template and associating the functional element instance with one or more other functional element instances in the development environment, wherein the association defines a dependency between the functional element instance and at least one of the one or more other functional element instances, wherein each functional element instance represents a block of code and the functional element instances together represent a body of code for compiling into an executable; and, in response to creating the functional element instance, creating an agent module associated with the functional element instance, wherein the agent module is configured to: receive a message; obtain an action from the message; and, execute the action, wherein the action which the agent module is configured to execute includes a change action which effects a change to configuration of the functional element instance with which the agent module is associated, such that executing the change action includes changing configuration of the functional element instance and in turn the block of code represented by the functional element instance.
2. The method as claimed in claim 1, including the agent module obtaining the action from the message, wherein obtaining the action from the message includes processing the message to determine whether a language model is required to extract the action from the message, wherein the language model is configured to determine the action from the message.
3. The method as claimed in claim 2, including the agent module: in response to determining that the language model is not required, extracting the action from the message; or, in response to determining that the language model is required, inputting the message into the language model and receiving the action from the language model.
4. The method as claimed in claim 1, wherein each of the one or more other functional element instances is associated with an agent module created for and unique to that functional element instance.
5. The method as claimed in claim 1, wherein the agent modules are associated with one another to define dependencies between the agent modules that mirror the dependencies definedby the associations of the functional element instances, wherein the dependencies are tree-like.
6. The method as claimed in claim 1, including the agent module receiving the message, wherein receiving the message includes receiving the message from a queue of messages.
7. The method as claimed in claim 1, wherein the message is an update message generated by one of the one or more other functional element instances in response to a change made to one of the one or more other functional element instances, and wherein the method includes the agent module extracting and executing a change action from the message.
8. The method as claimed in claim 1, wherein the agent module is unique to the functional element instance with which it is associated, and wherein the agent module persists for as long as the functional element instance with which it is associated persists.
9. The method as claimed in claim 1, wherein the association of the functional element instance to the one or more other functional element instances is either that of: child; or parent.
10. The method as claimed in claim 9, wherein the functional element instance is associated with the one or more other functional element instances by way of addresses such that the functional element instance either addresses or is addressable by one or more of the one or more other functional element instances.
11. The method as claimed in claim 6, wherein receiving the message includes receiving the message from one of the one or more other functional element instances which is a parent of the functional element instance with which the agent module is associated.
12. The method as claimed in claim 1, wherein the action which the agent module is configured to execute includes a delegation action, wherein the delegation action includes or is associated with an address of another functional element instance to which the message is to be rerouted, wherein, when the action is the delegation action, the method includes the agent module executing the action including rerouting the message to the other functional element instance based on the address, and wherein rerouting the message includes restructuring the message to comply with a flow schema.
13. The method as claimed in claim 1, wherein the application development environment provides a graphical user interface in which a visual representation of the functional element instance is output, and wherein, when the action is the change action, the method includes theagent module: executing the change action including changing configuration of the functional element instance; updating the visual representation of the functional element instance; and, outputting the updated visual representation of the functional element instance.
14. The method as claimed in claim 1, wherein the functional element templates are grouped into types of functional elements, wherein each functional element type includes one or more functional element templates.
15. The method as claimed in claim 1, wherein the action which the agent module is configured to execute is one of a set of actions which the agent module is configured to perform.
16. The method as claimed in claim 2, wherein processing the message includes retrieving a state associated with the agent module, wherein the state includes a list of actions which the agent module is configured to perform.
17. The method as claimed in claim 2, wherein processing the message includes passing the message through a flow associated with the instance of the functional element, wherein the flow is retrieved from the library.
18. The method as claimed in claim 2, wherein processing the message includes performing a schema validation on the message.
19. The method as claimed in claim 18, wherein processing the message to determine whether the language model is required determines that the language model is required when the schema validation fails.
20. The method as claimed in claim 18, wherein performing the schema validation includes using a schema associated with the functional element instance and which includes one or more fields from which the action can be extracted.
21. The method as claimed in claim 2, wherein the language model is configured to determine the action from the message based on one-shot or few-shot learning, wherein the one-shot or few-shot learning includes prompt language specific to one or more of: a state associated with the agent module; the functional element instance; and the functional element-type.
22. A computing system for executable generation, the system hosting an application development environment comprising a library of functional element templates from whichfunctional element instances can be created, the system comprising a non-transitory computer- readable storage medium and one or more processors coupled to the non-transitory computer- readable storage medium, wherein the non-transitory computer-readable storage medium comprises program instructions that, when executed on the one or more processors, cause the one or more processors to perform operations comprising: creating a functional element instance from a functional element template and associating the functional element instance with one or more other functional element instances in the development environment, wherein the association defines a dependency between the functional element instance and at least one of the one or more other functional element instances, wherein each functional element instance represents a block of code and the functional element instances together represent a body of code for compiling into an executable; and, in response to creating the functional element instance, creating an agent module associated with the functional element instance, wherein the agent module is configured to: receive a message; obtain an action from the message; and, execute the action, wherein the action which the agent module is configured to execute includes a change action which effects a change to configuration of the functional element instance with which the agent module is associated, such that executing the change action includes changing configuration of the functional element instance and in turn the block of code represented by the functional element instance.
23. A computer program product for executable generation comprising a computer-readable medium having stored computer-readable program code for performing, within an application development environment which comprises a library of functional element templates from which functional element instances can be created, the steps of: creating a functional element instance from a functional element template and associating the functional element instance with one or more other functional element instances in the development environment, wherein the association defines a dependency between the functional element instance and at least one of the one or more other functional element instances, wherein each functional element instance represents a block of code and the functional element instances together represent a body of code for compiling into an executable; and, in response to creating the functional element instance, creating an agent module associated with the functional element instance, wherein the agent module is configured to: receive a message; obtain an action from the message; and, execute the action, wherein the action which the agent module is configured to execute includes a change action which effects a change to configuration of the functional element instance with which the agent module is associated, such that executing the change action includes changing configuration of the functional element instance and in turn the block of code represented by the functional elementinstance.
24. A computer-implemented method for executable generation, the method conducted within an application development environment which comprises a plurality of functional element instances and a plurality of agent modules, wherein each agent module is associated with a functional element instance of the plurality of functional element instances and having been generated in response to creation of the associated functional element instance, and wherein each functional element instance represents a block of code such that the functional element instances together represent a body of code for compiling into an executable, the method comprising an agent module: receiving a message; obtaining an action from the message; and, executing the action, wherein when the action is a change action which effects a change to configuration of the functional element instance with which the agent module is associated, executing the change action includes changing configuration of the functional element instance and in turn the block of code represented by the functional element instance.
Citation Information
Patent Citations
Automatic software generation for computer systems
US11262986B2
Software Development Tool
US20110271258A1
Merged machine-level intermediate representation optimizations
US20220214866A1
Methods and devices for compiler function fusion
US20230266950A1
Software development tool to automatically generate an optimized executable
US9696966B2