Kontexttechnik für einen Quant-Forschungsagenten: Nachweisstufen und Datenspeicher

Entscheidung darüber, wem ein Agent vertrauen darf

Stellen Sie sich eine für den WorldQuant BRAIN Quant-Wettbewerb entwickelte Forschungsumgebung vor, die von KI gesteuert wird. Bevor es spezialisierte Agenten, Lebenszyklusprüfungen oder autonome Schleifen gibt, stellt sich ein grundlegenderes Designproblem: Welche Aussagen darf das System als wahr betrachten? Die Rohdaten liefern sich in vier völlig unterschiedlichen Formen.

Erstens gibt es die offizielle Dokumentation der Plattform und des Turniers, die erklärt, wie die Ausdrucks Sprache funktioniert, welche Operatoren und Datensätze verfügbar sind und welche Simulationseinstellungen zulässig sind. Zweitens sind die Methoden. Marcos López de Prados drei Bücher bieten Werkzeuge zur Analyse von Backtest-Statistiken, Strategierisiken, Mehrfachtests, Portfoliostrukturen sowie Falsifizierungsfragen, während Igor Tulchinskys „Finding Alphas“ auf praktische Weise den Aufbau von Ideen, die Umschichtung von Positionen, Korrelationen, Überanpassung, Verzerrungen und Langlebigkeit behandelt. Drittens gibt es eine Reihe von Artikeln und detaillierten Forschungsnotizen zu wirtschaftlichen Anomalien, Marktteilnehmern und Informationsflüssen, die als Graph angeordnet werden können, der Axiome, Theorien, Anomalien, Mechanismen und Implementierungsformen miteinander verbindet. Der Vierte umfasst alles, was das Projekt während seines Laufs erzeugt: Simulationsergebnisse, tägliche Gewinn- und Verlustkurven, Korrelationen von Portfolios, Resilienzstatistiken, Plattformüberprüfungen, Experimenthistorien, Betriebsereignisse, fehlgeschlagene Builds sowie die daraus gezogenen Lehren.

Jedes dieser Elemente stellt einen Kontext dar, weist jedoch unterschiedliche Wahrheitswerte auf, und keines passt eindeutig in eine einzige Anfrage, ein einziges Dokumentformat oder eine einzige Datenbank. Daher beginnt die Kontextgestaltung in diesem Umfeld nicht bei Tokenbudgets, sondern mit der Gestaltung von Beweisstufen sowie den Datensystemen, die jede dieser Stufen erhalten.

Links befindet sich der naive erste Entwurf, bei dem Regeln, Bücher, Artikel sowie die eigenen Ergebnisse des Systems in einen einzigen Prompt gepresst werden und alle gleich viel Gewicht haben. Rechts behält jede Behauptung ihr eigenes Niveau: Regeln bilden die „Wände“, Überzeugungen schlagen Tests vor, Beobachtungen präzisieren die Überzeugungen – und nichts innerhalb dieser „Wände“ kann sie ändern.

Drei Ebenen von Beweisen

Unter „Beweis“ ist im praktischen Sinne zu verstehen: Für jede Behauptung sollte man fragen, welcher Beweis ausreicht, wer dafür verantwortlich ist und was dazu führt, dass sie widerlegt werden kann. Drei Ebenen beantworten diese Fragen.

L1 erfasst, was die Plattform als Spiel deklariert, unter Verwendung offizieller Plattform- und Turniermaterialien. Wenn der Agent wissen muss, welche Einstellungen vorhanden sind, was ein Operator tut, welche Prüfungen ein Kandidat bestehen muss oder wie das Turnier seine Punktzahl berechnet, schaut er hierhin. Eine lokale Kopie kann veralten, doch kein überraschendes Experiment kann eine Regel ändern.

L2 erfasst, was das System tatsächlich gesehen hat. Hier gehören die Simulationsergebnisse sowie die täglichen PnL-Daten, das heutige Portfolio, Plattformprüfungen, operative Ereignisse und der aktuellste Leaderboard-Zustand. Jede Messung ist mit dem Zeitpunkt der Beobachtung versehen. Ein Neustart überschreibt nichts – er erzeugt eine neue Beobachtung, sodass die Historie niemals nachträglich aufgeräumt wird.

