Wie KI-Agenten wirklich funktionieren: Tool-Aufruf für Entscheider

Wenn ein Vendor dir «agentic AI» verkauft, kaufst du in Wirklichkeit einen Mechanismus: ein Large Language Model, das nicht nur antwortet, sondern in einer Schleife denkt, handelt und das Ergebnis seiner Handlung prüft – so lange, bis eine Aufgabe erledigt ist oder ein Abbruchkriterium erreicht wird. Wer diesen Mechanismus nicht versteht, kann weder Make-vs-Buy-Entscheidungen treffen noch die Governance-Frage beantworten, wer für einen autonomen Fehlentscheid haftet.

Chatbot vs. Agent: der entscheidende Unterschied

Ein Chatbot beantwortet eine Eingabe mit einer Ausgabe. Ein Prompt, eine Antwort, fertig. Ein KI-Agent dagegen erhält ein Ziel und arbeitet selbstständig darauf hin – er entscheidet zwischen mehreren Schritten, ruft externe Systeme auf und passt sein Vorgehen an, wenn ein Zwischenschritt scheitert. Diese Verschiebung von der Einzelantwort zum iterativen Prozess ist der Grund, warum 2026 als Wendepunkt gilt: Details dazu findest du in unserer Einordnung Warum 2026 das Jahr der autonomen Agenten wird.

Die Agent Loop: Reason → Act → Observe

Oracle beschreibt in seinem AI Developer Hub die Agent-Architektur präzise als «iterativen Execution Cycle»: Der Agent überlegt sich den nächsten Schritt (Reason), führt eine Aktion aus – meist einen Werkzeugaufruf (Act) – und wertet das Resultat aus (Observe). Dieser Zyklus wiederholt sich, bis die Aufgabe gelöst ist oder ein definiertes Stoppkriterium greift. Genau hier liegt der technische Unterschied zu klassischer Automatisierung: Der Ablauf ist nicht fest verdrahtet, sondern wird bei jedem Durchlauf neu vom Modell bestimmt.

1. Reason: Das Modell analysiert Ziel, verfügbaren Kontext und mögliche nächste Schritte.
2. Act: Es wählt ein Werkzeug aus und ruft es mit strukturierten Parametern auf – eine Datenbankabfrage, eine API, ein Code-Interpreter.
3. Observe: Das Ergebnis des Aufrufs wird zurück in den Kontext geschrieben und bewertet.
4. Loop oder Stop: Ist das Ziel erreicht, endet der Zyklus – sonst beginnt die nächste Reason-Phase mit erweitertem Wissen.

Function Calling: wie ein Agent tatsächlich ein Werkzeug aufruft

Technisch basiert der Werkzeugaufruf auf einem JSON-Schema: Das Modell erhält eine Liste verfügbarer Funktionen mit Namen, Beschreibung und erwarteten Parametern und entscheidet, welche davon aufgerufen wird – so definieren es die OpenAI Function-Calling-Dokumentation. Anthropic geht mit seinem «Advanced Tool Use» (November 2025) einen Schritt weiter: Programmatic Tool Calling erlaubt Ketten von Aufrufen in einem Durchgang, eine Tool Search Tool findet bei grossen Werkzeugkatalogen die passende Funktion, und Code Execution lässt den Agenten eigenständig Skripte ausführen statt nur vordefinierte Endpunkte anzusprechen. Welches Werkzeug ein Agent in welcher Reihenfolge wählt, ist keine triviale Frage – wir haben die Entscheidungslogik separat aufgeschlüsselt: Welches Tool ruft ein KI-Agent zuerst auf?

• Anthropic: 8.4 von 10 Punkten Zuverlässigkeit bei Function-Calling-Aufgaben (DigitalApplied Q1-2026-Benchmark)
• Google: 7.9 von 10 Punkten
• OpenAI: 6.3 von 10 Punkten

Diese Differenz ist für Einkaufsentscheider relevant: Nicht jedes Modell ruft Werkzeuge gleich verlässlich auf. Der QVeris-Vergleich der Function-Calling-APIs von OpenAI, Anthropic und Google zeigt, dass sich Modellwahl direkt auf Fehlerquote, Nacharbeit und damit auf die Total Cost of Ownership eines Agenten auswirkt – ein Faktor, den viele Pitches unterschlagen.

Architektur-Entscheidungen, die über Erfolg entscheiden

Deterministisch vs. probabilistisch

Ein LLM ist probabilistisch: Dieselbe Eingabe kann zu leicht unterschiedlichen Ausgaben führen. Für unternehmenskritische Prozesse ist das ein Risiko. Salesforce beschreibt in seinem Agentforce-Blog acht Entwicklungsrichtungen, mit denen Anbieter dieses Risiko einhegen – darunter deterministische Guardrails, die bestimmte Schritte fest vorschreiben, sowie «Agent Script» als kontrolliertere Alternative zu freiem Reasoning. Wer einen Agenten kauft, sollte fragen: Welche Schritte im Loop sind deterministisch fixiert, und welche überlässt der Anbieter dem Modell?

