Was ist ein AI-Agent? ReAct, Tool-Use und Production-Patterns Mai 2026

Was ist ein AI-Agent?

Ein AI-Agent ist ein Software-System, in dem ein Sprachmodell die Kontrolle über den Ablauf hat. Das Modell entscheidet nicht nur, was es antwortet – es entscheidet, welche Werkzeuge es aufruft, in welcher Reihenfolge, wann genug Information vorliegt, und wann eine Aufgabe abgeschlossen ist. Klassische Software ist umgekehrt: Code steuert, Modell antwortet. Beim Agent steuert das Modell, Code stellt Werkzeuge bereit.

Der Begriff hat sich seit Mitte 2023 etabliert, mit dem ReAct-Paper (Yao et al., 2022) als theoretischem Fundament. ReAct steht für "Reasoning + Acting" – das Modell wechselt zwischen Denken (Reasoning) und Handeln (Acting) über Tool-Aufrufe. 2024 wurde das Pattern produktreif durch native Tool-Use-Unterstützung in den grossen Anbietern: Anthropic Claude Tool Use (Mai 2024), OpenAI Function Calling und Assistants API, Google Gemini Function Calling, Mistral Tool Use.

Mai 2026 ist die Agent-Landschaft strukturiert: einfache Tool-Use-Flows mit den Provider-SDKs direkt, komplexere Multi-Step-Flows mit Frameworks wie LangGraph (LangChain), Anthropic Computer Use (steuert Bildschirm + Maus), OpenAI Agents SDK, AutoGen (Microsoft), CrewAI (Multi-Agent-Teams). Die Frage ist nicht mehr "kann man Agents bauen", sondern "wo lohnen sie sich und wo werden sie zu Risiko".

Warum es zählt – und warum es heikel ist

Agents lösen drei Probleme, die klassische Software nicht lösen kann. Sie schaffen aber drei neue Probleme, die ein Treuhand-/Anwalt-KMU kennen muss.

Was Agents lösen. Erstens: variable Workflows. Ein Mandanten-Onboarding hat 4-12 Schritte, je nach Mandanten-Typ. Klassischer Code muss alle Verzweigungen ausprogrammieren – bei 10 Mandanten-Typen schnell unwartbar. Ein Agent navigiert dynamisch durch den Prozess. Zweitens: unstrukturierte Eingabe. Eine E-Mail mit anhängender PDF und versteckter Anfrage in Absatz 3 kann ein Agent triagieren – klassischer Code nicht. Drittens: Tool-Komposition. Ein Agent kann Bexio-API + Email + Kalender + Wissensbasis kombinieren, ohne dass die Kombination im Code festgeschrieben ist.

Was Agents an Problemen erzeugen. Erstens: unkontrolliertes Verhalten. Wenn das Modell entscheidet, kann es entscheiden, falsch zu entscheiden. Loops (Agent ruft denselben Tool 50x auf), Halluzinations-getriebene Aktionen ("ich habe diesen Mandanten gelöscht – er existiert nicht"), unerwartete Tool-Kombinationen. Zweitens: Audit-Problem. Eine klassische Software-Aktion ist im Code dokumentiert – das wird ausgeführt, weil Zeile 247 das so sagt. Eine Agent-Aktion ist im Prompt-Output dokumentiert – das wird ausgeführt, weil das Modell es so vorgeschlagen hat. Für eine revisionsfähige Buchführung (Art. 957a OR), für DSFA-Dokumentation (Art. 22 revDSG) und für EU AI Act Art. 26 Deployer-Logging ist die zweite Form schwerer zu prüfen. Drittens: Kosten-Explosion. Ein Agent, der drei Mal pro Anfrage das Modell ruft (Reasoning, Tool-Call, Antwort-Synthese), kostet 3-10x mehr als ein einzelner Aufruf. Bei einem Endlos-Loop sind Tageskosten von CHF 1000+ in Stunden möglich.

Mai 2026 ist die Branche in der "Reality-Phase". Die Hype-Welle 2024-2025 hat viele Agents in Production gebracht, von denen mehrere mit teuren Vorfällen (Daten-Löschung, falsche Buchung, Compliance-Verstoss) endeten. Best Practices haben sich konsolidiert: Tools mit harten Limits, Human-in-the-Loop bei kritischen Aktionen, Audit-Trail jedes Schrittes, Eval-Suite gegen Regressionen.

Mechanik und Patterns

Ein typischer Agent-Zyklus besteht aus vier Schritten, die sich wiederholen, bis das Ziel erreicht oder ein Abbruchkriterium greift.

Schritt 1 – System-Prompt mit Aufgabe und Tool-Katalog. Das Modell erhält eine klare Aufgaben-Beschreibung ("Beantworte die Mandanten-Anfrage. Du darfst diese Werkzeuge verwenden: search_documents, fetch_bexio_balance, send_email") und einen strukturierten Tool-Katalog (Name, Beschreibung, Input-Schema, Output-Schema).

