Achieving interoperability is much more than a technical puzzle. It is a significant economic challenge. Today, connecting software systems still relies on human-intensive engineering, costing organizations immense time and money. But what if we could remove the human from the loop? At Fraunhofer IESE, we are pioneering a shift from manual development to automated solutions. By leveraging generative AI, we have begun engineering software-based systems that can achieve autonomous interoperability at runtime. Here is how we are turning “on-the-fly” data integration into a reality.
The Interoperability Challenge: Data Adaptation and Its Costs
Interoperability is a quality attribute in software-based systems that refers to their ability to exchange and use data with other systems. Achieving this quality is desired for a large range of systems.
For example:
- Legacy systems contain important business data for their organizations, and this data is typically desired by other applications.
- Modern platforms have interoperability at their core, as a typical goal of the platform owners is to be able to connect to a wide number of counterpart systems in their field.
- Systems of systems have interoperability as one of their key enablers: without the ability to exchange and use data, there is no “system of systems”.
The need for interoperability is also prominent in several domains. Notable examples include agriculture, defense, health, and smart cities, which are highly heterogeneous domains organized in multiple subdomains that frequently function as silos. And the more dynamic the ecosystems are, the harder interoperability is. Standardization, a typical alternative for addressing interoperability, is a far-off dream: As each organization has its own ways of organizing the data in their systems, defining a consistent and thoroughly accepted common information model across different companies is impractical. Semantic technologies such as annotations have been available for decades; however, they never took off (see an interesting reflection on that here [H20]). At the end of the day, as different organizations have different ways of representing [the same] data, human effort is required to understand the differences and implement solutions.
Finally, it is important to highlight that interoperability is a challenge beyond its technical aspect. From a purely technical perspective, there is already a diverse infrastructure in terms of data formats, protocols, and schema languages, all of this with corresponding software support. Nonetheless, even when all technical infrastructure and knowledge are available, implementing interoperable systems requires human efforts, and most direct costs relate to data adaptation (as discussed in this study [SH19]): at least one party among the interoperating systems must understand the counterpart data representation and develop, test, and deploy the necessary software artifacts to adapt data from representation A to representation B.
GRAIN – Generative AI for Interoperability
Leveraging Generative AI for Seamless Integration
Since 2024, we at Fraunhofer IESE have intensively researched a new approach to interoperability. Our goal has been to move the development time effort associated with implementing interoperability to runtime. In other words, we wanted to engineer systems that can, autonomously, recognize data in an unknown representation and convert it into a desired representation – everything on the fly.
We refer to the set of technologies we have developed to implement this vision as GRAIN (Generative AI for Interoperability). GRAIN leverages the recent developments in artificial intelligence to build software agents that do, at runtime, what we humans have done at development time. GRAIN uses large language models (LLMs) to implement two strategies for enabling autonomous interoperability: direct conversion and conversion module generation.
| Strategy DIRECT | Strategy CODEGEN | |
| Approach | LLM transforms data directly | LLM generates reusable adapter code |
| Performance | Higher latency per request | High speed after initial generation |
| Cost | Higher (LLM calls for every item) | Lower (One-time generation cost) |
| Ideal for | Dynamic, varying data structures | High-volume, stable data structures |
Strategy 1: Direct Data Conversion at Runtime (DIRECT)
The first strategy, which we call Direct Conversion (DIRECT), uses the LLM to directly transform the input data into the target representation. Instead of writing a fixed mapping at development time, we let the model “understand” the syntax and semantics of both the source and the target format and perform the conversion on demand.
At runtime, GRAIN dynamically constructs a prompt that contains the input data and a schema or example of the target data representation. This prompt is sent to the LLM, which responds with the data in the desired format. GRAIN then extracts the target data from the response and validates it for syntactic correctness. If the validation fails – for example, because the response is not valid JSON – GRAIN automatically triggers a new attempt.
DIRECT is particularly attractive when input data can vary over time, for instance when properties are missing or added. Since the LLM reasons over the structure and meaning of the data instead of following a fixed mapping, the approach can gracefully handle such variations. At the same time, DIRECT inherits typical limitations of LLMs: The conversion is not always fully deterministic, the model cannot reliably perform precise arithmetic or complex calculations, and every conversion requires a new LLM inference. This leads to non-negligible computational cost and latency at runtime.
This is also the reason why we do not “just” call an LLM and consider the problem solved. Raw LLM output can be incomplete, syntactically invalid, or otherwise unusable. GRAIN therefore wraps the LLM with additional logic for validation and resilience: it checks the syntactic correctness of the result, automatically retries when necessary, and ensures that only valid data reaches the consuming system.
Strategy 2: Automated Code Generation for Adapters (CODEGEN)
The second strategy, which we call Conversion Module Generation (CODEGEN), uses the LLM differently: not to convert individual data items, but to produce the algorithm that performs the conversion. Instead of returning the converted data, the LLM generates source code for an adapter that reads the input data and outputs the desired target representation.
Again, GRAIN dynamically builds a prompt at runtime. This prompt includes examples of input data, a schema, or example of the target representation, and instructions to generate code that implements the conversion. The LLM responds with the adapter code, which GRAIN extracts and deploys into a dedicated execution environment. From that point on, the adapter processes incoming data and produces the converted output without further involvement of the LLM. If execution fails – for example due to runtime errors or incorrect assumptions in the generated code – GRAIN starts another iteration by asking the LLM to produce an improved version of the adapter.
CODEGEN typically yields syntactically correct output data because the generated adapter can be compiled, tested, and constrained to emit valid structures. Moreover, once the adapter is deployed, conversions are fast and cheap: they no longer require repeated LLM calls but are handled by regular program code. The main trade-off is adaptability: if the input data format changes significantly or optional information becomes available that should be mapped as well, the adapter may need to be regenerated or updated via another code generation cycle.
See in the figure below the demonstrator we have created to illustrate the technology. It showcases an agricultural scenario, where the system is programmed to display field boundaries represented using GeoJSON. When the field boundaries are provided in a different (unknown) format, the visualization fails; then, with a 1-click action, the system processes the unknown data representation and converts it autonomously into the target representation (GeoJSON, in this case).
How effective is autonomous interoperability?
To know how reliable an LLM-based approach to interoperability is, we conducted a rigorous experimental evaluation. This involved the usage of 12 top-ranked LLMs that excel on coding tasks, four versions of a dataset containing agricultural data in different representations, and more than 64,000 LLM calls. On the effectiveness of GRAIN to make systems interoperate autonomously (the detailed results can be found here [FSS+25]).
The results were interesting – and, in a way, surprising. The summary is: yes, some LLM-based strategies can make systems interoperate autonomously. However, many factors influence the design decisions to make it work. One of these factors is the LLM choice. While all chosen LLMs performed well in general coding tasks (effectiveness above 70%), they behave differently when it comes to adapting data for interoperability purposes. In the agricultural use case we tried out, more than half of the LLMs failed, scoring below 40%. This percentage indicates the amount of data conversion tasks the models managed to do correctly from the datasets we created with several data records. On the other hand, the models that worked did a pretty good job. The effectiveness of the best model varied from 75% to 100%, depending on the dataset and implementation strategy we used.
Besides the model choice, influencing factors in the design of autonomous interoperability based on LLMs include the strategy you employ, how you prompt the LLMs, what the characteristics of the use case are, and what data type is involved. All to say that software engineers are required to design a system that can achieve the expected results with qualities such as functional correctness, reliability, scalability, and security.
The road ahead
Our next step in the research toward autonomous interoperability is focused on how to increase the reliability of GRAIN. As discussed, the current results show that the approach works; however, it may not work all the time in all use cases. Here, reliability strategies play an important role. We are designing GRAIN to not only work but also work reliably and securely. Stay tuned if you want to keep track of the progress.
References
[FSS+25] Falcão, R., Schweitzer, S., Siebert, J., Calvet, E., Elberzhager, F. Evaluating the effectiveness of LLM-based interoperability. Accepted for ICSE 2026 Research Track (preprint on ArXiv).
[H20] Hogan, Aidan. „The semantic web: two decades on.“ Semantic Web 11.1 (2020): 169-185.
[SG19] Stegemann, Lars, and Martin Gersch. “Interoperability–Technical or economic challenge?.” it-Information Technology 61.5-6 (2019): 243-252.