Entwurf von umgebungsorientierten KI-Agenten: Wiederbelebungskanäle, kostengünstiger Ruhezustand und sichere Wiederbelebung.

Die meisten Schriften über KI-Agenten beginnen mit dem Moment, in dem eine Anfrage eintrifft und der Zyklus in Gang kommt. Ein ambienter Agent, also einer, der selbstständig Postfächer, Warteschlangen und Dashboards überwacht, verbringt fast seinen gesamten „Lebenszyklus“ im gegenteiligen Zustand: Es passiert nichts, und das System muss immer wieder entscheiden, ob gerade etwas begonnen hat. Dieser Leitfaden befasst sich mit dieser inaktiven Zeit. Am Ende werden Sie in der Lage sein, die Schicht zu entwerfen, die entscheidet, wann ein Agent aktiv wird, die Kosten für den Ruhezustand nahe Null zu halten, jeden Aktivierungsprozess vor Duplikaten, Veraltungen und Manipulationen zu schützen sowie zu messen, ob die gesamte Konfiguration tatsächlich den Menschen hilft, deren Arbeit unterbrochen wird.

Ein warnendes Szenario: Für jedes „Nein“ bezahlen

Stellen Sie sich ein Team vor, das einen Agenten entwickelt, um seine Support-E-Mail-Box sowie seinen Notdienst-Kanal zu überwachen. Das Ziel ist einfach: Alles, was eine menschliche Intervention erfordert, bereits dann zu markieren, bevor jemand anderes es bemerkt. Das Prototyp zeigt in Demos beeindruckende Leistungen. Doch dann kommt die erste monatliche Rechnung – sie ist höher als die Gesamtkosten für die IDE-Lizenzen des Teams, die CI-Zeiten sowie die Tools zur Überwachbarkeit – und das für einen Agenten, der in dreißig Tagen etwa elf nützliche Aktionen durchführte.

Der Grund ist eine Architektur, die niemand schriftlich festgehalten hat. Um den Posteingang „zu überwachen“, wurde alle zwei Minuten ein geplanter Job ausgeführt, der die neuesten Nachrichten sammelte und anschließend ein Grenzmodell fragte, ob eine davon Aufmerksamkeit erforderte. Im Laufe eines Monats geschah das etwa zweißigtausendmal. Fast jede Antwort lautete auf ein sorgfältig begründetes „Nein“. Die elf „Ja“-Antworten waren hervorragend, doch die Rechnung wurde vor allem von den negativen Ergebnissen bestimmt. Das teuerste, was das System tat – um etwa drei Größenordnungen – war die Bestätigung, dass sich nichts geändert hatte.

An anderer Stelle in derselben Infrastruktur befand sich ein alter cron-Job, der alle Minute einen Festplattenschwellenwert überprüfte. Im Laufe seiner Existenz kostete er im Grunde nichts. Der Unterschied ist die Lektion dieses gesamten Themas: Warten ist etwas, das man entwirft – nicht etwas, das standardmäßig geschieht.

Die zentrale Idee ist folgende: Ein Ambient-Agent wird weit mehr durch das definiert, was ihn aktiviert, als durch das, was er nach der Aktivierung tut. Die eigentliche Herausforderung besteht darin, so kostengünstig wie möglich zu entscheiden, welches von Tausenden eingehender Ereignisse die Aufmerksamkeit eines Modells verdient – in Kombination mit einem ruhenden Zustand, der bis zur Aktivierung keinerlei Kosten verursacht. Chat-Agenten müssen sich mit diesem Problem nie auseinandersetzen, denn eine Person hat bereits vor dem Tippen entschieden, ob die Nachricht gesendet werden soll. Entfernt man diese Person aus dem Auslösepfad, wird die Sortierung zur eigenen Aufgabe. Löst man das Problem mit dem großen Modell selbst, hat man im Grunde den teuersten Spezialisten engagiert, um die Nachrichten zu sortieren.

Dies baut auf einigen Ideen auf, die eine eigene Behandlung verdienen: langlebige Ausführung (eine Laufzeit, die tagelang ohne Rechenleistungsaufwand bestehen kann), zeitliche Verankerung (was ein Agent beim Erwachen neu über den „Jetzt“-Zustand lernen muss) sowie Zielverschiebungen bei lang lebenden Agenten. Sie werden weiter unten dort behandelt, wo sie relevant sind.

Jeder Prompt war bereits ein Ereignis

Eine Chatanfrage erscheint als natürlicher Ausgangspunkt für einen Agenten, versteckt aber viel ungenutzte Arbeit. Die Person, die sie gesendet hat, hat drei Dinge getan, bevor ein einziger Token verarbeitet wurde: Sie entschied, dass die Situation eine Handlung rechtfertigt – das ist die Priorisierung. Sie fasste sie in wenige Sätze zusammen – das ist die Zusammenstellung des Kontexts. Und sie schickte sie zu einem bestimmten Zeitpunkt – das ist die zeitliche Steuerung. Ein Chatagent ist im Grunde ein Agent, der auf einer von einem Menschen angetriebenen Ereignisstruktur arbeitet.

Ambient-Agents – ein Begriff, den LangChain für Agenten populär gemacht hat, die einen Ereignisstrom konsumieren und darauf reagieren, möglicherweise gleichzeitig mehrere Ereignisse verarbeiten – ersetzen den Menschen dabei. Alle drei kostenlosen Dienste verschwinden. Was übrig bleibt, ist ein Ingenieurproblem mit fünf unterschiedlichen Eingabetypen, von denen jeder sich anders verhält:

• Nachrichten. Eine Person schreibt an den Agenten. Solche Fälle sind selten, bereits durch menschliches Urteilsvermögen gefiltert und enthalten klare Absichten. Das ist der einfache Fall.
• Zeitpläne. Cron und alle daraus abgeleiteten Systeme. Ein Zeitplan wird ausgelöst, unabhängig davon, ob etwas passiert ist oder nicht. Das ist nützlich, weil es Dinge erfasst, die Ereignisströme übersehen, aber auch verschwenderisch, da die meisten Auslösungen ohne Reaktion bleiben.

Ereignisse. Webhooks, Warteschlangen-Nachrichten, neue Zeilen in einer Tabelle. Die Außenwelt schickt sie Ihnen zu. Sie kommen in großen Mengen, in Wellen, ohne jegliche Sortierung, und werden von anderen Systemen sowie Unbekannten erstellt – nicht von Ihrem Benutzer.

