Von der Antwort zur Handlung
Ein Grosshaendler fuehrt einen KI-Chatbot fuer den Innendienst ein. Die Mitarbeiter sind zunaechst angetan — bis die ersten praktischen Fragen kommen. "Ist Auftrag 4711 schon raus?" Der Bot antwortet eloquent, dass er auf das Warenwirtschaftssystem leider keinen Zugriff habe. "Kannst du dem Kunden eine Terminbestaetigung schicken?" Kann er nicht; er kann nur einen Textentwurf liefern, den jemand von Hand in das Mailprogramm kopiert. Nach zwei Wochen ist die Begeisterung verflogen. Der Bot redet ueber Arbeit, aber er arbeitet nicht.
Genau an dieser Grenze setzt das Konzept des KI-Agenten an. Der Unterschied zum Chat ist nicht die Intelligenz des Modells, sondern die Architektur drumherum: Ein Agent ist ein Sprachmodell, das Werkzeuge benutzen darf — und zwar in einer Schleife. Es bekommt ein Ziel, ueberlegt, welcher Schritt als naechstes noetig ist, ruft ein Werkzeug auf, betrachtet das Ergebnis, und entscheidet auf dieser Grundlage ueber den naechsten Schritt. Das wiederholt sich, bis das Ziel erreicht ist oder der Agent feststellt, dass er nicht weiterkommt. Ein Chat beantwortet eine Frage in einem Zug; ein Agent verfolgt eine Aufgabe ueber viele Zuege hinweg — und der Weg dorthin steht vorher nicht fest, sondern entsteht Schritt fuer Schritt aus den Zwischenergebnissen. Genau diese Mehrschrittigkeit mit Rueckkopplung macht den Unterschied zwischen Reden und Handeln.
Werkzeuge: die Haende des Agenten
Was ein Agent kann, bestimmen seine Werkzeuge — im Fachjargon Tools. Technisch basiert das auf dem Tool-Calling der LLM-Schnittstellen: Der Entwickler beschreibt dem Modell eine Reihe von Funktionen mit Name, Zweck und Parametern, und das Modell antwortet statt mit Freitext mit dem strukturierten Wunsch, eine dieser Funktionen mit bestimmten Argumenten aufzurufen. Ausgefuehrt wird der Aufruf von der umgebenden Anwendung, die das Ergebnis an das Modell zurueckgibt — womit die naechste Runde der Schleife beginnt.
Die Palette typischer Werkzeuge ist breit. Eine Suche, mit der der Agent aktuelle Informationen aus dem Netz oder der internen Wissensbasis holt. Eine Code-Ausfuehrung, mit der er rechnen, Daten transformieren oder Dateien auswerten kann — Sprachmodelle sind notorisch unzuverlaessig im Kopfrechnen, aber sehr gut darin, ein kleines Skript zu schreiben, das die Rechnung uebernimmt. API-Aufrufe in Geschaeftssysteme: Auftragsstatus abfragen, einen Termin anlegen, einen Datensatz aktualisieren. Und Dateizugriffe, um Dokumente zu lesen oder Ergebnisse abzulegen. Fuer den Grosshaendler aus dem Eingangsbeispiel hiesse das: Mit einem Werkzeug fuer die Auftragsabfrage und einem fuer den Mailversand wird aus dem redseligen Bot ein Assistent, der die Frage nach Auftrag 4711 tatsaechlich im System nachschlaegt und die Terminbestaetigung nach Freigabe wirklich verschickt.
Dabei gilt eine Grundregel, die zugleich Sicherheitsprinzip ist: Ein Agent erhaelt genau die Werkzeuge, die seine Aufgabe erfordert, und keines mehr. Ein Agent, der Berichte zusammenstellen soll, braucht Lesezugriff auf Daten — aber kein Werkzeug, das Datensaetze loescht.
MCP: ein offener Standard fuer die Werkzeugkiste
Wer mehrere Agenten mit mehreren Systemen verbinden will, stoesst schnell auf ein Skalierungsproblem: Jede Kombination aus KI-Anwendung und Datenquelle brauchte lange ihre eigene, handgebaute Anbindung. Zehn Systeme und drei KI-Anwendungen bedeuteten im schlimmsten Fall dreissig Integrationen — jede einzeln zu pflegen.
Genau dieses Problem adressiert das Model Context Protocol, kurz MCP: ein offener Standard, der beschreibt, wie KI-Anwendungen und externe Systeme miteinander sprechen. Die Idee folgt einem bewaehrten Muster: Ein MCP-Server kapselt ein System — etwa die Warenwirtschaft, den Kalender oder die Dateiablage — und bietet dessen Faehigkeiten als sauber beschriebene Werkzeuge an. Jede MCP-faehige KI-Anwendung kann sich mit einem solchen Server verbinden, die verfuegbaren Werkzeuge abfragen und sie nutzen, ohne dass fuer diese Kombination je eine eigene Integration geschrieben wurde. Statt Anbindungen fuer jede Paarung entstehen einmal ein Server pro System und fertig — ein Prinzip, das oft mit einem einheitlichen Stecker verglichen wird, der beliebige Geraete mit beliebigen Anschluessen verbindet.
Fuer Unternehmen ist daran zweierlei interessant. Erstens die Wiederverwendbarkeit: Ein einmal gebauter MCP-Server fuer das eigene ERP steht jedem kuenftigen Agenten-Projekt zur Verfuegung, unabhaengig davon, welches Modell oder welche Anwendung darauf zugreift. Zweitens die Unabhaengigkeit: Weil der Standard offen ist und von einer wachsenden Zahl von Anbietern unterstuetzt wird, bindet man sich mit der Integrationsarbeit nicht an einen einzelnen KI-Hersteller.
Ein Wort zur Sorgfalt: Ein MCP-Server handelt mit den Rechten des Kontos, mit dem er verbunden ist. Bevor ein Server produktiv angebunden wird, gehoert deshalb geprueft, wer ihn pflegt, welche Berechtigungen er tatsaechlich benoetigt und ob ein eingeschraenktes technisches Konto genuegt. Fremde Server aus unbekannter Quelle blind einzubinden ist so riskant wie die Installation beliebiger Software — der Komfort des Standards entbindet nicht von der ueblichen Pruefung.
Design-Muster: definierte Werkzeuge statt Daten-Dump
Beim Entwurf von Agenten-Werkzeugen gibt es einen Fehler, der in fast jedem ersten Projekt auftaucht: der Daten-Dump. Der Agent bekommt ein Werkzeug namens "hole alle Kundendaten", das bei jedem Aufruf tausende Datensaetze zurueckliefert, und soll sich das Relevante selbst heraussuchen. Das ist gleich dreifach schlecht: Es flutet das Kontextfenster und treibt die Token-Kosten, es verschlechtert die Ergebnisqualitaet, weil das Modell die Nadel im Heuhaufen suchen muss, und es gibt dem Agenten Zugriff auf weit mehr Daten, als seine Aufgabe rechtfertigt.
Das bessere Muster: je System eine kleine Zahl klar definierter, zweckgebundener Werkzeuge. Statt "hole alle Auftraege" ein Werkzeug "suche Auftraege nach Kundennummer und Zeitraum", das gefiltert und begrenzt genau das liefert, was zur Beantwortung noetig ist. Die Filter- und Aggregationsarbeit erledigt das Quellsystem — Datenbanken koennen das ohnehin besser und billiger als ein Sprachmodell. Gute Werkzeuge aehneln damit einer gut gestalteten Programmierschnittstelle: wenige, sprechend benannte Operationen mit klaren Parametern, aussagekraeftigen Ergebnissen und verstaendlichen Fehlermeldungen, aus denen der Agent lernen kann, was er anders versuchen sollte. Es hat sich zudem bewaehrt, Werkzeugbeschreibungen so zu formulieren, als erklaere man sie einem neuen Kollegen — denn nichts anderes tut man: Die Beschreibung ist alles, was das Modell ueber das Werkzeug weiss.
Mehrere Agenten: wann Orchestrierung lohnt — und wann sie Overhead ist
Wenn ein Agent nuetzlich ist, liegt der Gedanke nahe, gleich mehrere zusammenarbeiten zu lassen: ein Orchestrator, der eine grosse Aufgabe zerlegt und Teilaufgaben an spezialisierte Agenten verteilt. Solche Multi-Agent-Architekturen haben ihre Berechtigung — aber deutlich seltener, als der aktuelle Enthusiasmus vermuten laesst.
Sinnvoll ist die Aufteilung in drei Situationen. Erstens bei echt parallelen Teilaufgaben: Sollen fuer einen Marktbericht zwanzig Quellen gesichtet werden, koennen mehrere Recherche-Agenten gleichzeitig arbeiten und ihre Ergebnisse zusammentragen — das spart schlicht Zeit. Zweitens bei klar getrennten Spezialrollen, die unterschiedliche Werkzeuge und unterschiedliches Kontextwissen brauchen: ein Agent, der Daten aus Systemen zieht, ein anderer, der daraus einen Bericht in Hausform verfasst. Die Trennung haelt den Kontext jedes einzelnen Agenten klein und fokussiert — was die Qualitaet messbar verbessert. Drittens zur Verifikation: Ein zweiter Agent, der die Arbeit des ersten prueft, gegenrechnet oder Belege verlangt, faengt Fehler, die dem Verursacher selbst nicht auffallen — nach demselben Prinzip wie das Vier-Augen-Prinzip unter Menschen.
Dem stehen reale Kosten gegenueber: Jeder zusaetzliche Agent bedeutet mehr Token-Verbrauch, mehr Latenz, mehr Stellen, an denen Kontext bei der Uebergabe verloren geht, und ein System, das schwerer zu testen und zu debuggen ist. Fuer eine lineare Aufgabe — Dokument lesen, Daten extrahieren, Ergebnis ablegen — ist ein einzelner Agent mit guten Werkzeugen fast immer die bessere Loesung, und haeufig genuegt sogar ein fest verdrahteter Workflow ganz ohne agentische Freiheit. Die ehrliche Reihenfolge lautet: erst der einfache Workflow, dann ein Agent, und Multi-Agent erst, wenn Parallelitaet, Spezialisierung oder Verifikation es konkret begruenden.
Grenzen und Aufsicht: der Mensch bleibt in der Schleife
Bei aller Faszination: Agenten erben alle Schwaechen der Modelle, auf denen sie basieren — und verstaerken sie durch die Schleife. Ein Modell, das sich in einer Einschaetzung irrt, schreibt im Chat eine falsche Antwort; ein Agent, der sich irrt, handelt auf Basis dieses Irrtums weiter und kann Folgefehler produzieren, bevor jemand eingreift. Deshalb gehoeren in jedes ernsthafte Agenten-System Leitplanken: Begrenzungen, wie viele Schritte und welches Budget eine Aufgabe verbrauchen darf. Eine vollstaendige Protokollierung jedes Werkzeugaufrufs, damit sich jederzeit nachvollziehen laesst, was der Agent wann getan hat und warum. Und vor allem definierte Freigabepunkte: Lesende Zugriffe darf ein Agent autonom ausfuehren, aber alles Irreversible oder Aussenwirksame — die Mail an den Kunden, die Bestellung, die Datenaenderung im ERP — wird vorbereitet und erst nach menschlicher Bestaetigung ausgefuehrt. In der Praxis bewaehrt sich ein gestuftes Vorgehen: Ein neuer Agent startet mit engen Zuegeln und ausschliesslich vorschlagender Rolle, und erst wenn seine Vorschlaege sich ueber Wochen als zuverlaessig erweisen, werden einzelne, gut verstandene Aktionen zur autonomen Ausfuehrung freigegeben.
Fazit: Handeln lassen, aber mit Geschirr
KI-Agenten verschieben die Grenze dessen, was sich automatisieren laesst: von der Antwort zur ausgefuehrten Aufgabe. Die Zutaten sind ueberschaubar — ein Modell, eine Werkzeugschleife, sauber entworfene Tools, zunehmend angebunden ueber den offenen MCP-Standard — und die Erfolgsfaktoren liegen weniger im Modell als im Entwurf drumherum: zweckgebundene Werkzeuge statt Daten-Dumps, Orchestrierung nur bei echtem Bedarf, und Aufsicht, die mit dem Vertrauen waechst.
Drei naechste Schritte: Identifizieren Sie eine mehrschrittige Aufgabe in Ihrem Betrieb, die heute manuelles Hin und Her zwischen Systemen erfordert, und schreiben Sie auf, welche Einzelschritte und Systemzugriffe sie umfasst. Pruefen Sie, welche dieser Systeme sich per Schnittstelle oder vorhandenem MCP-Server anbinden lassen. Und starten Sie mit einem Agenten im Vorschlagsmodus, dessen Aktionen ein Mensch freigibt — den Autonomiegrad koennen Sie erhoehen, wenn die Protokolle Vertrauen rechtfertigen. Wenn Sie dafuer einen erfahrenen Partner suchen: FJ Design unterstuetzt Unternehmen bei Konzeption und Umsetzung von Agenten-Systemen mit Augenmass.