KI-Engineering · Tag 4: KI-Agents & Tool-Use mit MCP

Willkommen zu Tag 4 unserer Serie KI-Engineering. In Tag 3 haben wir mit RAG dafür gesorgt, dass die KI auf Basis echter Dokumente antwortet statt zu raten. Heute geht es einen Schritt weiter: Wir geben dem Modell Hände. KI-Agents sind der Punkt, an dem ein Sprachmodell aufhört, nur Text zu produzieren, und anfängt, Dinge zu tun: eine Datenbank abfragen, ein Ticket anlegen, einen Kalender prüfen, eine Rechnung stornieren. Der Hebel dafür heißt Tool-Use, und der neue Standard, um KI sauber mit deinen Systemen zu verbinden, heißt Model Context Protocol (MCP). In dieser Episode klären wir, was das konkret bedeutet, wann sich ein Agent wirklich lohnt, und wo die ehrlichen Stolperfallen liegen.

Vorweg die unbequeme Wahrheit: Die meisten Probleme, für die Teams heute reflexartig einen Agenten bauen wollen, brauchen gar keinen. Ein fest verdrahteter Workflow ist billiger, schneller und vorhersehbarer. Wir zeigen dir deshalb nicht nur, wie Agents funktionieren, sondern auch, wann du die Finger davon lässt.

Was KI-Agents wirklich sind

Ein KI-Agent besteht aus drei Zutaten: einem Sprachmodell als Entscheider, einer Menge an Werkzeugen, die es aufrufen kann, und einem Ziel, das es erreichen soll. Das Modell bekommt eine Aufgabe, überlegt, welches Werkzeug als Nächstes hilft, ruft es auf, liest das Ergebnis, überlegt erneut und wiederholt diese Schleife, bis das Ziel erreicht ist oder es aufgibt. Genau diese Schleife unterscheidet einen Agenten von einem simplen Prompt.

Der Unterschied klingt harmlos, ist aber fundamental. Ein normaler Prompt ist eine Einbahnstraße: Frage rein, Antwort raus. Ein Agent trifft in jedem Durchlauf eine neue Entscheidung auf Basis dessen, was er gerade gelernt hat. Er ist damit flexibler, aber auch weniger kontrollierbar. Ein Agent kann eine Aufgabe lösen, die du vorher nicht in feste Schritte zerlegt hast, weil er den Weg selbst findet. Er kann aber auch fünf Werkzeuge in der falschen Reihenfolge aufrufen, weil er sich verrannt hat.

Autonomie ist ein Regler, kein Schalter

Es gibt nicht den einen Agenten. Autonomie ist ein Spektrum. Am einen Ende steht ein Modell, das genau ein Werkzeug aufrufen darf und danach fertig ist. Am anderen Ende steht ein System, das eigenständig plant, mehrere Werkzeuge in Folge nutzt, Zwischenergebnisse bewertet und selbst entscheidet, wann es fertig ist. Je weiter rechts du drehst, desto mächtiger wird das System und desto mehr Kontrolle gibst du ab. Gutes KI-Engineering heißt, diesen Regler bewusst zu setzen und nicht aus Begeisterung sofort ganz nach rechts zu drehen.

Tool-Use und Function-Calling: der Mechanismus dahinter

Damit ein Modell ein Werkzeug nutzen kann, muss es wissen, dass es existiert. Beim Function-Calling beschreibst du dem Modell jedes Werkzeug: einen Namen, eine kurze Beschreibung, was es tut, und welche Parameter es erwartet. Zum Beispiel ein Werkzeug namens Bestellung suchen mit dem Parameter Bestellnummer. Das Modell entscheidet dann selbst, ob und wann dieser Aufruf sinnvoll ist.

Wichtig ist das mentale Bild dahinter: Das Modell führt das Werkzeug nicht selbst aus. Es gibt lediglich eine strukturierte Aufforderung zurück, etwa den Wunsch, Bestellung suchen mit der Nummer 48231 aufzurufen. Deine Software fängt diesen Wunsch ab, führt den echten Datenbankzugriff aus, und reicht das Ergebnis zurück ins Modell. Diese Trennung ist die wichtigste Sicherheitslinie im ganzen System. Zwischen dem Wunsch des Modells und der Ausführung sitzt immer dein Code, und dort entscheidest du, was erlaubt ist.