Überwachungen. Bedingungen bezüglich des Zustands: Ein Pull Request wurde für die Fusion freigegeben, ein Dokument wurde geändert, ein Kunde antwortet nicht mehr. Nichts schickt diese Informationen an Sie. Irgendetwas muss sie bemerken, und das Bemerken hat seinen Preis.

Schwellenwerte. Eine Metrik hat eine Grenze überschritten. Dies ist der älteste Auslöser in der Betriebsführung, und er bringt jahrzehntelange, mühsam erlangte Erkenntnisse zur Alarmierung bezüglich Überlastung, unregelmäßiger Aktivitäten und Toleranzbereichen mit sich – Erkenntnisse, die Entwickler von Automatisierungen heute neu entdecken.

Das Entwerfen eines inaktiven Agenten bedeutet, zu entscheiden, wie diese Komponenten miteinander verbunden sind. Welche davon kann den Agenten wecken? Was liegt zwischen dem rohen Signal und dem Modell? Was reconstruiert der Agent über die Welt, wenn er wieder aktiv wird? Fällt man in eine Richtung falsch, erhält man das oben beschriebene Szenario – ein Modell, das alle zwei Minuten Stille wahrnimmt. Fällt man in die andere Richtung falsch, schläft der Agent einfach weiter durch den Vorfall, den er eigentlich erkennen soll.

Der Weckkanal: Triage als Treppenhaus

Die entscheidende wirtschaftliche Tatsache ist, dass ein Modellaufruf der teuerste bedingte Prozess ist, den man je schreiben wird. Die Frage an ein Grenzmodell „Ist das wichtig?“ kostet etwa fünf bis sieben Größenordnungen mehr als ein Datenbankfilter, der dieselbe Frage für strukturierte Daten beantwortet. Daher ist die Arbeitsarchitektur niemals eine direkte Verbindung von Ereignis zu Modell. Es handelt sich um einen Trichter: eine Reihe von Stufen, wobei jede Stufe günstiger ist als die nächste und dabei den größten Teil dessen aussortiert, was sie erhält.

Erste Stufe: strukturelle Regeln

Die erste Stufe kostet im Grunde nichts. Es handelt sich um einfachen Code, der die Struktur eines Events überprüft: seinen Typ, seinen Sender, seine Beschriftungen sowie das Repository oder die Warteschlange, aus der es stammt. Newsletter, automatische Benachrichtigungen, Kommentare von Bots sowie Events für Projekte, die dem Agenten nicht gehören, können alle ohne jegliche Bewertung hier hinzugefügt werden. In einer typischen Posteingangskiste muss ein großer Anteil des Rohdatenverkehrs nie weitergeleitet werden. Wenn weniger als die Hälfte Ihrer Rohevents in dieser Stufe verworfen wird, sind Ihre Regeln vermutlich zu restriktiv.

Zweite Stufe: Debouncing und Zusammenfassung

Ereignisse kommen in Wellen, die einen gemeinsamen Ursprung haben: Dutzende von E-Mails in einem Thread, ein Push mit dreißig Commit-Änderungen, Hunderte von Warnungen aus einem defekten Schalter. Die richtige Einheit für die Aufmerksamkeit des Agents ist nicht das einzelne Ereignis, sondern die dahinterliegende Situation. Deshalb legt diese Stufe ein kurzes Zeitfenster fest, gruppiert die eingehenden Ereignisse nach einer Korrelationskennung wie Thread, Pull Request oder Incident und leitet für jede Situation ein einziges kombiniertes Signal weiter.

Auch in dieser Phase ist Geduld erforderlich. Ein Dokument, das einmal geändert wurde, wird in den nächsten Minuten wahrscheinlich noch mehrmals geändert werden. Wenn Sie zu einem festgelegten Zeitpunkt nach der neuesten Änderung – und nicht sofort bei der ersten – reagieren, verringern Sie die Anzahl der Reaktionen erheblich und jede Reaktion erhält ein vollständigeres Bild. Dasselbe Prinzip gilt immer dann, wenn mehrere Benutzer den gemeinsamen Zustand ändern: Eine Serie von vierzig Ereignissen beschreibt in der Regel eine einzige Tatsache.

Hinweis zu Überwachungsmethoden: Abfragen und Vergleiche, niemals Abfragen und Urteile

Überwachungsmethoden erfordern eine Kostendecision, die andere Auslöser nicht benötigen. Irgendetwas muss die Änderung bemerken, und es gibt genau drei Möglichkeiten, dies zu tun:

• Die Quelle sendet eine Benachrichtigung. Ein webhook oder eine Abonnementfunktion informiert Sie, wenn sich der Zustand ändert. Wenn dies möglich ist, nutzen Sie es.

Man führt Abfragen durch und vergleicht. Zu einem festgelegten Zeitpunkt wird der aktuelle Zustand abgerufen, mit dem vorherigen Snapshot verglichen, und ein Event wird nur ausgesendet, wenn sich etwas geändert hat.

Man führt Abfragen durch und beurteilt. Zu einem festgelegten Zeitpunkt wird der Zustand abgerufen und ein Modell wird danach befragt. Genau das ist im anfänglichen Szenario schiefgelaufen.

Das Abfragen an sich verdient einen besseren Ruf, als dieses Szenario nahelegt. Das Abfragen ist kostengünstig; das Beurteilen hingegen teuer. Eine geplante Aufgabe, die eine Seite abruft, sie hasht und mit dem vorherigen Hash vergleicht, kostet pro Jahr nur einen unbedeutenden Betrag. Viele Systeme bieten keine Webhooks an, daher ist „niemals abfragen“ keine realistische Regel. Die eigentliche Regel lautet, dass eine Abfrage mit einem Unterschied enden muss – nicht mit einem Aufruf des Modells. Machen Sie einen Schnappschuss, vergleichen Sie ihn und lassen Sie nur veränderte Elemente als Ereignis in den Prozess ein, wo sie denselben Regeln und Klassifizierern wie alles andere unterliegen. Ob sich etwas geändert hat, ist eine Frage für eine Hash-Funktion. Ob die Veränderung von Bedeutung ist, ist die Frage, für die Sie das Modell vorsehen.

Stufe drei: günstige Klassifizierung

