Was ein Agent können soll

Ein Sprachmodell weiß viel über die Welt, aber nichts über dein Unternehmen. Es kann dir nicht sagen, wie viele Anfragen letzten Monat eingegangen sind oder wo eine Bestellung gerade steht.

Deshalb bauen Unternehmen KI-Agenten: Systeme, in denen ein Sprachmodell nicht nur antwortet, sondern Werkzeuge benutzt. Es fragt Datenbanken ab, ruft Schnittstellen auf und setzt aus den Ergebnissen eine Antwort zusammen.

Ein typischer Aufbau, stark vereinfacht:

Frage im Chat
  → Orchestrator: zerlegt die Frage und verteilt Teilaufgaben
    → Agent je Datenquelle: wählt ein Werkzeug und seine Parameter
      → Werkzeug: führt eine feste Abfrage aus
  → Zusammenführung: Antwort mit Diagramm, live im Chat

So ist im Kern auch das Multi-Agenten-System aufgebaut, an dem ich für einen deutschen Automobilkonzern arbeite. Fachleute stellen Analysefragen im Chat, spezialisierte Agenten holen die Daten aus mehreren Quellen, und ein Orchestrator setzt die Antwort zusammen.

Warum Sprachmodelle nie ganz gleich antworten

Sprachmodelle arbeiten mit Wahrscheinlichkeiten. Für jedes nächste Wortstück, ein sogenanntes Token, berechnen sie, welche Fortsetzungen wahrscheinlich sind, und wählen eine davon aus. Das ist gewollt. Genau diese Flexibilität macht sie gut darin, Sprache zu verstehen und Fragen zu beantworten, die so niemand vorhergesehen hat.

Im einzelnen Gespräch fällt das selten auf. In einem Agenten-System schon. Dort folgen mehrere Modellaufrufe aufeinander: Der Orchestrator plant, ein Agent wählt ein Werkzeug, ein weiterer formuliert die Antwort. Eine kleine Abweichung im ersten Schritt verändert alles, was danach passiert. Aus kleinen Unterschieden werden sichtbare.

Die Temperatur auf null zu setzen, löst das nicht. In der Praxis macht sie ein Modell nicht zuverlässig reproduzierbar, und sie nimmt ihm einen Teil der Flexibilität, für die du es überhaupt einsetzt.

Ein Beispiel aus dem Alltag

Stell dir ein internes Analyse-Tool vor. Jemand fragt: „Wie haben sich unsere Anfragen in den letzten drei Monaten entwickelt?“ Das System holt die Zahlen und zeigt ein Liniendiagramm. So weit, so gut.

Eine Woche später stellt dieselbe Person dieselbe Frage. Diesmal kommt ein Balkendiagramm, aufgeschlüsselt nach Kanal statt als Gesamtsumme. Falsch ist beides nicht. Die Rückmeldung ist trotzdem eindeutig: „Wenn ich das frage, will ich jedes Mal genau diese Auswertung sehen.“

Das ist keine überzogene Erwartung. Wer eine Frage regelmäßig stellt, will die Antworten vergleichen. Ein Bericht, der jedes Mal anders aussieht, ist für die tägliche Arbeit wenig wert. An dieser Stelle misst sich ein Agent nicht an einem Chatbot, sondern an dem Dashboard, das das Team seit Jahren nutzt.

Das Spannungsfeld

Bei wiederkehrenden Fragen erwarten Menschen deterministisches Verhalten: gleiche Frage, gleiche Antwort, gleiche Form. Das Modell darunter ist stochastisch. Keine der beiden Seiten lässt sich wegdiskutieren.

Auf KI zu verzichten, ist trotzdem selten die Antwort. Die Stärke des Modells liegt darin, eine frei formulierte Frage zu verstehen und den passenden Weg zur Antwort zu wählen. Seine Schwäche ist, auf jedem Schritt dieses Wegs ein wenig zu improvisieren. Also trennst du beides.

Das Modell entscheidet, Code führt aus

Der erste Reflex ist meist, den Prompt zu erweitern: mehr Regeln, mehr Beispiele, mehr „antworte immer so“. Das hilft eine Weile. Mit jedem neuen Fall wird der Prompt aber länger, widersprüchlicher und schwerer zu testen. Und er bleibt eine Bitte an das Modell, keine Garantie.

