Wir lassen jeden Tag vierundzwanzig Schachpartien zwischen fünf KI-Agents und Stockfish laufen. Nicht weil wir einen besseren Schach-Bot bauen wollen. Stockfish ist seit 2005 besser als jeder Mensch und seit Jahren besser als jede andere KI auf dem Planeten. Wir lassen sie laufen, weil Schach das sauberste Experiment ist, das wir gefunden haben, um zu untersuchen, was KI-Verhalten wirklich verändert.
Die fünf Agents sind keine unterschiedlichen Produkte. Es ist dasselbe System, an dem jeweils ein Knopf gedreht ist. Einer hat ein langes Gedächtnis vergangener Partien, einer hat eine kurze Identitätsbeschreibung, einer darf vor jedem Zug im Web suchen, einer soll seine eigenen Anweisungen über die Zeit umschreiben. Alle spielen gegen denselben Gegner. Wer verliert, verliert sauber. Wer gewinnt, gewinnt wegen des Knopfs.
Live anschauen kannst du das auf meetmyagent.io/chess. Die Seite zeigt die aktuelle Partie auf einem großen Brett, daneben eine kleine Spur, die Schritt für Schritt aufleuchtet während die KI denkt, und unten einen Feed, der in klaren Worten erklärt was gerade passiert ist. Keine Analyse, kein Kommentator. Es ist ein Forschungsinstrument, das zufällig öffentlich läuft.
Was wir wirklich fragen
Vier Fragen, die alle langweilig klingen, bis man sich die Antworten anschaut.
Die erste ist die direkteste: schlägt Memory die Websuche? Zwei unserer Agents nutzen dasselbe Modell, Claude Sonnet 4.6. Einer davon hat Zugriff auf ein strukturiertes Gedächtnis aus siebenundsechzig Schach-Notes plus zwölf Gegner-Pattern-Karten. Der andere hat kein Gedächtnis, kann aber vor jedem Zug das Web abrufen. Gleiches Gehirn, zwei verschiedene Wege informiert zu werden. Wenn Memory gewinnt, ist die Erkenntnis: eine kleine kuratierte Wissensbasis schlägt eine generische Suche für eine schmale Aufgabe. Wenn Websuche gewinnt, sollten wir aufhören Memory-Layer zu bauen und dem Modell einfach ein Such-Tool geben.
Die zweite Frage ist Reasoning-Tiefe. Claude Opus 4.8 ist genau an dem Tag erschienen, an dem dieser Text geschrieben wurde. Das Modell kann auf fünf verschiedenen Effort-Leveln aufgerufen werden, von low bis max, und Anthropic hat den Default Anfang des Jahres still von "high" auf "medium" geflippt, was nach Stella Laurenzos GitHub-Issue zu einer kleinen Saga in der Entwickler-Community wurde. Im Schach-Lab geben wir max Effort nur dem Opus-Agent. Jeder andere läuft auf Default. Opus bekommt zusätzlich einen längeren Personality-Prompt, ein längeres Memory-Fenster und einen schwereren Subprocess-Timeout. Jeder Opus-Zug kostet uns zwischen zehn und dreißig Cent statt der üblichen halben Cent. Lohnt sich das? Wir wissen es nach ein paar hundert Partien.
Die dritte Frage ist ob Self-Optimization wirklich hilft. Einer unserer Agents hat einen Slot, in dem sein eigener Prompt zwischen Generationen umgeschrieben werden kann. Wir nutzen eine einfache evolutionäre Schleife, keine fancy Theorie, einfach behalten was funktioniert und mutieren was nicht. Der Agent ist dasselbe Sonnet-Modell wie zwei der anderen, also kommt jede Verbesserung aus dem sich entwickelnden Prompt. Die ehrliche Erwartung ist hier marginal positiv, mit hohen Compute-Kosten. Aber das ist die Sorte Frage, die du nur beantworten kannst, indem du es Wochen laufen lässt.
Die vierte Frage ist Prompt-Länge. Unser kleinster Agent hat eine achtundzwanzigzeilige Persönlichkeitsbeschreibung. Der größte hat hundertzwölf Zeilen, strukturiert wie ein Mini-Handbuch mit Abschnitten zu Workflow, Memory-Disziplin, verbotenen Mustern und Identitätsanker. Das aktuelle LLM Chess Paper vom Dezember 2025 (arxiv 2512.01992) berichtet, dass "non-reasoning Modelle hochsensibel auf kleine Prompt- und Guideline-Variationen reagieren, die Performance unvorhersehbar kippen lassen können". Wir wollen sehen, ob unser Setup das reproduziert, und ob ein längerer Prompt das Modell tatsächlich verankert oder nur Rauschen hinzufügt.
Die fünf Spieler
Haiku 4.5 spielt die Rolle des Taktik-Jägers. Schnell, instinktiv, schaut zwei bis drei Züge voraus, schlägt gerne Figuren. Achtundzwanzig Zeilen Persönlichkeit. Das günstigste Modell in unserer Aufstellung.
Sonnet 4.6 spielt den soliden Strategen. König-Sicherheit zuerst, tauscht nur bei klarem Vorteil, geduldig. Fünfundvierzig Zeilen Persönlichkeit. Mittlere Kosten.
Opus 4.8 spielt den High-End Reasoning-Partner. Hundertzwölf Zeilen Persönlichkeit formatiert wie ein CLAUDE.md Handbuch mit explizitem Pre-Move Workflow, Memory-Disziplin-Regeln, zu vermeidenden Mustern und einem Identitätsanker. Bekommt max Reasoning-Effort, fünfzehn Memory-Hits pro Zug, zwei Minuten Timeout pro Stage. Der teuerste Agent.
Ein zweiter Sonnet 4.6 spielt den sich selbst entwickelnden Spieler. Dasselbe Modell wie der Stratege, aber sein Personality-Prompt hat einen Darwin-Slot, der zwischen Generationen mutieren kann. Gekoppelt an eine kleine evolutionäre Schleife, die Partie-Ergebnisse über die Zeit belohnt.
Ein dritter Sonnet 4.6 spielt den Web-Strategen. Überhaupt kein Gedächtnis. Stattdessen kann er vor jedem Zug das Web durchsuchen. Das ist die Kontrolle: dasselbe Modell wie zwei andere, aber ein komplett anderer Weg informiert zu werden.
Alle fünf spielen Stockfish 16, kalibriert auf etwa 1320 Elo. Klingt niedrig und ist es auch. Stockfish auf voller Stärke liegt bei rund 3600, aber wir wollen den LLMs eine echte Chance geben. Es geht darum die Unterschiede zwischen den fünf Agents zu messen, nicht sie mit einem 3600er Gegner zu demütigen, der in zwanzig Zügen gewinnt.
Der Stack, in klaren Worten
Jeder Zug durchläuft neun Stationen. Der Agent beobachtet das Brett, ruft relevante Memories zur Position ab, ruft relevante Memories zum Gegner ab, recherchiert optional etwas im Web, entwirft einen Plan, generiert Kandidatenzüge, verifiziert welche davon legal sind, reflektiert die Wahl und committet. Jede Station ist ein eigener Knoten in einer State Machine, und jede Station emittiert ein Trace-Event, das wir später auditieren können.
Die State Machine ist LangGraph. Der Scheduler der einmal pro Stunde ein Spiel feuert ist Temporal, self-hosted auf einer einzelnen Postgres-Instanz. Der Tracer der jeden Modell-Call und seine Kosten erfasst ist Langfuse, self-hosted auf derselben Box. Der Memory-Layer ist unser eigener Postgres-Memory-Server, wo jeder Agent seinen eigenen Scope hat. Die Brett-Validierung läuft über python-chess, exakt dieselbe Library die das ChessQA Benchmark nutzt. Der Gegner ist Stockfish 16 mit aktiviertem UCI_LimitStrength.
In diesem Stack sind keine exotischen Teile. Jedes Stück ist Open Source oder unser eigener Code. Das Ganze läuft auf einem Server.
Was wir bereits sehen
Es ist zu früh für starke Aussagen. Wir haben den stündlichen Cron vor ein paar Tagen gestartet, sind heute auf Opus 4.8 umgestellt und haben bisher etwa hundert Partien auf dem Brett. Aber drei Muster sind bereits sichtbar.
Memory-Hits zählen, aber nur wenn sie feuern. Wir hatten zwei Tage lang einen Bug, bei dem die Recall-Query gegen den Memory-Store den rohen FEN-String als Such-Token nutzte. Keine Memory-Note matchte je und Recall lieferte null Hits pro Zug. Die Agents spielten auf Random-Baseline-Stärke. Nachdem wir die Query auf einen phasen-bewussten Token umgestellt hatten ("position opening" oder "position middlegame"), sprang die Hit-Rate auf fünf pro Zug und die Spielqualität verbesserte sich sichtbar. Die Lehre ist nicht "Memory ist gut". Die Lehre ist, dass ein Memory-System ohne funktionierenden Retrieval-Layer Dekoration ist, und der einzige Weg das zu fangen ist es in einen echten Game-Loop zu bringen.
Personality-Prompts können Dinge vortäuschen die nicht stimmen. Unsere erste Opus-Personality-Datei referenzierte zwei Pipeline-Stationen, die in Wirklichkeit nicht existierten, plus einen "Recall-Strategy" Hook der nie verdrahtet war. Der Agent beschrieb pflichtbewusst seinen Workflow mit diesen Phantom-Stationen in der Reasoning-Trace. Die Lehre ist, dass du Personality-Dokumente in Sync mit der tatsächlichen Pipeline halten musst, sonst halluziniert der Agent sein eigenes Verhalten in seiner Reasoning-Narration, ohne dabei an Stärke zu verlieren. Das ist dasselbe Drift-Problem das du in Production-Docs siehst, nur schneller weil der Agent stündlich läuft.
Websuche braucht ein Opt-In Flag im Headless-Modus. Die Claude CLI im -p Print-Mode geht standardmäßig auf deny-all bei Tools. Wir haben das entdeckt als unser Web-Search-Agent still plausible aber unbelegte "Research"-Outputs produzierte, ohne jemals das Web zu treffen. Der Fix war --allowedTools WebSearch und --permission-mode bypassPermissions explizit zu übergeben. Die Lehre, wieder mal, ist dass Ablation-Studies nur dann valide sind wenn du verifizierst, dass jeder Hebel tatsächlich das bewegt was du denkst.
Was du davon mitnehmen kannst
Wenn du ein KI-System baust, das du über die Zeit nutzen willst, baue es so, dass die Unterschiede zwischen Konfigurationen von außen beobachtbar sind. Unser Schach-Lab ist kein Schach-Projekt. Es ist ein Weg, die unsichtbaren Unterschiede zwischen KI-Konfigurationen für jeden mit einem Browser sichtbar zu machen. Das ist ein nützliches Muster für jedes Team, das eine Config-Entscheidung verteidigen muss ("wir nutzen Memory weil hier sind 200 Partien wo es hilft") statt darüber zu streiten ("intuitiv sollte Memory helfen").
Wenn du ernsthafte KI-Evaluations machst, lass sie kontinuierlich laufen, nicht in Batches. Ein einmaliges Benchmark gibt dir einen Datenpunkt und friert dein Verständnis in genau diesem Moment ein. Eine kontinuierliche Schleife fängt Drift ab, fängt Modell-Updates ab (wir sind gerade mitten im Experiment auf Opus 4.8 umgestiegen) und gibt dir die Art statistischer Sicherheit, die ein einzelner Run nicht liefern kann. Das maxim-saplin LLM Chess Leaderboard auf GitHub zeigt das gut. Sie erweitern es immer wieder, wenn neue Modelle ankommen.
Wenn dich Schach im Speziellen interessiert, ist das LLM Chess Paper vom Dezember 2025 (arxiv 2512.01992) die sauberste Zusammenfassung des Felds gerade. Das EPAM 2026 Stück über die Wahl von KI-Modellen ist die einfachere Lektüre. Das dynomight-Blog von Ende 2024 ist das vergnüglichste, weil es versucht die seltsame Anomalie zu erklären, dass gpt-3.5-turbo-instruct, ein älteres non-reasoning Modell, Schach auf etwa 1750 Elo gespielt hat, während viele neuere chat-tunede Modelle nicht über 1300 hinauskommen. Die Antwort läuft auf "Regurgitation von Trainings-Daten plus ein paar Few-Shot Prompts haben die Arbeit gemacht" hinaus, also genau die Art Effekt die eine sorgfältige Ablation-Study erkennen und isolieren sollte.
Das nächste Mal wenn jemand behauptet, dass Memory, oder lange Prompts, oder höhere Effort-Settings KI-Agents zuverlässig besser machen, frag nach Belegen in einem Setting in dem du es selbst beobachten kannst. Wir haben Schach zu diesem Setting gemacht. Es gibt vermutlich bessere. Such dir deins aus und lass es ein paar Monate laufen.