Was den Regeln und der Konsolidierung standhält, wird an ein kleines, schnelles, günstiges Modell mit einer absichtlich eng gefassten Anweisung weitergeleitet – etwa „Antworte mit einem Wort: dringend, relevant oder ignorieren“. Dabei handelt es sich um die bekannte Kaskadenlogik der Modellzuweisung, angewandt auf Benachrichtigungen: Die günstige Stufe nimmt die Unklarheiten auf, die feste Regeln nicht ausdrücken konnten, und nur die Ergebnisse „relevant“ sowie „unsicher“ werden weitergeleitet. Ein kleines Modell, das zu 92 Prozent der Zeit richtig liegt, vor einem großen Modell, das dreißigmal teurer ist – das ist der gesamte wirtschaftliche Grund für diese Stufe. Für einen umfassenderen Überblick darüber, wo die Ausgaben für Agenten entstehen, siehe ein kostenorientiertes Architekturmodell für agentebasierte KI.

Phase vier: der Agent

Nur an diesem Punkt beginnt die vollständige Umsetzung mit der eigentlichen Zusammenstellung im Kontext, den notwendigen Werkzeugen und einem Budget. In einem funktionierenden Funnel erreicht nur ein winziger Teil des Rohverkehrs jenen Punkt – und jeder solche Fall kommt bereits als konkretes Szenario statt als reines Ereignis an.

Phase fünf: der Mensch

Der Funnel setzt sich auch über den Ansprechpartner hinaus fort, denn dieser ist ebenfalls ein Filter: Er entscheidet, welche seiner Erkenntnisse die Zeit eines Menschen wert sind. In dieser letzten Phase entscheidet sich, ob die umgebenden Systeme erfolgreich sind oder nicht – dazu gibt es unten einen eigenen Abschnitt.

Die Mathematik einer Neugestaltung

Wenden Sie dies von Anfang an auf das Team an. Angenommen, sie wechseln die Eingangskorrespondenz von Polling auf Webhooks und fügen strukturelle Regeln hinzu, wodurch etwa 70 % der Rohereignisse entfernt werden, da es sich um Newsletter und automatisierte E-Mails handelt. Das Zusammenfassen nach Themen entfernt weitere etwa 60 % von dem, was übrig bleibt. Ein kleiner Klassifikator markiert anschließend etwa 85 % des Rests als „ignorieren“. Das Frontier-Modell läuft nun etwa dreißig Mal pro Monat, gegenüber 22.000 zuvor, während weiterhin dieselben elf wertvollen Aktionen stattfinden. Die Kosten pro nützlichem Erwachen sinken um mehr als einen Größenordnungskoeffizienten.

Überraschenderweise verbessert sich auch die Genauigkeit. Jedes Erwachen betrachtet nun eine kohärente Situation anstelle irgendeines willkürlich in einem zweiminütigen Zeitfenster fallenden Ausschnitts, sodass das Modell bessere Informationen zum Abwägen hat.

Gut schlafen: Warum ein inaktiver Agent nichts kostet

Zwischen den Wachzuständen existiert der ideale Umgebungsagent überhaupt nicht. Er läuft nicht leise im Hintergrund; es gibt weder einen Prozess noch einen Container und keinen „warmen“ Kontext. Seine gesamte Existenz besteht aus einer Aufzeichnung in einem Speicher: eine Identität, eine Konfiguration, ein Zeiger auf sein Gedächtnis sowie eine Liste der Abonnements. Dies ist die Konzeption der dauerhaften Ausführung „Warten bedeutet lediglich einen Zustand“ in ihrer logischen Konsequenz. Ein geparkter Lauf sind ruhende Daten, und das Speichern von ruhenden Daten gehört zu den günstigsten Dienstleistungen, die ein Cloud-Anbieter anbietet.

Das bedeutet, dass das Erwecken ein Akt der Rekonstruktion ist. Alles, was auf die Wiederaufnahme eines pausierten Workflows zutrifft, gilt hier umso stärker, denn niemand beobachtet, was dabei geschieht.

Die Uhr wiederherstellen

Ein Agent, der nach sechs Tagen wieder zu Bewusstsein kommt, muss über die aktuelle Zeit informiert werden und alle in seinem Gedächtnis gespeicherten relativen Referenzen neu berechnen. Ein Zettel mit der Notiz „Der Fristtag ist Freitag“, geschrieben am Dienstag, ist bereits am folgenden Montag falsch. Geben Sie dem Agenten die aktuelle Zeit im Zeitzone seines Auftraggebers sowie die Zeit seines letzten Erwachens, damit er weiß, wie lange er inaktiv war.

Betrachten Sie das Gedächtnis als möglicherweise veraltet

Während der Agent abwesend war, ging die Welt weiter. Fakten im Gedächtnis sollten ein Zeitstempel enthalten und vor der Verwendung erneut überprüft werden; außerdem sollte der Kontext beim Erwachen frische Daten vor den im Gedächtnis gespeicherten Werten bevorzugen. Das ist dieselbe Vorgehensweise, die man anwendet, wenn ein menschlicher Freigabeschritt einen Workflow pausiert: Binden Sie Entscheidungen an einen Zeitpunkt-Snapshot und überprüfen Sie sie erneut, wenn die Ausführung fortgesetzt wird.

Beziehen Sie sich erneut auf das Ziel

In langlaufenden Agenten wird das Ziel bei jedem Schritt effektiv anhand des Kontexts neu aufgebaut, weshalb sich die Ziele im Laufe von Wochen verschieben. Ein „Wake“ erstellt seinen Kontext von Grund auf, was ihn entweder zum riskantesten Moment für eine Verschiebung oder zur besten Chance macht, diese zu korrigieren. Wenn dies richtig umgesetzt wird, liest jedes „Wake“ die Zieldefinition erneut. Wenn ein Agent zweihundert Mal pro Jahr neu aufgebaut wird, gibt es damit zweihundert Möglichkeiten, ihn ohne zusätzliche Kosten wieder auf seinen ursprünglichen Zweck zu bringen.

Deshalb halten Designs, die bei jedem Neustart eine neue Sitzung beginnen und Kontinuität in der externen Speicherung sowie Dateien bewahren anstelle eines stetig wachsenden Transkripts, deutlich länger stand als eine einzige „unsterbliche“ Sitzung, die Monate an Rückständen ansammelt. Die Funktionen für geplante Agenten in aktuellen Programmierwerkzeugen – wobei Claudes Code-Routinen zum Zeitpunkt der Niederschrift ein bekanntes Beispiel sind – folgen größtenteils diesem Modell einer neuen Sitzung pro Ausführung. Das ist eine vernünftige Entscheidung für jeden, der gesehen hat, welche Auswirkungen ein mehrere Wochen alter Kontext auf das Verhalten eines Agenten hat.

