Warum KI Architekturmuster noch wichtiger macht

Von Gari Ciodaro, Co-Founder und CTO der Recall Space GmbH‍

Agentische Workflows sind wertvoll, weil sie sich anpassen können. Architekturmuster helfen uns, diese Flexibilität dort einzusetzen, wo sie hingehört. So können wir einen Agenten verbessern, ohne alles um ihn herum neu gestalten zu müssen. LangChain und LangGraph machen diesen Ansatz praktisch umsetzbar.

Ein Kunde bittet um eine Rückerstattung. Ein Agent liest die Nachricht, die Anwendung prüft die Bestellung und liefert eine Entscheidung zurück. Die Demo funktioniert.

Dann ändert sich das Modell. Ein neues Tool kommt hinzu. Die Rückerstattungsfrist wird von 30 auf 60 Tage verlängert. Plötzlich sind Änderungen daran, wie die Anwendung Sprache versteht, eng mit Änderungen daran verknüpft, was das Unternehmen erlaubt.

KI macht die erste Version einfach. Gleichzeitig sorgt sie dafür, dass Veränderungen zum Dauerzustand werden: Modelle werden ausgetauscht, Prompts angepasst, Tools ergänzt. Und jede Überarbeitung verändert Verhaltensweisen, die niemand ausdrücklich programmiert hat. Je schneller sich die einzelnen Teile verändern, desto wertvoller werden die Grenzen zwischen ihnen. Deshalb macht KI Architekturmuster wichtiger, nicht überflüssig. Die entscheidende Frage lautet: Wie viel vom System muss sich mitverändern, wenn sich ein einzelner Bestandteil ändert?

Mit den Anforderungen des Unternehmens beginnen

Betrachten wir eine einfache Anwendung zur Prüfung von Rückerstattungsanfragen. Sie hat zwei unterschiedliche Aufgaben:

• Die Anfrage verstehen. Möchte der Kunde eine vollständige Rückerstattung, etwas anderes oder ist die Anfrage unklar? Welche Formulierungen stützen diese Interpretation?
• Die Richtlinie anwenden. Ist die Anfrage auf Grundlage verlässlicher Bestelldaten berechtigt? In diesem Beispiel ist eine bezahlte Bestellung bis zu einem Alter von 30 Tagen erstattungsfähig.

Die erste Aufgabe profitiert von einem Agenten. Kunden drücken dasselbe Anliegen auf unterschiedliche Weise aus. Möglicherweise muss der Agent zunächst Begriffe in einem Glossar nachschlagen, bevor er die Nachricht interpretieren kann. Die zweite Aufgabe folgt einer Regel, für die das Unternehmen verantwortlich ist. Unklare Anfragen werden zur Prüfung weitergeleitet; die tatsächliche Auszahlung ist eine separate Verantwortung.

Durch diese Trennung entsteht eine fachliche Grenze, noch bevor wir uns für ein Framework entscheiden.

Dem Agenten klare Grenzen geben

Die hexagonale Architektur gibt dieser Grenze eine konkrete Form. Die Anwendung definiert einen Port, also eine Schnittstelle mit dem Auftrag: „Interpretiere diese Anfrage und liefere die Absicht mit einem unterstützenden Beleg zurück – oder teile mit, dass die Interpretation nicht möglich war.“ Ein Adapter implementiert diese Schnittstelle mithilfe eines agentischen Workflows.

Der Adapter übersetzt die Ausgabe des Agenten in die Begriffe der Anwendung. Prompts, Tool-Aufrufe und Modellantworten bleiben innerhalb dieser Funktionalität. Die Rückerstattungsrichtlinie erhält eine Interpretation, mit der sie arbeiten kann.

from typing import Protocol

class RequestInterpreter(Protocol):
   async def interpret(
       self, message: str
   ) -> Request | InterpretationFailure: ...

Request enthält die erkannte Absicht und ein stützendes Zitat; InterpretationFailure macht ein Scheitern der Interpretation ausdrücklich kenntlich. Diese Python-Ausschnitte lassen unterstützende Typen und die Einrichtung bewusst weg, um den Fokus auf die Systemgrenzen zu legen.

So lässt sich das Prinzip von hoher Kohäsion und geringer Kopplung gut veranschaulichen: Die Aufgaben rund um die Interpretation bleiben zusammen, während ihre Implementierungsdetails von der Richtlinie ferngehalten werden. Der agentische Workflow wird zu einer Einheit, die Variabilität auffängt.

