Agentic AI, Agentic Data und Agentic First: Was agentenfähige Software braucht

In diesem Beitrag geht es um Agenten, die ein Sprachmodell zur Auswahl ihrer nächsten Schritte einsetzen. Ein Werkzeug ist dabei eine aufrufbare Funktion der Software, etwa zum Lesen eines Zustands oder zum Anfordern einer Aktion. Seine Rückgabe liefert Informationen für die nächste Entscheidung.

Anthropic unterscheidet zwischen Workflows mit vorgegebenen Codepfaden und Agenten, bei denen das Sprachmodell den Ablauf und die Werkzeugnutzung dynamisch steuert. Beide Ansätze können Teil einer Prozessautomatisierung sein. Ein Workflow kann durchaus verzweigen und ein Modell zur Klassifikation einsetzen. Entscheidend ist, wie weit die möglichen Abläufe bereits im Code festgelegt sind.

Beim Importlauf könnte ein Workflow bekannte Fehlercodes prüfen und jeweils eine fest definierte Behandlung ausführen. Ein Agent könnte dagegen nach der ersten Rückgabe entscheiden, ob er zusätzlich Validierungsergebnisse oder Ereignisse eines vorherigen Versuchs benötigt. Mit jeder Beobachtung aktualisiert er seine Einschätzung und wählt den nächsten Schritt innerhalb der bereitgestellten Möglichkeiten.

Die Auswahl durch das Modell und die Ausführung sind getrennte Verantwortlichkeiten. Das Modell schlägt beispielsweise einen Werkzeugaufruf mit Parametern vor. Die Agentenlaufzeit ist das Programm, das diesen Vorschlag verarbeitet: Es prüft den Aufruf, führt eine erlaubte Funktion aus und gibt das Ergebnis an das Modell zurück. Daraus kann das Modell den nächsten Schritt ableiten. Auch ein Agent braucht Grenzen für Werkzeuge, Dauer und Abbruch. Ich würde ihm die Ablaufsteuerung dort überlassen, wo zusätzliche Untersuchung verlangt ist. Für bekannte, wiederholbare Fehlerbehandlungen kann der bestehende Workflow zuständig bleiben.

Im Beispiel könnte „status = 3“ den fehlgeschlagenen Import bezeichnen. Der Agent benötigt diese Zuordnung und den Fehlerbericht, etwa „Pflichtfeld fehlt“. Außerdem muss er erfahren können, welche Eingaben zu diesem Lauf gehören, wann der Zustand ermittelt wurde und aus welcher Quelle die Information stammt. Ein verständlicher Statusname beantwortet diese weiteren Fragen noch nicht.

Zur nutzbaren Datengrundlage gehören Datentypen, Einheiten, Beziehungen und Definitionen, aber auch Qualitätsmerkmale und zeitliche Gültigkeit. Ein zwischengespeicherter Status von gestern kann korrekt dokumentiert und trotzdem für den heutigen Neustart unbrauchbar sein. Herkunft und Aktualität sollten bei einer zustandsabhängigen Aktion überprüfbar sein.

Das gilt auch für abgeleitete Werte. Die „durchschnittliche Laufzeit“ benötigt eine Definition: Welche Start- und Endereignisse zählen? Wie werden abgebrochene Versuche behandelt? Sind Wartezeiten enthalten? Eine semantische Schicht beschreibt solche Kennzahlen und Beziehungen zentral, sodass verschiedene Abfragen dieselbe fachliche Definition verwenden können. Snowflake zeigt diesen Ansatz mit Semantic Views, die Kennzahlen, fachliche Entitäten und ihre Beziehungen beschreiben.

Diese Beschreibungsebene verbessert die Interpretierbarkeit. Fehlerhafte Messwerte, fehlende Ereignisse oder widersprüchliche Quellen bleiben jedoch Datenprobleme. Im Beispiel würde ich deshalb den protokollierten Fehlercode von der vermuteten Ursache trennen. Der Code stammt aus dem System; die Ursache kann zunächst eine Hypothese des Agenten sein. Eine plausible Erklärung allein darf keinen Neustart rechtfertigen.