Was ein guter Kontext nach einem Neustart enthält

„Rekonstruktion“ klingt abstrakt, bis man selbst einen solchen Kontext erstellt. Ein gut strukturierter Prompt nach einem Neustart ähnelt einer Zusammenfassung, die das System Schritt für Schritt erstellt:

• Die Zieldatei, unverändert. Der Grund für die Existenz dieses Agenten sowie die Grenzen dessen, was er tun darf.

Die Uhr. Die aktuelle Zeit im Zeitzone des Leiters, zusammen mit dem Zeitstempel des vorherigen Aktivierungszeitpunkts.

Die Situation. Die zusammengefasste Zusammenfassung, die diese Aktivierung ausgelöst hat. Es handelt sich nicht um vierzig Rohereignisse, sondern um eine Beschreibung ihrer Struktur.

Frischer Zustand. Die aktuellen Werte für alles, was von der Situation betroffen ist – diese werden zum Aktivierungszeitpunkt abgerufen und jeweils mit einem Zeitstempel versehen.

Relevante Erinnerungen. Eine kleine Anzahl an dauerhaften Notizen aus früheren Aktivierungen, wie zum Beispiel „Dieser Kunde bevorzugt Anrufe am Abend“ oder „Beim letzten Mal, als diese Warnung ausgelöst wurde, lag der Grund im Cache“. Diese werden nur bei Bedarf abgerufen und nicht angesammelt.

Das Budget. Token-Limits, verfügbare Tools sowie die Obergrenze für die Autonomie bei dieser spezifischen Aktivierung.

Achten Sie darauf, was fehlt: die Transkripte früherer „Wakes“. Ihre Schlussfolgerungen bleiben erhalten, weil jede „Wake“ das Gelernte vor ihrem Ende in Erinnerung speichert, doch der verbleibende Arbeitsinhalt jeder Sitzung wird verworfen. Dieser Kompromiss sorgt dafür, dass die zweihundertste „Wake“ genauso präzise ist wie die zweite. Er hilft außerdem finanziell, da eine Zusammenfassung von einigen tausend Token einer Transkription mit Hunderttausenden von Tokens entspricht.

Liefergarantien – mit einer Besonderheit bei LLMs

Durch das „Erwachen“ treten auch die klassischen Probleme verteilter Systeme auf.

Die Lieferung erfolgt mindestens einmal, daher muss jede Aktion idempotent sein. Warteschlangen sowie webhook-Betreuungsdienste behalten sich vor, Ihnen dieselbe Nachricht zweimal zuzusenden. Für einen stateless Benachrichtiger ist eine Duplikate lediglich Störgeräusch. Für einen Agenten, der Werkzeuge besitzt, kann eine Duplikate jedoch bedeuten, dass dieselbe irreversible Aktion zweimal ausgeführt wird. Die Lösung ist die übliche: Erstellen Sie eine Idempotenzschlüssel aus dem Ereignis und überprüfen Sie diesen, bevor die Aktion etwas unumkehrbares ausführt. Falls Sie eine Erinnerung an die Funktionsweise benötigen, lesen Sie wie Idempotenzschlüssel in Node.js POST-Endpunkten funktionieren.

Ambient-Agenten benötigen ebenfalls eine zweite Überprüfung auf Ebene der Situation. Ein Agent, der wegen „PR #482 ist mergebar“ geweckt wird, sollte vor Handlungsunternehmen bestätigen, dass der Pull Request weiterhin mergebar ist. Der Weckvorgang kann bereits einige Minuten zurückliegen, und ein anderer Akteur – sei es eine Person oder ein weiterer Agent – könnte ihn bereits bearbeitet haben. Rennen zum Zeitpunkt des Weckens sind gewöhnliche Rennen mit gemeinsam genutztem Zustand, bei denen die Verzögerung zwischen Ursache und Wirkung länger ist.

Stream haben Lücken, weshalb jede Überwachung regelmäßige Abgleichsprozesse erfordert. Endpunkte sind anfällig für Ausfälle, Abonnements laufen aus und Anbieter unterbrechen manchmal die Übertragung, ohne es mitzuteilen. Eine Überwachungsanlage, die ausschließlich auf Reaktionen auf Ereignisse basiert, wird letztendlich eines übersehen, ohne dass jemand es bemerkt. Von außen sieht ein Agent, der schweigt, weil nichts passiert ist, genauso aus wie einer, der schweigt, weil er „blind“ geworden ist. Die Lösung ist alt und unspektakulär: ein langsamer, geplanter Abgleich, bei dem der tatsächliche Zustand mit dem verglichen wird, was der Ereignisstream gemeldet hat – ähnlich wie Zahlungssysteme abgleichen, was beabsichtigt war, was in Rechnung gestellt wurde und was tatsächlich geliefert wurde. Nutzen Sie Push für die Latenzzeit und den Abgleich für die Genauigkeit.

Fortgeschrittene Aspekte: Gegner, Aufmerksamkeit, Konkurrenz und „Stürme“

Der Auslöser ist die Angriffsfläche

Betrachten Sie die fünf Eingabetypen erneut aus Sicht der Sicherheit. Jeder, der ein Ereignis senden kann, kann im Grunde genommen einen Ambient-Agenten auslösen. Webhook-Payloads, E-Mail-Körpersätze sowie Kommentare zu Problemen, die einen Agenten aktivieren können, sind allesamt unzuverlässiger Text, der einem Modell mit Tool-Zugriff zur Verfügung gestellt wird. Im Gegensatz zum Chat ist zu Zeitpunkt der Aktivierung keine Person anwesend, die bemerken könnte, dass etwas nicht in Ordnung ist. Eine sorgfältig formulierte „dringende“ E-Mail verschwendet nicht nur Ressourcen des Agenten; sie bestimmt außerdem, was dieser denkt – und das ist der erste Schritt in fast jeder Kette von Prompt-Injection-Angriffen.