Warum die Beschreibung der Werkzeuge über Erfolg entscheidet

In der Praxis ist die Qualität eines Agenten selten eine Frage des Modells und fast immer eine Frage der Werkzeugbeschreibungen. Ein Werkzeug mit vagem Namen und ohne klare Grenzen wird falsch benutzt. Wir haben mehr Agentenprobleme durch präzisere Beschreibungen gelöst als durch teurere Modelle. Sag dem Modell explizit, wann es ein Werkzeug nutzen soll und wann nicht, welche Werte gültig sind, und was passiert, wenn nichts gefunden wird. Ein Werkzeug ist eine API für ein Sprachmodell, und wie bei jeder API entscheidet die Dokumentation über die Fehlerquote.

Das Model Context Protocol (MCP) als Standard

Bis vor Kurzem musste jedes Team seine Werkzeuge für jedes Modell neu anbinden. Wer sein CRM an einen Agenten hängen wollte, schrieb Glue-Code, der genau zu einem Anbieter passte. Wechselte man das Modell, fing man von vorne an. Das Model Context Protocol, kurz MCP, räumt mit diesem Chaos auf. Es ist ein offener Standard, der beschreibt, wie ein Sprachmodell und ein externes System miteinander reden. Man vergleicht MCP gerne mit einem USB-Anschluss für KI: eine einheitliche Buchse, an die du beliebige Systeme steckst, ohne für jedes einen eigenen Adapter zu bauen.

Das Prinzip ist einfach. Auf der einen Seite steht ein MCP-Server, den du für dein System bereitstellst, etwa für deine Bestelldatenbank, dein Ticketsystem oder deinen internen Dokumentenspeicher. Dieser Server bietet Werkzeuge, Datenquellen und vordefinierte Abläufe an. Auf der anderen Seite steht der KI-Client, also die Anwendung mit dem Sprachmodell. Der Client verbindet sich mit dem Server, fragt ab, welche Werkzeuge verfügbar sind, und nutzt sie. Weil beide Seiten dieselbe Sprache sprechen, ist ein einmal gebauter MCP-Server mit jedem MCP-fähigen Client nutzbar.

Was MCP dir konkret spart

Der praktische Gewinn ist Wiederverwendbarkeit. Baust du einen MCP-Server für dein Warenwirtschaftssystem, kannst du ihn im Kundenservice-Agenten, im internen Analyse-Assistenten und im Entwickler-Werkzeug gleichermaßen einsetzen. Du pflegst die Anbindung an einer Stelle statt an dreien. Und weil MCP ein offener Standard ist, bindest du dich nicht an einen einzigen KI-Anbieter. Das ist kein akademisches Detail, sondern eine strategische Absicherung: In einem Feld, das sich alle paar Monate bewegt, ist die Freiheit, das Modell zu wechseln, bares Geld wert.

Ehrlich bleibt dabei: MCP ist jung. Nicht jedes Werkzeug hat einen fertigen Server, die Authentifizierungs- und Berechtigungsmodelle reifen noch, und Sicherheit rund um MCP-Server ist ein aktives Thema. Behandle einen MCP-Server wie jede andere Schnittstelle, die auf deine Produktivdaten zugreift, mit sauberer Rechtevergabe und ohne blindes Vertrauen in fremde Server.

Ein konkretes Praxisbeispiel: der Retouren-Agent

Nehmen wir einen Onlineshop, der Retouren-Anfragen im Support automatisieren will. Ein Kunde schreibt: Ich möchte meine Bestellung 48231 zurückschicken, der Schuh ist zu klein. Ohne Agent müsste ein Mitarbeiter die Bestellung heraussuchen, das Rückgabefenster prüfen, ein Rücksendelabel erzeugen und dem Kunden antworten. Vier Schritte, alle langweilig, alle regelbasiert.

Der Agent bekommt drei Werkzeuge über einen MCP-Server: Bestellung nachschlagen, Rückgabefähigkeit prüfen und Rücksendelabel erstellen. Die Schleife läuft so ab: Das Modell liest die Anfrage, ruft Bestellung nachschlagen mit der Nummer 48231 auf und erfährt, dass die Bestellung vor zwölf Tagen geliefert wurde. Dann ruft es Rückgabefähigkeit prüfen auf und lernt, dass das Rückgabefenster dreißig Tage beträgt, die Retoure also erlaubt ist. Zuletzt ruft es Rücksendelabel erstellen auf und formuliert eine freundliche Antwort mit dem Download-Link. Drei Werkzeugaufrufe, eine Anfrage gelöst, kein Mensch nötig.

