Hello, and welcome to the demo of the new AutoBPMN.AI extension, Agentic Augmentation of Process Models with Endpoints and Data Flow. The tool has a simple and intuitive user interface. On the left side, you can provide a text description and select your preferred LLM. The generated executable process model is displayed above. On the right side, the properties of the selected element are displayed. Since we are aiming to create an executable process model, the first step is to define the available services we can use. These services come from the underlying process engine and are listed as available resources. URL: https://autobpmn.ai/flow/resources/endpoints/?description For this demo, we will use a smart home automation scenario, where the goal is to control room lighting. Here, you can see the complete list of available services prepared for this specific scenario, such as “Get ambient light level” and “Control lighting intensity”. To begin with, we will first model a basic use case: retrieving the current light level in a room. PROMPT: “get the light level in the room”. Now, in the background, the agent first generates an initial process model based on the user’s request. After that, each task in the model is mapped against the service registry to identify the most appropriate service implementation. If no suitable match is found, the corresponding task remains empty and can be refined later. When a match is found, the system automatically enriches the task by generating aligned input and output data structures based on both the selected service and the overall process description. Finally, the generated model is validated to ensure both syntactical and semantic correctness. After the model is generated, on the right side, we can see that generated task now includes not only a label, but also additional properties that make it executable. In this case, the task is linked to a single endpoint, “Get light level”. According to its documentation, it defines a single input parameter, mode, which is set to one. As output, the service returns the current illumination in lux, which is then stored in the process data object called light level. Now, let’s slightly extend the process. Instead of immediately requesting the sensor value, we want to introduce a short delay of five seconds beforehand. This can easily be achieved by refining the prompt to the LLM. PROMPT: "Before getting the light level, wait for 5 seconds" As before, the system updates the model accordingly. The newly added waiting task is also fully configured with all necessary properties. As soon as we start the execution, the process first pauses for 5 seconds. After this delay, the request is sent to the light service, where the value from the light sensor is retrieved and returned back to the process engine. In the engine, after execution, we can see that the process instance status is set to finished, and in the data object we now have a new entry, light level, which contains the value Now let’s move to a more complex example. We extend the previous scenario into a small control loop that runs five times. In each iteration, the system checks the current lighting conditions in the room and decides how to adjust the dining room lights accordingly. After each adjustment, the process waits for two seconds before continuing with the next iteration. Once all five iterations are completed, the process ensures that the lights are switched off. PROMPT: The system runs a loop 5 times. In each iteration, it measures the current lighting conditions and adjusts the dining room lights: increasing brightness if it is too dim, reducing it if it is too bright, or turning the lights off if it is night. After each update, it waits for 2 seconds and then proceeds to the next iteration until the loop completes. At the very end switch the light off. PROMPT: Change the condition of the first branch to be greater than 10 and less than 100. In comparison to the previous example, the agents also generate additional script tasks required to make the process executable. Unlike the service tasks, these are not mapped to endpoints from the service registry. Instead, they are inferred automatically from the process logic, with tasks such as initializing and decrementing the loop counter generated to ensure that the process is fully executable. Let’s execute the process. We can observe that by influencing the sensor, the intensity of the light is adjusted accordingly. Depending on the measured ambient light conditions, the system reacts by increasing, reducing or turning off the lights. Finally, let’s look at an example with a much less detailed prompt. The user specifies only the desired behavior. The agents automatically infer the necessary process logic while mapping the lighting operations to the available services, resulting in a complete executable process model. PROMPT: "Make the lights flicker for the next 10 seconds in a 1 second interval." Thank you for your attention. All prompts, video scripts, and the service registry can be found on autobpmn.ai.