In recent years, artificial intelligence has evolved at a pace that has surprised even experienced strategists. What once began as playful experimentation with text windows has, by 2026, been transformed by models such as GPT, Gemini, and Claude into a precise high-performance tool. Yet while the market is flooded with ever-new versions, one strategically crucial question arises for us: What distinguishes a merely “smart” answer from an AIsolution that creates real value within a complex enterprise architecture? The AIworkshop at setis served as a navigator through this technological fog. Today, it is no longer just about the machine reacting, but about mastering its internal mechanisms in order to develop it from a digital toy into a reliable business partner.

A professional approach to Large Language Models (LLMs) begins with demystification: an LLM is trained to anticipate human language, but it operates without any consciousness or genuine “understanding” of the world. The performance of these models is based on statistical probability, not cognitive insight.

For professional users, this knowledge is essential in order to manage the risk of hallucinations. When models cannot find facts, they often invent them with striking eloquence. From a strategic perspective, however, the absence of awareness is a major advantage: AI operates in a purely logical and structural way based on its training data, free from human emotions or bias. This objectivity allows us to use AI as a highly efficient sorting machine for information, as long as we understand the limits of statistical truth.

„AI is a field of computer science concerned with the development of intelligent machines... for tasks that normally require human intelligence.”

Today, we no longer see LLMs as a black box. Instead, we use precise model parameters — internal values learned during training — to shape how the system responds to prompts.

• Temperature: Controls the degree of randomness. A low temperature produces factual, logical results for technical documentation, while a high temperature opens the door to creative and imaginative approaches.
• Top-p & Top-k: These parameters limit word selection (tokens) based on cumulative probabilities. Low values lead to precise, compact answers, while high values result in more varied and extensive outputs.

This fine-tuning of the “hallucination probability” is what makes AIapplications in 2026 truly audit-ready for enterprise use. We control the machine’s creativity precisely according to the needs of the specific use case.

Standard models suffer from a “knowledge cut-off.” They know nothing about the period after their training and nothing about internal company knowledge. This is where RAG (Retrieval-Augmented Generation) becomes the decisive game changer. It connects general language understanding with exclusive data, such as the information we maintain in the setis wiki.

The process has three stages:

1. Retrieve: Targeted search in internal PDFs, wikis, or databases.
2. Augment: These facts are added to the user prompt as context.
3. Generate: The response is then generated based on exclusive facts rather than mere assumption.

RAG drastically reduces the error rate and turns AI into an expert on our own private company knowledge.

The most radical leap in 2026 is tthe transition from pure text output to genuine agency. The Model Context Protocol (MCP) serves as the link between the language model and external software tools or data sources.

While a chatbot can only suggest solutions, autonomous AIagents execute tasks independently. They use MCPto interact directly with systems without requiring constant prompts for every intermediate step. The process follows a clear logic:

• Register the tool: The capabilities of the software interfaces are made known to the model.
• Invoke the tool: The LLM autonomously decides which tool is needed to solve the problem.
• Use the result: The tool’s response is integrated directly into the working context.

The era of LLaMA 4 (in the Scout and Maverick variants) and Gemini 3 marks the final turning point: we are leaving behind the age of simple prompt engineering and entering the phase of agent-based orchestration. With frameworks such as spring-ai , setis developers can embed these agents directly into Java-based infrastructures and scale autonomous execution. In 2026, it is no longer just about smart answers, but about automating the execution of complex workflows.

The database is the foundation of any Automic Automation environment. Performance, stability, and operating costs depend heavily on it. Many companies traditionally rely on Oracle —an established but license- and resource-intensive product.

In a recent project, setis GmbH helped a customer migrate the Automic database from Oracle to PostgreSQL —achieving several goals at once:

• Reduced costs
• Established cloud readiness
• Delivered on the company’s open-source strategy

The existing Oracle database incurred high license fees, required ever more powerful hardware, and drove up storage needs for backups. At the same time, the company had made a strategic decision to increase its use of open source.

