Warum deine Software-Architektur über den Erfolg deiner KI-Agenten entscheidet

Stell dir ein volles Whiteboard vor, auf dem alles steht, was für dein Projekt zählt: Aufgaben, Regeln und Zwischenstände. Ein gängiges Bild aus meinem Alltag, wenn ich Workshops mit unseren Teams moderiere. Will ich etwas Neues notieren und die Fläche ist voll, muss ich etwas wegwischen. Und was weg ist, ist weg.

Genau so arbeitet ein KI-Agent. Sein Kontextfenster ist dieses Whiteboard: begrenzt. Alles, was er zum Lösen einer Aufgabe braucht, muss draufpassen. Was nicht draufpasst, existiert für ihn nicht.

Macht der Agent dann Fehler, halluziniert, verliert den Faden oder liefert inkonsistente Ergebnisse, ist die erste Reaktion oft: Modell wechseln oder Prompt verbessern.

Doch beides greift zu kurz. In vielen Fällen liegt das Problem tiefer – in deiner Software-Architektur.

Vielleicht denkst du für einen Architektur-Umbau haben wir weder Zeit noch Budget, und unser Bestandssystem können wir nicht einfach neu bauen. Verständlich. Musst du auch nicht. Viele der Methoden, die wir dir hier vorstellen, lassen sich schrittweise einführen. Modul für Modul, neben dem laufenden Betrieb.

Dieser Artikel zeigt dir, warum Architektur im KI-Zeitalter zur Kernkompetenz wird und welche Methoden dir helfen. Für Bestandssoftware genau wie für Neuentwicklungen.

Bevor wir über Architekturmethoden sprechen, lohnt sich ein kurzer Blick auf das technische Fundament.

KI-Agenten arbeiten nicht wie Menschen, die sich durch eine große Codebasis navigieren und dabei auf ihr Langzeitgedächtnis zurückgreifen. Sie arbeiten mit einem Context Window, einem begrenzten Arbeitsgedächtnis, das bei jeder Aufgabe neu befüllt wird.

Alles, was der Agent für eine Aufgabe wissen muss, wie der relevante Code, die Dokumentation, die Systemregeln, die Aufgabenbeschreibung, muss in dieses Fenster passen. Was nicht hineinpasst, sieht der Agent nicht.

Das klingt wie ein technisches Detail, ist aber ein Architekturprinzip.

Monolithische Dateien sind der Feind des Context Windows. Eine 3.000-Zeilen-Datei ist ein massiver Block an Rauschen. Das Modell muss Hunderte irrelevante Zeilen verarbeiten, um eine einzige Funktion zu finden.

Wie teuer das werden kann, zeigt eine erste Studie von Tony Mason (University of British Columbia / Georgia Tech) aus dem März 2026. Mason hat 857 Produktionssessions mit 54.170 API-Aufrufen ausgewertet (allerdings von einem einzelnen Power-User). Sein Ergebnis:

• 21,8 % der verarbeiteten Tokens waren struktureller Ballast: ungenutzte Tool-Definitionen, doppelte Inhalte und veraltete Ergebnisse, die immer wieder mitgeladen werden.
• Inhalte werden vielfach neu verarbeitet: Im Median wird jedes Ergebnis eines Tool-Aufrufs rund 84-mal erneut gelesen. Für jede unnötige Zeile zahlst du bei jedem Schritt aufs Neue.
• Die größte Quelle für aufgeblähten Kontext sind Datei-Inhalte, die der Agent einliest.

Den Teil des Problems, der bei den Tools liegt, kannst du nur begrenzt beeinflussen. Was der Agent lesen muss, schon. Je kleiner und klarer deine Module geschnitten sind, desto weniger Code landet im Kontext.  

Genau hier liegt dein Hebel: im Design der Software-Architektur.

Egal welche Architekturmethode du wählst, das Ziel ist immer dasselbe:

