Der agentische Stack: Eine Architektur-These

1. Die These

Software arbeitet nicht mehr nur auf Befehl. Agenten lesen Daten, greifen auf Tools und APIs zu, planen Schritte und führen sie aus – mit einem Grad an Eigenständigkeit, das klassische Automatisierung nicht kennt. Für Infrastruktur-Teams verändert das nicht zuerst die Werkzeugliste, sondern die Grundfrage: Es geht nicht mehr zuerst um „Welches Modell nehme ich?“, sondern um „Welche Rechte, welche Grenzen und welches Fehlerverhalten legen wir fest, bevor der erste Agent läuft?“

Meine These: Der Unterschied zwischen einem kontrollierten System und einem unkontrollierten Risiko entsteht nicht im Modell, sondern in der Architektur. Das ist eine gute Nachricht, denn Architektur ist entscheidbar – in Schichten, mit klaren Zuständigkeiten, dokumentiert wie jede andere Produktionsumgebung auch. In der Praxis ist genau dieser Schritt häufig der übersprungene.

Für DSGVO-sensible Unternehmen – viele meiner Bestandskunden zählen dazu – ist das kein theoretisches Thema. Datenhoheit, Kontrollierbarkeit und ein Betrieb, der auch in zwei Jahren noch nachvollziehbar ist, sind dort keine Verkaufsargumente, sondern Anforderungen an jede neue Technologie. Agenten unterstehen derselben Prüfung – mit einem Unterschied: Es sind Systeme, die sich selbst ein Stück weit führen.

Was dieses Paper ist – und was nicht

Dieses Paper ist kein Tutorial, keine Produktreview und keine Rechtsberatung. Es ist eine Architekturthese – mit Argumenten, Beobachtungen aus dem Betrieb und einem Entscheidungsrahmen, den Sie auf Ihre Umgebung übertragen können. Rechtliche Grundlagen werden dort erwähnt, wo sie Architekturentscheidungen direkt berühren; sie ersetzen keine rechtliche Prüfung im Einzelfall. Abschnitt 6 zeigt drei Wege, wie die Umsetzung konkreter wird.

2. Wo wir stehen: Agentic AI zwischen Hype und Produktion

Vom Chatbot zum Agenten

Ein Chatbot beantwortet Fragen. Ein Agent erledigt Aufgaben – in einer Schleife aus Planung, Werkzeugzugriff, Ergebnisprüfung und dem nächsten Schritt. Drei Eigenschaften unterscheiden Agenten von dem, was viele Unternehmen heute unter „KI“ verstehen:

1. Orchestrierung: Ein Agent plant nicht nur die Antwort, sondern den Weg dorthin – Schritte, Reihenfolge, Zwischenergebnisse, Abbruchbedingungen.
2. Werkzeugzugriff: Agenten können Systeme aufrufen – Datenquellen, APIs, Ticketsysteme, teilweise auch Server-Administration.
3. Autonomiegrade: Von „schlägt vor, Mensch bestätigt“ bis „führt aus, Mensch prüft am Ende“ ist vieles konstruierbar. Welcher Grad richtig ist, hängt von Prozess, Risiko und Umgebung ab – und ist eine Architekturentscheidung, keine Geschmacksfrage.

Der Sprung vom Chatbot zum Agenten ist deshalb kein Upgrade, sondern ein Klassensprung: Aus einem Dialogsystem ohne Schreibrechte wird ein System mit Rechten an Produktionssysteme.

Wo Agenten heute realistisch tragen

Die Marktberichte zeichnen die Spannung nach, in der Agentic AI heute steht: McKinsey meldet in der State-of-AI-Erhebung vom März 2025, dass 78 % der befragten Organisationen KI in mindestens einer Geschäftsfunktion einsetzen – erhöht gegenüber 72 % Anfang 2024 und 55 % im Jahr davor. Gartner prognostiziert in der Pressemitteilung vom 25. Juni 2025, dass bis 2028 rund 33 % der Unternehmenssoftware-Anwendungen Agenten-Fähigkeiten enthalten werden – gegenüber weniger als 1 % in 2024 – und dass mindestens 15 % der alltäglichen Arbeitsentscheidungen autonom durch Agenten getroffen werden.

Im selben Bericht schätzt Gartner, dass mehr als 40 % der Agentic-AI-Projekte bis Ende 2027 abgebrochen werden – wegen steigender Kosten, unklarem Geschäftsnutzen oder unzureichenden Risikokontrollen. Beide Aussagen gelten gleichzeitig: Die Adoption ist breit, die Ausfallquote ist hoch. Wer heute einen Agenten-Piloten startet, muss beides einrechnen.