Ebenso muss die Rückgabe erkennen lassen, ob eine Abfrage ein belastbares Ergebnis geliefert hat. Ein leeres Ergebnis beweist nicht automatisch, dass kein Fehler vorliegt: Auch eingeschränkte Sichtbarkeit oder eine nicht verfügbare Quelle können Informationen fehlen lassen. Welche Details nach außen gegeben werden dürfen, hängt dabei von den Zugriffsregeln ab.

Aus der Gestaltung barrierefreier Formulare lässt sich ein passendes Prinzip übertragen. W3C beschreibt Beschriftungen und Hinweise als Hilfe, um die erwartete Eingabe und ihr Format zu verstehen. Ein Agent benötigt ebenfalls verständliche Beschreibungen, wenn er Parameter korrekt befüllen soll. Die Analogie bezieht sich auf klare Benennungen und Eingabehinweise.

Ein Parameter „date“ lässt offen, welches Datum gemeint ist. Bei „started_at“ ist die Bedeutung näher eingegrenzt, aber Zeitformat und Zeitzone müssen weiterhin feststehen. Bei einem Zeitraum gehört auch dazu, ob die Grenzen eingeschlossen sind. Namen, Schema und Beschreibung sollten zusammenpassen. Verbindliche Eingaberegeln werden zusätzlich im Code validiert.

Agentic First bedeutet hier, die fertige Software für die Nutzung durch Agenten zu entwerfen. Der Begriff begegnet auch im Zusammenhang mit agentischer Softwareentwicklung. Wer Coding-Agenten bei der Erstellung einer Anwendung verwendet, hat damit noch keine Aussage darüber getroffen, wie andere Agenten diese Anwendung später bedienen können.

Für unseren Importlauf würde ich Werkzeuge entlang der Aufgabe anbieten: den Laufzustand abrufen, Fehler des letzten Versuchs lesen, aktuelle Voraussetzungen prüfen und einen Neustart anfordern. Jedes Werkzeug braucht einen eindeutigen Zweck, beschriebene Eingaben und passende Rückgaben. Der technische Vertrag einer Funktion beschreibt ihre Eingaben, möglichen Rückgaben, Voraussetzungen und Wirkung. Anthropic betont beim Tool-Design klare Beschreibungen und eine auf die Aufgabe abgestimmte Funktionalität. Ein API-First-Entwurf kann dafür eine Ausgangsbasis liefern. Ob eine bestehende API bereits geeignet ist oder eine zusätzliche Werkzeugschicht sinnvoll ist, muss an realen Aufgaben geprüft werden.

In der folgenden Tabelle bezeichnet run_id einen Importlauf. operation_id kennzeichnet dagegen den Auftrag, einen Neustart auszulösen. expected_version enthält die beim Lesen ermittelte Version des Laufzustands. Der idempotency_key ordnet wiederholte Anfragen derselben beabsichtigten Aktion zu.

Eine mögliche Werkzeugoberfläche für das Beispiel

Der Fehlerbericht des gescheiterten Laufs sagt noch nicht, ob der fehlende Pflichtwert inzwischen ergänzt wurde. Dafür prüft check_restart die aktuellen Eingaben und weiteren Neustartvoraussetzungen. Diese Prüfung ist eine Momentaufnahme. Beim tatsächlichen Auslösen des Neustarts muss die ausführende Software die erforderlichen Voraussetzungen erneut wirksam durchsetzen.

Beim Neustart sollte der Vertrag erklären, welche Zustände ihn erlauben und welche Nebenwirkungen entstehen können. Die Software setzt diese Regeln durch. Läuft der Vorgang inzwischen wieder, darf eine veraltete Beobachtung nicht ungeprüft zur zweiten Ausführung führen. Eine Versionsbedingung kann helfen, Änderungen seit dem Lesen zu erkennen; HTTP kennt dafür beispielsweise bedingte Anfragen mit „If-Match“. Die gelesene Versionskennung wird im Beispiel als expected_version übergeben. Eine Version des Laufzustands erfasst Änderungen an der Eingabedatei nicht automatisch; diese müssen zusätzlich fachlich geprüft werden.