Against this backdrop, setis advised the customer during the decision-making phase: Which alternatives are viable? What impact would a migration have on operations and costs? How can Automic be run in a future-proof way? The analysis led to a clear decision: PostgreSQL as the database platform.

Implementation followed a structured, multi-stage plan:

• Analysis of the existing Automic environment, dependencies, and data sets
• Migration concept including tools, timeline, and adjustments (e.g., monitoring, SQL scripts, permission model)
• Provisioning of new environments for test and production
• Test migration with validation of all functions
• Production migration in close coordination with the customer’s teams and service providers
• Decommissioning of the legacy environment and documentation updates

The migration was seamless and did not interrupt any automation processes. The customer immediately benefited from:

• Elimination of Oracle licenses and a significant reduction in infrastructure costs
• Lower resource requirements with PostgreSQL, especially for storage and backups
• Cloud readiness and improved integration with modern platforms
• Strategic future-proofing through consistent execution of the open-source strategy

Key to success were:

• die Early involvement of setis in the decision-making process
• A thorough test migration to safeguard the production cutover
• sowie die Close collaboration among all stakeholders

This turned a technically demanding task into a smooth step toward modernization.

The migration of the Automic Automation database from Oracle to PostgreSQL shows how echnical modernization can align with strategic goals: lowering costs, reducing complexity, and paving the way for the cloud.

With extensive experience in automation projects, setis supports customers not only during implementation but also in decision and planning phases —ensuring migrations don’t just work, but deliver real value.

Broadcom has fundamentally revised the licensing model for Automic Automation. The solution now follows a modern execution-based approach, replacing the previous model. This article explains how it works, highlights its benefits, and offers practical guidance for maximizing its value. We also discuss why monitoring executions is helpful and how to establish an effective monitoring strategy.

Execution-based licensing directly aligns costs with business value, as fees depend on the successful execution of automated jobs. This approach is better aligned with today’s automation challenges: scaling across hybrid cloud environments, orchestrating end-to-end business processes, and moving beyond traditional batch workloads. By emphasizing workflows and API-driven orchestration, it reflects the realities of the modern automation landscape.

The license size is determined by the number of successful job executions across all environments, including DEV and QA. The calculation basis for the license size is the calendar month with the highest number of executions.

Which jobs are counted?

• All executions of the types JOBS and JOBF that end successfully with status 1900 or 1904.
• Except for executions with the agent types AVALOAGENT or BS2000, these agents are licensed separately.

Which environments are considered?

• All of your environments. There is no separation between PROD, QA, or DEV.

License cost calculation

• The executions are counted per month.
• The month with the highest number of executions in the year forms the basis for the license capacity.

How is the data collected?

• Through the Automic Automation telemetry feature. It collects the data and reports it to Broadcom.

The telemetry feature in Automic Automation supports users in collecting and transmitting license-relevant statistics.

The best way to access the telemetry data is through Client 0 in the AWI. In addition to configuration, telemetry data can also be accessed there. The data can be filtered and exported as a CSV file. The executions are not broken down by client or application.

It collects the data daily and stores it in the database – the most important information is in the LAH and LAHD table. Additionally, the current overview of executions can be accessed and displayed via the REST endpoints.

👉More info and configuration: Telemetry documentation
👉REST endpoints: API documentation

The new model requires more precise monitoring of executions:

• Where do most executions occur (which application)?

• How many executions are generated in total?

It is helpful to define and monitor current high-watermarks. This prevents unexpected license increases, e.g., due to development errors.

👉 Based on this data, targeted optimizations can be made.

The changes also bring some important advantages:

• License costs can be fairly allocated to applications.

• The licensing model has been streamlined and made more transparent.

• Analyses reveal optimization potential in workflows and processes.

• The costs for a later switch to Broadcom Automic SaaS can be calculated in advance.

Monitoring and analysis are key to optimizing your environment. You get a quick overview of your current overall status and can see which applications are causing the biggest impact.

This helps make executions more efficient and prevents unnecessary license upgrades caused by development errors. At the same time, it enables you to easily allocate costs to your customers on this basis.

We have developed a proprietary license reporting solution to address this challenge. For more information, please feel free to contact us.