Wie passt das zusammen? Die Zahlen sagen mehr über Reifegrad als über Systeme. Der überwiegende Teil der heutigen KI-Nutzung ist Assistenz: Vorschläge, Entwürfe, Zusammenfassungen. Agenten sind der nächste Schritt – und genau dort, wo ein System Rechte bekommt, entscheiden nicht Spezifikationen des Modells, sondern Rechte, Grenzen und Aufzeichnungen. Wenn Projekte abgebrochen werden, ist selten das Modell schuld; es fehlen meist drei Entscheidungen, die vor dem Start zu treffen gewesen wären: ein definierter Eigentümer, eine beschriebene Grenze, ein Messplan. Diese drei Entscheide kosten wenig Zeit und sind die billigste Prüfung gegen Hype, die es überhaupt gibt.

Meine Praxisbeobachtung aus Linux-Produktionsumgebungen im DACH-Raum: Agenten tragen heute realistisch dort, wo Aufgaben wiederkehrend, gut abgegrenzt und fehlertolerant sind – im Betrieb (Routine-Diagnose, Vorfall-Vorsortierung), in der Dokumentation (Änderungsprotokolle, Runbook-Entwürfe) und im Incident-Support (Korrelation von Logs, erste Berichte). An derselben Stelle, an der ich die Betriebsrealität selbst gehosteter Agenten im Blog beschrieben habe (Self-Hosted Agenten-Betrieb, EN), liegt auch die Kernaussage: Der Betrieb ist der eigentliche Test.

Agenten-Frameworks laufen bei mehreren unserer Kunden bereits aktiv. Der Unterschied zwischen den Umgebungen ist selten die Modellwahl. Es ist die Architektur um sie herum. Das ist der Stand von 2026: keine zukünftige Technologie mehr, sondern ein Betriebswissen, das sich aufbauen lässt – Schicht für Schicht, mit den Grenzen aus Abschnitt 3.

3. Architektur zuerst

Warum Agenten keine Tools sind

Ein klassisches Tool hat einen Betriebsmodus: Es tut etwas, wenn es aufgerufen wird. Sein Verhalten ist eng, sein Fehlerzustand liegt klar – kein Aufruf, kein Ergebnis. Genau diese Eigenschaft macht Tools leicht zu sichern: Least Privilege pro Werkzeug, Audit-Trail pro Aufruf.

Ein Agent dagegen entscheidet selbst: Er wählt, welche Werkzeuge er in welcher Reihenfolge aufruft, wie oft er es versucht und was er tut, wenn ein Versuch scheitert. Damit verlagert sich das Risiko vom Werkzeug auf die Kombination aus Werkzeug, Modell und Anweisung. Drei Fragen folgen:

1. Rechte: Was darf der Agent lesen, schreiben, ausführen? Nur-Lese-Zugriff, Schreibzugriff auf definierte Systeme, Freigabe für Deployments?
2. Grenzen: Welche Systeme, Datenklassen und Netzwerkzonen liegen im Umfang – und was ist ausdrücklich ausgeschlossen?
3. Fehlerverhalten: Was passiert, wenn ein Werkzeugaufruf scheitert? Wiederholen, abbrechen, an einen Menschen eskalieren – nach welcher Regel, nach wie vielen Versuchen, mit welcher Zeitgrenze?

Das typische Fehlmuster in der Praxis: Ein Agent bekommt Zugriff, weil der erste Test gut ausfiel. Rechte, Grenzen und Fehlerverhalten landen dann nie auf einem Blatt – und werden erst beantwortet, wenn etwas schiefgegangen ist. Agenten sind deshalb keine Tools, die man installiert, sondern Systeme, denen man Bedingungen gibt.

Der agentische Stack in Schichten

Ich beschreibe agentische Stacks in vier Schichten – nicht aus Vorliebe für Architektur-Diagramme, sondern weil die Schichten unterschiedliche Lebensdauern und Zuständigkeiten haben:

Zwei Regeln folgen aus dem Schichtmodell:

• Modelle sind austauschbare Komponenten, die Zugriffsschicht ist die Investition. Modellwechsel sind normal und eingeplant; Rechte und Protokollierung müssen stabil bleiben.
• Rechte werden in der Zugriffsschicht vergeben – nie in der Orchestrierung. Die Orchestrierung entscheidet, was ein Agent tut; die Zugriffsschicht entscheidet, was er darf. Nur dort sind Rechte auch auditierbar.

