Die Agent Loop-Architektur

Alle fragen sich: "WTF ist eine Schleife?" Hier ist die Frage, die niemand stellt: Was betreibt die Schleife?

Der KI-Diskurs hat sich auf Schleifen als zentrales Primitiv von agentischen Systemen geeinigt. Matt Van Horn (@mvanhorn) hat die Abstammung von Agentenschleifen von ReAct über Tool-Nutzung zu Orchestrierungsschleifen bis hin zu Schleifen, die Schleifen überwachen, zurückverfolgt. Addy Osmani (@addyosmani) hat die Bausteine innerhalb von Schleifen aufgeschlüsselt: Automatisierungen, Arbeitsbäume, Fähigkeiten, Konnektoren, Sub-Agenten. Van Horn betonte Beständigkeit und argumentierte, dass Schleifen, die einen Neustart nicht überleben, keine Schleifen sind. Osmanis roter Faden war Orchestrierung: Entwerfe das System, das den Agenten promptet, anstatt dich selbst.

Ich möchte ihre Punkte weiterführen. Beständigkeit ist nicht nur eine Eigenschaft der Schleife. Es ist die gesamte Ausführungsschicht darunter. Die wichtige Tatsache ist, dass beständige Orchestrierung grundlegend für den Aufbau deiner Agentenschleifen-Architektur ist. Lassen wir uns diese Architektur genauer ansehen.

Wo Schleifen brechen

Die /Schleife- und /Ziel-Muster funktionieren gut für Einzel-Agenten-, Einzel-Sitzungs-Arbeit. Ein Agent schleift, bis eine Aufgabe erledigt ist. Das deckt viel ab. Aber die nächste Stufe (Stufe 5 in Van Horns Rahmenwerk) ist der Punkt, an dem es auseinanderfällt:

• Schleifen, die andere Schleifen überwachen
• Schleifen, die nach Zeitplänen laufen, nicht nur von einem Menschen ausgelöst
• Schleifen, die Prozessneustarts, Bereitstellungen und Abstürze überleben
• Schleifen, die Sub-Agenten erzeugen und auf Ergebnisse warten (manchmal Stunden später)
• Schleifen, die im Nachhinein beobachtbar sein müssen

Das ist kein Prompting-Problem. Das ist ein Infrastruktur-Problem.

Van Horn zitiert @runes_leo: "Das Kostspieligste beim KI-Coden ist nicht mehr das Schreiben von Code, sondern die Verwaltung der Agentenschleife." Ein while True in einem Terminal gibt dir nichts davon. Ebenso wenig ein langlebiger Prozess auf einer VM oder in einer Sandbox.

Denk darüber nach, was passiert, wenn du eine Agentenschleife auf einem Server ausführst. Der Prozess stirbt oder startet neu. Eine Bereitstellung, ein OOM, eine Rückforderung einer Spot-Instanz. Die Schleife startet neu. Aber was hat sie gerade gemacht? Bei welchem Schritt war sie? Hat sie diese Slack-Nachricht bereits gesendet? Hat sie den Sub-Agenten bereits aufgerufen?

Du weißt es nicht. Sie fängt von vorne an. Ruft Daten erneut ab, die sie bereits hatte. Ruft das LLM erneut für Entscheidungen, die sie bereits getroffen hat. Sendet eine doppelte Benachrichtigung. Erzeugt einen doppelten Sub-Agenten. Du wachst auf und findest drei identische Slack-Nachrichten und ein verwirrtes Team vor.

Die Lösung ist nicht "bessere Fehlerbehandlung" – es ist ein Ausführungsmodell, bei dem jeder Schritt einen Prüfpunkt hat, jede Entscheidung beibehalten wird und die Wiederherstellung bedeutet, den Betrieb ab dem letzten erfolgreichen Schritt wieder aufzunehmen.

Die Architektur der Agentenschleife in drei Schichten

Drei Schichten. Jede bildet sich auf ein konkretes Primitiv ab.

