Integrating AI into existing systems: Why context dictates architecture

Many AI initiatives begin with a single use case. Often, this involves an internal knowledge assistant or document analysis. In other cases, the entry point is in customer service, for instance, by providing support for recurring queries. Actual business processes continue to run in parallel. CRM and ticketing systems remain productive. Document platforms, specialist applications, and legacy systems are frequently deeply embedded in workflows that cannot simply be paused or rebuilt. In any case, their backlogs are usually already full.

At this point, it is decided whether AI within the enterprise moves beyond pilot projects. The chatbot is not the core of the architecture. The deciding factor is how models access existing systems while utilising the correct context.

The technical environment is changing rapidly. New model generations alter what is possible. Agentic workflows further shift the question of how much autonomy a system should be granted. This increases not only the potential but also the integration effort.

Anyone wishing to use AI in the long term must first limit the context. Which information is relevant to a process? The next step raises the question of which actions an AI system is permitted to execute and via which existing services these actions are provided in a controlled manner.

Powerful AI systems do not emerge solely through better models. What matters is how information is selected and provided. In this way, context engineering becomes an architectural task.

Most enterprises do not start from scratch. Over time, system landscapes have evolved that already provide many functional business capabilities. For example, CRM systems can read or update customer data. Ticketing tools can create incidents, and document platforms can manage content. Specialist systems, in turn, calculate prices or verify contract data.

Therefore, the first step is by no means to layer an additional AI level over everything. It is more sensible to make existing capabilities visible.

These capabilities can be described as clearly defined actions that a system can perform. These include, for example, creating a ticket, retrieving a contract, updating customer data, checking an order, or prioritising an incident.

In classical architectures, such functions are frequently provided via REST APIs or service endpoints. They are particularly relevant for AI systems because they describe what a model can actually do within a process context: retrieving information or triggering actions.

The first architectural question addresses the already existing capabilities, their location, and the conditions for their use.

As previously described, every capability operates with specific data. In AI-supported processes, capabilities and data must therefore be considered together. Their mapping defines the context within which an AI system can operate meaningfully.

An example makes this tangible: an AI-supported process is intended to analyse support tickets and generate proposed solutions. For this, the ticket description alone is insufficient. What is required are current ticket data, comparable historical tickets, relevant knowledge articles, and product information from a specialist system. Only when all these sources and capabilities are neatly mapped can the context be precisely assembled.

This step has a direct impact on the quality of the results. A model can only deliver robust recommendations if it sees the appropriate section of the system landscape. Too little context leads to superficial answers. Too much context increases costs, latency, and the risk of errors.

Targeted context provision therefore has a practical side effect: in many cases, smaller, more efficient models can be deployed. This reduces token consumption, response times, and operating costs without artificially bloating the architecture.

Instead of assuming chatbots or isolated applications, the focus should be on the process. Which steps are involved? Which systems deliver data? Which capabilities must be executed? Which decisions require human approval?

The result is a capability map for the respective process. It shows which functions and data sources jointly form the respective context. Anyone who models these relationships cleanly will quickly arrive back at classical architecture tools. Sometimes, UML is even sufficient for this.

The capability map makes visible which parts of a process can be supported by AI and which dependencies arise as a result. On this basis, it can be decided whether a chat interface is the appropriate frontend. In many cases, a UI mask is closer to the working context. For other process steps, an automated background process logic is better suited.

For AI systems to use existing capabilities, they must first be able to understand them and deploy them in a controlled manner. This is precisely where two concepts currently under intensive discussion come into play.

MCP (Model Context Protocol) describes how an AI model can utilise external tools and data sources. It specifies which capabilities are available, which parameters are required, and how results flow back. In short, MCP creates an interface standard between the model and tooling.

Agent-to-Agent (A2A) addresses communication between specialised AI components when tasks cannot be handled by a single agent. In other words, it is a protocol for collaboration between agents.

Both MCP and A2A attempt to establish a common language between AI systems and classical software services. Nevertheless, a sober perspective is required. In many organisations, hundreds of APIs already exist, often as REST services. These interfaces offer precisely the functions that artificial intelligence systems are supposed to use.

It would be unrealistic to expect every existing system to additionally run its own MCP server in the short term. More crucial is the consideration of how existing services can be made accessible in such a way that artificial intelligence can use them in a controlled manner.

In some cases, MCP can help as a description layer for capabilities. In other cases, it is sufficient to cleanly model existing APIs and provide them via an orchestration layer. The specific protocol is less decisive here than the underlying architectural principle: capabilities must be described comprehensibly for AI systems and tied to clear access permissions.

Once the capabilities and data sources for a process are cleanly modelled, a clear context for AI support emerges. Only then does the question of the user interface arise.

Some scenarios are best solved via classical applications or process masks. Others, in turn, can be excellently resolved via a chat interaction. Yet others run fully automated in the background.

One possible manifestation is a so-called companion app—a central AI assistant for employees. In a service-oriented architecture, such an assistant can access various functions, for example, creating tickets, summarising documents, initiating processes, or consolidating information from multiple systems.

However, the prerequisite for this is a resilient foundation in the form of a clear model of available capabilities, a transparent data perspective, as well as a security and role model that limits tool access. Without this foundation, artificial intelligence remains an experiment alongside the existing process landscape. With it, AI can become part of the process architecture.

The discussion about AI in enterprises often revolves around models, tools, and chatbots. However, a crucial point is overlooked in the process. AI must be integrated into existing process architectures and must not be placed alongside them.

Those who ask the right questions create the foundation for resilient AI applications. Which capabilities are available? Which data flows into which processes? What context arises from this? Which access rights must be controlled?

The actual decision lies in the architecture of the processes and systems. Whether artificial intelligence (AI) stops at individual pilots or becomes permanently embedded in productive processes is decided precisely there.

The architectural guidelines of the major cloud providers support this perspective: instead of pure chatbots, they define AI systems as orchestrated systems that bring together models, tools, data sources, workflows, context, and governance. The differences lie in the details.

The common line is clearly defined. The user interface is not the starting point. The structure underneath is decisive. AI requires clearly described capabilities and a limited, controlled context.