Klar definierte Grenzen → kleine, kohärente Einheiten → minimale Tokenmenge pro Aufgabe

Ein Kontext ist dann gut geschnitten, wenn er:

• eine klare Verantwortung hat,
• nach innen kohärent ist,
• nach außen stabile Schnittstellen bietet und
• ohne Umwege verständlich ist.

Der Agent muss also nicht erst andere Teile des Systems verstehen, um hier arbeiten zu können.

Das ist kein neues Prinzip. Es ist das alte Prinzip guter Softwarearchitektur (Single Responsibility, Loose Coupling, High Cohesion), jetzt mit einem konkreten, messbaren Kostenfaktor.

Es gibt keine universelle Antwort. Ob du ein bestehendes System modernisierst oder neu baust, macht einen entscheidenden Unterschied. Hier sind die wichtigsten Methoden und ihre Relevanz für KI-gestützte Entwicklung.

DDD geht auf das gleichnamige Buch von Eric Evans aus dem Jahr 2003 zurück und strukturiert Software entlang fachlicher Domänen.

Das Herzstück ist der Bounded Context: ein klar abgegrenzter Bereich, in dem ein konsistentes Fachmodell gilt.

Für KI-Agenten ist das unmittelbar wertvoll: Ein Bounded Context ist eine natürliche Tokengrenze. Der Agent weiß, wo sein Zuständigkeitsbereich beginnt und endet. Die Ubiquitous Language – eine gemeinsame, konsistente Sprache von Fachbereich und Technik reduziert Mehrdeutigkeiten im Prompt und damit Fehler.

Die Hexagonale Architektur von Alistair Cockburn hält den Domain Core, also die eigentliche Fachlogik, vollständig frei von technischen Abhängigkeiten. Datenbankzugriff, externe APIs, UI: Alles läuft über klar definierte Schnittstellen (Ports), an die du beliebige Adapter anschließen kannst.

Das Bild ist wörtlich gemeint: Der Port ist die Steckdose, eine Schnittstelle, die der Kern vorgibt („Ich brauche etwas, das Kund*innen speichern kann“). Der Adapter ist der Stecker, also die konkrete technische Umsetzung (Postgres, eine REST-API, eine Testattrappe).

Entscheidend ist die Richtung der Abhängigkeit: Der Kern kennt seine Adapter nicht, nur die Adapter kennen den Kern.

Deshalb kannst du Postgres gegen MongoDB tauschen oder eine neue API anschließen, ohne eine einzige Zeile Fachlogik anzufassen.

Für KI-Agenten bedeutet das: Weil die Technik sauber am Rand liegt, kann der Agent einen einzelnen Adapter als abgeschlossene Aufgabe schreiben oder austauschen, ohne die Domänenlogik überhaupt im Kontext zu haben. Der fachliche Kern bleibt unberührt. Nicht aus Disziplin, sondern weil die Architektur die Abhängigkeiten in eine Richtung zwingt.

Konzentrische Schichten mit einer klaren Regel: Abhängigkeiten zeigen immer nach innen, von Frameworks über Interface Adapters und Use Cases bis zu den Entities. Jede Schicht hat ihre eigene Verantwortung.

Use Cases sind für KI-Agenten besonders interessant: kleine, gut isolierte Einheiten mit klarer Ein- und Ausgabe. Ideal als atomare Aufgaben für einen Agenten.

Bei CQRS werden Lese- und Schreibpfad im Code konsequent getrennt.

Event Sourcing ergänzt das: Der Zustand des Systems wird nicht als aktueller Snapshot gespeichert, sondern als vollständige Folge von Events.

Für KI-Agenten ist das elegant: Commands sind explizite Absichten – das ideale Format für eine Aufgabe. Events sind vollständige, isolierte Fakten, die wenig Kontext brauchen, um sie zu verstehen. Read Models sind vorberechnete Sichten, aus denen der Agent nur das liest, was er gerade braucht.