L3 erfasst das, was das System derzeit als nützlich betrachtet. Bücher, Artikel, Wirtschaftstheorien, Spezifikationen, Auswertungen von Wissensgraphen, aufgeschriebene Lektionen sowie gezielte Falsifizierungen gehören zu dieser Schicht. Sie leiten die nächste Aktion vor und bleiben offen für Überprüfung.

Die Reihenfolge ist nicht streng – L1 übertrifft stets L2 und L2 wiederum L3. Jede Ebene beantwortet eine andere Art von Frage. Bei sachlichen Streitigkeiten zwischen Quellen hat die stärkste direkte Quelle Vorrang; daher hat eine offizielle Regel mehr Gewicht als eine Paraphrase in einer Agentenanweisung, und eine abgewogene Antwort hat mehr Gewicht als das, was ein Buch jemanden erwarten ließ. Bei der Frage, was als Nächstes ausprobiert werden soll, reichen jedoch Regeln und Messungen nicht aus, um eine Antwort zu liefern. Dann wird L3 benötigt, um eine begründete Entscheidung zu treffen.

In dieser Tabelle werden drei Ideen verfolgt. Der „Post-Earnings Drift“ wurde durch seinen Falsifizierer nicht beseitigt; stattdessen wurde die fehlerhafte Konstruktion identifiziert, wodurch die Idee auf der Grundlage von Analystanpassungen neu aufgebaut wurde und zwei Versionen eingereicht wurden. Eine Idee vom Typ „Peer-Basket“ begann als reine Annahme ohne jeglichen Beweis und schaffte dennoch die Überprüfung. Die Idee vom Typ „Dividenden-Uhr“ scheiterte bei allen zehn Konstruktionen, wodurch die Annahme auf die Dividendentermine beschränkt wurde. Grüne Quadrate haben die Plattformprüfungen bestanden, rote haben sie nicht bestanden, graue weisen keine vorhandenen Prüfungen auf, und umrandete wurden eingereicht.

Eine einzige Datenbank kann sowohl eine Messung (L2) als auch die daraus resultierende Interpretation durch eine Person (L3) enthalten, was bedeutet, dass das Niveau zur Aussage selbst gehört und nicht zu ihrem Speicherort. Ein nützliches Kontextdokument ist daher reicher als reiner Text. Es sollte die Aussage selbst, ihr epistemisches Niveau, die Quelle, den Eigentümer, den Umfang, die Zeit der Beobachtung oder Überprüfung, die Unsicherheit, einen stabilen Identifikator sowie alle Beweise aufzeichnen, die sie ändern könnten. Bei Fakten, die sich im Laufe der Zeit ändern, hilft ein Paar Zeitlinien: Wann etwas zutraf und wann das System es erkannte. APIs, die spät antworten und historische Daten nachträglich einfügen, verschärfen diese Lücke.

Kontext ist im Grunde eine kleine Datenplattform

Jeder Store wird entsprechend seinem Verhalten dargestellt. Das Protokoll stapelt die Beweise in Schichten, wobei eine einzige Abstammungskette durch sie verläuft; alte Ereignisse verblassen allmählich. Das Diagramm besteht aus einem Paar Tabellen, das im Speicher zu einem Multigraphen wird, und die Dateien werden nach ihrem Lebenszyklus gruppiert. Stabile IDs halten alle Komponenten zusammen. Der tägliche Gewinn- und Verlustausweis befindet sich weiterhin an dem Ort, den die eigene Spezifikation des Projekts vorsieht.

Sobald Beweisniveaus vorhanden sind, wird ein weiterer Punkt offensichtlich: Der Kontext ist kein einziges Korpus. Er verhält sich wie eine bescheidene Datenplattform. Der größte Teil besteht aus dem Forschungsregister, das auf der überprüften Arbeitsstation als transaktionale SQLite-Datenbank vorliegt. Es als Experimentstabelle zu bezeichnen, unterschätzt dessen Bedeutung, denn es fungiert als Beweisregister, das mehrere Datensätze enthält. Eine Gruppe umfasst die Forschungsziele, also Mechanismen, Hypothesen, Vorhersagen sowie die Abfolge der Implementierungen. Eine weitere Gruppe beinhaltet Messdaten, die Plattformantworten, Statistiken aus den Beobachtungsdaten, Überprüfungen, tägliche Gewinn- und Verlustwerte sowie Metriken für Stresstests speichern. Eine dritte Gruppe dient der Interpretation und enthält Zuordnungen, Erkenntnisse sowie gezielte Falsifizierungsversuche. Eine vierte Gruppe kümmert sich um die Governance und verfolgt potenzielle Entscheidungen, Genehmigungen sowie das, was bei der Einreichung geschah. Die letzte Methode ist die materialisierte Analyse: Portfolio-Deltas, Korrelationsübersichten, Mustercaches sowie Zusammenfassungen von Stresstests – all das kann aus kanonischen Eingaben neu erzeugt werden.