Auch eine verlorene Antwort muss berücksichtigt werden. Der Server kann den Neustart angenommen haben, während der Agent nur einen Timeout sieht. Für dieselbe beabsichtigte Aktion kann ein Idempotenzschlüssel Wiederholungen zuordnen und doppelte Nebenwirkungen vermeiden, wenn die ausführende Software ihn entsprechend verarbeitet. AWS beschreibt dieses Vorgehen mit Idempotenzschlüsseln. Ein jeweils neu erzeugter Schlüssel würde diese Zuordnung aufheben. Die Laufzeit sollte den Schlüssel der beabsichtigten Aktion zuordnen und bei einem erneuten Versuch wiederverwenden. Im vorgeschlagenen Vertrag liefert der Server dann auch die zugehörige Vorgangskennung zurück, damit sich die bereits angenommene Aktion weiterverfolgen lässt.

Wenn der Neustart im Hintergrund erfolgt, sollte seine Rückgabe zunächst den Annahmestatus und eine stabile Vorgangskennung (operation_id) enthalten. Über get_operation lässt sich prüfen, ob ein neuer Lauf angelegt wurde; dessen Kennung führt zurück zu get_run. Ein angenommener Auftrag, ein gestarteter Import und ein erfolgreich abgeschlossener Import sind unterschiedliche Zustände. Welcher davon das Ziel ist, muss im Auftrag stehen. Für die Aussage „Der Import ist erfolgreich abgeschlossen“ braucht der Agent den bestätigten Endzustand des neuen Laufs.

Das Model Context Protocol (MCP) kann solche Werkzeuge und Kontext über ein gemeinsames Protokoll zugänglich machen. Die offizielle Spezifikation umfasst unter anderem Tools für aufrufbare Funktionen, Resources für bereitgestellte Inhalte und Prompts für wiederverwendbare Eingabevorlagen. Die fachlichen Verträge und Ausführungsregeln muss die Anwendung weiterhin bereitstellen. Agentic First beschreibt hier diese Gestaltung; MCP ist eine mögliche technische Verbindung.

Agentic Data beschreibt die Bedeutung und Qualität der Datengrundlage. Context Engineering betrifft die Zusammenstellung des gesamten Arbeitskontexts für den jeweiligen Modellaufruf. Dazu gehören der Auftrag, Handlungsregeln, Werkzeugbeschreibungen, relevante Daten und bisherige Ergebnisse. Entscheidend ist, welche Informationen das Modell für den nächsten Schritt benötigt. Anthropic beschreibt beim Context Engineering unter anderem das gezielte Nachladen über Werkzeuge und Referenzen.

Für die erste Untersuchung des Importlaufs könnten Status, Fehlercode und die unmittelbar betroffenen Validierungsergebnisse ausreichen. Die gesamte Ereignishistorie würde ich erst bei Bedarf nachladen. Ein geeignetes Werkzeug erlaubt begrenzte Zeiträume, Filter und weitere Seiten. Gibt es nur einen Ausschnitt zurück, muss er als solcher erkennbar sein. Andernfalls könnte der Agent unvollständige Daten für den vollständigen Verlauf halten.

Berechnungen mit festgelegter Logik würde ich möglichst in der Datenbank oder Fachfunktion ausführen lassen. Der Agent erhält den berechneten Wert zusammen mit seiner Definition und dem Datenstand. Bei der Kontextauswahl zählt, ob die relevanten Informationen vorhanden sind. Eine kurze Rückgabe, die eine entscheidende Einschränkung auslässt, wäre ebenso ungeeignet wie eine umfangreiche Rückgabe voller irrelevanter Details.