Die verlockende Alternative besteht darin, auf Architektur zu verzichten und einfach per „Vibe Coding“ Schritte miteinander zu verbinden, funktionierende Lösungen zu übernehmen und weiter zu iterieren. Doch ein Graph aus miteinander verbundenen Schritten legt nicht automatisch fest, wer für die Geschäftsregeln verantwortlich ist. Die hexagonale Architektur regelt Abhängigkeiten; der Graph beschreibt die Ausführung. Beide ergänzen sich.

Es hilft außerdem, den Zielkonflikt ausdrücklich zu benennen. Das erste Gesetz der Softwarearchitektur von Richards und Ford besagt, dass Softwarearchitektur immer aus Abwägungen besteht. Anpassungsfähigkeit ist ebenso ein Architekturmerkmal wie Testbarkeit oder Auditierbarkeit – und sie ist nicht kostenlos. Ein agentischer Workflow gewinnt Anpassungsfähigkeit auf Kosten der Vorhersagbarkeit. Die Grenze beseitigt diesen Zielkonflikt nicht. Sie legt fest, wo wir welche Seite des Kompromisses in Kauf nehmen. Anpassungsfähigkeit liegt im Adapter, wo sie einen Mehrwert schafft. Deterministisches Verhalten bleibt in der Richtlinie, wo das Unternehmen darauf angewiesen ist.

Wo LangChain und LangGraph ins Spiel kommen

LangChain stellt die adaptive Funktionalität bereit. Die create_agent-API bietet die Schleife aus Modell- und Tool-Aufrufen. In diesem Beispiel kann der Agent bei Bedarf ein schreibgeschütztes Support-Glossar heranziehen. Structured Output liefert dem Adapter eine erkannte Absicht und ein stützendes Zitat zur Validierung. Über Middleware lässt sich zudem die Anzahl der Modell- und Tool-Aufrufe begrenzen. So können wir auf diesen Funktionen aufbauen, ohne eine eigene Agenten-Laufzeitumgebung entwickeln zu müssen.

agent = create_agent(
   model=model,
   tools=[support_glossary],
   response_format=IntentOutput,
)

class LangChainRequestInterpreter:
   def __init__(self, agent):
       self.agent = agent

   async def interpret(self, message):
       result = await self.agent.ainvoke({
           "messages": [
               {"role": "user", "content": message}
           ]
       })
       output = result["structured_response"]
       return to_domain(output, message)

IntentOutput ist das Ausgabeschema des Agenten. Die Hilfsfunktion to_domain im Adapter validiert das Zitat und gibt die anwendungseigenen Typen zurück. Prompt-Konfiguration, Fehlerbehandlung und Aufruflimits sind hier der Übersichtlichkeit halber ausgelassen.

LangGraph verbindet diese Funktionalität mit dem Geschäftsprozess. Ein StateGraph verknüpft Interpretation, Richtlinienprüfung und manuelle Überprüfung. Wenn die Interpretation unklar ist, kann der Workflow über einen Interrupt mit einem Checkpointer pausiert werden. Eine Person kann die Interpretation korrigieren und den Workflow anschließend fortsetzen. Danach wird dieselbe Richtlinie erneut angewendet.

graph = StateGraph(TriageState)
graph.add_node("interpret", interpret_request)
graph.add_node("policy", apply_policy)
graph.add_node("review", review_request)
graph.add_edge(START, "interpret")
graph.add_edge("interpret", "policy")
graph.add_conditional_edges("policy", next_step)
graph.add_edge("review", "policy")
workflow = graph.compile(checkpointer=checkpointer)

Die Knoten rufen den Interpreter auf, wenden die Richtlinie an oder pausieren für eine manuelle Prüfung. next_step leitet einen ungelösten Fall einmalig an die Prüfung weiter. Nach der Korrektur durch die prüfende Person entscheidet die Richtlinie erneut; diese Entscheidung ist dann endgültig. Ein weiterhin ungeklärter Fall verlässt den Workflow und wird manuell bearbeitet.

LangChain-Agenten basieren selbst auf LangGraph. Diese gemeinsame Grundlage ermöglicht es uns, einen dynamischen Agenten in einen expliziter definierten Workflow einzubetten und für jede Verantwortung das passende Maß an Flexibilität zu wählen.