Durch die Überprüfung wurde eine Unstimmigkeit festgestellt. In einem Designdokument heißt es, dass die täglichen PnL-Werte in Parquet-Dateien gespeichert wurden, doch die Datenbank speichert weiterhin jede Zeile. Das Dokument stellt eine Annahme dar (L3), die Datenbank hingegen eine Beobachtung (L2); im Falle eines Konflikts hat die Beobachtung Vorrang.

Danach kommt ein Event-Store für operative Zwecke, der als eigenständige SQLite-Datenbank geführt wird. Die darin gespeicherten Events können Identifikatoren für Zyklen, Batch-Operationen, Kandidaten, Hypothesen, Agenten und Prozesse sowie einen versionierten JSON-Inhalt enthalten. Es wäre verlockend, sie in das Hauptbuch aufzunehmen, doch die Aufbewahrungsanforderungen unterscheiden sich. Forschungsergebnisse sind kanonisch und müssen dauerhaft erhalten bleiben. Debug-Ausgaben, versandte Events, Warteschlangen für Zustandswechsel sowie temporäre Eingriffe nehmen schnell zu und können komprimiert oder gelöscht werden. Wenn diese Strukturen getrennt bleiben, kann ein Anstieg an Observabilitätsdaten das wissenschaftliche Archiv nicht überlasten oder blockieren.

Dann gibt es noch das Wissensgraph – ein transaktionales Eigenschaftsgraph mit einer absichtlich einfachen physischen Struktur: eine Knotentabelle, eine Kantenliste sowie JSON-Attribute für Beweise, die jeweils auf einen bestimmten Typ zutreffen; all das wird in ein im Speicher liegendes Graph eingeladen, um darin navigieren zu können. Die transaktionale Schicht vermeidet die Probleme durch Korruptionen und Konkurrenzen, die bei einem einzigen riesigen YAML-Datei auftreten können, während die im Speicher vorhandene Form das logische Arbeiten erleichtert.

Das Dateisystem gilt ebenfalls als Datensystem. Ein Repository enthält unveränderliche Plattformdokumente, Bücher, Artikel sowie daraus abgeleitete Berichte, und es wäre ein Fehler, all das in den Speicher zu laden, da sich ihre Lebenszyklen unterscheiden. Plattformdokumente ändern sich niemals. Spezifikationen unterliegen unter Versionskontrolle designbedingten Prioritäten. Berichte sind Ableitungen, die aufgezeichnete Eingaben sowie eine Methode zur Neuerstellung benötigen. Speicherdateien sind kurze, lesbare Verweise auf wiederverwendbare Erkenntnisse. Warteschlangendateien, Caches und Protokolle stellen vorübergehenden Betriebszustand dar, während Modellbinärdateien, PnL-Exporte sowie große Snapshots Artefakte sind, die am besten in Objektspeichern statt in Git aufbewahrt werden sollten.

Die Fehlerbeispiele sind aufschlussreich. Ein besonders leistungsstarker Alpha-Algorithmus wäre beinahe verworfen worden, weil das Buchhaltungssystem behauptete, alle Prüfungen seien erfolgreich verlaufen, während ein Skript eine Ausführungsdatei las, die einen Sharpe-Wert von 0 anzeigte. Ein früher Gewinner hatte überhaupt keine Entscheidungsprotokolle, bis ein Abgleich sechs Wochen später welche lieferte. Ein Urteil zugunsten des Wetten-gegen-Beta-Ansatzes existierte nur in einer Markdown-Datendatei, sodass das Buchhaltungssystem selbst nichts unternommen hätte, um eine erneute Ausführung zu verhindern.

Es zeigt sich ein mehrfach typisiertes Kontextsystem, obwohl fast alles noch auf einem einzigen Laptop läuft. SQLite kümmert sich um Transaktionen, das Graphenmodell um Beziehungen, Parquet ist das geplante Format für große Zeitreihen, Markdown enthält Wissen, das von Menschen überprüft werden kann, und vorübergehende Dateien koordinieren lokale Prozesse.