Sie alle gelten als Standardmaßnahmen zur Abschwächung. Behandeln Sie den Inhalt der Ereignisse streng als Daten. Sichern Sie den Umgebungsagenten enger ab als einen Chat-Agenten. Trennen Sie die drei gefährlichen Fähigkeiten – den Zugriff auf private Daten, die Exponierung gegenüber unzuverlässigem Inhalt sowie die Möglichkeit zur externen Kommunikation – voneinander; ein Agent, der die Posteingänge überwacht und über umfangreiche Tools sowie die Möglichkeit zur Ausgangskommunikation verfügt, besitzt alle drei Fähigkeiten sowie zusätzlich weitere Risiken. Fügen Sie eine Regel hinzu, die speziell für Umgebungssysteme gilt: Die Autonomie sollte mit dem Grad der Vertrauenswürdigkeit des Auslösers skaliieren. Ein durch Ihren eigenen Zeitplan ausgelöster Zustand kann handeln, während ein durch Inhalt von Außenstehenden ausgelöster Zustand in der Regel nur benachrichtigen sollte.

Der Mensch ist die knappste Ressource in diesem Kreislauf

Der größte Teil dessen, was ein Ambient-Agent erzeugt, sind Störungen für Menschen, und Störungen sind eine Art „Währung“, deren Wert sinkt, wenn sie übermäßig eingesetzt werden. Ein nützliches Muster, das gut durch die Arbeit mit der Agenten-Eingangskorrespondenz von LangChain beschrieben wird, ist eine dreistufige Hierarchie dafür, was ein Agent von einer Person verlangen kann:

• Benachrichtigen. Nur zur Information; es ist keine Aktion erforderlich.
• Fragen. Der Agent benötigt eine einzige Tatsache, bevor er fortfahren kann.
• Überprüfen. Der Agent hat eine Aktion vorbereitet und möchte Zustimmung erhalten.

Die für den jeweiligen Kontext spezifische Erkenntnis ist, dass diese Leiter gleichzeitig als Qualitätsmaßstab dient. Notieren Sie, wie die Menschen auf jede Störung reagieren: sie handeln darauf ein, ignorieren sie oder lehnen sie ab. Dadurch erhalten Sie eine präzise Messung für den gesamten Prozessablauf. Ein Agent, dessen Benachrichtigungen zu 80 Prozent ignoriert werden, bedeutet nicht nur einen Verlust von 80 Prozent der Effektivität – dadurch werden die Nutzer dazu ermutigt, die Benachrichtigungen auszuschalten, wodurch auch die nützlichen 20 Prozent verschwinden. Schon vor der Existenz von Sprachmodellen hat die Alarmmüdigkeit die Einführung von Überwachungssystemen jahrzehntelang behindert, und überzeugende Alarmtexte ändern daran nichts.

Konkurrenz: Eine Superkraft mit einem Risiko

Die Definition eines ambienten Agenten beinhaltet das gleichzeitige Handeln an mehreren Ereignissen, und dieser Aspekt wird leicht übersehen. Ein Chat-Agent kümmert sich um ein einziges Gespräch. Ein ambienter Agent könnte gleichzeitig vierzig Instanzen haben, jede in einem separaten, sauberen Kontext – wobei jede nur einen Teilbild der gemeinsamen Realität besitzt. Man erhält somit ein Mehr-Agenten-System, ohne es bewusst entschieden zu haben, zusammen mit den damit verbundenen Problemen bezüglich des gemeinsamen Zustands. Zwei Instanzen, die durch zusammenhängende Ereignisse entstehen, könnten dasselbe Ticket beanspruchen, widersprüchliche Antworten in einem Thread schreiben oder beide dieselbe Aufgabe übernehmen – wobei keines davon etwas bemerken kann, da die sauberen Kontexte voneinander unabhängig sind.

Die Abhilfemöglichkeiten in grober Reihenfolge der Priorität:

• Die Instanzen nach einer Korrelationsklave aufteilen, sodass jede Situation ihren eigenen Zustand besitzt. Die in Schritt zwei erstellte Gruppierung dient ebenfalls als Regel für die Zustandszuordnung: Jede Situation erhält genau eine Instanz und keinen parallelen Zwilling.

Die Route wird über einen einzigen Writer geschrieben, wenn Teilung nicht ausreicht.

Nutzen Sie optimistische Konkurrenz, wenn zwei Wake-Operationen tatsächlich dasselbe Objekt berühren müssen, und betrachten Sie Konflikte als Fehler – dadurch überprüft der zweite Writer seine Entscheidung erneut, anstatt den ersten zu überschreiben.

Falls der Funnel gut konstruiert ist, entsteht das meiste davon kostenlos – und das ist kein Zufall. Die Korrelationschlüssel, die Ereignisse gruppieren, sowie die Eigentumschlüssel, die den Zustand schützen, sollen naturgemäß dieselben Schlüssel sein.

Storm-Modus

Ein einzelnes Ereignis im Upstream kann zehntausend korrelierte Ereignisse auslösen. Ein naiver Funnel verwandelt diese in zehntausend Wake-Operationen, was zu einem starken Anstieg des Tokenverbrauchs sowie zu vierzig Benachrichtigungen führt, wodurch der Kanal mitten im Ereignis stummgeschaltet wird. Betriebsteams haben diese Problematik bereits vor langer Zeit durch Flap-Erkennung und Ereignisgruppierung gelöst.

Der entsprechende Agent ist ein Sturmdetektor, der die aktuelle Ereignisrate mit einem Basiswert vergleicht und bei einem Anstieg den Funnel in einen anderen Modus schaltet. Im Sturmmodus werden alle zusammenhängenden Informationen zu einer einzigen Situation zusammengefasst, ein einzelner Agent wird mit dem Zusammenfassungstext geweckt und erhält eine spezifische Anweisung: Es handelt sich um einen Sturm; fassen Sie ihn zusammen, identifizieren Sie die wahrscheinlichste Ursache und senden Sie eine Benachrichtigung. Die Kostenkontrolle ist wichtig, da gerade die späten Phasen der Arbeitsbelastung dazu führen können, dass Budgets überschritten werden, doch das Argument der Aufmerksamkeit ist noch wichtiger. Während eines Incidents sinkt die Fähigkeit einer Person, Unterbrechungen zu bewältigen, genau in dem Moment, in dem die Ereignisrate ansteigt. Das Sturmmodus berücksichtigt diese Umkehrung.

Den inaktiven Agenten wie ein Produkt messen

Zwei Zahlen sind am wichtigsten:

• Kosten pro nützlichem Wake. Die Gesamtausgaben geteilt durch die Anzahl der Wakes, die eine Person im Nachhinein für lohnenswert hält. Dies sind betriebswirtschaftliche Kennzahlen, die auf Ihr eigenes System angewandt werden.
• Präzision und Treffgenauigkeit der Triage. Diese können sehr effektiv offline bewertet werden. Übertragen Sie dreißig Tage an vergangenen Ereignissen durch einen Kandidaten-Filter und vergleichen Sie die Wakes, die dadurch ausgelöst worden wären, mit den tatsächlichen Reaktionen der Menschen.