Ein Aufgabenprofil sollte beschreiben, welches Ergebnis erwartet wird und welche Werkzeuge dafür bereitstehen. Dazu gehören ein dokumentierter Zweck, messbare Erfolgskriterien und klare Grenzen dafür, was der Agent selbstständig ausführen darf. Ein Profil umfasst damit mehr als eine Rollenbeschreibung im Prompt.

Für unser Beispiel wären zwei Profile denkbar. Eines untersucht den fehlgeschlagenen Lauf und liefert eine begründete Diagnose. Ein anderes darf zusätzlich einen zulässigen Neustart anfordern. Beide können dasselbe Modell und dieselbe Laufzeit verwenden. Die tatsächlich verfügbaren Werkzeuge und Berechtigungen unterscheiden sich. Alternativ kann ein einzelnes Profil beide Aufgaben abdecken und vor dem Neustart einen vorgesehenen Freigabeschritt verlangen.

Ich würde die Auswahl der Werkzeuge an den benötigten Aufgaben prüfen. Wenige Werkzeuge garantieren noch keine passende Auswahl. Ein einzelner Agent kann mehrere Schritte einer begrenzten Aufgabe übernehmen. Weitere Agenten würde ich hinzufügen, wenn die Aufteilung einen messbaren Nutzen bringt und die Übergaben klar geregelt sind. Auch dabei muss feststehen, wer ein Ergebnis verifiziert und wer bei einem Fehler übernimmt.

Der Agent kann wissen, dass er einen Importlauf lesen darf. Diese Information im Kontext ist keine technische Autorisierung. Beim Zugriff muss die ausführende Software prüfen, ob die verwendete Identität auf genau diesen Lauf zugreifen und die angeforderte Aktion ausführen darf. OWASP empfiehlt die Berechtigungsvalidierung bei jeder Anfrage.

Dabei muss nicht jedes Mal ein Mensch zustimmen oder zwingend eine vollständige Rechteabfrage in der Datenbank stattfinden. Eine vorhandene Autorisierung kann mehrere Zugriffe abdecken. Die technische Prüfung kann beispielsweise auf einem validierten, passend begrenzten Berechtigungstoken oder einer passenden Policy beruhen. Sie muss trotzdem den konkreten Zugriff abdecken; Gültigkeitsdauer und der Umgang mit entzogenen Rechten gehören zum Entwurf.

Die Auswahl eines Aufgabenprofils muss deshalb mit den tatsächlich erlaubten Funktionen im Backend übereinstimmen. Für einen risikobasierten Freigabeschritt würde ich die konkrete Aktion samt Parametern zur Prüfung vorlegen. Ändert sich anschließend eine relevante Voraussetzung, muss die Software das berücksichtigen. Eine allgemeine Zustimmung zur Diagnose ist keine Zustimmung zu beliebigen Änderungen.

Auch Datenquellen können Anweisungen enthalten, etwa in einer Logzeile oder einem Dokument. Wenn der Agent solchen Text als Handlungsanweisung übernimmt, entsteht das Risiko einer Prompt Injection. Solche Inhalte müssen als Daten behandelt und von den autorisierten Handlungsregeln getrennt werden. Das gilt auch für Inhalte, die in einem internen System gespeichert sind. Beschränkte Werkzeugrechte, Validierung und kontrollierte Ausführung ergänzen die Vorgaben im Prompt.

Anthropic formuliert den Zielkonflikt so: „Agentic systems often trade latency and cost for better task performance.“ Mehr Untersuchungsschritte können bessere Ergebnisse ermöglichen und dafür zusätzliche Zeit und Kosten benötigen.

Zur Bewertung gehören sämtliche Modellaufrufe, verarbeiteten Tokens, Werkzeugzugriffe und Wiederholungen eines Auftrags. Für agentische Abläufe würde ich deshalb explizite Abbruchbedingungen und Iterationsgrenzen festlegen. Außerdem sollte erkennbar sein, welcher Aufwand für die eigentliche Ausführung und welcher für ihre Koordination entsteht. Solche Grenzen müssen in der Laufzeit durchgesetzt werden.