Ein echter Mechanismus wird hier ohne Angabe seiner Bezeichnung dargestellt. Links ist seine Abstammung im Wissensgraphen zu sehen, rechts werden jede Hypothese, jedes Experiment sowie jeder Kandidat aufgeführt, der ihn getestet hat. Einige Fehler traten bei jeder Konstruktion auf, während andere nur auf eine bestimmte Implementierung beschränkt waren. Die beiden Teile teilen sich außer der ID entlang der Naht nichts, und diese einzige Schlüsselwerte reicht aus, um sie zu einem kompakten Kontextpaket zusammenzufügen.

Mechanismen fungieren als Verbindung zwischen den beiden Speichern. Im Graphen erscheinen sie als wirtschaftliche Konzepte zusammen mit ihren Quellen, während sie im Buchhaltungssystem als Tag bei jeder Hypothese sowie jedem Kandidaten angegeben werden, der sie angewandt hat. Empirische Zusammenfassungen können zur Erleichterung der Navigation wieder auf Graphenknoten zurückgeführt werden, doch diese sind lediglich Spiegelbilder – die Experimentdatenbank bleibt der Ort, an dem die Zahlen tatsächlich vorhanden sind. Ein gutes Kontextpaket wird daher durch die Verknüpfung verschiedener Systeme erstellt. Es umfasst einen kleinen Graphenbereich, die Herkunft der Quellen, aktuelle empirische Zusammenfassungen, kürzlich aufgetretene Fehler sowie die geltenden Plattformbeschränkungen. Das Modell benötigt weder den gesamten Graphen noch jede PnL-Zeile. Entscheidend ist vielmehr der kürzeste Beweisweg zur jeweiligen Entscheidung.

Wenn Graph und Ledger denselben Mechanismus-ID teilen, kann eine vollständige Abteilung gemeinsam dargestellt werden: Theorie, Experimente, alle Kandidaten sowie eine Zusammenfassung auf dem Graphenode, der dem Ledger entspricht. Die Idee einer Rückkaufserlaubnis stammt direkt aus einer Veröffentlichung aus dem Jahr 1995, wurde jedoch nie der Abteilung für Aktienrückkäufe zugeordnet, sodass keine ihrer Ergebnisse über den Graphen erreichbar sind.

Mehrere Datenspezifikationen sollten strenger gestaltet werden. Objekte, die zwischen verschiedenen Speichern übertragen werden, sollten eine explizite JSON-Schema-Version enthalten. Jede abgeleitete Metrik sollte die Codeversion, den Quellcode-Zustandsbildschirm sowie die Methodeversion angeben, die sie erzeugt hat. Jedes Experiment benötigt ein inhaltsbasiertes Manifest zur Wiederholbarkeit, das den Code-Commit, die Umgebungsübersicht, die Plattformeinstellungen sowie die IDs der Hypothese und der Implementierung auflistet. Zudem sollte die Abstimmung wie jede andere Frage der Datengüte getestet werden, anstatt davon ausgegangen zu werden, dass sie harmlos sei.

Zusammenfassend lässt sich sagen, dass das Diagramm Kontext ist, das Register Kontext ist und auch die Verbindung zwischen ihnen Kontext darstellt. Diese Verbindung erfordert denselben ingenieurtechnischen Aufwand wie der Modellcode.

Wo dies auf die Steuerungsingenieurwesen trifft

Keine Anfrage wird in ihrer Gesamtheit weitergeleitet. Jeder Speicher liefert einen kleinen Teil für ein typisiertes Paket, und jeder Spezialist erhält genau das, was er benötigt. Die Ergebnisse fließen nach Typ an die richtigen Empfänger zurück, die Regeln werden niemals überschrieben, und zwei Schleifen füllen das nächste Paket mit unterschiedlichen Geschwindigkeiten wieder auf.

Dies markiert die Grenze zwischen Kontextengineering und Harness-Engineering. Die Kontextverwaltung ist für die Ebenen L1 bis L3 verantwortlich: Sie speichert Quellen, Messwerte, Prioritäten, Herkunft, Zeitstempel, Umfang sowie stabile Identifikatoren. L4, das agierende Harness, entscheidet, welche Beweise abgerufen werden, wie viel über eine Stufengrenze hinaus erlaubt ist, welcher Spezialist sie erhält und welche Schlussfolgerungen zulässig sind. Darunter liegen der Quellcode (L5), die lokale Infrastruktur (L6) sowie die verteilte Infrastruktur (L7). Diese Schichten werden eine fehlerhafte Entscheidung fehlerfrei ausführen, haben aber keine Einflussmöglichkeit darauf, ob eine Eingabe eine Regel, eine Beobachtung oder ein Glaube war.