Schicht 1: Die Schleife

Eine Schleife ist ein Cron-Job plus ein Entscheider. Sie läuft nach einem Zeitplan (oder einem Auslöser), bewertet den Zustand und entscheidet, was als Nächstes zu tun ist.

Das ist Van Horns Definition, konkret gemacht: Was Cron nie hatte, ist die Entscheidung in der Mitte. Der Agent entscheidet, nicht du. Der Cron-Job ist der Herzschlag. Das LLM ist der Entscheider. Schritte sind die beständige Ausführung, die den Fortschritt prüft.

1export const infraHealthCheck = inngest.createFunction(
2  { id: "infra-health-check" },
3  { cron: "*/30 * * * *" }, // Alle 30 Minuten
4  async ({ step }) => {
5    const metrics = await step.run("fetch-service-metrics", async () => {
6      return await fetchServiceMetrics(); // Fehlerraten, Latenz, Speicher, CPU
7    });
8
9    const assessment = await step.run("assess-health", async () => {
10      return await callLLM({
11        prompt: `Klassifiziere anhand dieser Servicemetriken den Gesamtzustand des Systems
12                 als "normal", "beeinträchtigt" oder "kritisch". Erkläre deine Begründung.
13                 Metriken: ${JSON.stringify(metrics)}`,
14      });
15    });
16
17    if (assessment.status === "degraded" || assessment.status === "critical") {
18      await step.invoke("triage-incident", {
19        function: incidentTriage,
20        data: { metrics, assessment, services: assessment.affectedServices },
21      });
22    }
23  }
24);

Jeden Montag um 9 Uhr feuert die Schleife. Sie ruft Daten ab, fragt das LLM, ob ein Bericht gerechtfertigt ist, und ruft eine Fähigkeit auf, wenn ja. Wenn der Prozess zwischen den Schritten neu startet, werden die bereits abgeschlossenen Schritte nicht erneut ausgeführt. Das ist die Schleife. Nicht das LLM, die Schleife um das LLM herum.

Schicht 2: Die Fähigkeit

In diesem Zusammenhang ist eine Fähigkeit kein Prompt. Es ist ein beständiger Workflow. Mehrschrittig, wiederholbar, zusammensetzbar, unabhängig bereitstellbar.

Van Horn: "Die Schleife ist die Infrastruktur. Das Kapital ist die Fähigkeit, die sie aufruft." Das ist der Teil, der sich verzinst. Jede neue Fähigkeit, die das System lernt, macht jede Schleife leistungsfähiger.

1export const incidentTriage = inngest.createFunction(
2  { id: "incident-triage", retries: 3 },
3  { event: "infra.incident.triage" },
4  async ({ event, step }) => {
5    const details = await step.run("fetch-detailed-metrics", async () => {
6      return await fetchDetailedMetrics({ services: event.data.services });
7    });
8
9    const deploys = await step.run("fetch-deploy-history", async () => {
10      return await fetchRecentDeploys({ since: hoursAgo(2) });
11    });
12
13    const analysis = await step.run("correlate-incident", async () => {
14      return await callLLM({
15        prompt: `Bringe diese Servicemetriken mit den letzten Bereitstellungen in Verbindung.
16                 Identifiziere die wahrscheinlichste Ursache und den Schweregrad.
17                 Metriken: ${JSON.stringify(details)}
18                 Letzte Bereitstellungen: ${JSON.stringify(deploys)}`,
19      });
20    });
21
22    await step.run("post-triage-summary", async () => {
23      await slack.postMessage({
24        channel: "#incidents",
25        text: formatTriageSummary({
26          analysis,
27          affectedServices: event.data.services,
28          recommendedActions: analysis.recommendations,
29        }),
30      });
31    });
32
33    return analysis;
34  }
35);