Schritt 2 – Reasoning. Das Modell überlegt: was muss ich tun, welches Werkzeug eignet sich. Bei Claude und GPT-4 ist das oft im Tool-Call selbst eingebettet; bei kleineren Modellen sieht man explizite "thinking"-Blocks.

Schritt 3 – Tool-Call. Das Modell ruft ein Werkzeug auf, formal als JSON-Aufruf. Der umgebende Agent-Code führt das Werkzeug aus (API-Request, DB-Query, Datei-Lesung) und gibt das Ergebnis als Nachricht zurück.

Schritt 4 – Iteration oder Abschluss. Das Modell entscheidet: noch ein Werkzeug nötig, oder Antwort fertig? Wenn fertig, gibt es die finale Antwort. Wenn noch Werkzeug nötig, nächster Zyklus.

Klassische Patterns Mai 2026.

ReAct (Yao et al. 2022). Der Urvater. Modell denkt in natürlicher Sprache und ruft Tools auf. Heute meist implizit durch die Provider-SDKs.

Plan-and-Execute. Das Modell macht zuerst einen kompletten Plan, dann führt es ihn Schritt für Schritt aus. Robuster bei langen Aufgaben, langsamer.

Reflexion / Self-Critique. Nach jedem Schritt prüft das Modell sein eigenes Ergebnis und korrigiert ggf. Reduziert Halluzinationen, kostet aber Tokens.

Multi-Agent. Mehrere Agents mit verschiedenen Rollen (Researcher, Writer, Critic) arbeiten zusammen. CrewAI und AutoGen popularisieren das. In der Praxis oft Overkill – ein gut gebauter Single-Agent reicht in 80% der KMU-Fälle.

LangGraph (LangChain). Ein Graph statt eines Loops. Knoten sind Schritte (LLM-Call, Tool-Call, Branch, Loop-Back), Kanten sind Übergänge. Mai 2026 das fortgeschrittenste Open-Source-Framework für Production-Agents.

Anthropic Computer Use (Oktober 2024+). Der Agent steuert direkt Bildschirm und Maus eines Computers – er sieht den Bildschirm, klickt, tippt, scrollt. Mai 2026 noch eine Spezial-Anwendung mit hoher Fehlerquote, aber bei UI-Automatisierung ohne API-Zugang die einzige Lösung.

Production-Hardening. Token-Limits pro Conversation, Tool-Call-Limit pro Conversation (z.B. max 10 Tool-Calls), Timeout pro Tool-Aufruf, klare Refusal-Anweisungen ("wenn das Werkzeug fehlschlägt, sage es"), Human-in-the-Loop für alle Aktionen mit irreversiblem Effekt (Löschen, Senden, Buchen, Zahlen), strukturiertes Audit-Logging jedes Schrittes in eine zentrale Audit-DB.

Agent-Bau in 7 Schritten

1. 01Aufgabe schärfen: was ist Ziel, was sind erlaubte Aktionen, was sind verbotene Aktionen, was sind Erfolgs- und Abbruch-Kriterien?
2. 02Prüfen, ob überhaupt ein Agent nötig: reicht ein einfacher Tool-Use-Aufruf oder ein klassischer Workflow? Wenn ja, kein Agent bauen.
3. 03Tool-Katalog definieren: jedes Werkzeug mit klarem Input/Output-Schema, harten Limits (Geld-Beträge, Lösch-Wirkung), Timeout, Idempotenz wo möglich.
4. 04Sicherheits-Layer: Tool-Call-Limit pro Conversation, Token-Limit, Schwellenwerte für Human-in-the-Loop (z.B. jede Zahlung > CHF 100 freigeben).
5. 05Audit-Logging in zentrale DB (Postgres, Loki): pro Schritt Zeitstempel, Modell-Aufruf, Tool-Call, Input, Output, Entscheidung, Mensch-Freigabe.
6. 06Eval-Suite: 30-100 reale Szenarien mit erwartetem Verhalten. Vor jedem Modell-Wechsel und vor jedem Prompt-Update durchlaufen.
7. 07Stufenweise Inbetriebnahme: zuerst Shadow-Mode (Agent schlägt vor, Mensch entscheidet immer), nach 2-4 Wochen ohne Vorfall partielle Autonomie für unkritische Aktionen.

Wann ein Agent passt

Vier Anwendungs-Profile, in denen ein Agent Mai 2026 sinnvoll ist.