In einer frühen Version verschwamm diese Trennung. Die Hauptanweisungsdatei entwickelte sich zu einer 627 Zeilen umfassenden Wiki, die Turnierregeln, den Live-Status, Methoden sowie die Lektionen des Vortags enthielt. Nachdem sie auf eine kleine Router-Struktur reduziert wurde, erreichte der Kontext den Agenten über vier Wege. Eine kurze Schicht bleibt ständig geladen. Ein Startpaket übermittelt aktuelle Lektionen und Warnungen. Gebietsbezogene Regeln werden nur dann hinzugefügt, wenn eine Aufgabe dieses Gebiet betrifft, und spezialisierte Rollen mit ihren Erinnerungen werden bei Bedarf abgerufen.

Eine Anfrage, schrittweise verfolgt

Betrachten Sie die Frage „Was sollte als Nächstes ausprobiert werden?“ Der Harness beginnt damit, ein Prüfpaket zusammenzustellen. Aus L1 werden die relevanten Ausdrücke sowie Einschränkungen hinsichtlich Einstellungen und Bewertung herangezogen. Aus L2 stammen das aktuelle Portfolio, aktuelle Messungen, Angaben dazu, wie viel des Suchraums abgedeckt ist, sowie noch ungelöste Ergebnisse. Aus L3 werden der am relevantesten erscheinende Graphenzweig, die theoretische Herkunft, spezifizierte Falsifizierer, Forschungsanforderungen sowie empirische Erkenntnisse entnommen.

Dann treten Subagenten in Aktion. Ein Hypothesenspezialist arbeitet mit diesem Paket, um einige wirtschaftliche Ansätze vorzuschlagen, ohne die schwachen Argumente hinter den Formeln zu verbergen. Nachdem ein Ansatz ausgewählt wurde, übernimmt ein Modellierungsspezialist die registrierte Hypothese und entwickelt Implementierungen, die sich wirklich voneinander unterscheiden. Ein Experimentsspezialist erhält den Implementierungsbaum sowie die Plattformbeschränkungen und dokumentiert anschließend, was gemessen wird.

Jede Phase hat ihr eigenes Ziel. Der L2 des Buchhaltungssystems erhält rohe Plattformergebnisse sowie normalisierte Messwerte. Betriebsereignisse wie Startvorgänge, Toolaufrufe, Wiederholversuche und Koordinationsverkehr gehören in den Ereignisspeicher. Wenn ein Ergebnis eine Lektion oder einen spezifischen Falsifizierer liefert, wird es unter L3 abgelegt. Graphische Zusammenfassungen entstehen durch Abgleich mit dem Buchhaltungssystem und werden niemals manuell bearbeitet, während große PnL-Reihen, Diagramme und angepasste Modelle zu Artefakten werden, auf die andere Einträge verweisen.

Sowohl die eingereichten Alpha-Versionen begannen mit Paketen, die bereits Beweismittel enthielten. Eine Gruppe hatte zuvor das Portfolio verbessert, während die andere Idee eine bereits vorhandene Version verwendete, die unkorrelierte Alpha-Ergebnisse ergeben hatte. Auch eine Idee zur Bewertungsänderung erhielt ein Paket, eine ungetestete Zelle auf der Chancenkarte sowie einen früheren Gewinner zum Nachahmen – doch alle 18 ihrer Konstruktionen scheiterten dennoch.

Phasenweise Einführung der Infrastruktur

Alles auf einmal zu verschieben, wäre ein Fehler. Jeder Kanal wechselt in seiner eigenen Phase, und ein Tor öffnet sich nur dann, wenn ein messbarer Auslöser dies rechtfertigt. Die rechte Seite zeigt den vertrauenswürdigen einzigen Schreibweg (Commit, Outbox, Exporter, Projection), im Gegensatz zu einem doppelten Schreibvorgang, der zwei widersprüchliche Wahrheiten erzeugt.