Diese Fähigkeit ruft ab, klassifiziert und leitet weiter. Es ist eine Arbeitseinheit mit eingebauter Fehlertoleranz. Die Fähigkeit kann ein KI-Workflow mit einem LLM in der Mitte oder deterministischer Code sein.

Schicht 3: Der Orchestrator

Der Orchestrator ist die Engine, die alles ausführt: plant Cron-Jobs, führt Schritte aus, verwaltet Wiederholungen, setzt Parallelitätsgrenzen durch, speichert den Ausführungsverlauf und stellt neue Funktionen/Workflows bereit (Hot-Deploy), ohne laufende zu stören.

Das ist die Schicht, über die niemand spricht, weil sie unsichtbar sein soll. Aber sie ist grundlegend.

Die meisten Leute denken bei Agenten an "LLM + Werkzeuge". Die Architektur der Agentenschleife formuliert dies neu: Agenten sind "Schleifen + Fähigkeiten + Orchestrierung". Das LLM + Werkzeuge sind innerhalb der Schleifen. LLMs und Werkzeuge können ausgetauscht oder angepasst werden, während die Architektur bestehen bleibt. Die Orchestrierung ermöglicht die Architektur.

Was passiert, wenn Dinge brechen

Der glückliche Pfad ist einfach. Aber das ist Software, die in der Produktion läuft – läuft wirklich alles immer nach Plan?

Deine Incident-Triage-Fähigkeit feuert und die Metriken-API gibt ein Timeout. Der Lesevorgang musste auf die Festplatte und der In-Memory-Cache hatte die Daten nicht. Der Schritt, der diese API aufruft, wiederholt sich jetzt und ruft die API erneut auf. Die Daten sind jetzt teilweise zwischengespeichert und die API wird erfolgreich abgeschlossen. Die Fähigkeit fährt mit dem nächsten Schritt fort, als wäre nichts passiert.

Manchmal ist es nicht so einfach. Was, wenn ein API-Schlüssel abläuft oder dein Hosting-Provider für 30 Minuten ausfällt? Alle deine Wiederholungsversuche sind erschöpft. Was passiert jetzt? Du musst auch mit Fehlern umgehen können.

1export const incidentTriage = inngest.createFunction(
2  {
3    id: "incident-triage",
4    retries: 3,
5    onFailure: async ({ error, event, step }) => {
6      // Die Funktion ist fehlgeschlagen, nachdem alle Wiederholungsversuche erschöpft waren.
7      // Wir haben immer noch die ursprünglichen Event-Daten. Nichts ist verloren.
8      await step.run("notify-failure", async () => {
9        await slack.postMessage({
10          channel: "#agent-ops",
11          text: `⚠️ Incident-Triage fehlgeschlagen: ${error.message}. ` +
12                `Wird beim nächsten Health-Check-Zyklus erneut versucht. ` +
13                `Betroffene Dienste: ${event.data.services.join(", ")}`,
14        });
15      });
16    },
17  },
18  { event: "infra.incident.triage" },
19  async ({ event, step }) => {
20    /* die gleiche Logik wie bei der Fähigkeit oben */
21  }
22);

Der onFailure-Handler feuert, nachdem alle Wiederholungsversuche erschöpft sind. Er postet in einen Ops-Kanal, damit jemand Bescheid weiß. Das Event bleibt erhalten, nichts geht verloren. Die nächste geplante Ausführung setzt dort an, wo die fehlgeschlagene es nicht konnte.

Beständige Orchestrierung muss dir Schritt-für-Schritt-Wiederholungen für vorübergehende Fehler und Fehlerbehandlungs-Hooks für nicht behebbare Fehler bieten. Ohne das bricht etwas (wie es nun mal passiert), und du erfährst Stunden oder Tage später davon.

Vorübergehende Fehler sind auch teuer. Wenn deine Fähigkeit oder dein Agent von Anfang an wiederholt, rufst du LLMs mehrfach auf und verbrennst unnötig Tokens. Der LLM-Aufruf kann mit einem Prüfpunkt versehen werden. Multipliziere das jetzt mit 10 oder 30 Agenten in deinem System. Das ist teuer.