Die Systemgrenze erfordert dennoch technisches Urteilsvermögen. Ein formal gültiges Ausgabeformat beweist nicht, dass eine Interpretation richtig ist. In diesem Beispiel prüft der Adapter das stützende Zitat, fehlgeschlagene Interpretationen werden zur Überprüfung weitergeleitet und der Agent verfügt über kein Tool zum Auslösen von Zahlungen.

Der entscheidende Test: Was passiert, wenn sich etwas ändert?

Verlängern wir nun die Rückerstattungsfrist auf 60 Tage. Diese Änderung gehört in die Richtlinie und ihre Tests. Wenn wir dagegen ein neues Modell ausprobieren oder das Glossar-Tool verbessern, betrifft das die Interpretationsfunktion und ihre Evaluierungen. Der Rest der Anwendung kann weiterhin dieselbe Schnittstelle verwenden.

Manche Änderungen überschreiten diese Grenze. Wenn wir Teilrückerstattungen unterstützen möchten, entsteht ein neues fachliches Konzept. Deshalb müssen sich möglicherweise sowohl die Schnittstelle als auch die Richtlinie weiterentwickeln. Eine gute Grenze macht diese Auswirkungen sichtbar.

Genau darin liegt der praktische Wert von Architekturmustern in KI-Systemen: Änderungen wirken sich nur auf einen begrenzten Teil des Systems aus, Verantwortlichkeiten sind klarer und der Agent kann unabhängig verbessert werden. Je häufiger sich die KI-Komponenten ändern, desto häufiger machen sich diese Grenzen bezahlt. Derselbe Ansatz lässt sich auch auf die Interpretation einer Lieferantenbestätigung oder die Klassifizierung eines Supportfalls übertragen.

Gebt agentischen Workflows Raum, sich anzupassen. Nutzt Architektur, damit diese Anpassungsfähigkeit dem gesamten System zugutekommt.

Architektur-Glossar

• Domäne (Domain) – Die fachlichen Konzepte und Regeln, die eine Software abbildet: hier Kundenanfragen, Bestellungen und die Berechtigung auf Rückerstattung.
• Hexagonale Architektur – Ein Architekturansatz, der die Geschäftslogik von Technologieentscheidungen unabhängig hält, indem er sie über Ports und Adapter mit konkreten Implementierungen verbindet.
• Port / Vertrag (Contract) – Eine Schnittstelle, die der Anwendung gehört und die eine Funktionalität sowie ihre erwarteten Eingaben und Ergebnisse einschließlich möglicher Fehler definiert.
• Adapter – Die Implementierung eines Ports, die zwischen den Konzepten der Anwendung und einer konkreten Technologie wie einem LangChain-Agenten übersetzt.
• Kohäsion (Cohesion) – Beschreibt, wie eng die Aufgaben einer Komponente zusammengehören. Hohe Kohäsion bündelt die Interpretation einer Anfrage innerhalb einer Funktionalität.
• Kopplung (Coupling) – Beschreibt, wie stark Komponenten von den Details anderer Komponenten abhängen. Geringe Kopplung ermöglicht Änderungen am Agenten, während die Richtlinie dieselbe Schnittstelle weiterverwendet.
• Architekturmerkmal (Architecture Characteristic) – Eine Qualität, die ein System unterstützen muss, etwa Anpassungsfähigkeit, Testbarkeit oder Auditierbarkeit. Verbesserungen in einem Bereich gehen meist zulasten eines anderen; die Abwägungen werden bewusst getroffen statt vermieden.
• Änderungsradius (Blast Radius) – Beschreibt, wie weit sich die Auswirkungen einer Änderung oder eines Fehlers ausbreiten können. Klare Grenzen helfen, diese Auswirkungen einzudämmen.

Quellen

• Hexagonal architecture, Alistair Cockburn
• Structured design, W. P. Stevens, G. J. Myers und L. L. Constantine, IBM Systems Journal, 1974
• Fundamentals of Software Architecture: A Modern Engineering Approach, Mark Richards und Neal Ford, O’Reilly Media
• Agents, LangChain-Dokumentation
• Structured output, LangChain-Dokumentation
• Built-in middleware, LangChain-Dokumentation
• Workflows and agents, LangGraph-Dokumentation
• Interrupts, LangGraph-Dokumentation

‍