Der Trade-off, den man dabei sehen muss

Jetzt kommt die ehrliche Rechnung. Solange die Anfrage im Rahmen ist, ist der Agent brillant. Aber was, wenn der Kunde schreibt, er habe drei Bestellungen und wolle nur einen Artikel aus der mittleren zurückschicken, und der sei außerdem beschädigt angekommen? Jetzt muss der Agent Bestellungen auseinanderhalten, einen Sonderfall für Beschädigung erkennen und womöglich eine Kulanzregel anwenden. Genau hier häufen sich Fehler. Deshalb bauen wir bei Retouren eine harte Grenze ein: Über einem bestimmten Warenwert oder bei Stichwörtern wie beschädigt oder Reklamation übergibt der Agent an einen Menschen, statt selbst zu entscheiden. Der Agent erledigt die achtzig Prozent Standardfälle und weiß, wann er die Hand hebt. Das ist keine Schwäche, sondern das eigentliche Design.

Agent oder einfacher Workflow? Wann sich was lohnt

Die wichtigste Entscheidung fällt vor der ersten Zeile Code: Brauchst du überhaupt einen Agenten? Ein Agent lohnt sich, wenn der Lösungsweg nicht im Voraus feststeht, wenn die Anzahl der Schritte je nach Fall variiert und wenn echte Entscheidungen unterwegs nötig sind. Der Retouren-Fall ist ein Grenzfall, der gerade so einen leichten Agenten rechtfertigt, weil der Pfad je nach Bestellstatus verzweigt.

Ein fester Workflow ist die bessere Wahl, wenn die Schritte immer gleich sind. Wenn du eine eingehende E-Mail klassifizieren, eine Zusammenfassung erzeugen und beides in ein Ticket schreiben willst, ist das kein Agentenproblem. Das sind drei feste Schritte in fester Reihenfolge. Ein Modell für die Klassifikation, ein Modell für die Zusammenfassung, dazwischen normaler Code. Das ist billiger, schneller und du weißt bei jedem Durchlauf exakt, was passiert. Verpacke einen linearen Prozess nicht in einen Agenten, nur weil Agenten gerade spannend klingen. Die zusätzliche Autonomie zahlst du mit Kontrollverlust, und den willst du nur ausgeben, wenn du dafür echte Flexibilität zurückbekommst.

Eine einfache Faustregel

Frag dich: Könnte ich den Ablauf als Flussdiagramm mit festen Kästen zeichnen? Wenn ja, baue genau dieses Flussdiagramm als Code und lass das Modell nur die einzelnen Denkschritte übernehmen. Erst wenn du das Diagramm nicht zeichnen kannst, weil die Verzweigungen von zu vielen Zwischenergebnissen abhängen, ist ein Agent gerechtfertigt.

Die Risiken und wie man sie begrenzt

Agents sind mächtig, aber sie bringen drei Klassen von Risiken mit, die du von Anfang an einplanen musst.

Fehlerketten

Weil ein Agent Schritte aufeinander aufbaut, pflanzt sich ein früher Fehler fort. Zieht das Modell im ersten Schritt die falsche Bestellnummer, sind alle folgenden Schritte auf Sand gebaut. Begrenzen kannst du das, indem du eine feste Obergrenze für die Anzahl der Schritte setzt, sodass der Agent nicht endlos weiterläuft. Ergänze eine Prüfung nach jedem wichtigen Werkzeugaufruf, damit ein unplausibles Zwischenergebnis den Lauf stoppt, bevor Schaden entsteht. Und mache jeden schreibenden Schritt idempotent oder rückgängig machbar, damit ein Fehlgriff keine doppelte Rücksendung auslöst.

Kosten

Jeder Durchlauf der Schleife ist ein Modellaufruf, und jeder Modellaufruf kostet Geld und Zeit. Ein Agent, der für eine simple Anfrage acht Runden dreht, ist schnell teurer als der Mitarbeiter, den er ersetzen sollte. Setze deshalb Budgets pro Anfrage, sowohl für die Anzahl der Schritte als auch für die verbrauchten Token. Nutze für die einfachen Denkschritte ein kleineres, günstigeres Modell und hebe dir das große Modell für die wirklich schwierigen Entscheidungen auf. Und miss von Anfang an mit, wie viele Runden deine Agents im Schnitt brauchen, denn diese Zahl ist dein wichtigster Kostentreiber.