Der aktuelle lokale Stack kann mehr leisten, als es auf den ersten Blick scheint. SQLite eignet sich hervorragend als Standard für einzelne Forscher – mit echten Transaktionen, einfachen Backups, schnellen lokalen Abfragen und nahezu keiner Überhead-Operation. Dennoch sind Belastungen sichtbar: Eine Datenbank von mehreren Gigabyte enthält Dutzende Millionen von Zeitserie-Zeilen, mehrere Prozesse können um lokale Schreibvorgänge konkurrieren, Laufzeitereignisse nehmen ständig zu, Artefakte und Snapshots sind an einen einzigen Rechner gebunden, und das Wiedererzeugen eines Ergebnisses an einem anderen Ort erfordert mehr versteckten Zustand, als irgendjemand wünscht. Eine fünfphasige Entwicklung macht daher Sinn.

Phase 0 zielt darauf ab, das Design der Realität anzupassen: Entweder wird die unvollendete PnL-Migration abgeschlossen oder bewusst rückgängig gemacht, anschließend wird die Prüfung automatisiert, bei der die Dokumentation mit dem tatsächlichen Speicher verglichen wird. In Phase 1 werden umfangreiche Dateien nach außen verlagert, sodass tägliche PnL-Daten, Diagramme, Modelldateien, umfangreiche Berichte sowie Datenbank-Snapshots in S3-kompatiblen Objektspeichern abgelegt werden. Dabei werden die PnL-Daten in komprimierte Parquet-Partitionen aufgeteilt, die durch unveränderliche Manifeste, Checksummen sowie Lebenszyklusregeln gesichert sind. In Phase 2 werden Metadaten nur dann verschoben, wenn Konkurrenzen dies erfordern. Wenn Remote-Arbeiter, mehrere Maschinen oder Kollegen gleichzeitig schreiben müssen, werden das Buchhaltungssystem sowie der Ereignisspeicher in verwaltete PostgreSQL-Instanzen übertragen – entweder als separate Datenbanken oder zumindest als separate Schemata mit eigenen Aufbewahrungsrichtlinien. In Phase 3 wird MLOps lediglich als Ergänzung hinzugefügt und niemals als Quelle der Wahrheit; daher können Tools wie Weights & Biases oder MLflow unterstützen, ohne das Buchhaltungssystem oder das Graphenmodell zu ersetzen. In Phase 4 wird die Orchestrierung vom Zustand getrennt: Forscher arbeiten in Containern mit unveränderlichen Job-Manifesten, während ein Warteschlangen- oder Workflow-Engine idempotente Aufgaben mit Leasing-Optionen, Wiederholungsversuchen und Zeitlimits zuweist. In Phase 5 werden umfangreichere Analysen nur dann bereitgestellt, wenn die Arbeitslast dies rechtfertigt. Ein Lakehouse-Tabellenformat, eine spezielle Graph-Datenbank oder eine Streaming-Plattform könnten letztendlich vorteilhaft sein, aber nur dann, wenn bestimmte Abfragen zu Problemen führen, wie zum Beispiel Scans von Milliarden von Beobachtungen, viele gleichzeitige Graph-Überquerungen, Schema-Änderungen in großen Parquet-Dateien oder ein Bedarf an Echtzeit-Event-Verarbeitung.

Kein genauer Leistungszuwachs kann dieser Architektur zugeschrieben werden, da ihre Wirkung nie isoliert untersucht wurde. Ihr eigentlicher Beitrag besteht darin, dem System zu ermöglichen, ehrlich Widersprüche aufzuweisen. Ein Paper schlägt etwas vor, eine Simulation stimmt nicht zu, ein Falsifizierer verengt den Glauben daran – doch die Turnierregel bleibt weiterhin gültig.

Verwandte Artikel

• Die fünf Ebenen eines Agent Harness, mit Code, der ohne sie fehlschlägt — Eine praktische Übersicht über die fünf Stellen, an denen ein Agent Harness Regeln im Code durchsetzt, von Ausführungsgrenzen bis zu Kontextpipelines, sowie darüber, was die Forschung beweisen kann und was nicht.
• Selbstverbessernde Agenten durch Fähigkeiten: Wiederverwendung, Auswahl, Reparatur und Überprüfung — Ein vierteiliges Konzept für Agenten, die ihre eigenen Fähigkeiten verbessern: Funktionierenden Code speichern, Beschreibungen verfeinern, überprüfte Korrekturen vorschlagen und die Ausgabe vor der Weitergabe überprüfen.