Key-Features:

• Enable monthly reporting per client / application.

• Assign clients and customers, and set up an automated process to generate reports on your applications.

• Validation and comparison with telemetry data for quality control.

• Support threshold alerts (high-watermarks) to prevent license overruns

• Be individually adaptable (e.g., mapping sub-applications within a client)

• Working without extended log retention for the reports

The transition to execution-based licensing is simple and opens up additional benefits. Below are a number of recommendations to help with this process.

• Regularly evaluate execution results to avoid unexpected execution changes.
  • Establish continuous monitoring and alerting for ongoing transparency.
• Raise awareness among your applications about the impact of higher execution numbers.
• Nevertheless, the cost-benefit ratio should always be taken into account.
• Identify and optimize applications with the highest impact.
• Establish internal recommendations and guidelines, and openly share them with your application teams. For example:
  • Consider reducing ForEach-JOBPs when appropriate. Asynchronous REST calls no longer require ForEach-JOBP with polling—the new IG REST agent has a built-in polling capability. In other use cases, use a job that implements the ForEach logic within its own loops or AE script data sequences. The execution of jobs within the workflows is being significantly optimized.
  • Review high-frequency, time-scheduled workflows and their scheduling intervals to ensure they reflect today’s requirements. It is not uncommon for requirements to change over time, creating potential for optimization.
  • Convert file-triggered workflows into batch processes wherever feasible, align frequency with business needs while improving efficiency.

Broadcom’s execution-based licensing model brings more transparency and simplifies licensing, but also new requirements. Effective monitoring and optimization safeguard against avoidable license growth.

If you need support, please feel free to contact me or my company setis GmbH. We support you with the implementation of license monitoring, as well as process analysis and optimization.

Migrating to the cloud raises a key question for many companies: how can existing processes and tools continue to be used in the new infrastructure? This is especially true when it comes to automation solutions like Automic Automation in the context of RISE with SAP – SAP’s cloud offering for the transformation into an intelligent enterprise.

In this article, we highlight the possibilities and limitations of using Automic Automation with RISE with SAP — and share proven best practices.

When companies move their SAP systems to the cloud for the first time (greenfield) and don’t yet use centralized job scheduling, Automic Automation can be introduced as an orchestration solution right from the start.

Since RISE with SAP does not allow third-party software — including the SAP agent from Automic — to be installed on SAP systems, data exchange typically takes place via standardized protocols such as SFTP. This architecture creates a clear separation between SAP and the automation system and provides a solid foundation for future expansion.

In practice, many companies migrate their SAP landscapes to the cloud step by step — and already use Automic Automation to manage business processes, SAP jobs, and file transfers.

A common setup involves Automic JOBF-Jobs for file transfers between SAP and third-party systems. In the new RISE environment, however, such direct transfers are problematic, since no agents or third-party components may be installed on cloud systems.

While a complete switch to SFTPtransfers is possible, it usually involves considerable additional effort — particularly in large, historically grown automation landscapes.

A proven way to integrate Automic with RISE is through Fileshares, mounted on the cloud side and accessible from the Automic system. Two approaches have worked well in practice:

1. On-premises filesystem mounted in the cloud
   A central local filesystem (e.g., NetApp) is provided to SAP systems in the cloud as a fileshare. File transfers remain centrally controlled.

2. Cloud-based filesystem mounted by an Automic agent
   A centrally provided cloud filesystem is mounted on an on-premises system with an Automic agent. This way, Automic can handle file operations as usual — without installing software on RISE systems.

Both options allow existing automation processes to continue with manageable adjustments — and remain compliant with SAP’s guidelines.

Using Automic Automation in a RISE with SAP environment is possible — but it requires specific technical and organizational conditions. Especially in migration scenarios involving existing JOBFtransfers, early planning is key to avoiding costly and time-intensive changes.

The solution lies in an architecture that leverages the strengths of Automic Automation without conflicting with RISE with SAP operating policies — for example, by using central fileshares or standardized interfaces.

We’re here to help you design a future-proof SAP and automation strategy — get in touch with us.