Genau deshalb kommt die Architektur zuerst: Nicht, weil Orchestrierung unwichtig wäre, sondern weil die Zugriffsschicht den Rahmen vorgibt, in dem alles andere laufen kann. Wer zuerst die Orchestrierung auswählt, hat die wichtigste Entscheidung bereits delegiert.

Der Entscheidungsrahmen: Prozesse, Daten, Berechtigungen

Vor dem ersten Piloten werden drei Fragen schriftlich beantwortet:

1. Prozesse: Welche Prozesse sind Kandidaten? Meine Kriterien: wiederkehrend, gut abgegrenzt, fehlertolerant, messbar. Ein Prozess, der alle vier erfüllt, ist ein brauchbarer Pilot; alles andere wartet besser oder wird umgestaltet.
2. Daten: Welche Daten darf der Agent sehen – welche Datenklassen, über welche Systeme? Die Schutzklassifizierung Ihrer Daten ist an dieser Stelle ein Architektur-Input, kein Hindernis, das es zu umschiffen gilt: Sie bestimmt, welche Modelle infrage kommen und wie die Zugriffsschicht aussehen muss.
3. Berechtigungen: Welche Rechte braucht der Agent pro Aufgabe? Least Privilege, je Fall vergeben, entziehbar und ablaufend.

Dazu kommt eine vierte Frage, die in Piloten oft fehlt und am Ende über den Fortbestand entscheidet: Zuständigkeiten. Wem gehört der Agent nach dem Piloten – wer übernimmt die Überwachung, wer darf die Rechte ändern, wer entscheidet über die Erweiterung? Piloten ohne Eigentümer wechseln von der Begeisterung direkt zur Stilllegung – ein Verlauf, der sich im Nachhinein schwer erklären lässt.

Aus diesem Rahmen entsteht die Roadmap: Pilot in kontrollierten Grenzen, gemessene Erweiterung, produktiver Betrieb. Das ist die Arbeitsweise, die Infrastruktur-Teams kennen: erst der Plan, dann das Installieren. Sie unterscheidet Piloten, die zu mehrjährigen Roadmaps entwickelt werden, von Piloten, die nach drei Monaten still abgeschaltet werden.

4. Lokale und souveräne LLMs

Datenhoheit und Betriebsrealität

Die Frage „lokal oder Cloud?“ wird oft als Glaubensfrage geführt. Es ist eine Architekturentscheidung mit zwei klaren Hebeln.

Datenhoheit: Was lokal verarbeitet wird, verlässt die Organisation nicht. Für DSGVO-sensible Umgebungen ist das ein Architekturargument der ersten Ordnung – der Datenpfad ist kurz, und Zugriffe bleiben im eigenen Kontrollbereich. Wichtig ist der zweite Satz: Lokal ist damit noch kein Datenschutz-Feature. Auch ein lokaler Stack schreibt Protokolle, baut Kontexte auf und braucht Zugriffsschichten – die Architektur entscheidet, ob man diese Fläche klein hält oder nicht. Was lokal entfällt, ist der Anbieterteil des Datenwegs: keine Auslieferung von Eingaben und Kontexten an ein externes Modell-Angebot, weniger Dienstleister im Berichtspfad. Das ersetzt keine rechtliche Bewertung, aber es verkleinert die Fläche, die man erklären, kontrollieren und auditieren muss.

Betriebsrealität: Lokale Modelle laufen nicht selbst. Sie brauchen laufenden Betrieb: Hardware, Modell-Updates, Kapazitätsplanung und ein bewusst gewähltes Kontextfenster. Das ist vertrautes Handwerk: Modelle sind Versionen wie andere Software auch – der Wechsel folgt denselben Mustern wie bei anderen Updates (getestet, protokolliert, reversibel), und Kapazität und Monitoring gehören ohnehin zum Betrieb. Nach der einmaligen Hardware-Anschaffung wird die Kostenlogik planbar: Der Stack skaliert nicht mit der Nutzung, sondern mit der Dimensionierung. Beispielrechnung (explizit gekennzeichnet): Die 8B-Variante von Metas Llama 3.1 hat laut Model Card ein Kontextfenster von 128k; die quantisierte Q4_K_M-Fassung (Ollama-Bibliothek) liegt bei rund 4,9 GB Modellgröße. Auf einem kleinen Server ist ein solches Modell lauffähig – in der Praxis kalkuliert man zusätzlich Hauptspeicher für Kontext, Zwischenspeicher und Betrieb, realistischerweise deutlich mehr als die nackte Modellgröße. Konkrete Kosten-, Hardware- und Leistungszahlen hängen von Aufgabe, Hardware und Modellwahl ab; für Zahlen aus dem eigenen Betrieb verweise ich auf meinen Blog-Post zu lokalen LLMs auf kleiner Server-Umgebung (Lokale LLMs, EN).