Dieses Wiedergabepaket ist eine der seltenen Bewertungsmethoden, die nahezu kostenlos erstellt werden können, da die entsprechenden Labels bereits in Ihrer Tickethistorie vorhanden sind. Dadurch werden Änderungen am Filter von subjektiven Meinungen zu messbaren Unterschieden.

Autonomie, die von der Zeit abhängt

Noch ein Muster ist günstig umzusetzen und dennoch selten: Die Autonomiegrenze eines „Wake“-Systems soll davon abhängen, wann es aktiviert wird und wer erreichbar ist. Eine Erkenntnis, die eine automatische Korrektur um 11 Uhr an einem Dienstag rechtfertigt – wenn Menschen online sind, ein Stopptasten in der Nähe liegt und der Auswirkungsbereich gut bekannt ist – verdient möglicherweise lediglich eine Warnung in den frühen Morgenstunden eines Sonntags.

Das ist keine übermäßige Vorsicht. Es handelt sich um eine Entscheidung auf der Grundlage des Erwartungswerts unter Berücksichtigung der Zeit. Die Kosten für eine Überprüfung sind während der Arbeitszeiten gering und nachts sehr hoch. Gleichzeitig sinkt der Nutzen einer menschlichen Überwachung – die Wahrscheinlichkeit, dass jemand einen Fehler entdeckt, multipliziert mit dem Kostenfaktor dieses Fehlers – nachts, weil niemand zuschaut. Daher dominiert der Fehlerfaktor und die Schwellenwertgrenze sollte in Richtung einer Überprüfung verschieben, was in der Praxis bedeutet, die Aktion zu verschieben, da niemand wach ist, um zu antworten.

Codeieren Sie dies als Abfrage im System, das Triggervertrauen, Handlungsgrad und menschliche Verfügbarkeit kombiniert und sie auf eines von drei Ergebnissen abbildet: sofort handeln, in die Warteschlange für den Morgen geben oder umgehend benachrichtigen. Die Option „in die Warteschlange für den Morgen geben“ ist der unerkannte Held. Die meisten Dinge, die ein Ambient-Agent um 3 Uhr morgens bemerkt, sind völlig in Ordnung, um sie um 8:55 Uhr zur Überprüfung abzulegen – bereits zusammen mit der vom Agenten vorgeschlagenen Handlung, etwa zur Zeit, wenn der erste Kaffee fertig ist.

Muster in realen Systemen

Ein E-Mail-Assistent mit einer Posteingangskiste für seine Benutzer

LangChains Referenz-Agent für allgemeine Aufgaben kümmert sich um E-Mails: Er entwirft Antworten, speichert Nachrichten und leitet Fälle weiter. Sein Interaktionsdesign ist lehrreicher als seine Funktion zur Erstellung von Texten. Das Team hinter ihm betrachtet die Einbeziehung eines Menschen nicht als Kompromiss, sondern als etwas, das das Risiko verringert, die Implementierung erleichtert, Vertrauen aufbaut und zur langfristigen Erinnerung beiträgt. Ihre Agent Inbox – eine einzige Übersichtsfläche, auf der alle offenen Kommunikationswege zwischen einem Menschen und seinen Agenten gelistet sind – ist die physische Verkörperung einer Hierarchie aus Benachrichtigung, Fragestellung und Überprüfung. Ein Running Gag aus diesem Projekt besagt, dass, wenn man ignoriert wird, es sicherlich am Agent liegt – das fasst die gesamte Aufmerksamkeitsökonomie zusammen: Der Agent existiert dazu, eine Personens Aufmerksamkeit klüger einzusetzen, und die Witze beginnen, wenn er dies nicht tut.

Geplante Agenten in Programmierwerkzeugen

Die wichtigsten Coding-Agent-Plattformen fügen Agenten hinzu, die nach Zeitplänen oder Ereignissen im Repository statt auf Anweisungen ausgeführt werden; die Routinen von Claude Code sowie die durch GitHub ausgelösten Ausführungen sind Beispiele, auf die viele Entwickler bereits gestoßen sind. Prüfen Sie die aktuelle Dokumentation, da sich diese Funktionen schnell weiterentwickeln. Zwei Gestaltungsprinzipien kommen in ihnen immer wieder vor und stützen beide die hier dargelegte Argumentation. Jede Ausführung startet eine neue Sitzung, wobei die Kontinuität in Dateien und im Speicher aufrechterhalten wird, anstatt in endlosen Transkripten. Die Auslösemechanismen basieren auf klassischer Infrastruktur wie Cron-Expressionen, Webhook-Filtern und bedingtem YAML – im gesamten Ablaufweg kommt kein Modell zum Einsatz. Intelligenz ist teuer, während Alarme billig sind, weshalb die Produkte sie voneinander trennen.

Infrastruktur-Beobachter

Cloud-Anbieter haben Muster für Umgebungsagenten beschrieben, die Infrastrukturen überwachen und proaktiv Erkenntnisse liefern. Die gut konzipierten Ansätze sehen aus wie die in diesem Leitfaden dargestellte Praxis. Ereignisse stammen vom nativen Event-Bus der Plattform, sodass eine strukturelle Filterung kostenlos verfügbar ist. Bevor ein Agent aufgerufen wird, werden die Ereignisse miteinander in Beziehung gesetzt. Bei bedeutsamen Vorfällen erstellen die Agenten Erkenntnisse zur Überprüfung, anstatt eigenständig Korrekturen vorzunehmen. Der wertvolle Aspekt, den man übernehmen kann, ist der Vertrauensgrad: Je weiter eine vorgeschlagene Aktion reicht, desto höher steigt sie in der Hierarchie von Benachrichtigung, Abfrage und Überprüfung. Das Beobachten kann autonom erfolgen; das Eingreifen hingegen unterliegt Aufsicht.

Das Abfragemodul, ein Quartal später