Ein einziges Deployment, aber mit klar definierten, technisch durchgesetzten Modulgrenzen und stabilen Schnittstellen zwischen den Modulen.

Das ist aktuell einer der interessantesten Ansätze für Teams, die bestehende Systeme KI-tauglich machen wollen: Module sind Tokengrenzen ohne den Overhead von Microservices.

Der Agent kann Modul für Modul bearbeiten, ohne das gesamte System im Blick haben zu müssen.

Besonders gut funktioniert hier das Strangler Fig Pattern: Neue Module wachsen neben dem Altsystem und übernehmen Stück für Stück seine Aufgaben, bis das alte System abgelöst ist.

Jeder Bounded Context wird zu einem eigenständigen, unabhängig deploybaren Service. Maximale Isolation: Jeder Service ist sein eigenes Tokenfenster.

Ein neuerer Ansatz, der gerade an Relevanz gewinnt, etwa durch GitHubs Spec Kit: Spezifikationen werden zur zentralen Grundlage. Code wird aus Specs generiert oder gegen sie validiert.

Für KI-Agenten ist das konzeptionell sehr stark: Specs sind maschinenlesbare Kontextdefinitionen. Der Agent generiert Code aus der Spec, nicht aus bestehendem Code, den er erst verstehen muss. DDD liefert das Fachmodell, SDD die Implementierungsspezifikation.

Ein Beispiel aus unserem Team: [Platzhalter: ein konkretes Projekt, in dem ein Modulschnitt oder klarere Grenzen die Arbeit mit KI-Agenten verbessert haben – mit Vorher/Nachher, z. B. Tokenverbrauch, Fehlerrate oder Bearbeitungszeit.]

Interessanterweise passiert in der KI-Community gerade etwas, das die Softwareentwicklung in den 2000er- und 2010er-Jahren schon einmal durchlebt hat: Entwickler*innen, die MCP-Server für KI-Agenten bauen, erfinden Bounded Contexts und Anti-Corruption Layers neu.

Oft, ohne auf das zurückzugreifen, was DDD dafür längst bietet.

Dabei passieren ähnliche Fehler wie bei der ersten Microservices-Welle ab 2014: Der Code wird aufgeteilt, nicht das mentale Modell.

Die Erkenntnis: Es geht nicht darum, welche Methode du wählst. Es geht darum, dass du überhaupt eine wählst und sie konsequent durchhältst.

Und die Fachlichkeit sollte für Menschen immer eindeutig ablesbar bleiben.

Für dein Entwicklungsteam heißt das konkret:

• Bestehende Software: Fang damit an, die größten Kontextbrüche zu finden. Wo gibt es 3.000-Zeilen-Dateien, zirkuläre Abhängigkeiten, Module ohne klare Verantwortung? Das sind die Stellen, an denen KI-Agenten heute scheitern.
• Neue Software: Modelliere die Domäne, bevor du die Technik wählst. Ein sauber geschnittener Bounded Context kostet einmal Aufwand und zahlt sich bei jedem KI-Einsatz aus.

Unabhängig davon, ob es eine bestehende oder neue Software ist, gilt: Dokumentation ist kein Nice-to-have. Wenn ein Agent erst ein ganzes Modul analysieren muss, um zu verstehen, was es tut, ist das System schlecht geschnitten.

KI-Agenten werden in den nächsten Jahren ein normaler Teil der Softwareentwicklung sein. Ob als Entwicklungsassistenten, als Testautomatisierer oder als Codegeneratoren. Wenn du sie effizient einsetzen willst, wirst du merken: Das Modell ist selten der Flaschenhals. Die Architektur ist es.

Die gute Nachricht: Du musst dafür nicht alles neu bauen. Ein erster sauber geschnittener Kontext bringt schon messbar weniger Tokens, weniger Fehler und schnellere Agenten.

Am Ende gilt: Schlechte Strukturen multiplizieren sich mit KI. Gute Strukturen auch.