Auch die Qualitätsrelation gehört zur Betriebsrealität: Spitzmodelle in der Cloud sind leistungsfähiger als kompakte lokale Modelle. Die ehrliche Frage ist deshalb nicht „Was ist das beste Modell?“, sondern „Für welche Aufgaben genügt ein lokales Modell?“ – und da fällt in meiner Praxis mehr heraus, als man bei reinen Benchmarks erwartet: Zusammenfassungen, Auswertungen, Dokumentation, Vorfall-Vorsortierung sind wiederkehrende Aufgabentypen, für die kompakte Modelle oft genug tragen. Zwischen beiden Polen liegt der große Bereich dazwischen, für den beide Wege funktioniert haben – und die Grenze verschiebt sich mit jedem Modell-Update ein Stück nach oben.

Der praktische Mix

Das Ergebnis ist fast immer ein Mix – lokaler Betrieb und kontrollierte Cloud statt Entweder-Oder:

• Lokal: Aufgaben mit hohem Volumen und einfachem Anspruch, sensible Daten, planbare Kosten, Verfügbarkeit unabhängig vom Standort eines Cloud-Anbieters.
• Kontrollierte Cloud: komplexe Aufgaben mit Qualitätsanspruch, nicht-sensible Daten – mit definierten Routen, Protokollierung und bewussten Anforderungen an Datenpfad und Anbieterstandort.

Beide Wege sind legitim; religiös geführte Positionen helfen nicht. Der Mix ergibt sich pro Aufgabe aus dem Entscheidungsrahmen in Abschnitt 3 – nicht als einmalige Grundkonfiguration, sondern als laufende Abwägung mit geprüften Zahlen. Für DSGVO-sensible Unternehmen in Mitteleuropa ist dieser Mix weniger Kompromiss als bewusste Architektur: lokal, wo Datenhoheit und planbare Kosten wichtiger sind; kontrollierte Cloud, wo Modellqualität den Unterschied macht.

5. Governance und Sicherheit

Rechte klein halten, Handlungen nachvollziehen

Agenten bekommen Rechte, sobald sie anfangen zu arbeiten. Governance beginnt deshalb nicht mit dem Betrieb, sondern mit der Berechtigungsvergabe:

• Least Privilege pro Agent: getrennte Zugangsprofile je Agent, keine geteilten Admin-Zugänge, Rechte gebunden an die konkrete Aufgabe – nicht an die Person, die ihn eingerichtet hat.
• Nachvollziehbares Logging: jeder Werkzeugaufruf protokolliert – welcher Agent, welche Aktion, welche Daten, welches Ergebnis. Dieses Protokoll ist die Rohfassung für Debugging, Audit und jede Meldung im Vorfallsszenario.
• Klare Kontrollebene: unumkehrbare Aktionen laufen über bestätigte Schritte; jeder Agenten-Prozess ist stoppbar, Rechte sind entziehbar, und es gibt geübte Notfallprozeduren.
• Geheimnisse: Zugangsdaten gehören nicht in den Prompt-Kontext; Zugänge werden getrennt von Agenten-Kontexten verwaltet und nur über definierte Wege vergeben.
• Monitoring: Agenten-Prozesse laufen unter demselben Monitoring wie andere Systeme auch – Metriken für Laufzeit, Fehlerquote und Werkzeugaufrufe, Alarme an dieselben Kanäle. Ein Agent, den niemand beobachtet, ist kein Betrieb, sondern ein Experiment.

Governance klingt nach Verwaltung. In der Praxis sind es drei Fragen: Wer darf was? Wer kann es später erklären? Und wie kann ein laufender Agenten-Prozess in Minuten gestoppt werden? Wenn diese Fragen schriftlich beantwortet sind, sinkt auch die Hemmschwelle im Team – Agenten werden betrieben wie andere Systeme auch.

Dazu gehört eine letzte Konsequenz, die leicht übersehen wird: Auch die Vergabe und Entzug von Rechten ist protokolliert. Wer wann welchem Agenten welche Berechtigung erteilt hat, ist spätestens dann relevant, wenn jemand das Team wechselt oder ein Vorfall rückwirkend aufzuklären ist. Für bestehende Umgebungen ist das nichts Neues: Es ist dieselbe Disziplin, die Systemkonten und Zertifikate ohnehin verlangen – Agenten erweitern sie, und ersetzen sie nicht.