Profil 1: Triage und Routing. Eine Mandanten-Email kommt rein, der Agent klassifiziert (MWST-Frage, Lohn-Frage, Vertrags-Frage), zieht passende Quellen aus der Wissensbasis, schlägt eine Antwort vor. Sender-Email, Klassifikations-Entscheidung und vorgeschlagene Antwort gehen an einen Menschen zur Freigabe. Kein irreversibler Schritt ohne menschliche Bestätigung.

Profil 2: Datenerhebung aus mehreren Quellen. Vor einem Mandanten-Gespräch braucht der Treuhänder: aktuelle Bexio-Bilanz, letzte 5 Mahnungen, Mandantenakte aus DMS, MWST-Status. Ein Agent ruft die vier APIs auf und stellt ein Briefing zusammen. Klassischer Code würde das auch können, aber mit jeder neuen Datenquelle wächst der Code-Aufwand linear; mit Agent nur das Tool-Inventar.

Profil 3: Workflow mit variablen Verzweigungen. GwG-Onboarding eines Neukunden: nach Land, Branche und Geschäftsmodell verzweigen sich die Pflichten. Ein Agent navigiert dynamisch, fragt die nötigen Informationen, prüft sie gegen externe Datenbanken. Bei kritischen Aktionen (Mandanten anlegen, Risikoeinstufung speichern) immer Human-in-the-Loop.

Profil 4: Unstrukturierte-zu-Strukturierte-Konvertierung. Eingehende Rechnungen, Verträge oder Korrespondenz werden vom Agent gelesen, klassifiziert, in das interne Schema eingetragen. Mit OCR für Papier-Dokumente (siehe ai-belegerkennung-ocr). Wichtig: bei Buchungen IMMER ein menschlicher Review-Schritt – Art. 957a OR und Steuer-Risiko verbieten direktes Auto-Buchen.

Wo Agent NICHT die Antwort ist. Wenn die Aufgabe deterministisch und stabil ist: klassischer Code. Wenn die Aufgabe sicherheitskritisch ist (Auszahlung > CHF 5000, Vertragsabschluss, Mandanten-Löschung): mindestens Human-in-the-Loop, oft komplett ohne Agent. Wenn die Aufgabe selten ist (1-2x pro Monat): manuelle Bearbeitung schneller als Agent-Entwicklung. Wenn Halluzinationen unakzeptabel sind: RAG mit klarer Refusal-Politik, kein Agent.

Wann KEIN Agent

Drei klare Fälle, in denen Agents Schaden anrichten.

Erstens: irreversible Aktionen ohne Aufsicht. Löschen, Zahlen, Senden, Buchen. Ein Agent, der ohne Human-in-the-Loop Geld bewegt oder Daten löscht, ist ein Compliance-Verstoss vorprogrammiert. Mai 2026 sind in mehreren publizierten Vorfällen Versicherungs-/Anwalts-Setups durch falsche Agent-Aktionen in fünfstellige Schadenfälle geraten.

Zweitens: Anwendungen unter strikter Determinismus-Anforderung. Eine MWST-Berechnung MUSS bei gleichem Input immer den gleichen Output liefern. Ein Agent ist non-deterministisch – gleiche Eingabe kann unterschiedliche Tool-Calls und Antworten produzieren. Solche Aufgaben gehören in klassischen Code (Math.js, Excel-Engine, eigene Regel-Engine). Das Sprachmodell darf höchstens als Prüf-Instanz davor oder dahinter sitzen.

Drittens: höchste Daten-Sensitivität ohne Audit-Klarheit. Ein Agent, der mit Mandantendaten arbeitet, muss jeden Schritt protokollieren: welcher Prompt, welcher Tool-Call, welcher Output, welche Entscheidung. Diese Audit-Spur muss im Voraus konzipiert und in der Pipeline erzwungen sein – nicht "vergisst der Entwickler, baut der Agent nichts". Ohne diese Audit-Garantie ist Berufsgeheimnis (StGB 321) und revDSG-DSFA gefährdet.

Marktbeobachtung Mai 2026. Die Branche unterscheidet zunehmend zwischen "Agentic AI" (echte Autonomie, Multi-Step, eigene Plan-Erstellung) und "AI mit Tool-Use" (eine einzelne Anfrage, eine Funktion, eine Antwort). Das Zweite reicht für 80% der KMU-Aufgaben und ist deutlich sicherer. Wer einen "Agent" beauftragt oder baut, sollte zuerst prüfen: brauchen wir wirklich Mehr-Schritt-Autonomie, oder reicht ein Tool-Use-Aufruf? Die Antwort ist oft das zweite.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Yao et al. – ReAct: Synergizing Reasoning and Acting in Language Models · 2022-10
2. Anthropic – Building Effective Agents (Engineering Blog) · 2026-02
3. LangGraph – Documentation and Production Patterns · 2026-05
4. OpenAI – Agents SDK and Assistants API Reference · 2026-04