Schrittweise Prüfpunkte sind nicht nur eine Korrektheitsfunktion. Sie sparen Geld.

Der Agent, der seine eigenen Fähigkeiten baut

Hier wird es interessanter. Das System ist nicht statisch, es ist darauf ausgelegt, sich weiterzuentwickeln und zu erweitern.

Der Agent läuft nicht nur innerhalb von Schleifen – er verfasst neue Schleifen und registriert sie bei der Orchestrierungs-Engine. Jede bereitgestellte Funktion ist eine beständige Fähigkeit, die unabhängig läuft, von einer Schleife oder einem Agenten ausgelöst werden kann oder nach einem Zeitplan läuft, mit ihrer eigenen Wiederholungslogik. Fähigkeiten potenzieren sich.

Es ist ein orchestrierungsbewusster Agent.

So funktioniert es. Ein KI-Agent hat Zugriff auf das Orchestrierungs-SDK als Werkzeug. Er kann neue Funktionen schreiben, sie bei der Engine registrieren, und sie beginnen sofort zu laufen. Der Agentenprozess lädt neue Funktionen per Hot-Reload, ohne laufende Durchläufe zu unterbrechen oder neu zu starten.

Gehen wir ein konkretes Beispiel durch:

1. Ein Mensch äußert ein Bedürfnis. Ein Ingenieur sagt: "Unsere Dienste haben nachts ständig Latenzspitzen und niemand bemerkt es bis zum Morgen." Das ist der Auslöser. Der Agent muss kein vages Muster aus Umgebungsdaten ableiten. Er hat klare Anweisungen.

2. Agent schreibt eine Fähigkeit. Zwei mehrschrittige Funktionen: eine Health-Check-Schleife, die alle 30 Minuten läuft, Fehlerraten, Latenz und Ressourcennutzung abruft, wobei das LLM den Systemzustand als normal, beeinträchtigt oder kritisch klassifiziert. Und eine Incident-Triage-Fähigkeit, die detaillierte Metriken und den letzten Bereitstellungsverlauf abruft, Ursachen mit einem LLM korreliert und eine Triage-Zusammenfassung mit empfohlenen Maßnahmen in Slack postet. Fehlerbehandlung: Wenn die Metriken-API ausfällt, zurückhalten und wiederholen. Wenn das LLM ausfällt, auf regelbasierte Schweregradklassifizierung zurückfallen.

3. Agent stellt die Fähigkeit bereit. Der Agent schreibt den Funktionscode, der von einem Sidecar-Prozess aufgenommen wird. Die neuen Funktionen werden automatisch registriert. Sie sind sofort live, ohne Bereitstellungspipeline, ohne PR.

4. Fähigkeit läuft autonom. Alle 30 Minuten löst die Engine den Health-Check aus. Wenn etwas nicht stimmt, ruft sie die Triage-Fähigkeit auf. Kein Mensch im Kreislauf. Vollständig beständig.

5. Agent iteriert basierend auf Signalen. Das ist der Teil, den die Leute übergehen, also lass mich konkret sagen, was "iterieren" bedeutet. Der Agent bemerkt nicht magisch Muster. Er hat einen separaten Überprüfungszyklus: eine cron-gesteuerte Funktion, die wöchentlich läuft, den Ausführungsverlauf vom Orchestrator liest und die Leistung bewertet:

1export const reviewSkillPerformance = inngest.createFunction(
2  { id: "review-skill-performance" },
3  { cron: "0 10 * * 5" }, // Jeden Freitag um 10 Uhr
4  async ({ step }) => {
5    const runs = await step.run("fetch-run-history", async () => {
6      return await getInngestRuns({
7        functionId: "incident-triage",
8        since: daysAgo(7),
9      });
10    });
11
12    const analysis = await step.run("analyze-performance", async () => {
13      const successRate = runs.filter(r => r.status === "completed").length / runs.length;
14      const avgDuration = average(runs.map(r => r.duration));
15      const incidents = await fetchIncidentOutcomes(); // Korrelierten die Vorfälle mit tatsächlichen Ausfällen?
16
17      return await callLLM({
18        prompt: `Überprüfe die Leistung dieser Fähigkeit in der letzten Woche.
19                 Erfolgsrate: ${successRate}
20                 Durchschnittliche Dauer: ${avgDuration}ms
21                 Mit tatsächlichen Ausfällen korrelierte Vorfälle: ${incidents.confirmed}/${incidents.total}
22                 Fehlalarme: ${incidents.falsePositives}
23                 Team hat auf Warnungen reagiert: ${incidents.actedOn}/${incidents.total}
24
25                 Sollten wir Schwellenwerte oder die Klassifizierung anpassen? Welche spezifischen Änderungen?`,
26      });
27    });
28
29    if (analysis.shouldModify) {
30      await step.invoke("update-skill", {
31        function: coreAgent,
32        data: { prompt: `Aktualisiere die Incident-Triage-Fähigkeiten basierend auf den folgenden vorgeschlagenen Änderungen: ${analysis.proposedChanges}` },
33      });
34    }
35  }
36);

Die "Überprüfung" ist eine Funktion. Sie liest den Ausführungsverlauf, prüft, ob Vorfälle mit tatsächlichen Ausfällen korrelierten, und gibt dieses Signal an das LLM weiter. Wenn der Health-Check immer wieder einen Dienst als beeinträchtigt markiert, das Team ihn aber ignoriert, weil die Schwellenwerte zu empfindlich sind, fängt der Überprüfungszyklus es auf, und die Fähigkeit wird aktualisiert, um die Klassifizierung anzupassen. Keine Magie. Ein Cron-Job mit einem LLM auf dem Entscheiderstuhl.

Was ist mit Validierung? Der Agent, der Code schreibt, ist nur so gut wie die Schutzmaßnahmen darum herum. Der Code kann typprüfbar sein. Der Agent kann die Funktion selbst aufrufen, um sie zu testen, da er mit der Orchestrierungs-Engine selbst interagieren kann. Es ist zwar nicht absolut sicher, aber du gibst dem Kernagenten die Fähigkeit, die Fähigkeiten, die er schreibt, nativ innerhalb des Systems, in dem er operiert, zu debuggen. Der Überprüfungszyklus fängt Probleme, die beim anfänglichen Debuggen nicht erkannt wurden.

Wenn man das eine Stufe weiterdenkt, kann der Agent onFailure-Hooks verwenden, um sich selbst auszulösen, einen bestimmten Fehler selbst zu bewerten. Es ist eine Rückkopplungsschleife, die sich ständig verbessert.

Was ist mit Konflikten? Ablaufsteuerungen, insbesondere Parallelitätssteuerungen oder Singletons, behandeln den einfachen Fall (Parallelität: [{ limit: 1, key: "event.data.service" }]), was bedeutet, dass nur eine Incident-Triage gleichzeitig pro Dienst läuft. Aber die tiefergehende Frage ist: Was passiert, wenn zwei Health-Checks gleichzeitig Probleme im selben Dienst erkennen? Der Orchestrator stellt sie in die Warteschlange. Die zweite Triage wartet, bis die erste abgeschlossen ist. Keine doppelten Warnungen, keine Wettlaufsituationen. Das ist nicht theoretisch. Es ist das gleiche Parallelitätsprimitiv, das du in jeder Job-Warteschlange verwenden würdest.

Der Agent führt nicht nur Aufgaben aus. Er baut sich seine eigene Infrastruktur. Jede Fähigkeit bleibt über das Gespräch hinaus bestehen, das sie erstellt hat. Töte den Agentenprozess und starte ihn neu. Die Fähigkeiten laufen weiter. Tausche das zugrundeliegende Modell aus. Die Fähigkeiten laufen weiter. Der Agent ist vergänglich – seine Ausgabe ist beständig.