NIS2 als Architekturprinzip – keine Rechtsberatung

Vorab klar: Ich bin kein Anwalt, und nichts in diesem Abschnitt ist Rechtsberatung. Aber die NIS-2-Richtlinie lässt sich als Architekturprinzip lesen, und sie trifft Agenten-Stacks unmittelbar.

Das Faktengerüst aus dem offiziellen Text der Richtlinie (EU) 2022/2555: Die Mitgliedstaaten mussten die Richtlinie bis zum 17. Oktober 2024 in nationales Recht überführen und wenden deren Vorgaben ab dem 18. Oktober 2024 an (Artikel 41). Für wesentliche Vorfälle gilt die Meldekette aus Artikel 23: eine Frühwarnung unverzüglich und in jedem Fall innerhalb von 24 Stunden nach Kenntnis, die Meldung innerhalb von 72 Stunden und ein Endbericht binnen eines Monats nach der Meldung.

Diese Fristen sind eine Betriebs-, nicht eine Formularfrage. Innerhalb von 24 oder 72 Stunden lässt sich nur melden, was man über die eigenen Systeme weiß: Wer war beteiligt, was wurde geändert, welche Daten waren betroffen. Ein Agenten-Stack, dessen Handlungen nicht protokolliert werden, erzeugt genau die Lücke, die die Meldungsfristen praktisch unausfüllbar macht. Deshalb kommt Governance vor dem Pilotenstart – nicht irgendwann danach. Für Agenten konkret heißt das in Notfallprozeduren: stoppen können (Kill-Switch), Rechte sofort entziehen können, Logs und Snapshots unmittelbar sichern können – dieselben drei Schritte, die Sie ohnehin für Vorfallsmeldungen üben, erweitert um den Agenten-Bestandteil.

Als Ergänzung im Regulierungsfeld: Der überwiegende Teil der EU-KI-Verordnung (Verordnung (EU) 2024/1689) gilt seit dem 2. August 2026, darunter die Transparenz-Anforderungen nach Artikel 50 (Zeitleiste: Europäische Kommission, AI Act Service Desk, abgerufen 2026-11-01). Transparenz und Nachvollziehbarkeit sind damit keine wünschenswerten Eigenschaften, sondern Entwurfsanforderungen – auch das spricht für dasselbe Prinzip: Architektur vor Betriebsaufnahme.

Konkrete NIS2-Fragen zu Technik, Meldefristen und Betrieb habe ich separat aufbereitet (NIS2-Blog-Post, DE). Für die Bewertung Ihrer Pflichten nehmen Sie rechtliche Beratung zum Einzelfall – mein Teil ist die Architektur, die diese Vorgaben betriebsfähig macht.

6. Vom Paper zur Umsetzung: Drei Wege

Ein Paper bleibt Papier, bis es auf Ihre Umgebung geprüft wird. Dafür gibt es drei definierte Wege – einzeln buchbar, aber als Stufen gedacht. Sinnvoll wird die Reihenfolge durch das, was jeder Schritt voraussetzt:

Wann welcher Weg passt: Wenn unklar ist, ob und wo Agenten Ihnen nützen, beginnt es mit dem Audit. Wenn die Richtung fehlt oder die Entscheidung auf Tech-Lead- oder Geschäftsführungsebene fällt, beginnen die Vision-Sessions. Sind die Entscheidungen durch und soll gebaut werden, folgt der Stack-Aufbau. Alle drei Wege münden in dasselbe Ziel: eine Umgebung, in der Agenten unter Regeln arbeiten – dokumentiert, mit begrenzten Rechten und mit einem Betrieb, den man auch in Jahren noch erklären kann.

7. Schluss und Kontakt

Agenten werden Teil von Infrastrukturen. Die offene Frage ist nicht, ob – sondern ob unter Architektur oder neben ihr. Erst die Architektur ist keine Verzögerung; sie ist der Weg, wie Agenten kontrolliert in den Betrieb gehen und dort bleiben können. Und dafür ist nichts mit Nullanfang verbunden: Automatisierung, Monitoring und Dokumentation, die bestehende Umgebungen längst mitbringen, sind genau das Fundament, auf dem ein agentischer Stack aufbaut.

Wenn Sie prüfen wollen, wo Agenten in Ihrer Umgebung realistisch tragen: Erzählen Sie mir in einem kostenlosen 30-minütigen Kennenlern-Gespräch (per Video-Call oder Telefon), woran Ihr Unternehmen arbeitet – ich sage offen, ob Agenten dafür der richtige Weg sind.