Nachdem sich die Neugestaltung etabliert hat, kehrt das Team zur ursprünglichen Vorgehensweise zurück. Ihr Prozess umfasst nun Webhooks, das Zusammenführen von Threads mit einer zehnminütigen Ruhephase, einen kleinen Klassifikator, dessen gesamte Anweisung auf eine Visitenkarte passt, sowie etwa dreißig Ausführungen von Grenzmodellen pro Monat. Zwei Aspekte sind besonders hervorzuheben: Die Kosten pro nützlicher Ausführung sinken um etwa vierzig Mal. Zudem steigt überraschenderweise die Erfolgsrate – das ursprüngliche Abfragedesign hatte die Situationen in willkürliche zweiminütige Abschnitte unterteilt und mindestens zweimal eine unvollständige Sichtweise als negativ eingestuft, obwohl diese insgesamt eindeutig zu einem „Ja“ geführt hätte.

Die Neugestaltung führte also nicht nur zu Kostensenkungen. Durch die Gruppierung der Ereignisse verbesserte sich die Qualität der Beurteilungen, da das Modell schließlich ganze Situationen statt willkürlicher Fragmente bewertete. Das geplante Arbeitsverfahren war nie das Problem – vielmehr lag das Problem darin, vom Modell bei jedem Schritt eine Beurteilung zu verlangen.

Auswahl der Bausteine

Den größten Teil dieses Stack sollte man kaufen oder wiederverwenden anstatt selbst zu entwickeln.

• Trigger-Infrastruktur. Cron und seine verwalteten Entsprechungen; Event-Busse und -Warteschlangen wie EventBridge, Pub/Sub, Kafka oder einfache Webhooks; sowie Zeitpläne und Signale in Workflow-Engines wie Temporal, Restate oder Inngest, die außerdem eine dauerhafte Speicherung ermöglichen. Die Phasen eins und zwei des Funnel-Modells entsprechen direkt den Funktionen dieser Tools.

Ambient-Agent-Struktur.** LangGraph mit Persistenzfunktion, Unterbrechungsmöglichkeiten und Cron-Unterstützung sowie die Open-Source-Lösung Agent Inbox; die geplanten und ausgelösten Betriebsmodi wichtiger Programmier-Agenten wie Claude Code-Routinen und GitHub Actions-Integrationen; sowie eine wachsende Anzahl an Connectoren, die E-Mails oder Webhooks in Agent-Ausführungen umwandeln. Beurteilen Sie alle diese Lösungen anhand von drei Kriterien: Wo findet die Triage statt (sie sollte vor dem Modell erfolgen), was wird durch das Wiederherstellen rekonstruiert, und was sieht die Person letztendlich.

Triage-Ebene.** Jedes kleine, schnelle Modell eignet sich. Der Schlüssel liegt in präzisen Anfragen und der Offline-Wiederholungsbewertung – nicht darin, welches Modell man wählt.

Die Inbox.** Verwenden Sie Agent Inbox von LangChain, wenn Sie eine vorhandene Plattform möchten, oder die aktuellen Kanäle Ihres Teams wie Slack, E-Mail oder Tickets – wobei die drei Aktionen klar und kontrolliert definiert bleiben sollten.

Verwenden Sie Ihr Budget für Neuheiten für den Funnel sowie für die Rekonstruktion des Wake-Contexts und kaufen Sie alles andere. Scheduler sind ein bereits gelöstes Problem, das durch jahrzehntelange praktische Erprobung gestützt wird. Ein selbstgebauter Loop, der alle zwei Minuten ein Modell abfragt, ist das nicht.

Das gesamte Design passt in wenige Zeilen Pseudocode. Lesen Sie ihn von oben nach unten wie einen Funnel: eine kostenlose Regelprüfung, die sich zu einer Situation zusammenfügt (während ein Ansturm noch abklingt, wird nichts zurückgegeben), eine günstige Klassifizierung, ein Schutz gegen doppelte Zustellungen durch Idempotenzprüfung, die Rekonstruktion des Wake-Contexts aus der aktuellen Zeit, die Zieldatei sowie erneute Lesevorgänge, ein budgetierter Agentenaufruf und schließlich die Zustellung über eines der drei Verben für die Inbox.

async def on_event(evt):
    if not rules_pass(evt):            return                  # stage 1: free
    sit = coalesce(evt, window="10m")                          # stage 2: situations, not events
    if sit is None:                    return                  # burst still settling
    if triage_small_model(sit) == "ignore": return             # stage 3: cheap
    if seen(sit.idempotency_key):      return                  # at-least-once armor
    ctx = rebuild(now(), goal_file, fresh_reads(sit))          # stage 4: wake = reconstruction
    outcome = await agent.run(sit, ctx, budget=WAKE_BUDGET)
    inbox.deliver(outcome.verb, outcome.summary)               # notify | question | review

Achten Sie darauf, wo die Idempotenzprüfung stattfindet: nach den günstigen Filtern, aber vor allem Teuren oder irreversiblen Aktionen. Sie könnte genauso gut früher erfolgen; wichtig ist, dass niemals Duplikate bei agent.run ankommen. In einem echten System findet auch die situationsbezogene Prüfung „vor der Ausführung“ bei rebuild statt, da dies der erste Moment ist, in dem ein neuer Zustand verfügbar ist.

Führer durch Fehlermodi

• Das Abfragen-Problem. Ein teures Modell wird wiederholt gebeten, nichts zu überprüfen. Lösung: Regeln und Zusammenfassung vor jeder Modellaufruf, anschließend ein günstiges Modell vor dem teuren.
• Die ausufernde Ausfallwirkung. Ein einziger Ausfall führt zu Tausenden weiterer Probleme. Lösung: Sturmmodus mit Geschwindigkeitsdetektor, vollständige Zusammenfassung sowie ein einziger Agent und eine einzige Benachrichtigung.

Die doppelte Wachstube. Ein erneut übermitteltes Ereignis erreicht einen Agenten, der tatsächliche Aktionen ausführen kann. Lösung: Idempotenzschlüssel für die Wachstuben sowie eine Überprüfung der Situation vor Ausführung einer Aktion.

Die veraltete Wachstube. Entscheidungen basieren auf einem Zeitpunktssnippet vom Moment des Auslösers, obwohl sich die Realität inzwischen weiterentwickelt hat. Lösung: Jede Wachstube liest die Zeit erneut ab, holt den aktuellen Zustand und überprüft die Fakten erneut, bevor eine Aktion ausgeführt wird.

Die eingefügte Wachstube. Inhalt von Außenstehenden bestimmt, worauf sich Ihr autonomer Agent konzentriert. Lösung: Behandeln Sie den Ereignisinhalt als Daten, skalieren Sie die Autonomie entsprechend dem Vertrauen in den Auslöser und sichern Sie Umgebungsagenten strenger ab als Chat-Agenten.

