Vor ein paar Monaten habe ich über [meinen Agentenstack](/posts/what-my-agentic-stack-actually-does) geschrieben: ein privates Monorepo, in dem KI-Agenten meine E-Mails, Zahlungen und Bereitstellungen verwalten, mit [Neotoma](https://neotoma.io) als strukturiertem Speicher darunter. Dieser Beitrag endete mit einem Versprechen. Ich sagte, ich sei die Strategieebene und die Architektur sei so konzipiert, dass diese Rolle durch Software ersetzbar sei. Dies ist der Beitrag darüber. [Ateles](https://github.com/markmhendrickson/ateles) ist nach Neotoma mein zweites Produkt und baut direkt darauf auf. Es handelt sich um einen persönlichen Agentenschwarm. Während der alte Stack aus einem Agenten pro Sitzung bestand und ich für jede Aufgabe auf dem Laufenden war, ist Ateles eine ständige Flotte von Agenten, die nach Rollen definiert, über Neotoma koordiniert und täglich unter launchd ausgeführt werden. Es ist der Unterschied, ob ich jeden Agenten leite oder ein Team leite, das seine Aufgaben bereits kennt. In diesem Beitrag wird erklärt, warum ich es gebaut habe, wie es funktioniert und wohin es führt. ## Warum der Stapel nicht mehr skaliert Der Auslöser war die Lautstärke. Nach der [Entwicklerversion](/posts/neotoma-developer-release) von Neotoma Ende Februar teilte sich meine Aufmerksamkeit auf drei Modi, die nicht viel gemeinsam haben: die Entwicklung des Produkts, die Vermarktung und die Verwaltung der Beziehungen zu frühen Benutzern. Außerdem versorgte ich Neotoma immer mehr mit Kontext über mein berufliches und persönliches Leben, und je besser die Erinnerung wurde, desto mehr konnte jeder einzelne Agent damit anfangen. Dadurch wurde die Einschränkung nicht entfernt, sondern verschoben. Das Limit war nicht mehr das, was die Agenten wussten. Ich war der Einzige, der das, was er wusste, Sitzung für Sitzung in die Tat umsetzte. Der alte Ansatz bestand aus einer Reihe repospezifischer Regeln und Fähigkeiten. Sie haben es mir ermöglicht, mich beim Verfahren nicht zu wiederholen. Ein Skill definierte die Schritte für die E-Mail-Triage oder die Bereitstellung einer Website und konnte in jeder Sitzung mit dem bereits in Neotoma vorhandenen Kontext ausgeführt werden. Das funktionierte, bis die Sitzungen voll waren. Der Fehler war konkret. Wenn ein generischer Agent alle Regeln und Rollen gleichzeitig übernimmt, übernimmt er nicht alle gleichmäßig. In jeder Kurve neigt es sich zu einer Art von Arbeit und lässt den Rest gleiten. Es verfasst die E-Mail gut und vergisst die ständige Regel, wie ich mich abmelde. Es behebt den Fehler und überspringt den Regressionstest. Es gab auch keine kontradiktorische Prüfung. Ein Agent plante, führte aus und überprüfte seine eigene Arbeit, ohne dass ihm etwas aufgefallen wäre, als er sicher falsch lag. Zwei weitere Dinge gingen in die gleiche Richtung. Ich habe meine Produktoperationen standardmäßig auf GitHub verlagert und dabei Issues und Pull Requests verwendet, anstatt sie direkt auf Main zu übertragen. Dies wurde teilweise durch die [von mir erstellte Issue-Pipeline](/posts/agent-to-agent-issue-resolution-with-humans-at-the-edges) erzwungen, die damit begann, echte Berichte von Benutzern und ihren Agenten an Neotoma und an GitHub weiterzuleiten. Und ich wollte, dass mein Entwicklungsprozess öffentlich lesbar ist, damit die Leute, die Neotoma verwenden, genau sehen können, was an Arbeit vor sich geht. Beide benötigen eine Reihe spezialisierter Agenten für Design, Produktmanagement, Qualitätssicherung und Freigabe. Ein Agent, der alles erledigt, macht den Punkt zunichte. Ateles ist also die Entscheidung, eine Flotte aufzubauen und diese Flotte in Neotoma selbst zu definieren. ## Neotoma als Stoff, nicht nur als Erinnerung Der Unterschied zwischen Ateles und Neotoma besteht darin, dass er zwei Dinge gleichzeitig in der Hand hat. Es enthält den operativen Kontext, den der Schwarm benötigt, die gleichen Fakten, die mein alter Stack gelesen und geschrieben hat. Und es hält den Schwarm selbst. Agenten sind Neotoma-Einheiten. Bei jeder davon handelt es sich um eine „agent_definition“ mit einer Eingabeaufforderung, einer Tool-Zulassungsliste und einer Reihe von Funktionsgewährungen. Das Aktualisieren des Verhaltens eines Agenten ist ein „correct()“-Aufruf für diese Entität mit vollständigem Versionsverlauf und Autorenangabe. Kein Commit, kein erneutes Bereitstellen. Die SKILL.md-Dateien auf der Festplatte sind generierte Spiegel dieser Entitäten, nicht der Quelle. Auch ihre Beziehungen sind Neotoma-Einheiten. Der Schwarm hat eine Hierarchie, ausgedrückt als Baum, sodass ein Koordinator weiß, welche Agenten er entsendet, und eine Aufgabe weiß, welcher Agent sie besitzt. Und die Arbeit selbst besteht aus Neotoma-Entitäten: Aufgaben, Pläne, Workflow-Definitionen, Teilnahmeaufzeichnungen. Ein Agent übernimmt eine Aufgabe, führt sie aus und schreibt das Ergebnis als Beobachtung zurück, die seiner Identität zugeordnet wird. Das Ergebnis ist ein Weltdiagramm für alles. Die Fakten, auf die der Schwarm einwirkt, die Definition des Schwarms, der auf sie einwirkt, und die Aufzeichnung dessen, was er getan hat, befinden sich alle im selben Nur-Anhänge-Speicher. Das gibt dem Ganzen drei Eigenschaften, die mir am Herzen liegen. Es ist transparent, da jede Aktion eine zugeschriebene Beobachtung ist, die Sie rücklesen können. Es ist überprüfbar, da Sie die Aktionen jedes Agenten in jedem Fenster wiedergeben können. Und es ist umkehrbar, weil nichts die bestehende Wahrheit überschreibt. Wenn ein Agent einen fehlerhaften Anruf tätigt, kann ich das Ereignis zurückverfolgen, das ihn verursacht hat, den Status wiederherstellen und die Regel, die dazu geführt hat, einmal korrigieren. Identität ist das Stück, das die Zuschreibung real und nicht erstrebenswert macht. Jeder Agent verfügt über ein [AAuth](/posts/know-which-of-your-agents-wrote-what) Schlüsselpaar und signiert jeden Toolaufruf. Der Harness überprüft die Signatur vor dem Handeln und zeichnet auf, wer behauptet hat, neben dem, der tatsächlich gehandelt hat, auf GitHub zu handeln. Ein Code-Schreibagent fungiert nicht mehr nur als ich. Es verhält sich wie es selbst, und das Protokoll sagt es auch. ## Die Agenten, nach Rolle Der Schwarm ist in Schichten organisiert. T1 ist der Host: der Prozess, der einen Kanal besitzt und die Agenten erzeugt, derzeit OpenClaw für diejenigen, mit denen ich spreche, und launchd für die Hintergrundagenten. Es handelt sich um eine Infrastruktur, nicht um einen Agenten mit einer Rolle. Die Agenten selbst laufen darüber hinaus in drei Ebenen. T2-Agenten sind immer erreichbar und haben eine Persönlichkeit: Ateles selbst ist derjenige, mit dem ich spreche, und es ist der einzige Agent, der mich anpiept. T3-Daemons sind ereignisgesteuerte Hintergrundprozesse ohne Persona, die jeweils Neotoma-Ereignisse oder einen externen Webhook abonniert haben. T4-Agenten sind zustandslos, werden pro Aufgabe erzeugt und verfügen über eine stabile Identität und ein stabiles Gedächtnis, das sie durch Abfragen von Neotoma erhalten. Einige der Rollen, die heute laufen: **Produkt.** Ein Koordinator-Daemon liest Workflow-Definitionen von Neotoma und sendet Gates in der Reihenfolge: Design, Produktmanagement, Qualitätssicherung, Freigabe. Die Codearbeit geht an einen Issue-Worker, der Pull-Requests über Repos hinweg öffnet. Jeder Pull-Request erhält eine grundlegende Überprüfung durch einen separaten Reviewer-Agenten, wobei Domain-Spezialisten die ihnen gehörenden Pfade einbinden. Der Sinn dieser Aufteilung liegt in der gegnerischen Kontrolle, die der einzelne Agent nie hatte. Derjenige, der den Code schreibt, ist nicht derjenige, der ihn löscht. **Finanzen.** Ein Daemon für wiederkehrende Zahlungen führt Wise- und Bitcoin-Überweisungen aus, die durch Kalenderereignisse und Fälligkeitstermine von Aufgaben ausgelöst werden, wobei jeder Empfänger und Betrag aus Zahlungsprofilentitäten und nicht aus Code geladen wird. Das Hinzufügen einer neuen wiederkehrenden Zahlung ist eine neue Entität und kein Commit. Für die Budgetierung und den Abgleich sind eine Finanzberaterrolle und eine Steuer- und Einreichungsrolle definiert. **Recht und Compliance.** Eine juristische Rolle umfasst die Risikobewertung und die Überprüfung der Bedingungen. Eine Compliance-Rolle umfasst Datenschutz und Datenverwaltung. Diese sind umso wichtiger, je mehr ein Schwarm auf die Daten von Menschen reagieren kann, was bei mir der Fall ist. **Strategie.** Dies ist die Rolle, die ich im letzten Beitrag als meine beschrieben habe, und es ist die, die ich ganz bewusst abgebe. Diese Übergabe ist die konkrete Version eines Arguments, das ich in „The Human Inversion“ (/posts/series/the-human-inversion) vorgebracht habe: Während Agenten die Ausführungsmitte übernehmen, verlagert sich der Hebel des Menschen zu den Enden, es kommen schärfere Maßstäbe zum Einsatz und ein dichteres Urteilsvermögen kommt zum Vorschein. Die Autonomie wird pro Plan kalibriert, nicht global. Eine Ausführungsrichtlinieneinheit legt für einen bestimmten Plan fest, was ein Agent selbst tun darf, welche Qualitätskriterien er erfüllen muss und wo er anhalten und sich mit mir absprechen muss, bevor er fortfährt. Die Eskalationskette reicht für mich vom handelnden Agenten über einen Domänenexperten bis hin zum Verfassungshüter, und jeder Beschluss wird als Einheit zurückgeschrieben, sodass die nächste Instanz das Urteil erbt. Dahinter sitzen die Aufnahme- und Support-Daemons, die den Graphen mit Daten versorgen: E-Mail-Triage, Audioimport, Kalendervorbereitung, Gesundheit und Fitness, Issue-Triage. Bei jedem handelt es sich um einen kleinen Prozess, der ein eingehendes Signal in Neotoma-Entitäten umwandelt, auf die der Rest des Schwarms reagieren kann. ## Der Aufgabenrücken Was die Flotte zusammenhält, ist das Aufgabenmanagement, und es ist absichtlich langweilig. Eine Aufgabe ist eine Entität. Es hat einen Eigentümer, einen Status, eine Priorität und eine Aufzeichnung darüber, für wen es ausgeführt wurde. Plant Gruppenaufgaben und trägt eigene Entscheidungen und nächste Schritte. Workflow-Definitionen deklarieren die Phasen und Gates, die eine Arbeit durchläuft. Da sich all dies im selben Speicher befindet wie alles andere, koordiniert der Schwarm ohne eine separate Orchestrierungsdatenbank. Ein Daemon abonniert Aufgabenereignisse über den Ereignisstrom von Neotoma. Wenn eine Aufgabe erscheint, wird sie nach Domäne an den richtigen Agenten weitergeleitet, hinter einem Tor, das das Vertrauen des Agenten gegen den Schaden abwägt, den eine falsche Aktion anrichten könnte. Niedriger Explosionsradius und hohes Vertrauen funktionieren von alleine. Ein hoher Explosionsradius wartet auf mich. Dies ist das Rückgrat, um das herum ich den Rest der Erfahrung aufbaue. ## Wohin das führt Die von mir gewünschte Schnittstelle ist einfach anzugeben. Ich gebe dem Schwarm einen Input, über das nächstgelegene Transportmittel, und der Schwarm nimmt ihn auf und handelt. Eine Eingabeaufforderung in einem Terminal. Eine E-Mail. Eine Telegram-Nachricht. Eine während eines Spaziergangs aufgenommene Audio-Memo, mit der die Notizen zu diesem Beitrag begannen. Alles sollte im selben Diagramm landen, und der Schwarm sollte die damit verbundene Arbeit proaktiv angehen, ohne dass ich dabei die Hand eines Agenten halten muss. Zwei Eigenschaften machen das möglich. Der Schwarm muss sich selbst entwickeln. Wenn es neue Kontexte und neue Arten von Arbeit annimmt, sollte es die Fähigkeiten bereitstellen und die Fähigkeiten erweitern, die es benötigt, und sich an meine Korrekturen anpassen, anstatt darauf zu warten, dass ich es manuell neu konfiguriere. Und mein Beitrag, der immer noch in den Momenten erforderlich ist, in denen wirklich eine Beurteilung erforderlich ist, sollte niemals zweimal gegeben werden müssen. Wenn ich eine Vorgehensweise einmal korrigiere, wird sie zu einer Einheit und die Korrektur bleibt bestehen. Bei der näheren Roadmap geht es um Reichweite. Ateles wurde für meinen eigenen Gebrauch gebaut, sodass ein Großteil davon immer noch von einem einzigen Bediener, nämlich mir, abhängt. Ich [treibe es dahingehend voran, dass es installierbar und für mehrere Betreiber geeignet ist](https://github.com/markmhendrickson/ateles/blob/main/docs/multi_tenant.md): ein Schwarm, den jemand anderes aufspalten, auf sein eigenes Neotoma zeigen, seine eigenen Kontextentitäten bereitstellen und ausführen kann. Da die Agenten aufgrund ihrer Richtlinien betreiberunabhängig sind und nichts Betreiberspezifisches in den Code integriert ist, ist der Fork-Fall hauptsächlich eine Frage des Kontexts und nicht des Umschreibens. Die wirklich neue Arbeit besteht darin, mehr als einen Menschen in einem einzelnen Mieter zu unterstützen, weshalb die Mietergrenze bereits jetzt geplant und nicht später nachgerüstet wird. Neotoma hat Agenten geschaffen, die sich erinnern, und Ateles ist das, was diese Erinnerung ermöglicht hat: ein Schwarm, der darauf reagieren kann, ohne dass ich bei jedem Schritt dabei bin. Die beiden erheben sich gemeinsam. Ein besseres Gedächtnis ist kein fertiges Problem, an dem ich vorbeigekommen bin. Es ist das Substrat, auf dem der gesamte Schwarm steht, und jeder Gewinn an dem, was Neotoma halten und auflösen kann, ist ein Gewinn an dem, was der Schwarm leisten kann. Das Gedächtnis verbessert sich immer weiter und der Schwarm verbessert sich damit immer weiter.