Von „Go Ahead“ bis „Done“: Zustand, Freigabe und Idempotenz für handelnde Agenten
Erfahren Sie, wie explizite Vorschläge, gebundene Genehmigungen, Neuvalidierung, Idempotenzschlüssel sowie Ergebnisüberprüfung einen mehragentenbasierten Rückerstattungsprozess in einen vertrauenswürdigen Prozess verwandeln.
Quellen: The Architecture of a Multi-Agent System That Can Actually Take Action
Eine Multi-Agent-Demo endet in der Regel mit einer überzeugenden Antwort. Ein Produktivsystem beginnt anschließend mit seiner schwierigsten Aufgabe, sobald der Benutzer antwortet „Großartig, machen Sie weiter“ und die Software eine konversationelle Empfehlung in eine tatsächliche Änderung in einem anderen System umsetzen muss. Dieser Artikel verfolgt einen einzelnen Rückerstattungsantrag durch einen Koordinator, einen spezialisierten Agenten, gespeicherte Vorschläge, menschliche Freigabe und Ausführung und zeigt auf, welche Verantwortlichkeiten dem Modell zukommen und welche im Anwendungscode bleiben müssen. Am Ende erhalten Sie eine konkrete Checkliste, um zu entscheiden, ob ein agiler Workflow bereit ist, in der Realität zu handeln.
Was ändert sich, wenn ein Assistent handeln muss
Bis zum Zeitpunkt der Genehmigung musste der Assistent lediglich eine Anfrage interpretieren und eine hilfreiche Antwort liefern. Sobald der Benutzer zustimmt, treten andere Verpflichtungen auf. Das System muss genau daran erinnert werden, was es angeboten hat, das richtige Datensatz finden, den für die Aufgabe zuständigen Komponenten auswählen, bestätigen, ob die Aktion immer noch sinnvoll ist, überprüfen, ob dieser Benutzer sie autorisieren darf, einen externen Dienst aufrufen, mit Fehlern umgehen und schließlich etwas feststellen, was einfach klingt, aber selten der Fall ist: ob die Aktion tatsächlich stattgefunden hat.
Die bekannte Demo-Architektur umfasst nur den ersten Teil. Ein Orchestrierer erhält die Anfrage, delegiert sie an Spezialisten, diese rufen Tools auf, und es kommt eine Antwort zurück. Diese Struktur ist wertvoll, doch für reale Abläufe stellt sie lediglich den Eingangspunkt dar. Ein sicheres Vorgehen erfordert expliziten Zustandsverlauf, Autorisierungen, Workflows, die Wartezeiten überstehen, Neubewertungen, Idempotenz, Wiederherstellung bei unklaren Fehlern sowie Nachweise dafür, dass die Aufgabe abgeschlossen ist. Genau an diesem Punkt wird das Design von Agenten zu einem Architekturproblem statt zu einem Problem der Anweisungsgabe.
Aufzeichnung einer einzelnen Rückerstattungsanfrage
Nehmen wir eine Anfrage, die ein Kunde an einen Support-Assistenten senden könnte: Prüfen Sie Bestellung Nr. 4821, entscheiden Sie, ob sie für eine Rückerstattung in Frage kommt, und erstellen Sie gegebenenfalls einen Entwurf zur Freigabe. Ein menschlicher Agent würde diesen Prozess in etwa zehn Schritte unterteilen:
- Ermitteln, was der Kunde verlangt.
- Die Bestellung abrufen.
In der Software benötigt jeder dieser Übergänge einen Verantwortlichen sowie einen Ort, an dem er abgebildet wird. Eine funktionierende Abfolge leitet die Anfrage vom Benutzer an einen Orchestrierer weiter, anschließend an einen Spezialisten, der Beweise sammelt und einen Vorschlag erstellt, dieser wird genehmigt, umgesetzt und schließlich überprüft.
- Die Weiterleitung der Anfrage ist die Aufgabe des Orchestrierers.
- Der Spezialist führt die Untersuchung im jeweiligen Bereich durch.
- Tools verbinden das System mit Dokumentationen und aktuellen Datensätzen.
- Der explizite Zustand gibt die vorgeschlagene Aktion an.
- Der Benutzer genehmigt einen bestimmten Vorschlag.
Ein einziges Prinzip verbindet diese Elemente miteinander:
Das Modell kann entscheiden, was geschehen sollte; die Anwendung entscheidet, was zulässig ist.
Die folgenden Auszüge sind architektonische Skizzen in Python unter Verwendung von LlamaIndex. Die Konfiguration des Modells sowie die Integrationen von Speicher- und Servicekomponenten werden weggelassen, und Bezeichnungen wie llm und policy_retriever stehen für Komponenten, die Ihre Anwendung bereitstellen würde. Einige Auszüge weisen außerdem zusammengefasste Zeilenumbrüche auf (zum Beispiel sind Aussagen in einer Zeile zusammengefasst), sodass sie eher als Überblick denn als Code zum Kopieren und Einfügen gelesen werden sollten.
Trennung der Routenverwaltung von spezialisierten Aufgaben
Der schnellste Weg, einen Agenten zu erstellen, besteht darin, ihm alle Werkzeuge auf einmal zur Verfügung zu stellen: Dokumentensuche, Bestellabfrage, Zahlungsprüfungen, Rückerstattungen, E-Mail-Kommunikation, Berichterstellung. Für eine kleine Anwendung ist das völlig vernünftig. Wenn sich jedoch die Verantwortlichkeiten ansammeln, wird es schwierig, die Aufgaben des Agenten in einem Satz zu beschreiben, und eine Frage zur Lieferzeit muss sich dann mit einer Aufgabe teilen, die mit Geld umgeht.
Eine klarere Trennung teilt zwei Aufgabenbereiche voneinander: die Entscheidung darüber, wohin eine Anfrage gehört, und die Ausführung der spezialisierten Arbeit daran. Für den Support-Assistenten bedeutet das einen Koordinator, der allgemeine Fragen entgegennimmt und Anfragen im Zusammenhang mit Rückerstattungen an einen spezialisierten Experten weiterleitet. Der Experte wird mithilfe von LlamaIndex’s FunctionAgent erstellt:
from llama_index.core.agent.workflow import FunctionAgent
Durch seine Definition erhält es eine enge Aufgabestellung, drei Werkzeuge sowie die Befugnis, die Kontrolle an den Koordinator zurückzugeben. Beachten Sie, dass der Systemhinweis verlangt, dass es seine Beweise vor dem Vorschlagen von etwas erläutert:
refund_specialist = FunctionAgent(
name="refund_specialist",
description="Checks refund eligibility and prepares proposals.",
system_prompt=(
"Check the order and the applicable policy. "
"Explain your evidence before proposing a refund. "
"Hand back unrelated requests to the coordinator."
),
tools=[get_order, search_policy, prepare_refund],
llm=llm,
can_handoff_to=["coordinator"],
)
Das Feld description dient nicht der Dekoration; es ist Teil der Architektur. Ein Etikett wie „hilfreicher Assistent“ vermittelt keine Informationen. „Prüft die Erstattungsfähigkeit und erstellt Vorschläge“ definiert eine Verantwortung, die getestet und geprüft werden kann. In LlamaIndex sind die Klassen FunctionAgent und AgentWorkflow genau für diese Art von expliziter Übergabe konzipiert. Falls Sie noch ein Framework auswählen, behandelt der Vergleich von LangChain und LlamaIndex die umfassenderen Abwägungen.
Das Hinzufügen von Agenten ist nicht automatisch eine Verbesserung. Jeder Spezialist verursacht Koordinationsaufwand, weshalb jeder seine Notwendigkeit nachweisen muss. Hier bildet ein Paar von Agenten – ein Koordinator und ein Erstattungsspezialist – eine sinnvolle Trennung ohne zusätzlichen Aufwand.
Vernetzung des Koordinators mit dem Spezialisten
Sowohl der Koordinator als auch der Workflow, der die beiden Agenten verbindet, stammen aus demselben Modul:
from llama_index.core.agent.workflow import AgentWorkflow
Der Koordinator hat Zugriff auf die Richtliniensuche für allgemeine Fragen und kann Aufgaben an den Erstattungsspezialisten weiterleiten. AgentWorkflow registriert beide Agenten und macht den Koordinator zum Wurzelelement, das alle Anfragen erhält. Im Auszug befinden sich der schließende Klammernzeichen des Koordinators sowie die Zuweisung des Workflows auf derselben Zeile; es handelt sich dabei um zwei getrennte Anweisungen:
coordinator = FunctionAgent(
name="coordinator",
description="Answers general questions and routes refund requests.",
system_prompt=(
"Use documentation for general questions. "
"Hand refund requests to the refund specialist."
),
tools=[search_policy],
llm=llm,
can_handoff_to=["refund_specialist"],
)workflow = AgentWorkflow(
agents=[coordinator, refund_specialist],
root_agent="coordinator",
)
Dadurch erhält die Anfrage einen Pfad. Der Koordinator erkennt eine Rückerstattungsanfrage und leitet sie weiter; der Spezialist holt die Bestellung ab, prüft die Richtlinien, notiert, was noch fehlt, und erstellt bei ausreichenden Beweisen einen Vorschlag.
Der Ablauf im Gespräch variiert. Ein Kunde gibt den Liefertermin bereits im Voraus an; ein anderer fragt zuerst nach den Rückerstattungsregeln und erwähnt die Bestellung erst drei Nachrichten später. Die Agenten können diese Unterschiede berücksichtigen, während die Anwendung weiterhin festlegt, welche Funktionen verfügbar sind und wie sie eingesetzt werden dürfen.
Gespräche können flexibel bleiben, während die damit verbundenen Abläufe kontrolliert werden.
Beweise vor der Eignungsprüfung
Das Versenden der Anfrage an den richtigen Agenten macht dessen Schlussfolgerung noch nicht richtig. Der Spezialist muss weiterhin Beweise sammeln.
Nehmen wir an, die Richtlinie erlaubt es, unöffnete Produkte innerhalb eines Zeitraums von 30 Tagen zurückzusenden, während die Bestellunterlagen zeigen, dass Bestellung #4821 vor 12 Tagen eingegangen ist. Diese Informationen stammen aus zwei verschiedenen Systemen, und beide sind notwendig: Die Richtlinie legt die Regel fest, die Bestellung beschreibt die Situation, und die Eignung ergibt sich erst durch ihre Kombination. Die Abfrage wird somit zu einem Schritt im Arbeitsablauf. Der Spezialist durchsucht die Richtliniedokumente, während er gleichzeitig die aktuelle Bestellunterlage lädt.
Ein minimales Tool zur Richtliniensuche beginnt mit einer asynchronen Signatur sowie einer Dokumentation, die dem Agenten mitteilt, wofür das Tool dient:
async def search_policy(question: str) -> list[dict]:
"""Find policy passages relevant to a customer request."""
Der Codeabschnitt holt die passenden Abschnitte ab und gibt jeden davon zusammen mit seinem Quelltitel und -abschnitt zurück. Wie im vorherigen Beispiel gehören der Aufruf von aretrieve und die return-Anweisung auf getrennte Zeilen:
matches = await policy_retriever.aretrieve(question) return [
{
"text": match.node.get_content(),
"source": match.node.metadata.get("title"),
"section": match.node.metadata.get("section"),
}
for match in matches
]
Wichtig ist, was zusammen mit dem Text übermittelt wird: seine Herkunft. Falls der Assistent später behauptet, dass die Bestellung innerhalb des Rückerstattungsfensters liegt, sollte die Erklärung in der Lage sein, auf den entsprechenden Abschnitt der Richtlinie zu verweisen, der dieses Fenster definiert. Die Herkunft hat jedoch ihre Grenzen:
Eine Quelle kann nicht beweisen, dass eine Interpretation richtig ist; sie ermöglicht lediglich einer Person, diese zu überprüfen.
Der Zustand „ungeöffnet“ weist eine Lücke auf: Im Bestellsystem wird nicht festgehalten, ob das Paket geöffnet wurde. Die richtige Vorgehensweise besteht darin, nicht zu raten, sondern den Kunden zu fragen. Ein robuster Entwurf zeigt fehlende Informationen explizit an, anstatt Unsicherheiten in eine zuversichtliche Empfehlung umzuwandeln.
Gesprächshistorie ist kein Anwendungsstatus
Man geht davon aus, dass die Prüfung abgeschlossen ist. Der Spezialist teilt mit, dass Bestellung Nr. 4821 für eine Rückerstattung von 79 € in Frage kommt, und fragt, ob weiter vorgegangen werden soll. Der Benutzer antwortet mit ja.
Die Weiterleitung funktionierte, die Prüfung war erfolgreich und die Tools lieferten ihre Beweise – dennoch besteht weiterhin eine Lücke. Das System kann nicht genau angeben, was genehmigt wurde: Die Bestellung, der Betrag sowie die Währung und auch die Version des Angebots werden nur angenommen, aber nicht festgehalten. Falls im Gespräch zwei Bestellungen angesprochen wurden oder der Betrag nach dem Angebot neu berechnet wurde, wird das Wort „ja“ mehrdeutig.
Deshalb dürfen folgende Schritte nicht nur im Chatverlauf festgehalten werden. Die Anwendung benötigt eine ausdrückliche Aufzeichnung der ausstehenden Aktion, wie zum Beispiel diese:
pending_action = {
"proposal_id": "refund-proposal-17",
"order_id": "4821",
"amount_minor": 7900,
"currency": "EUR",
"status": "awaiting_approval",
"evidence": [
"returns-policy:section-3",
"order:4821",
],
}
Das Feld status ist nützlich, doch proposal_id ist der entscheidende Faktor. Die Genehmigung sollte auf den genauen Vorschlag verweisen, den der Benutzer gesehen hat. Wenn sich die Beträge ändern, handelt es sich um einen neuen Vorschlag. Wenn sich die Reihenfolge ändert, handelt es sich um einen neuen Vorschlag. Wenn neue Beweise die Empfehlung ändern, handelt es sich um einen neuen Vorschlag. Das Geld wird als amount_minor in ganzzahligen Cent angegeben, wodurch Rundungsprobleme bei Fließkommazahlen vermieden werden, und die evidence-Liste zeigt an, welche Richtlinienabschnitte und Reihenfolgeaufzeichnungen das Angebot rechtfertigen.
Die Transkription dient dem Verständnis; der strukturierte Zustand dient zur Handlung.
Das Gespräch hilft dem Modell dabei, zu verstehen, was mit „weitermachen“ gemeint ist. Der gespeicherte Vorschlag gibt der Anwendung etwas Eindeutiges zum Ausführen.
Genehmigung als Daten statt als Worte
Die naive Art, Zustimmung zu erfassen, besteht aus einem einzigen Faktum:
user said yes
Ein sichereres Modell verbindet Identität, Vorschlag, Aktion und Kontext miteinander:
user X approved proposal Y,
containing action Z,
under the current conditions.
Diese Unterscheidung wird entscheidend, sobald ein Agent externe Systeme beeinflussen kann. Die Zustimmung sollte eine bestimmte Person mit einer bestimmten vorgeschlagenen Aktion verknüpfen – niemals mit etwas, was das Modell später rekonstruiert. Der Vorschlag muss daher alle relevanten operativen Details enthalten:
- das Zielobjekt
- die Menge
- die Währung
- die unterstützenden Belege
- der aktuelle Status
- einen eindeutigen Vorschlag-Identifikator
Natürliche Sprache erklärt der Benutzer die Aktion; der strukturierte Vorschlag definiert sie für das System.
Warten ist Teil des Workflows
Menschliche Genehmigung führt außerdem zu Zeitverzögerungen. Der Benutzer kann sofort antworten, nach dem Mittagessen oder am nächsten Tag nach Schließen des Browsers. Wenn ein Workflow von einer Person abhängt, ist eine Pause kein Sonderfall, sondern eine normale Phase – daher muss die ausstehende Arbeit gespeichert und später wieder aufgenommen werden.
LlamaIndex stellt Workflow-Kontextobjekte sowie Möglichkeiten zur Pause für menschliche Eingaben bereit, wodurch diese Interaktion strukturiert wird. Dauerhafte Speicherung, Autorisierung, Ablaufregeln sowie der umgebende Anwendungslebenszyklus bleiben jedoch in Ihrer Verantwortung.
Bei einer so wichtigen Angelegenheit wie einem Rückzahlungsvorgang besteht eine sinnvolle Arbeitsteilung darin, dass der Agent den Vorschlag vorbereitet und der gewöhnliche Anwendungscode die genehmigte Aktion ausführt. Der Genehmigungsverarbeiter beginnt damit, den gespeicherten Vorschlag zu laden:
async def approve_refund(proposal_id, user):
proposal = await proposals.load(proposal_id)
Dann wird überprüft, ob die Berechtigungen vorliegen, bestätigt, dass der Vorschlag noch ausstehend ist, er wird neu validiert, der Zahlungsdienst wird mit der Vorschlags-ID als Idempotenzschlüssel aufgerufen, und die Quittung wird gespeichert. Im Auszug werden diese asynchronen Aufrufe auf gemeinsamen Zeilen ausgeführt; jeder await ist eine eigene Anweisung:
await permissions.require(
user,
"approve_refund",
proposal,
) await proposals.require_pending(proposal) await refunds.revalidate(proposal) receipt = await payments.refund(
order_id=proposal.order_id,
amount_minor=proposal.amount_minor,
idempotency_key=proposal.id,
) await proposals.mark_completed(
proposal.id,
receipt,
) return receipt
Mehrere Grenzen sind in dieser kurzen Funktion verborgen:
- Der Vorschlag stammt aus dem gespeicherten Zustand und nicht aus der Konversation.
- Die Autorisierung wird außerhalb des Modells durchgesetzt.
- Der Code bestätigt, dass der Vorschlag noch auf Genehmigung wartet, was eine zweite Ausführung über diesen Weg verhindert (unter Konkurrenzsituationen sollte diese Überprüfung atomar mit der Statusaktualisierung erfolgen).
- Die Eignung wird unmittelbar vor der Ausführung neu validiert.
- Der Zahlungsaufruf verwendet einen stabilen Idempotenzschlüssel.
- Das Ergebnis wird persistiert.
Die Abfolge erstreckt sich von einem gespeicherten Vorschlag über eine autorisierte Genehmigung, eine erneute Überprüfung sowie die eigentliche Ausführung bis hin zu einem gespeicherten Ergebnis. Diese Abfolge ist weitaus wichtiger als die Frage, ob der Agent seine Nachricht perfekt formuliert hat.
Erneut überprüfen, bevor man handelt
Warum noch einmal prüfen, nachdem der Benutzer bereits zugestimmt hat? Weil die Welt weiterläuft, während das System wartet. Die Bestellung könnte bereits über einen anderen Support-Kanal erstattet worden sein, der Zahlungszustand könnte sich geändert haben, jemand könnte die Bestellung bearbeitet haben oder ein paralleler Workflow könnte die Operation bereits durchgeführt haben.
Ein Vorschlag ist ein Momentaufnahme dessen, was zum Zeitpunkt seiner Erstellung korrekt erschien. Die Ausführung erfolgt danach, manchmal viel später. Vor einer bedeutenden Operation sollte die Anwendung bestätigen, dass die Annahmen hinter dem Vorschlag weiterhin gelten.
Ein Ja gewährt die Erlaubnis zum Handeln; es hindert die Welt nicht daran, sich zu verändern.
Höher die Zeitdauer, in der ein Vorschlag unentschieden bleibt, desto wichtiger wird dies. Die Kombination aus erneuter Überprüfung und Ablaufzeit für Vorschläge hält den Zeitraum der veralteten Annahmen in Grenzen.
Wiederholte Versuche dürfen die Aktion nicht wiederholen
Betrachten wir einen weiteren Misserfolg: Der Benutzer stimmt zu, die Anwendung sendet den Rückzahlungsbetrag, der Zahlungsdienstleister verarbeitet ihn – doch das Netzwerk bricht ab, bevor eine Antwort eintrifft. Der Client versucht es erneut. Soll der Kunde einen zweiten Betrag von 79 Euro erhalten? Offensichtlich nicht.
Idempotenz verhindert das. Ein stabiler Operationsschlüssel ermöglicht es jedem externen Service, der Idempotenz unterstützt, zwei Anfragen als eine logische Operation zu erkennen. Anstatt die Wiederholungsanfrage als „weitere Rückerstattung auslösen“ zu interpretieren, behandelt der Service sie als Anfrage nach dem Status oder Ergebnis der bereits mit Vorschlag #17 verknüpften Operation. Die Verwendung des Vorschlagsids als Schlüssel funktioniert, weil jeder genehmigte Vorschlag höchstens eine Rückerstattung auslösen sollte. Die Mechanismen auf der Serverseite werden ausführlicher in Understanding Idempotency Keys in Node.js POST Endpoints erläutert.
Dies kommt in ausgereiften Mehr-Agenten-Demos nur selten vor. Sobald ein System jedoch Geld überweisen, Nachrichten senden, Datensätze ändern, Tickets erstellen oder irgendeine andere reale Wirkung auslösen kann, gehören Wiederholungsversuche zur Architektur.
"Unbekannt" ist ein legitimes Ergebnis
Nun der unangenehmste Fall: Der Zahlungsvorgang läuft über die Frist hinaus. Vielleicht ist nichts passiert, oder vielleicht wurde das Geld kurz vor Abbruch der Verbindung überwiesen. Für den Kunden macht das einen Unterschied von 79 Euro aus.
Dem Benutzer mitzuteilen, dass die Rückerstattung fehlgeschlagen ist und erneut versucht wird, wäre falsch, denn nichts stützt diese Behauptung. Das System verfügt lediglich über das Fehlen einer Bestätigung, was ein anderer Umstand ist. Ein zuverlässiger Arbeitsablauf sorgt dafür, dass diese Unsicherheit sichtbar bleibt: Anstatt die Operation zu wiederholen, wird der Status des bestehenden Transaktionsablaufs abgefragt, und in der Zwischenzeit wird dem Benutzer etwas Genaueres mitgeteilt, wie zum Beispiel, dass die Abschlussbestätigung nicht möglich war und der Status überprüft wird.
Diese Disziplin gilt in jeder Phase, nicht nur zum Zeitpunkt der Zahlung:
- Wenn die Abfrage eines Auftrags fehlschlägt, ist das Vorhandensein des Auftrags unbekannt – nicht widerlegt.
Toxische Systeme modellieren dies als separate Zustände, anstatt sie in „fehlgeschlagen“ oder „nicht gefunden“ zusammenzufassen.
Eine zurückgegebene Toolaufruf bedeutet noch nicht Fertigstellung
Hier geht die Architektur über die reine Orchestrierung hinaus. Ein zurückkehrender Toolaufruf bedeutet nicht, dass die Arbeit abgeschlossen ist. Eine Fehlerantwort deutet darauf hin, dass es nicht abgeschlossen ist. Ein Timeout ebenfalls nicht. Wenn die Anwendung nicht feststellen kann, ob eine Rückerstattung stattgefunden hat, ist sie sicherlich noch nicht fertig.
Eine stärkere Definition der Fertigstellung wäre, dass das System Beweise dafür liefern kann, dass das gewünschte Ergebnis tatsächlich eingetreten ist. Das verschiebt den Vertrag. Das Ziel ist nicht dieses:
call refund()
Das Ziel ist dieses:
establish that refund proposal #17
for order #4821
was successfully processed exactly once
Das sind sehr unterschiedliche Garantien, und genau dieser Unterschied ist der Grund, warum Orchestrierer und Spezialisten nur der Anfang des Designs sind.
Nine Fragen, bevor ein Mehr-Agentensystem handeln kann
Bevor Sie einen KI-Arbeitsablauf mit Aktionen mit tatsächlichen Folgen verbinden, beantworten Sie zunächst diese Fragen:
- Hat jedes Agent eine begrenzte Verantwortung, die man in einem Satz beschreiben kann?
- Kann eine wichtige Entscheidung auf die dahinterliegenden Dokumente und Aufzeichnungen zurückverfolgt werden?
- Kann fehlende Information explizit als unbekannt bleiben, oder verwandelt sich die Unsicherheit heimlich in eine zuversichtliche Empfehlung?
- Wird die vorgeschlagene Aktion als strukturierten Zustand gespeichert oder existiert sie nur im Gespräch?
- Stimmt der Benutzer einem präzisen Vorschlag zu, sodass ein „Ja“ etwas Bestimmtes autorisiert?
Falls auf einige dieser Fragen keine klare Antwort existiert, haben Sie möglicherweise trotzdem eine beeindruckende Demo – aber vermutlich noch kein System, dem man zum Handeln vertrauen kann.
Zusammenfassung
Prüfen Sie die ursprüngliche Anfrage erneut: Überprüfen Sie Bestellung Nr. 4821 und bereiten Sie eine Rückerstattung zur Freigabe vor. Jeder Bestandteil hat nun seinen Platz gefunden. Der Koordinator leitet die Aufgaben weiter, der Spezialist sammelt Beweise, die Tools werden mit Dokumentationen und Live-Daten verknüpft, der explizite Status speichert den Vorschlag, eine Person genehmigt eine bestimmte Aktion, der Anwendungscode überprüft Berechtigungen und validiert erneut, das Zahlungssystem führt die Transaktion aus, und das Ergebnis wird gespeichert und bestätigt. Zu diesem Zeitpunkt kann der Assistent eine angenehm langweilige Antwort geben: Die Rückerstattung von 79 € für Bestellung Nr. 4821 wurde bearbeitet, wobei eine Bestätigung beigefügt ist. Dieser Satz ist glaubwürdig, dank all dessen, was dahintersteckt.
Sobald ein System wächst, bleiben dieselben Fragen von Bedeutung. Besitzt jemand jede einzelne Funktionalität? Können die Beweise hinter einer Entscheidung überprüft werden? Behält der Arbeitsablauf Unsicherheiten bei und kann er sich erholen, wenn eine Abhängigkeit fehlschlägt? Kann eine Person genau erkennen, was sie genehmigt, und kann das System nachweisen, dass das beabsichtigte Ergebnis eingetreten ist? Die Antworten zeigen an, wo ein weiterer spezialisierter Agent Wert hinzufügt, wo eine einfache Funktion ausreicht und wo strengere Grenzen erforderlich sind. Die beste agentenbasierte Erfahrung kann mit einem einfachen Wort enden – „Erledigt“ – und die Architektur sorgt dafür, dass dies glaubwürdig erscheint.