Die gedämpfte Posteingangstasche. Die Präzision bei Störungen nimmt ab, bis die Menschen nicht mehr zuhören. Lösung: Erfassen Sie für jede Benachrichtigung, ob darauf reagiert, ignoriert oder abgelehnt wurde, und betrachten Sie eine Reaktionsrate unter 50 % als Ausfall.

Die stille Lücke. Ein webhook liefert seit Monaten keine Daten mehr, und niemand bemerkte es, bis eine Erneuerung überfällig wurde. Lösung: Überwachen Sie die Latenz, prüfen Sie die Realität und führen Sie eine langsame Abstimmungsprozedur durch, bei der davon ausgegangen wird, dass der Datenfluss falsche Informationen liefert.

Der unsterbliche Daemon. Eine Sitzung bleibt monatelang aktiv und weicht allmählich von ihrem Ziel ab. Lösung: Jedes Mal bei Aktivierung wird eine neue Sitzung eröffnet, wobei die Kontinuität in Dateien und im Speicher aufrechterhalten wird, anstatt in einer Transkription.

Die Mitternachtsüberraschung. Die gefährlichsten Aktionen finden mitten in der Nacht statt, weil niemand zur Verfügung steht, um dagegen zu protestieren. Lösung: Folgeaktionen einer Überprüfung unterziehen, die Autonomiegrenzen von der Uhrzeit abhängig machen und einen funktionierenden Stoppknopf griffbereit halten.

Ein einwöchiger Plan zum Start

1. Prüfen Sie Ihre Auslöser. Schreiben Sie alle Pfade auf, die heute Ihren Agenten in Gang setzen können, sowie den Kostenfaktor für jeden Auslöser. Markieren Sie alle Pfade, die darauf hinauslaufen, „ein Modell nach Ablauf einer Zeit zu rufen“, als Erstes zum Beheben.
2. Bauen Sie die erste Phase auf. Setzen Sie strukturelle Filter vor jeden Auslöser und messen Sie die Ablehnungsrate. Ist sie unter der Hälfte, sind Ihre Regeln zu vorsichtig.

Koaleszieren. Wählen Sie Korrelationschlüssel wie Thread, Pull Request, Incident oder Kunde, fügen Sie eine Verzögerungsfunktion hinzu und ändern Sie die Eingabe Ihres Agents von „ein Ereignis“ zu „eine Situation“.

Fügen Sie die Triage-Ebene hinzu. Verwenden Sie ein kleines Modell mit einer eindringlichen Ausgabe. Erstellen Sie anschließend eine Wiederholungsbewertung anhand der Ereignisse des letzten Monats sowie der tatsächlich gegebenen Antworten und bewerten Sie die Genauigkeit und den Recall des Funnels, bevor Sie sich darauf verlassen.

Sichern Sie die Wakes. Fügen Sie Idempotenzschlüssel, eine Prüfung vor Handlung sowie ein Rekonstruktionsverfahren hinzu: Uhrzeit, frische Lesevorgänge, Zieldatei.

Installieren Sie die Leiter. Machen Sie „Benachrichtigen“, „Fragen“ und „Überprüfen“ zu expliziten Ausgabetypen, die an einen Ort übermittelt werden, den Sie nachverfolgen können, und beginnen Sie damit, aufzuzeichnen, ob jede Aktion umgesetzt, abgelehnt oder ignoriert wurde.

Führen Sie zwei Übungen durch. Wiederholen Sie einen Datenstrom, um zu überprüfen, ob der Sturmmodus ihn bündelt, und deaktivieren Sie einen webhook für eine Stunde, um zu bestätigen, dass die Überwachungslösung die Lücke erkennt. Schließlich berechnen Sie zum ersten Mal die Kosten pro nützlichem Datenstromabschnitt und zeigen diese neben den Tokenausgaben an.

Zusammenfassung: Umgebungsperzeption, menschliches Engagement

Es gibt eine echte Debatte darüber, wohin die Schnittstellen für KI-Agenten entwickelt werden sollen. Eine Seite argumentiert, dass Chat eine Übergangsschnittstelle sei und dass Agenten zunehmend innerhalb von Ereignisströmen agieren werden, um Probleme bereits vor den Menschen zu erkennen. Aufmerksamkeit ist das knappste Gut von Wissensarbeitern, und Software, die ihre eigene Aufmerksamkeit für das Beobachten aufwendet und Ihre nur dann, wenn es notwendig ist, ist einfach bessere Software.

Die andere Seite weist darauf hin, dass ein ständig verfügbarer Agent mit entsprechenden Tools genau die oben besprochenen Risiken in sich vereint: unzuverlässige Auslöser, keine Anwesenheit eines Menschen zum Aktivierungszeitpunkt sowie Autonomie mitten in der Nacht. Aus dieser Sicht war die Anweisung niemals eine zusätzliche Belastung. Es handelte sich um Einwilligung, und jeder Schritt, der einen Menschen aus dem Prozess entfernt, verlagert das Risiko vom Zeitpunkt der Aktion auf die Qualität der Sicherheitsmechanismen.

Sowohl Seiten haben Recht, und der Trichter ist der Punkt, an dem sie aufeinandertreffen. Es ist möglich, alles zu überwachen, doch beachten Sie, dass das Erfolgsrezept der oben genannten Beispiele die traditionelle Ingenieurkunst war: Filtern, Debouncing, idempotente Verarbeitung, Abgleichsvorgänge sowie Rücksicht auf Alarmüberflutung. Eine Entscheidung erfordert weiterhin Zustimmung – genau das drückt die Hierarchie aus „Benachrichtigen, Fragen und Überprüfen“ aus: Autonomie bei der Beobachtung, Eskalation bei der Handlung. Das Rezept besteht darin, Agenten zu verwenden, die weitreichend beobachten, selten aktiv werden und vor der Änderung wichtiger Dinge Zustimmung suchen.

Eine nützliche Übung dauert einen Abend. Wählen Sie den lautesten Strom an Benachrichtigungen in Ihrem eigenen Arbeitsalltag aus und skizzieren Sie einen Trichter dafür: Welche einfachen Regeln könnten etwas aussortieren, was würde zusammengefasst werden, welches kleine Modell könnte Dinge priorisieren und was verdient tatsächlich eine aktive Bearbeitung? Bevor Sie auch nur einen Codezeilen schreiben, haben Sie bereits Ihren ersten inaktiven Agenten entworfen.

Verwandte Artikel