RAG-Grounding und das IDEAL-Stack-Modell

Retrieval-Augmented Generation verankert die Antworten eines Agenten in geprüften Unternehmensdaten statt im reinen Modellwissen und reduziert damit Halluzinationsrisiko bei jedem Reasoning-Schritt. Neontri fasst die notwendige Architektur im IDEAL-Fünf-Schichten-Modell zusammen: Intelligence (das Modell selbst), Decision (Planungslogik), Execution (Orchestrierung des Loops), Action (die eigentlichen Werkzeugaufrufe) und Learned (Feedback-Schleifen aus vergangenen Ausführungen). Fehlt eine dieser Schichten, entsteht entweder ein überautonomer, unkontrollierbarer Agent oder ein teurer Chatbot mit Agenten-Etikett. Wie unterschiedliche Standards diese Schichten technisch verbinden, erklären wir in Agent Standards War: Was der MCP-Konflikt für Schweizer KMU bedeutet.

Was Agentic AI wirklich kostet

Jeder Durchlauf der Agent Loop kostet einen zusätzlichen Modellaufruf – Reasoning, Werkzeugwahl und Auswertung sind separate Inferenzen. In der Praxis kalkulieren CFOs deshalb mit deutlich höher als die Kosten eines einfachen Chatbot-Requests für einen Single-Agenten. Bei Multi-Agenten-Orchestrierung, wie sie Beam AI in seinen Agentic Insights beschreibt, kommen Kommunikation zwischen spezialisierten Teilagenten und domänenspezifischen Modellen hinzu – hier steigen die Kosten deutlich an und können ein Vielfaches eines einfachen Chatbot-Aufrufs erreichen. Wer diese Struktur nicht kennt, budgetiert ein Pilotprojekt falsch und erlebt beim Skalieren eine böse Überraschung.

Die Lücke zwischen Pilotprojekt und produktivem Nutzen bleibt gross: McKinsey beziffert den Anteil der Unternehmen, die Agenten bereits skalieren, auf 23%, während 39% im Experimentierstadium feststecken. Am weitesten ist die Finanzbranche: In Banking und Insurance laufen bei 47% der Unternehmen bereits produktive Agenten, mit einer medianen Time-to-Value von 5.1 Monaten.

Observability: Was du von jedem Vendor verlangen musst

Ein Agent, dessen Reason-Act-Observe-Zyklen nicht lückenlos protokolliert werden, ist eine Blackbox mit Handlungsvollmacht. Salesforce nennt in seiner Agentforce-Übersicht einen dedizierten Observability-Stack und einen strukturierten Agent Development Lifecycle (ADLC) als Reifegrad-Merkmale, ergänzt um Massnahmen wie Latenzreduktion von bis zu 70% durch effizientere Harnesses. Für dich als Entscheider heisst das konkret: Verlange vollständige Trace-Logs jedes einzelnen Loop-Durchlaufs, nachvollziehbare Begründungen für jede Werkzeugwahl und die Möglichkeit, einzelne Aktionen im Nachhinein zu prüfen – nicht nur das Endergebnis.

Schweizer Governance: revDSG und EU AI Act

Autonome Entscheide eines Agenten fallen in der Schweiz unter die Regeln zu automatisierten Einzelentscheiden im revidierten Datenschutzgesetz: Betroffene Personen haben ein Recht, eine automatisierte Entscheidung anzufechten und eine menschliche Überprüfung zu verlangen. Wer Agenten für Kreditentscheide, Personalprozesse oder Kundenkommunikation einsetzt, muss diesen Prozess vorab technisch abbilden können – was wiederum vollständige Observability voraussetzt. Zusätzlich wirken die Transparenzpflichten des EU AI Act ab August 2026 auf Schweizer Unternehmen mit EU-Bezug oder EU-basierten Modellanbietern durch. Governance ist damit kein Compliance-Anhängsel, sondern ein Architekturmerkmal, das von Anfang an mitgebaut werden muss.

Make-vs-Buy: die Entscheidung für dein Unternehmen

Wer die Agent Loop, Function Calling, Guardrails und Observability als zusammenhängenden Mechanismus versteht, kann einen Vendor-Pitch in Sekunden entlarven: Fragt der Anbieter nach deinem Use Case, bevor er über Reasoning-Architektur, deterministische Grenzen und Trace-Logging spricht, fehlt ihm entweder die technische Tiefe oder die Bereitschaft zur Transparenz. Die Wahl zwischen Eigenbau und externem Betrieb ist letztlich eine Frage der Kontrolle über genau diese Bausteine – nicht eine Frage des Modell-Namens auf der Rechnung.