Ich war am 19. Mai bei Code w/ Claude in London, Anthropics Dev-Konferenz. Am meisten geblieben ist mir Boris Chernys Keynote. Keine Ankündigung, sondern seine Story: er hat selbst als Builder angefangen, kleines Team, ein Projekt das sie fast aufgegeben hätten, und heute ist es eins der wichtigsten Produkte bei Anthropic. Sowas von jemandem zu hören der genau da saß wo du gerade sitzt, das trifft anders. Hier die drei Sachen die nach einer Woche noch bei mir hängen, plus eine Linse die ich erst danach aufgeschnappt hab.
Managed Agents: Session State wird dir abgenommen
Managed Agents und die Infra dahinter kenne ich natürlich. Mein Reflex war trotzdem immer: baue ich lieber selber. Isabella Hes Workshop hat mir nochmal sauber gezeigt, was das Ding einem eigentlich abnimmt.
Der normale Weg: ein Agent hat ein Context Window, das stirbt zwischen Sessions, also persistierst du alles selbst. Task Board, Zwischenergebnisse, Tool-Call-Historie. Heißt Datenbank, Migrations, Infra die du für etwas das sich jede Woche ändert selbst pflegst.
Managed Agents drehen das um. Der Session State (Messages, Tool Calls, Results) liegt serverseitig bei Anthropic, ich halt nur eine Session-ID, und die Historie spielt sich über sessions.events.list() zurück. Kein Schema-Design, keine Backups, Audit Trail by default.
Ich bin da ehrlich gespalten. Einerseits geil, ein riesiger Berg Infra-Arbeit fällt einfach weg. Andererseits gibst du viel Kontrolle ab. Was wenn ich meine Memory komplett anders haben will, oder bessere Workflows da drin laufen lassen will? Und Anthropics Modelle sind nicht gerade billig, die laufenden Kosten sind ein echter Faktor. Für das was ich baue passt der Trade meistens, aber ich geh mit offenen Augen rein.
Memory + Dreaming: ein Filesystem und ein Kurator
Der Workshop zu dem ich immer wieder zurückkomme.
Ich hatte Karpathys LLM wiki im Kopf als ich reinging, im Grunde Obsidian für Agents. Ein Agent liest rohe Transcripts, zieht die wichtigen Punkte raus und schreibt sie als sauber verlinkte Markdown-Notizen. So wächst echtes Wissen mit der Zeit, statt dass bei jeder Anfrage alles neu aus RAG-Chunks zusammengesucht wird. Genau das hat Anthropic gezeigt, nur eben fertig gebaut, in zwei Teilen.
Teil eins: der Speicher ist ein Filesystem. Alles liegt in einem /memory-Directory das zwischen Sessions bleibt. Der Agent greppt nach dem Keyword das er braucht, findet die Datei, liest nur den Chunk. Selbe Form wie Claude Code in einem Repo. Context Window bleibt klein auch wenn der Store wächst.
Der zweite Teil ist der, der das Ganze für mich rund macht: Dreaming. Ein async Subagent der zwischen Sessions durch den Memory-Tree läuft und aufräumt. Führt Duplikate zusammen, schmeißt Veraltetes raus, baut das Layout um. Kein In-Place-Edit, er baut einen frischen Store den du beim nächsten Mal reinswappst. Das ist im Prinzip genau Karpathys Schritt von raw zu wiki, nur dass Anthropic ihn managed übernimmt statt dass er lokal auf deinem Obsidian läuft.
Ein Satz von Kevin ist mir geblieben: Memory ist nicht der Ort für Antworten, sondern für das was der Agent gelernt hat.
Agent Decomposition: der harte Teil ist das Interface
Klingt simpel: wenn dein Orchestrator zu viele Tools hat (so ab 15 bis 20) gruppierst du verwandte Tools in Subagents, und der Orchestrator ruft Subagents statt Tools. Soweit klar.
Williams eigentlicher Punkt:
Der harte Teil ist nicht den Split auszusuchen. Es ist das Interface zwischen den Layern zu definieren.
Wöchentliche Insights zu AI-Architektur. Kein Spam.
Sobald du Orchestrator plus Subagents hast, hast du ein Protokoll. Was geht rein, was kommt zurück, in welchem Format, was wenn ein Subagent halb fehlschlägt. Ist das schwammig, degradiert das ganze System und du findest den Fehler kaum, weil er über die Grenze verschmiert ist. Selbe Lektion wie Microservices in den 2010ern, nur für Agents.
Mein SEO-Agent hat gerade 13 Tools auf einem Orchestrator und läuft gut. Aber die Cluster seh ich schon (GSC, Paid-Audit, Content-Briefs, Webflow-Publishing). Der Split ist easy, der Contract dazwischen ist die Arbeit. Läuft heute sauber, also zieh ich das Pattern rein bevor ich's brauche, nicht erst wenn's bricht.
Das größere Muster: Hill Climbing auf dem Eval
Die Zeile die am härtesten saß:
Hill climb on the eval.
William Steuk (paraphrasiert)
Das war der Faden durch jeden Workshop. Deine Eval-Suite ist eine Landschaft, jede Änderung ein Schritt, das Eval gibt dir den Gradient. Ohne bist du nicht am engineeren, du vibest nur.
Das Ding das wirklich saß: LLMs können ihre eigenen Evals nicht schreiben. Anwenden ja (LLM-as-judge geht), aber die Rubric muss von einem Menschen mit Geschmack kommen. Und dann der Satz: manchmal guckst du dir was an, du weißt es ist schlecht, aber du kannst nicht sagen warum. Genau dieser Gap ist der ganze Job.
Das war meine Brücke. Evals hatte ich vorher schon in Teilen, aber nie den "ah, SO schreibt man eine gute" Moment. Der Job ist nicht der Grading-Code, das ist easy. Der Job ist das Warum in Worte zu fassen. Sobald du sagen kannst warum was schlecht ist, schreibt sich das Eval fast von allein.
Praktisch teilt sich das in zwei. Code Graders: deterministisch, gratis, laufen auf jedem PR (ist Output da, liegt der Word Count im Range, ist das Keyword im H1). Judge Graders: LLM-as-judge mit 0 bis 5 Scores (hookt das Intro, ist der Ton on brand). Beide in eine Scorecard, rot gelb grün, Deltas gegen eine Baseline, du guckst vor und nach jeder Änderung. Und batch die Judge-Calls, einer für alle Dimensionen statt einer pro Dimension.
Ich bin aus London raus mit dem Wissen dass das meine größte Lücke ist. Nicht "ich hab keine Evals", eher "ich wusste nie wie man gute schreibt". Jetzt schon, und es kommt dieses Quartal in den SEO-Agent.
Die Linse danach: The Bitter Lesson
Ein Speaker hat Rich Suttons The Bitter Lesson nur kurz erwähnt, so als "lies das mal". Hab ich auf dem Heimweg gemacht. Zwei Seiten von 2019.
Kurz: über 70 Jahre AI gewinnen die generellen Methoden die Compute hebeln gegen die cleveren handgebauten. Jedes Mal. Übertragen auf Harness Engineering war mein Takeaway nicht "hör auf den Harness Layer zu bauen", sondern: pass auf wie viel du engineerst, bau nichts über das das nächste Modell eh frisst.
Du siehst es ja: 2022 Prompt-Engineering-Magie, heute weg. 2023 handgebaute JSON-Parser, weg. 2024 fette RAG-Pipelines, schrumpfen. 2025 handgewartetes Memory und custom Orchestration, und genau das schrumpft jetzt mit Managed Agents und Memory + Dreaming.
Also die Frage: was bau ich tief, was ist Wegwerf? Tief: Evals, General-purpose Tools, Production Substrate (Sandboxes, Permissions, Audit Trails), Domain Knowledge, Geschmack. Wegwerf: das meiste Prompt Engineering, handgebaute Memory Schemes, custom Orchestration, schmale Tools wo ein General Tool reicht. Die Kurzform: encode deinen Geschmack als Evals, nicht als Rules. Rules werden gefressen wenn das Modell smarter wird, Evals bauen sich auf.
Was ich jetzt ändere
Drei Sachen für den nächsten Monat.
Echte Evals für den SEO-Agent. Klein anfangen, zehn bis zwanzig Inputs per Hand, definieren was gut heißt, vor und nach jeder Änderung laufen lassen. Aufhören auf Vibes zu optimieren.
Die 13 Tools auditen. Ist jedes Tool wirklich tragend, oder nur da weil die Modelle noch nicht zuverlässig genug sind? Zweiteres steht auf einer Uhr.
Den Decomposition-Contract designen bevor ich splitte. Das Protokoll zwischen den Subagents ist die eigentliche Arbeit. Läuft heute gut, also hab ich Zeit es richtig zu machen.
Wenn du auch in London warst oder an Agent Harnesses arbeitest, schreib mir wie du die Eval-Frage angehst.
Weiterführend
- The Bitter Lesson, Rich Sutton, 2019. Zwei Seiten. Lies sie heute Abend.
- Karpathys LLM wiki gist, das Pattern hinter Memory + Dreaming.
- Code w/ Claude, Recordings landen auf Anthropics YouTube.
- Mein LinkedIn-Recap.