Ich würde Erfolgsquote, Zeitaufwand und Kosten gemeinsam betrachten. Die Kosten pro erfolgreicher Erledigung sollten auch den Aufwand der fehlgeschlagenen Versuche enthalten. Ein günstiger Aufruf bringt wenig, wenn der Agent danach mehrfach erfolglos weiterarbeitet. Eine teurere Untersuchung kann sich dagegen lohnen, wenn sie die Aufgabe nachweisbar besser erledigt.

Ob der Agent erfolgreich war, ergibt sich aus dem vereinbarten Ziel. Bei einer Diagnose braucht es eine belegbare Einordnung der Ursache oder eine begründete Feststellung, dass die Informationen dafür nicht ausreichen. Bei einem Neustart muss feststehen, ob nur dessen Auslösung oder auch der erfolgreiche Abschluss des neuen Imports zum Auftrag gehört. Anthropic unterscheidet bei der Evaluation von Agenten zwischen dem aufgezeichneten Ablauf und dem tatsächlichen Zustand der Umgebung am Ende eines Versuchs.

Den Test würde ich vor der Umsetzung anhand konkreter Fälle definieren: eine behobene Ursache, weiterhin ungültige Eingaben, fehlende Berechtigung, veraltete Daten und eine verlorene Antwort nach angenommener Aktion. Erfolg bedeutet dabei auch, korrekt abzulehnen oder mit nachvollziehbarem Grund abzubrechen. Erneutes Starten ist nur dann das richtige Ergebnis, wenn es zum Auftrag und zum tatsächlichen Zustand passt.

Wiederholte Durchläufe zeigen, ob das Verhalten stabil genug für die Aufgabe ist. Ich würde sowohl den erreichten Zustand als auch unzulässige Aufrufversuche, unnötige Wiederholungen, Laufzeit und Kosten prüfen. Ein gespeichertes Ergebnis lässt sich häufig mit Code verifizieren. Eine offene Diagnose kann zusätzlich eine fachliche Beurteilung benötigen. Bewertet ein anderes Sprachmodell die Antwort, muss auch diese Bewertung gegen menschliche Urteile kalibriert werden.

Im Betrieb braucht es zudem ein nachvollziehbares Protokoll von Auftrag, Werkzeugaufrufen und Zustandsänderungen. Solche Ablaufspuren werden als Traces bezeichnet. Die Erfassung dieser Spuren und die Beobachtung des Agentenverhaltens gehören zum Betrieb. Damit lässt sich untersuchen, wo ein Fehler entstanden ist. Evaluationen sollten nach relevanten Änderungen erneut laufen; Betriebsbeobachtung ergänzt diese Tests.

Semantik, Eingabevalidierung und Berechtigungen sind bekannte Aufgaben der Softwareentwicklung. Bei agentischer Nutzung erhält jedoch ein Modell mehr Spielraum, Informationen auszuwählen und Funktionen zu kombinieren. Deshalb werden die Beschreibungen, Rückgaben und Ausführungsgrenzen dieser Funktionen zu einem wichtigen Teil der Bedienbarkeit.

Im Importbeispiel greifen die drei Ansätze ineinander: Die durch Agentic AI gesteuerte Untersuchung nutzt Daten mit nachvollziehbarer Bedeutung und Herkunft. Agentic First betrifft den Entwurf der Funktionen, mit denen diese Untersuchung und ein zulässiger Neustart möglich werden. Ob die Architektur trägt, zeigt sich am Ergebnis: Der Agent muss den ursprünglichen Fehler einordnen und die aktuellen Neustartvoraussetzungen prüfen. Erfolgt ein Neustart, muss er dessen Ergebnis korrekt wiedergeben. Ist kein Neustart zulässig, muss er die Ablehnung nachvollziehbar begründen.