KI-Agenten in der Softwarearchitektur: Wann sich der Overhead lohnt

Der Use Case: Produktrecherche automatisieren

In einem Kundenprojekt stand ich vor folgender Aufgabe: Nutzer geben über ein Formular Produktinformationen ein. Im Hintergrund sollen diese Angaben automatisch recherchiert, angereichert, bewertet und als normalisierte JSON-Struktur zurückgegeben werden. Der Nutzer bekommt von der Verarbeitung nichts mit, für ihn ist es eine Blackbox.

Wie baue ich diese Automatisierung sinnvoll auf?

Erster Ansatz: Multi-Agenten-System mit SmolAgents

Das Prinzip eines Multi-Agenten-Systems ist schnell erklärt: Ein übergeordneter Manager-Agent verteilt Aufgaben an spezialisierte Sub-Agenten. Nur der Manager kennt die anderen Agenten. In meinem Fall gab es:

• einen Recherche-Agenten mit Zugriff auf eine Search-API,
• einen Extraktions-Agenten, der Informationen zusammenfasst, und
• einen Bewertungs-Agenten, der die Ergebnisse validiert.

Durch diese klare Aufgabenteilung vermeidet man Kontextverlust, ein häufiges Problem, wenn ein einzelnes LLM zu viele Schritte auf einmal bewältigen soll.

Beim Framework fiel meine erste Wahl auf SmolAgents von Hugging Face. Es ist leichtgewichtig, LLM-agnostisch und folgt einem Plug-and-Play-Prinzip bei Modellen und Tools. Als LLM-Backend kam die OpenAI-API zum Einsatz.

SmolAgents macht den Einstieg in ein Multi-Agenten-System angenehm einfach: Mit dem @tool-Decorator wird jede Python-Funktion zum Tool, das ein Agent nutzen kann. Der CodeAgent arbeitet in einer Think → Act → Observe-Schleife und entscheidet selbstständig, welches Tool er mit welchen Parametern aufruft.

Was gut funktioniert hat

• Semantisches Verständnis: Die Agenten konnten Aufgaben lösen, die vorher nur durch manuelle Recherche möglich waren.
• Flexibilität: Wenn eine Suchanfrage keine Treffer lieferte, formulierte der Agent sie kontextbezogen um, ganz ohne zusätzliche Programmierung.
• Schneller Aufbau: Dank SmolAgents stand ein funktionierender Prototyp in kurzer Zeit.

Wo es wehtat

Jeder Schritt des Agenten („Was ist die Anfrage?", „Welche Tools habe ich?", „Was weiß ich bereits?", „Welches Tool rufe ich auf?", „Wie bewerte ich das Ergebnis?") ist ein eigener LLM-Call. Das summiert sich: Mehr Agenten bedeuten mehr Overhead, bei Latenz und bei Kosten. Für zeitkritische Prozesse kann das zum echten Problem werden.

Die Alternative: Eine deterministische Pipeline mit gezieltem LLM-Einsatz

Im Projektverlauf zeigte sich: Nicht jeder Prozessschritt braucht die Flexibilität eines Agenten. Wenn sich ein Ablauf klar definieren lässt, ist eine deterministische Pipeline oft die bessere Wahl.

Konkret bedeutet das: Wir wissen, welche Suchanfragen bei einer bestimmten Produktkategorie funktionieren. Also bauen wir die Queries selbst, fetchen die Ergebnisse und übergeben den extrahierten Text an einen einzigen LLM-Call. Dieser weiß per Prompt, wonach er suchen und wie er die Ausgabe strukturieren soll.

Das Ergebnis: Eine saubere Architektur, normalisierte Datenstrukturen und die semantische Intelligenz des LLMs genau dort, wo sie gebraucht wird – ohne den Overhead einer Agenten-Orchestrierung.

Wann sich der Overhead lohnt und wann nicht

Die Entscheidung zwischen Agenten und Pipeline ist letztlich eine Architekturfrage. Agenten lohnen sich dort, wo Prozesse explorativ und unscharf sind, wo Suchanfragen umformuliert, Ergebnisse interpretiert und Sonderfälle abgefangen werden müssen, ohne dass man jeden Pfad vorher kennt. Sie bringen echten Mehrwert, wenn die Alternative wäre, Dutzende if-else-Zweige zu programmieren, die nie alle Fälle abdecken.

Eine Pipeline ist hingegen die richtige Wahl, wenn der Ablauf vorhersehbar ist. Feste Eingabefelder, bekannte Datenquellen, klare Extraktionsregeln: Hier sorgt ein deterministischer Prozess mit einem gezielten LLM-Call für niedrigere Latenz, geringere Kosten und einfachere Wartbarkeit.

In unserem Projekt hat am Ende die Kombination aus beidem zum besten Ergebnis geführt: Agenten für die unscharfen, explorativen Aufgaben; Pipelines für alles, was sich klar definieren ließ.

Goldene Regeln aus der Praxis

1. Datenvertrag zuerst: Definiere dein Pydantic-Modell, bevor du den ersten Agenten baust. Ohne klare Ausgabestruktur baut man ins Blaue.

2. Weniger Tools, klare Aufgaben: Jedes zusätzliche Tool ist eine neue Fehlerquelle für den Agenten. Halte den Werkzeugkasten schlank.

3. Immer messen: Latenz, Kosten, Vollständigkeit – ohne Metriken gibt es keine Entscheidungsgrundlage für oder gegen Agenten.

4. Defense in Depth: Verlasse dich nie auf eine einzige Schicht. Prompt-Guardrails, Post-Processing und Pydantic-Validierung ergeben zusammen ein robustes System.

Fazit

KI-Agenten sind kein Allheilmittel, aber dort, wo Prozesse unscharf sind, und semantisches Verständnis gefragt ist, entfalten sie echte Stärke. Der Schlüssel liegt darin, bewusst zu entscheiden, wo Agenten Mehrwert liefern und wo eine schlanke Pipeline die bessere Architektur ist.