KI-Agenten, die Arbeit abnehmen

Chatbot versus Agent: der Unterschied in der Praxis

Ein Chatbot reagiert. Du stellst eine Frage, du bekommst eine Antwort. Der Chatbot hat keine Erinnerung an vorherige Nachrichten, keinen Zugriff auf externe Systeme und keine Moglichkeit, etwas ausserhalb des Gesprachs zu tun. Das ist nutzlich fur Kundendienst, FAQ-Bearbeitung und Informationsvermittlung. Aber ein Chatbot fuhrt keine Aufgaben aus.

Ein KI-Agent handelt. Du gibst einen Auftrag als Ausgangspunkt. Der Agent analysiert den Auftrag, bestimmt welche Schritte notwendig sind, fuhrt diese Schritte uber Tool-Calls aus und pruft, ob das Ergebnis korrekt ist, bevor er zum nachsten Schritt ubergeht. Wenn etwas fehlschlagt, erholt sich der Agent selbst oder fragt nach menschlichem Input. Der Prozess stoppt erst, wenn die Aufgabe abgeschlossen ist oder der Agent angibt, nicht weitermachen zu konnen.

Der Unterschied ist architektonisch. Ein Chatbot ist ein Input-Output-System. Ein Agent ist eine Schleife: Plan, Aktion, Beobachtung, Korrektur. Diese Schleife kann mehrere Zyklen fur einen einzigen Auftrag durchlaufen. Das macht Agenten geeignet fur Aufgaben, die zu komplex fur ein Skript, aber zu kontextabhangig fur eine feste Automatisierung sind.

Wann ein Agent die richtige Wahl ist

Nicht jede Aufgabe braucht einen Agenten. Aber fur eine spezifische Kategorie von Aufgaben ist ein Agent die effektivste Losung:

• ▸Mehrstufige Aufgaben, bei denen jeder Schritt vom Ergebnis des vorherigen Schritts abhangt. Ein Skript kann damit nicht gut umgehen, weil die Verzweigungen zu komplex sind.
• ▸Aufgaben, die kontextabhangige Entscheidungen erfordern. Der Agent muss verstehen, was die richtige Aktion ist, basierend auf der spezifischen Situation, nicht auf einer festen Regel.
• ▸Aufgaben, bei denen mehrere Tools kombiniert werden mussen. Zum Beispiel: Daten aus einem System abrufen, analysieren, uber eine externe API anreichern und das Ergebnis zuruckschreiben.
• ▸Aufgaben, bei denen die Fehlerbehandlung selbst Denkvermogen erfordert. Wenn ein Tool ein unerwartetes Ergebnis zuruckgibt, muss der Agent entscheiden, ob das akzeptabel ist oder ob er die Aufgabe anders angehen soll.
• ▸Aufgaben, bei denen der Output vor der Verwendung validiert werden muss. Der Agent kann sein eigenes Ergebnis beurteilen und es erneut versuchen, wenn es nicht den Anforderungen entspricht.

Das gemeinsame Merkmal ist Variabilitat. Wenn die Aufgabe immer auf genau die gleiche Weise verlauft, ist ein Skript oder n8n-Workflow effizienter. Sobald die Aufgabe Variationen aufweist, die menschliches Denken erfordern, ist ein Agent die bessere Wahl.

Wann du keinen Agenten brauchst

Einen Agenten zu bauen ist teurer als ein Skript zu schreiben oder einen Workflow in n8n zu konfigurieren. Das ist kein Problem, wenn die Aufgabe es erfordert, aber es ist ein Grund, kritisch zu sein:

• ▸Vollstandig deterministische Aufgaben: wenn die Schritte immer identisch sind und der Input strukturiert ist, ist ein Skript oder Workflow schneller, gunstiger und zuverlassiger als ein Agent.
• ▸Einzelne API-Calls: wenn es darauf hinauslauft, Daten abzurufen und zuruckzuschreiben ohne Entscheidungen dazwischen, baue ich lieber eine direkte Integration oder einen n8n-Node.
• ▸Regelbasierte Logik: wenn die Entscheidungen vollstandig in Wenn-Dann-Regeln ohne KI-Reasoning ausgedruckt werden konnen, hat ein Agent keinen Mehrwert.
• ▸Situationen mit null Toleranz fur Variation: fur Finanztransaktionen oder medizinische Daten, bei denen jede Abweichung inakzeptabel ist, ist ein Agent nicht die richtige Wahl. Deterministischer Code ist sicherer.
• ▸Wenn das Budget nicht zur Komplexitat passt: Agenten verbrauchen mehr Tokens pro Aufgabe als ein Chatbot. Bei grossen Volumina mussen die Kosten abgewogen werden.

Das sage ich auch in einem Erstgesprach, wenn es zutrifft. Wenn eine einfachere Losung besser passt, schlage ich diese vor. Das ist letztendlich besser fur die Zusammenarbeit.

Architektur: wie ich einen Agenten baue

Der Kern jedes Agenten, den ich baue, besteht aus drei Schichten:

• ▸Reasoning-Engine: Claude (via Anthropic API) oder OpenAIs neuestes Modell (via OpenAI API) als Modell, das plant, entscheidet und Text generiert. Die Wahl hangt von der Aufgabe, dem Budget und dem erforderlichen Kontextfenster ab.
• ▸Tool-Schicht via MCP-Server: der Agent hat Zugriff auf eine Reihe von Tools, die ich explizit definiere. Ein Tool kann eine Datenbankabfrage, ein REST-API-Call, eine Dateibearbeitung oder ein externer Dienst sein. Jedes Tool hat ein Schema mit Parametern und einer Beschreibung. Der Agent entscheidet selbst, welches Tool relevant ist.
• ▸State-Schicht in Postgres: der Agent speichert seinen aktuellen Aufgabenstatus in einer Postgres-Tabelle. Jeder Schritt wird mit Timestamp, Tool-Name, Parametern, Ergebnis und eventuellen Fehlern protokolliert. So ist die vollstandige Ausfuhrung rekonstruierbar.
• ▸Audit-Log: zusatzlich zur State-Tabelle schreibe ich alle Tool-Calls in ein separates Audit-Log. Dieses Log ist schreibgeschutzt und unveranderlich. Gedacht fur Debugging, Compliance und Post-mortem-Analyse.
• ▸Orchestrator: der Anwendungscode, der die Schleife steuert. Er sendet den Auftrag an das Modell, verarbeitet die Tool-Calls, gibt Ergebnisse zuruck an das Modell und bestimmt, wann die Aufgabe abgeschlossen oder gestoppt werden muss.

Der Orchestrator ist bewusst einfach gehalten. Komplexe Orchestrierungs-Frameworks fugen Abstraktionen hinzu, die Debugging schwieriger machen. Ich schreibe den Orchestrator selbst in TypeScript oder Python, je nach Kontext.

Guardrails: wie ich den Agenten kontrolliere

Ein Agent ohne Grenzen ist ein Agent, dem du nicht vertrauen kannst. Jeder Agent, den ich baue, hat explizite Einschrankungen:

• ▸Max Iterations: der Agent stoppt nach einer konfigurierbaren maximalen Anzahl von Schritten, auch wenn die Aufgabe nicht abgeschlossen ist. Das verhindert unendliche Schleifen bei unerwartetem Input oder Modellfehlern.
• ▸Tool-Whitelist: der Agent hat nur Zugriff auf explizit definierte Tools. Keine generische Code-Ausfuhrung, kein Zugriff auf Systeme ausserhalb des Umfangs. Jedes Tool steht in der Konfiguration.
• ▸Human-Approval bei kritischen Aktionen: Aktionen mit unumkehrbaren Konsequenzen, wie das Uberschreiben von Dateien, das Loschen von Daten oder das Senden externer Nachrichten, erfordern einen menschlichen Genehmigungsschritt. Der Agent pausiert und wartet.
• ▸Rollback-Transaktionen: Schreibaktionen in eine Datenbank laufen uber Transaktionen. Wenn der Agent auf halbem Weg einen Fehler macht, wird die gesamte Operation zuruckgerollt. Keine teilweise geanderten Daten.
• ▸Parameter-Validierung pro Tool: jeder Tool-Call wird vor der Ausfuhrung validiert. Falsche Parameter werden mit einer klaren Fehlermeldung abgelehnt, die der Agent interpretieren kann.
• ▸Vertrauensschwelle: fur Aufgaben, bei denen der Agent eine Beurteilung vornimmt, konfiguriere ich einen minimalen Vertrauensschwellenwert. Unterhalb dieser Schwelle fragt der Agent nach menschlichem Input.

Guardrails sind kein Nachgedanke. Sie sind der Grund, warum du einen Agenten bei echten Aufgaben einsetzen kannst, ohne standig zuzuschauen.

Was ich nicht baue

Es gibt bewusste Grenzen bei dem, was ich baue:

• ▸Keine Agenten ohne Logging. Ohne Audit-Trail gibt es keine Moglichkeit zu uberprufeen, was der Agent getan hat. Ich liefere immer ein vollstandig protokolliertes System.
• ▸Keine Agenten mit uneingeschranktem Tool-Zugriff. Ein Agent mit Zugriff auf alles ist ein Sicherheitsrisiko. Die Tool-Whitelist ist immer explizit und minimal.
• ▸Keine Agenten ohne Fehlerwiederherstellung. Ein Agent, der stecken bleibt und ohne Meldung stoppt, ist nicht produktionsreif. Fehlerbehandlung und Fallback auf Human-in-the-Loop sind Standard.
• ▸Keine Agenten fur Aufgaben, bei denen deterministischer Code besser passt. Wenn ein Skript oder Workflow die Aufgabe abdeckt, ist das die bessere Wahl.
• ▸Keine Agenten ohne klare Stoppbedingung. Ein Agent muss wissen, wann er fertig ist. Ohne Stoppbedingung iteriert ein Agent weiter, bis das Token-Budget erschopft ist.

Weiterlesen