Systemübersicht der Agentenschleifen-Architektur

Die Sicht des Entwicklers

Das ist wichtig, denn wenn der Entwickler nicht sehen kann, was der Agent bereitgestellt hat, nicht debuggen kann, was kaputt gegangen ist, und nicht prüfen kann, was um 3 Uhr morgens lief, ist die gesamte Architektur eine große Haftung.

Die Orchestrierungs-Engine speichert jeden Durchlauf, jeden Schritt, jede Eingabe, jede Ausgabe, jeden Wiederholungsversuch. Eine Fähigkeit, die der Agent letzten Dienstag bereitgestellt hat und die um 4 Uhr morgens fehlgeschlagen ist? Du kannst genau sehen, welcher Schritt fehlgeschlagen ist, was die Eingabe war, welchen Fehler er ausgelöst hat und wie oft er wiederholt wurde, bevor er aufgegeben hat. Vollständige Ablaufverfolgungen bis auf Schritt-Ebene sind die Ausgabe der Orchestrierungs-Engine selbst.

Das ist kein Dashboard, das hinterher aufgesetzt wurde. Es ist der beständigen Ausführung inhärent. Jeder step.run() ist ein Prüfpunkt. Jeder Prüfpunkt ist beobachtbar. Wenn das Ding, das den Code geschrieben hat, kein Mensch ist, ist Beobachtbarkeit kein Nice-to-have – es ist die Vertrauensebene.

Im Alltag sieht der Workflow des Entwicklers so aus: Morgens das Durchlauf-Dashboard prüfen. Sehen, welche Fähigkeiten über Nacht gelaufen sind, welche erfolgreich waren, welche fehlgeschlagen sind. Wenn eine Fähigkeit, die der Agent geschrieben hat, sich falsch verhält, kannst du den Code direkt lesen, bearbeiten, löschen oder dem Agenten sagen, er soll sie reparieren. Der Agent hat sie geschrieben, aber du besitzt sie. Der Agent und seine Fähigkeiten sind immer noch ein Garten, den du pflegen solltest.

Warum Beständigkeit grundlegend ist

Van Horn: "Diese Dinge müssen einen Neustart überleben."

Hier ist, was Beständigkeit in der Praxis bedeutet:

"Lass es einfach in einem Container laufen" verschafft dir Betriebszeit. Es verschafft dir keine Korrektheit. Ein Container, der nach einem Absturz neu startet, bringt den Prozess zurück, aber jeder laufende Durchlauf der Schleife beginnt von vorne. Jeder Schritt wird erneut ausgeführt. Jeder LLM-Aufruf wird neu getätigt. Die Schleife sieht so aus, als liefe sie, aber sie läuft blind.

Wie das im Vergleich zu bestehenden Werkzeugen steht

Einige Werkzeuge bieten dir vielleicht eine "hübsche" schlüsselfertige Lösung für diese Art von System an, oder du entscheidest dich, einige Werkzeuge niedrigerer Ebene zusammenzustückeln und dein eigenes System zu erstellen. Keine Wahl ist falsch, aber die richtige Architekturebene sollte es dir und deinem Agenten ermöglichen, sich im Laufe der Zeit weiterzuentwickeln. Flexibel, dynamisch, beständig.

Beständige Ausführungsprimitiven, die gut für einen Agenten passen, die ein Agent leicht schreiben kann, und die Beobachtbarkeit und APIs, um den Agenten zu beobachten und ihm zu ermöglichen, orchestrierungsbewusst zu sein.

Ein funktionierendes Beispiel

Wir testen diese Muster intern bei Inngest, und du kannst ein Konzept davon im "Utah"-Projekt-Repo hier sehen: https://github.com/inngest/utah: Es ist ein Agenten-Geschirr, das auf Inngests beständiger Orchestrierung aufbaut und ebenfalls orchestrierungsbewusst ist.