Verlässlicher ist eine klare Arbeitsteilung. Das Modell entscheidet, was gebraucht wird. Wie es ausgeführt wird, legt Code fest. Das zeigt sich an sechs Stellen:

  1. Feste Werkzeuge. Wiederkehrende Fragen bekommen ein eigenes Werkzeug mit fester Abfrage und festem Diagrammtyp. Das Modell wählt das Werkzeug und füllt die Parameter. Die Zahlen berechnet es nicht selbst.
  2. Klare Verträge. Jedes Werkzeug hat ein Schema: welche Parameter es gibt, welche Werte erlaubt sind und welches Format zurückkommt. Was nicht ins Schema passt, wird gar nicht erst ausgeführt.
  3. Prüfungen. Code prüft jede Ausgabe des Modells, bevor sie weiterverwendet wird. Ist das Format gültig? Liegt der Zeitraum im erlaubten Bereich? Passt die Summe zu den Einzelwerten?
  4. Rechte. Ein Agent sieht nur die Daten und Werkzeuge, die er für seine Aufgabe braucht, und nur das, was die fragende Person auch sehen darf. Das entscheidet das Backend, nicht der Prompt.
  5. Fallbacks. Schlägt eine Prüfung fehl oder fehlen Daten, sagt das System das klar. Es fragt nach, zeigt einen festen Standardbericht oder gibt an einen Menschen ab. Raten gehört nicht dazu.
  6. Evals. Eine feste Sammlung typischer Fragen mit erwarteten Ergebnissen läuft bei jeder Änderung an Prompt, Modell oder Werkzeug. So siehst du, ob das System besser wird oder nur anders.

Für das Beispiel oben sieht ein solches Werkzeug schematisch so aus:

// Schematisch: ein Werkzeug für eine wiederkehrende Frage.
const inquiryReport = tool({
  description: 'Anfragen pro Monat als Liniendiagramm',
  inputSchema: z.object({
    months: z.enum(['3', '6', '12']),
    breakdown: z.enum(['total', 'channel']).default('total'),
  }),
  // Feste Abfrage, festes Diagramm: Das Modell wählt nur die Parameter.
  execute: ({ months, breakdown }) => reports.inquiries({ months, breakdown }),
});

Fragt jemand nach den Anfragen der letzten drei Monate, wählt das Modell dieses Werkzeug mit months: '3'. Abfrage, Rechenweg und Diagramm sind jedes Mal dieselben. Will die Person ausdrücklich die Aufteilung nach Kanal sehen, ist auch das ein erlaubter Wert und keine Improvisation.

Für Abläufe aus mehreren Schritten folgen Agent Skills derselben Idee: fest hinterlegte Anleitungen, oft mit eigenen Skripten, die ein Agent für eine bestimmte Aufgabe lädt. Was jedes Mal gleich ablaufen soll, wird einmal festgeschrieben, statt jedes Mal neu erfunden.

Was stochastisch bleiben darf

Nicht alles muss deterministisch sein. Eine offene Frage wie „Was fällt dir an diesen Zahlen auf?“ darf jedes Mal etwas anders beantwortet werden. Unklare Fragen verstehen, Ergebnisse zusammenfassen, verständlich formulieren: Darin sind Sprachmodelle stark.

Entscheidend ist die Grenze. Was jedes Mal gleich sein muss, weil Menschen darauf Entscheidungen bauen, gehört in Code. Was variieren darf, weil es beim Verstehen und Formulieren hilft, übernimmt das Modell. Diese Grenze ziehe ich in jedem Projekt neu, zusammen mit den Menschen, die das System später jeden Tag benutzen.

Fazit

Ist das die endgültige Lösung? Wahrscheinlich nicht. Modelle werden besser, und die Werkzeuge rund um Agenten ändern sich schnell. Die Grundidee halte ich trotzdem für stabil: Ein Agent wird nicht verlässlich, weil das Modell besser rät, sondern weil das System drumherum festlegt, was nicht geraten werden darf.