Kontrolle und Sicherheit

Der gefährlichste Fehler ist, einem Agenten Werkzeuge zu geben, die mehr dürfen als nötig. Ein Support-Agent braucht kein Werkzeug, das Kundenkonten löschen kann. Gib jedem Agenten nur die minimal nötigen Rechte, nach dem Prinzip der geringsten Berechtigung. Baue für alles, was Geld bewegt, Daten löscht oder nach außen kommuniziert, eine menschliche Freigabe ein, statt den Agenten allein entscheiden zu lassen. Und protokolliere jeden Werkzeugaufruf lückenlos, damit du im Zweifel nachvollziehen kannst, warum der Agent was getan hat. Ohne dieses Protokoll debuggst du einen Agenten im Dunkeln.

So gehst du vor

Wenn du deinen ersten KI-Agenten bauen willst, arbeite dich in dieser Reihenfolge vor, statt sofort das große Ganze zu planen.

• Schreibe das Ziel in einem Satz auf. Was genau soll der Agent erledigt haben, wenn er fertig ist? Wenn du das nicht scharf formulieren kannst, ist das Problem noch nicht reif für einen Agenten.
• Prüfe ehrlich, ob ein Workflow reicht. Zeichne den Ablauf. Ist er ein festes Flussdiagramm, baue den Workflow und spare dir den Agenten.
• Definiere die Werkzeuge sauber. Gib jedem Werkzeug einen klaren Namen, eine präzise Beschreibung und enge Parameter. Beschreibe explizit, wann es nicht genutzt werden soll.
• Binde Systeme über MCP an. Baue oder nutze einen MCP-Server pro System, damit die Anbindung wiederverwendbar und modellunabhängig bleibt.
• Setze harte Grenzen von Anfang an. Maximale Schrittzahl, Token-Budget, minimale Rechte und eine menschliche Freigabe für alles Kritische.
• Starte mit dem engsten sinnvollen Fall. Lass den Agenten zuerst nur die Standardsituation lösen und alles andere an einen Menschen übergeben. Erweitere den Umfang erst, wenn die Zahlen stimmen.
• Miss und beobachte im Betrieb. Protokolliere jeden Lauf, verfolge Erfolgsquote, Rundenzahl und Kosten, und nutze diese Daten, um Werkzeuge und Grenzen nachzuschärfen.

Dieser Weg klingt vorsichtiger, als die euphorischen Demos vermuten lassen, und genau das ist der Punkt. Ein Agent, der neunzig Prozent der Fälle zuverlässig löst und den Rest sauber weiterreicht, ist im Betrieb Gold wert. Ein Agent, der alles versucht und in den Randfällen kippt, verbrennt Vertrauen und Geld.

Fazit

KI-Agents sind der Schritt vom Reden zum Handeln: ein Sprachmodell, das über Tool-Use echte Werkzeuge bedient und über MCP sauber mit deinen Systemen spricht. Der Standard MCP macht diese Anbindung endlich wiederverwendbar und modellunabhängig, statt dich an einen Anbieter zu ketten. Die eigentliche Kunst liegt nicht darin, möglichst viel Autonomie zu geben, sondern die richtige Menge: einen Agenten dort einzusetzen, wo der Weg wirklich variiert, und einen einfachen Workflow überall sonst. Wer die Risiken, Fehlerketten, Kosten und Kontrollverlust von Anfang an mit harten Grenzen einhegt, bekommt ein System, das im Alltag trägt. Morgen, an Tag 5, schauen wir uns an, wie du solche KI-Systeme testest und bewertest, denn ein Agent ohne belastbare Messung ist nur eine teure Vermutung.

Alle Episoden findest du in der Serien-Übersicht. Wenn du einen KI-Agenten oder eine MCP-Anbindung für deine Systeme planst und dabei die Trade-offs von Anfang an richtig setzen willst, sieh dir unsere KI-Engineering-Leistungen an oder nimm direkt Kontakt mit uns auf. Wir bauen Agents, die die Standardfälle zuverlässig lösen und wissen, wann sie einen Menschen fragen.