Wo KI Agenten in die Plattform und Datenlandschaft des Unternehmens passen
KI ist über den Punkt hinaus, an dem die einzige interessante Frage lautet, ob sie eine nützliche Antwort liefern kann. Viele Organisationen betreiben bereits Assistenten, die zusammenfassen, Entwürfe erstellen und Informationen abrufen. Die anspruchsvollere Frage ist architektonischer Natur: Wenn KI dazu beitragen soll, Arbeit voranzubringen, wo ist sie dann im Unternehmen angesiedelt? Ein Agent lässt sich am besten als Ausführungs und Orchestrierungsschicht verstehen, die auf vorhandenen Daten, Anwendungen, Workflows und Kontrollen aufsetzt. Sein Nutzen wird weniger durch das dahinterliegende Modell bestimmt als dadurch, wie gut sich diese Schicht mit den Systemen verbindet, die das Geschäft bereits tragen.
Die Designfrage verändert sich
Sobald ein Agent handeln und nicht nur antworten soll, drehen sich die entscheidenden Fragen nicht mehr um die Wahl des Modells. Sie lauten nun: Auf welche Daten und Systeme kann der Agent zugreifen, was kann er auslösen, welchen Kontext erhält er und unter welchen Kontrollen agiert er? Diese Fragen gehören zu Architektur, Integration und Governance. Sie erklären auch, warum viele Organisationen bereits einen Teil des Fundaments besitzen, ohne einen einzigen Agenten gebaut zu haben. Datenplattformen, Integrationsdienste, Workflow Engines, Observability Werkzeuge, API Gateways und Zugriffsverwaltung sind allesamt unmittelbar relevant für die agentische Readiness.
Eine einzelne Anfrage, vier Schichten
Eine konkrete Betrachtung hilft. Stellen Sie sich eine Anfrage aus dem Kundenkontakt oder dem Backoffice vor, die bei einem Agenten eingeht. Um sie zu bearbeiten, stellt der Agent zunächst Kontext zusammen: Kundenstammdaten aus dem CRM, Auftrags oder Bestandsstatus aus dem ERP, Fall oder Vertragsdaten aus einer fachspezifischen Anwendung und relevante Passagen aus einer internen Wissensbasis. Das ist die Kontextschicht, und ihre Qualität ist entscheidend. Sind diese Daten fragmentiert, veraltet oder fehlt wesentlicher Zustand, sinkt die Entscheidungsqualität rasch. Deshalb besteht die anspruchsvollere Arbeit zunehmend darin, festzulegen, welche Daten, welchen Zustand und welche abgerufenen Informationen ein Agent in jedem Schritt sehen soll, und weniger darin, einen Prompt zu formulieren. Dieser Wandel wird mitunter als Context Engineering bezeichnet.
Mit dem Kontext in der Hand plant der Agent und wählt eine Aktion. Diese Reasoning und Orchestrierungsschicht entscheidet, was geschehen soll und in welcher Reihenfolge. Um den Schritt auszuführen, greift sie auf die Aktionsschicht zu und ruft ein Tool oder eine API auf, um eine Berechtigung zu prüfen, einen Datensatz zu aktualisieren oder einen Workflow auszulösen. Bevor etwas ausgeführt wird, greift ein Kontrollpunkt: Der Agent prüft Berechtigungen, protokolliert die Aktion und führt entweder eine begrenzte Operation aus oder leitet den Fall mit dem vollständigen Verlauf an eine Person weiter. In diesen vier Schichten, Kontext, Reasoning, Aktion und Kontrolle, wird die Unternehmenslandschaft zur Arbeitsumgebung des Agenten und nicht nur zum Hintergrund.
Figure 1 — An agent sits between the existing systems it reads from and acts on (left) and the control plane that governs every step (right).
Die verbindenden Elemente
Zwei Elemente halten dies zusammen und verdienen architektonische Aufmerksamkeit. Das erste ist die Art, wie Agenten sich mit Systemen verbinden. Statt für jedes System eine massgeschneiderte Integration zu bauen, erreichen Agenten diese zunehmend über definierte Tool und Funktionsschnittstellen. Jede Schnittstelle wirkt wie ein Vertrag: Sie legt fest, was der Agent aufrufen darf und was er im Gegenzug zurückerhält. Offene, gemeinsam genutzte Konventionen für solche Schnittstellen entstehen derzeit, das Model Context Protocol ist ein Beispiel dafür, und sie machen die Verbindungen über Systeme hinweg einheitlicher und wiederverwendbar. Auch die Identität gehört hierher. Ein Agent ist ein maschineller Akteur und sollte begrenzte, prüfbare Berechtigungen erben, statt unter einem weit gefassten Servicekonto zu laufen.
Das zweite Element ist die Orchestrierung. Geschäftlicher Nutzen entsteht selten aus einer einzelnen Inferenz. Er entsteht daraus, mehrere Schritte zuverlässig zu koordinieren: Kontext abrufen, ein Tool auswählen, eine Aktion ausführen, das Ergebnis prüfen und dann entscheiden, ob fortgefahren, pausiert oder eskaliert wird. Hier wird die operative Disziplin, die Plattformteams bereits praktizieren, unverzichtbar. Schritte benötigen Timeouts und sichere, idempotente Wiederholungen, damit das erneute Ausführen eines fehlgeschlagenen Aufrufs keinen Auftrag und keine Zahlung doppelt auslöst. Jeder Schritt sollte zudem Signale aussenden, die das Monitoring erfassen kann, von der Latenz und Erfolgsrate von Tool Aufrufen bis hin zu unerwarteten Ausgaben. So bemerken Teams, wenn das Verhalten abweicht, statt es erst im Nachhinein festzustellen. Nicht jeder Prozess braucht zudem einen offen angelegten Agenten. Stabile, klar definierte Prozesse sind oft mit strukturierten Workflows besser bedient, die sich leichter testen und prüfen lassen, während Agenten den Fällen vorbehalten bleiben, die wirklich flexible, modellgetriebene Entscheidungen erfordern.
Control is the enabler, not the obstacle
Je näher Agenten an die Handlung rücken, desto stärker werden Identität, Berechtigungen, Observability und die Durchsetzung von Richtlinien Teil des Designs selbst. Jede Aktion, die der Agent ausführt, sollte protokolliert werden: ihre Eingaben, die aufgerufenen Tools und das Ergebnis. Dieser Audit Trail stützt die Nachvollziehbarkeit und, wo nötig, eine Rekonstruktion des Geschehenen. In regulierten Schweizer Branchen wie Banken, Versicherungen, dem Gesundheitswesen und dem öffentlichen Sektor ist es diese Kontrollebene, die Agenten überhaupt erst tragfähig macht. Nachvollziehbarkeit, begrenzte Berechtigungen und klare Punkte menschlicher Freigabe machen Kontrolle zum Wegbereiter statt zur Bremse. Und die zugrunde liegende Architekturfrage bleibt dieselbe, ob die Plattform auf Microsoft Fabric, Databricks, Snowflake oder einem cloud nativen Stack läuft.
Daraus ergibt sich ein praktischer nächster Schritt für Organisationen, die isolierte Assistenten bereits hinter sich gelassen haben. Bevor ein Modell ausgewählt oder eine ehrgeizige Liste von Anwendungsfällen entworfen wird, ist die nützlichere Übung ein ehrlicher Blick auf die architektonische Passung, Prozess für Prozess: wo vertrauenswürdiger Kontext bereits vorhanden ist, wo sichere Wege zur Handlung bereits bestehen und wo die Kontrollmechanismen noch fehlen. Eine solche Überprüfung zeigt meist, dass ein Teil der Grundlagen bereits gelegt ist, und sie weist klar auf die Lücken hin, die zuerst geschlossen werden sollten. Genau hier beginnt der Weg von KI Experimenten hin zu einer verlässlichen Unternehmensfähigkeit.