Das System hat einen Sidecar-Prozess, der es dem Hauptagenten ermöglicht, Inngest-Funktionen in seinem eigenen Workspace zu schreiben und zu bearbeiten und sich so mit "Fähigkeiten" (im Kontext dieses Artikels) zu erweitern. Wir planen bald, ein ganzes System mit Beispiel-Starter-Schleifen bereitzustellen, aber die Ideen dort können die Ideen in diesem Artikel etwas klarer demonstrieren.

Die sich potenzierende Schleife

Satya Nadellas aktueller Beitrag hat etwas benannt, das die Industrie gefühlt hat: Der Burggraben ist nicht das Modell – es ist die Schleife.

Sein Rahmenwerk: Es gibt zwei Arten von Kapital. Humankapital, das Wissen und Urteilsvermögen, das dein Team über Jahre aufgebaut hat. Und was er Token-Kapital nennt, die KI-Workflows, Entscheidungsmuster und erlernten Fähigkeiten, die ein Unternehmen auf Basis von Foundation-Modellen aufbaut.

Die These: Diese potenzieren sich gegenseitig. Jeder verbesserte Workflow erzeugt bessere Signale. Bessere Signale führen zu schärferem KI-Verhalten. Schärferes Verhalten macht menschliche Aufmerksamkeit für Arbeiten mit höherem Urteilsvermögen frei. Eine Hügelsteigungsmaschine.

Das ist es, was die Architektur der Agentenschleife konkret ermöglicht:

• Jede beständige Fähigkeit, die der Agent bereitstellt, ist institutionelles Wissen, das als ausführbare Infrastruktur kodiert ist. Es bleibt bestehen. Es läuft, ob ein Mensch zusieht oder nicht.
• Ein cron-gesteuerter Überprüfungszyklus, der die Fähigkeitsleistung bewertet und iteriert. Das ist die Hügelsteigungsmaschine, real gemacht. Kein Schwungrad-Diagramm in einer Präsentation. Eine Funktion mit einem Cron-Trigger.
• Wenn deine Fähigkeiten bei einem Prozess-Neustart sterben, setzt sich die Potenzierung auf Null zurück. Beständigkeit ist das, was die Investition bestehen lässt.

Nadellas Kernpunkt: "Ein Unternehmen sollte in der Lage sein, ein 'Generalisten'-Modell auszutauschen, ohne die als 'Unternehmensveteran' bekannte Expertise zu verlieren, die in ihr Lernsystem eingebaut ist." Das ist das Fähigkeitsbibliotheks-Muster. Beständige Funktionen kümmern sich nicht darum, welches LLM sie aufruft.

Baue entsprechend

Die Diskussion drehte sich darum, was Agenten tun: Schleifen, Werkzeuge, Argumentation, Kontext-Engineering. Die nächste Diskussion dreht sich darum, was die Agenten betreibt.

Drei Schichten: Schleife, Fähigkeit, Orchestrator. Die Schleife ist die Arbeitseinheit. Die Fähigkeit ist das Kapital. Die Orchestrierungs-Engine ist das, was beide beständig macht. Das Sidecar-Muster ist das Modell: Ein Agent schreibt seine eigenen beständigen Fähigkeiten, stellt sie bereit, überprüft, wie sie funktionieren, und iteriert. Kein Gedankenexperiment. Es ist ein funktionierendes Modell.

Wir haben Inngest als Orchestrierungs-Engine dafür gebaut: step.run(), step.invoke(), Cron-Trigger, ereignisgesteuerte Ablaufsteuerung, Parallelitätssteuerungen und vollständige Schritt-für-Schritt-Beobachtbarkeit. Aber das Architekturmuster ist größer als jedes einzelne Werkzeug. Wenn du Agentenschleifen in der Produktion baust, definiere die drei Schichten.

Die Primitiven existieren heute. Baue entsprechend.