Die State-Location ist der Mechanismus, nicht das Agent-Label

Eine Lektüre des Ehrlichen Architekten von Stateful vs. Stateless Agent Design: Tradeoffs for Scalable Agentic Systems, veröffentlicht am 2026-07-24 von Iván Palomares Carrascosa auf MachineLearningMastery.com.

Die Oberflächenbehauptung des Artikels ist eine Taxonomie: stateless Agents versus stateful Agents, mit Codebeispielen für jede. Der Ehrliche Architekt liest sie für den Mechanismus unter der Taxonomie und findet sechs. Der lasttragende ist die State-Location: die eigene Rahmung des Artikels ist, dass „wo resides der Agent-Speicher?" die Frage ist, die „beantwortet werden muss, bevor ein Load Balancer konfiguriert wird". Das Agent-Label (stateless oder stateful) ist die Marketing-Schicht; die State-Location ist die Mechanismus-Schicht. Theorem 3 in Everythinks HAI Engine stellt dieselbe Form auf: eine Eigenschaft ist genau dann garantiert, wenn ihr Mechanismus implementiert und messend ist. Hier ist die Eigenschaft „skaliert horizontal zu jeder Instanz"; der Mechanismus ist „es existiert kein serverseitiger State."

Dieser Post extrahiert sechs Mechanismusformen aus dem MachineLearningMastery-Artikel, wendet Theorem 3 auf jede an und zieht domänenübergreifende Parallelen zur Everythink-Plattform. Jede Parallelität von unserer Plattform ist als ⚠️ markiert — Everythink operiert in ziviler und defensiver Vorhersage, der MachineLearningMastery-Artikel operiert in Entwicklerbildung und Agent-Architektur, sodass die Parallelität strukturell ist, nicht eine Behauptung, dass unsere Systeme denselben Markt bedienen. Die sechs Mechanismusformen selbst sind ✅ — sie sind aus der eigenen Evidenz des Artikels extrahierbar.

Mechanismus 1 — State-Losigkeit ist der horizontale-Skalierungs-Mechanismus

Der Artikel stellt fest, dass „auf stateless Agents basierende Architekturen mit bemerkenswerter ease horizontal skaliert werden können. Da kein Benutzergedächtnis auf einem Backend-Server gespeichert wird, können eingehende Anfragen an jede verfügbare Instanz weitergeleitet werden". Der Ehrliche Architekt liest dies als Mechanismusbehauptung: horizontale Skalierung zu jeder Instanz wird garantiert durch die Abwesenheit von serverseitigem State, nicht durch einen intelligenteren Load Balancer. Der Mechanismus, der „jede Instanz kann jede Anfrage bedienen" produziert, ist „keine Instanz hält State, den eine andere Instanz nicht hat". Wenn der State null ist, ist das Routing trivial; wenn der State nicht-null ist, muss das Routing ihn respektieren. ✅ Produktion — der Artikel nennt den Mechanismus (kein Benutzergedächtnis auf dem Backend) und die Eigenschaft (jede Instanz kann bedienen).

Der Artikel ist ehrlich, dass dies ein Tradeoff ist, kein Sieg. Dieselbe Abwesenheit von serverseitigem State, die horizontale Skalierung einfach macht, macht auch Multi-Turn-Kontinuität schwierig, was der nächste Mechanismus ist. State-Losigkeit kauft Skalierung; sie kostet Kontinuität.

Die domänenübergreifende Parallelität zu Everythinks HAI Engine ist nur strukturell. Der HAI Engine läuft Sisters, die SisterOutput zurückgeben und selbst nie auf Postgres schreiben — der Loom persistiert. Die Sisters sind stateless Compute-Worker; der Loom ist die stateful Persistenz-Schicht. Der „stateless Agent skaliert horizontal, weil kein serverseitiger State" des MachineLearningMastery-Artikels und Everythinks „stateless Sisters skalieren, weil sie Output zurückgeben und nicht persistieren" teilen dieselbe Form: der Compute-Knoten ist stateless, die Persistenz ist woanders. ⚠️ Teilweise — die Parallelität ist strukturell; Everythinks stateless Sisters dienen ziviler und defensiver Vorhersage, der MachineLearningMastery stateless Agent dient Entwicklerbildung. Unterschiedliche Domänen, dieselbe Form: der Compute-Knoten trägt keinen State, also kann er frei ersetzt oder repliziert werden.

Mechanismus 2 — Vom Client gelieferte Historie ist der stateless-Kontinuitäts-Mechanismus

Der Artikel stellt fest, dass in einem stateless Design „das Frontend die gesamte Konversationshistorie mit jeder neuen Anfrage neu senden muss. Infolgedessen wächst das Kontextfenster mit einem Schneeball-Effekt und treibt schnell die Token-Nutzung hoch". Der Ehrliche Architekt liest dies als Kontinuitätsbehauptung: Multi-Turn-Kontinuität in einem stateless Design wird garantiert durch den Client, der die Historie trägt, nicht durch den Agent, der sie erinnert. Der Mechanismus, der Kontinuität produziert, ist die vom Client gelieferte Payload, nicht das Gedächtnis des Agents. Die Kosten werden ehrlich benannt: die Payload wächst wie ein Schneeball, und die Token-Nutzung wächst mit ihr. ✅ Produktion — der Artikel nennt den Mechanismus (Client sendet Historie neu) und die Kosten (Schneeball-Kontextfenster).

Der Artikel ist ehrlich, dass diese Kosten eine Decke sind, keine Belästigung. Ein stateless Agent, der beliebig lange Konversationen verarbeitet, muss beliebig lange Payloads empfangen, also wachsen die Token-Kosten mit der Konversationslänge. Dies ist ein Mechanismus mit einer benannten Decke, kein gratis Mittagessen: es funktioniert, bis die Payload das Kontextfenster oder das Budget übersteigt, und dann funktioniert es nicht mehr.

Die domänenübergreifende Parallelität zu Everythinks Eye Key ist nur strukturell. Der Eye Key ist die eigene Credential des Benutzers — der HMAC und der Fingerabdruck werden aufgezeichnet, der Klartext berührt nie die Festplatte, und der Schlüssel ist die Rate-Limit-Grenze des Benutzers. Der „der Client trägt die Historie, der Server trägt keine" des MachineLearningMastery-Artikels und Everythinks „der Benutzer trägt den Schlüssel, der Server speichert nur den HMAC" teilen dieselbe Form: das Souveränität-tragende Artefakt lebt beim Client, der Server speichert nur einen Verifizierer. ⚠️ Teilweise — die Parallelität ist strukturell; Eye Key regiert API-Souveränität für zivile und defensive Vorhersage, die MachineLearningMastery Client-Historie regiert Multi-Turn-Kontinuität für Entwicklerbildung. Unterschiedliche Domänen, dieselbe Form: der Client trägt das lasttragende Artefakt, der Server trägt ein Derivat.

Mechanismus 3 — Die serverseitige Datenbank ist der stateful-Kontinuitäts-Mechanismus

Der Artikel stellt fest, dass in einem stateful Design „der Agent die Gedächtnislast selbst übernimmt. Der Client muss unterdessen nur den neuesten Benutzer-Prompt zusammen mit einem eindeutigen Identifikator senden. Der Agent ruft dann die Sitzungshistorie oder den Kontext aus einer Datenbank ab und hängt die neue Nachricht an". Der Ehrliche Architekt liest dies als Kontinuitätsbehauptung: Multi-Turn-Kontinuität in einem stateful Design wird garantiert durch eine serverseitige Datenbank, die nach Sitzungs-Identifikator geschlüsselt ist, nicht durch den Client, der die Historie neu sendet. Der Mechanismus, der Kontinuität produziert, ist der Datenbank-Lookup, nicht die Payload-Größe. Die Client-Payload bleibt klein; der Server speichert die wachsende Historie. ✅ Produktion — der Artikel nennt den Mechanismus (Datenbank geschlüsselt nach Sitzungs-Identifikator) und die Eigenschaft (Kontinuität bei kleiner Client-Payload).

Der Artikel ist ehrlich, dass dies die Kosten verschiebt, nicht eliminiert. Das stateful Design tauscht Payload-Kosten gegen Datenbank-Kosten: „ diese Lösung zu skalieren wird viel schwieriger, beginnend mit der Notwendigkeit einer persistenten Datenbank-Schicht in der Architektur". Statefulness kauft kleine Payloads und serverseitiges Trimmen; sie kostet eine Datenbank-Schicht und schwierigeres Skalieren.

Die domänenübergreifende Parallelität zu Everythinks Loom-Persistenz ist nur strukturell. Der Loom persistiert Simulationen und Foresight durch seinen slice-eigenen LoomStore-Port, und die Sisters geben SisterOutput zurück ohne zu persistieren — der Loom ist die stateful Schicht, die Sisters sind die stateless Worker. Der „der Agent ruft die Historie aus einer Datenbank ab und hängt die neue Nachricht an" des MachineLearningMastery-Artikels und Everythinks „der Loom ruft vorherigen State ab, fächert zu den Sisters auf, persistiert das fusionierte Ergebnis" teilen dieselbe Form: der Orchestrator besitzt den State, die Worker besitzen die Berechnung. ⚠️ Teilweise — die Parallelität ist strukturell; der Loom dient ziviler und defensiver Vorhersage, der MachineLearningMastery stateful Agent dient Entwicklerbildung. Unterschiedliche Domänen, dieselbe Form: die Persistenz-Schicht ist der Kontinuitätsträger, die Compute-Schicht ist der stateless Produzent.

Mechanismus 4 — Der Sitzungs-Identifikator ist der Routing-Schlüssel

Der Artikel stellt fest, dass „der Sitzungs-Identifikator verwendet wird, um die relevanten Informationen aus vergangenen Interaktionen in der aktuellen Konversation abzufragen". Der Ehrliche Architekt liest dies als Routing-Behauptung: stateful-Gedächtnis-Abfrage wird garantiert durch den Sitzungs-Identifikator als Routing-Schlüssel, nicht durch das Erinnern des Agents. Der Mechanismus, der die Historie abfragbar macht, ist der session_id-Schlüssel, nicht das interne Gedächtnis des Agents. Ohne den Schlüssel ist die Datenbank ein unindexierter Haufen; mit dem Schlüssel ist die Datenbank eine abfragbare Historie. ✅ Produktion — der Artikel nennt den Mechanismus (Sitzungs-Identifikator als Abfrage-Schlüssel) und die Eigenschaft (abfragbare Historie).

Der Artikel ist ehrlich, dass der Sitzungs-Identifikator ein Routing-Anliegen ist, kein Gedächtnis-Anliegen. Ein stateful Agent, der den Sitzungs-Identifikator verliert, verliert die Historie, selbst wenn die Historie noch in der Datenbank ist. Das stateful Design hängt davon ab, dass der Routing-Schlüssel vorhanden und konsistent ist, nicht dass die Datenbank existiert.

Die domänenübergreifende Parallelität zu Everythinks „the space is the router" ist nur strukturell. Everythinks Topologie ist Netzwerk → Community → Raum: eine Anfrage wird an einen Raum geroutet, bevor etwas antwortet, und der Raum-Schlüssel ist der Routing-Schlüssel, der den richtigen State abfragbar macht. Der „der Sitzungs-Identifikator routet die Anfrage an die richtige Historie" des MachineLearningMastery-Artikels und Everythinks „die Topologie routet die Anfrage an den richtigen Raum" teilen dieselbe Form: der Routing-Schlüssel precedes die Antwort, und der Routing-Schlüssel entscheidet, welcher State abfragbar ist. Everythinks World Monitor verkörpert dieselbe Form in planetarischem Maßstab: Geo-Signale werden nach Geohash-Präfix geroutet, Clients lesen den Cache nicht die Upstreams, sodass der Routing-Schlüssel (der Geohash) entscheidet, welcher Tile-State abfragbar ist, bevor irgendeine Viewport-Antwort kommt. ⚠️ Teilweise — die Parallelität ist strukturell; Everythinks Router ist eine Topologie öffentlicher Räume und Geohash-Tiles, der MachineLearningMastery-Router ist ein Sitzungs-Identifikator. Unterschiedliche Domänen, dieselbe Form: der Routing-Schlüssel ist der Abfragbarkeits-Träger, und die Routing-Entscheidung precedes die Antwort.

Mechanismus 5 — Lokalisierte Amnesie ist das stateful-Skalierungs-Fehlerszenario

Der Artikel stellt fest, dass „in Infrastrukturen, die horizontal skalieren, Strategien wie zentralisiertes Memory-Caching mit Redis möglicherweise ebenfalls notwendig werden, um ‚lokalisierte Amnesie' zu vermeiden, bei der die Historie einer Sitzung auf der einzigen Instanz gestrandet ist, die die früheren Turns bedient hat". Der Ehrliche Architekt liest dies als Fehlerszenario-Behauptung: der stateful-Skalierungs-Fehler wird garantiert durch instanz-lokalen State in einer horizontal skalierten Flotte, nicht durch eine langsame Datenbank. Der Mechanismus, der lokalisierte Amnesie produziert, ist „der State lebt auf der Instanz, die ihn geschrieben hat, und der Load Balancer routet nicht nach session_id". Die Korrektur wird ehrlich benannt: zentralisiertes Memory-Caching mit Redis, sodass der State über Instanzen geteilt wird. ✅ Produktion — der Artikel nennt das Fehlerszenario (lokalisierte Amnesie), den Mechanismus (instanz-lokaler State in einer skalierten Flotte) und die Korrektur (zentralisiertes Caching).

Der Artikel ist ehrlich, dass dies ein spezifisches Fehlerszenario mit einem spezifischen Mechanismus ist, kein vages „Skalieren ist schwer". Lokalisierte Amnesie passiert, wenn der State instanz-lokal ist und das Routing state-blind ist; sie passiert nicht, wenn der State geteilt ist oder das Routing sitzungsbewusst ist. Der Fehler hat einen Mechanismus, und der Mechanismus hat eine Korrektur.

Die domänenübergreifende Parallelität zu Everythinks hexagonalen trait-basierten Ports ist nur strukturell. Everythinks AppState-Repositories sind Arc, sodass Tests Mocks tauschen, und Persistenz wird durch einen Port erreicht, nie einen konkreten PgPool — der State ist hinter einem geteilten Trait, nicht auf einer konkreten Instanz gestrandet. Der „zentralisiertes Caching, sodass der State über Instanzen geteilt wird" des MachineLearningMastery-Artikels und Everythinks „geteilter Trait, sodass der State durch jeden Adapter erreichbar ist" teilen dieselbe Form: der State wird durch eine Abstraktion geteilt, nicht auf einem konkreten Träger gestrandet. ⚠️ Teilweise — die Parallelität ist strukturell; Everythinks geteilter Trait dient ziviler und defensiver Vorhersage, der MachineLearningMastery zentralisierte Cache dient Entwicklerbildung. Unterschiedliche Domänen, dieselbe Form: der State wird geteilt, sodass keine Instanz der alleinige Träger ist.

Mechanismus 6 — Workflow-Match ist der Auswahl-Mechanismus

Der Artikel stellt fest, dass „die Wahl zwischen einem stateful und einem stateless Architekturdesign darauf hinausläuft, die Infrastruktur richtig auf den Workflow abzustimmen", und gibt die Kriterien: stateless für „einfache Pipelines, die auf sehr spezifische Aufgaben ausgerichtet sind, wie Textextraktion, Zusammenfassung oder Single-Turn-Klassifikations-Chatbots"; stateful für „langlaufende Assistenten, Code-Assistenten oder Multi-Turn-Bots in Anwendungen wie Kundenservice". Der Ehrliche Architekt liest dies als Auswahlbehauptung: das richtige State-Modell wird garantiert, indem die State-Location auf die Kontinuitätsnachfrage des Workflows abgestimmt wird, nicht indem das anspruchsvollere Design gewählt wird. Der Mechanismus, der die richtige Wahl produziert, ist der Workflow-Match, nicht die Technologie-Präferenz. ✅ Produktion — der Artikel nennt den Mechanismus (Infrastruktur auf Workflow abstimmen) und die Kriterien (Single-Turn vs Multi-Turn).

Der Artikel ist ehrlich, dass kein Design universell überlegen ist. Ein stateless Agent, der in einen Multi-Turn-Workflow gezwungen wird, schneeballt Payloads; ein stateful Agent, der in einen Single-Turn-Workflow gezwungen wird, zahlt Datenbank-Kosten, die er nicht braucht. Es gibt keinen globalen Gewinner: der richtige Mechanismus hängt vom Workflow ab, und der Workflow ist das Auswahlkriterium.

Die domänenübergreifende Parallelität zu Everythinks hexagonalen trait-basierten Ports ist nur strukturell. Everythinks Architektur ist ein Satz von Ports, wo jeder Port eine andere Frage beantwortet, und die Use-Case-Crates hängen vom Trait ab, nie vom konkreten Adapter — der richtige Port wird durch die Frage ausgewählt, nicht durch die Implementierungs-Präferenz. Der „stimme das State-Modell auf den Workflow ab" des MachineLearningMastery-Artikels und Everythinks „stimme den Port auf die Frage ab" teilen dieselbe Form: die Auswahl ist durch die Nachfrage, nicht durch das Angebot. ⚠️ Teilweise — die Parallelität ist strukturell; Everythinks Port-Auswahl dient ziviler und defensiver Vorhersage, die MachineLearningMastery State-Modell-Auswahl dient Entwicklerbildung. Unterschiedliche Domänen, dieselbe Form: der Auswahl-Mechanismus ist der Nachfrage-Match, nicht die Angebot-Präferenz.

Was dies für Bereich und Grenzen bedeutet

Der MachineLearningMastery-Artikel handelt von Entwicklerbildung und Agent-Architektur. Everythinks Plattform handelt von ziviler und defensiver Vorhersage. Die domänenübergreifenden Parallelen in diesem Post sind strukturell — sie teilen Mechanismusformen, nicht Märkte. Der Ehrliche Architekt markiert die Parallelen aus diesem Grund ⚠️.

Everythinks eigener Go-to-Market für kommerzielle Agent-Tools ist 🔵 Roadmap — die Plattform ist Pre-Revenue, und jede kommerzielle Anwendung der hier gezogenen Parallelen unterliegt jenem Roadmap-Zustand und der Howey-Prüfung, bevor sie angeboten werden könnte. Die architektonischen Parallelen gelten unabhängig; die kommerziellen Behauptungen nicht.

Was der Artikel nicht behauptet, verdient ebenfalls eine Markierung. Er behauptet nicht, dass stateless überlegen ist — er nennt die Schneeball-Payload-Kosten. Er behauptet nicht, dass stateful überlegen ist — er nennt die Datenbank-Schicht-Kosten und das lokalisierte-Amnesie-Versagen. Er behauptet nicht, dass der Tradeoff lösbar ist — er nennt das Match-Kriterium. Diese Bereichsgrenzen sind die Ehrlichkeit des Artikels, und dieser Post bewahrt sie.

Wesentliche Erkenntnisse

• Horizontale Skalierung zu jeder Instanz wird garantiert durch die Abwesenheit von serverseitigem State, nicht durch einen intelligenteren Load Balancer. Die State-Location ist der Skalierungs-Mechanismus. ✅ Produktion.
• Multi-Turn-Kontinuität in einem stateless Design wird garantiert durch den Client, der die Historie trägt, mit Schneeball-Payload-Kosten. Die Client-Payload ist der Kontinuitätsträger. ✅ Produktion.
• Multi-Turn-Kontinuität in einem stateful Design wird garantiert durch eine serverseitige Datenbank, die nach Sitzungs-Identifikator geschlüsselt ist, mit Datenbank-Schicht-Kosten. Die Datenbank ist der Kontinuitätsträger. ✅ Produktion.
• Stateful-Gedächtnis-Abfrage wird garantiert durch den Sitzungs-Identifikator als Routing-Schlüssel. Der Routing-Schlüssel ist der Abfragebarkeits-Träger. ✅ Produktion.
• Der stateful-Skalierungs-Fehler wird garantiert durch instanz-lokalen State in einer horizontal skalierten Flotte; die Korrektur ist geteilter State oder sitzungsbewusstes Routing. Der Fehler hat einen Mechanismus, und der Mechanismus hat eine Korrektur. ✅ Produktion.
• Das richtige State-Modell wird garantiert, indem die State-Location auf die Kontinuitätsnachfrage des Workflows abgestimmt wird. Der Workflow ist der Auswahl-Mechanismus. ✅ Produktion.
• Domänenübergreifende Parallelen zu Everythinks HAI Engine (stateless Sisters, stateful Loom), „the space is the router" (Routing-Schlüssel precedes Antwort), World Monitor (Cache als stateful Schicht, Poller als stateless Feeder), Eye Key (Client trägt das lasttragende Artefakt) und hexagonalen Ports (geteilter Trait, Auswahl durch Nachfrage-Match) sind nur strukturell — unterschiedliche Märkte, dieselben Mechanismusformen. ⚠️ Teilweise.
• Everythinks Go-to-Market für kommerzielle Agent-Tools ist 🔵 Roadmap — Pre-Revenue, Howey-Prüfung unterworfen; die architektonischen Parallelen gelten, die kommerziellen Behauptungen nicht.

Sources

• Iván Palomares Carrascosa, Stateful vs. Stateless Agent Design: Tradeoffs for Scalable Agentic Systems, MachineLearningMastery.com, veröffentlicht am 2026-07-24. https://machinelearningmastery.com/stateful-vs-stateless-agent-design-tradeoffs-for-scalable-agentic-systems (abgerufen am 2026-08-23).
• Everythink-Plattformarchitektur: HAI Engine seit 2016 in Produktion; Theorem 3 (eine Eigenschaft ist genau dann garantiert, wenn ihr Mechanismus implementiert und messend ist); Topologie „the space is the router" (Netzwerk → Community → Raum); World Monitor (Geo-Signale geroutet nach Geohash-Präfix, Clients lesen den Cache nicht Upstreams); Oracle-Ensemble-Normalisierung mit Entropie in Nats auf jeden Merge gestempelt; typisierte Sisters (Analyst, Contrarian, Disruptor, Historian, Institutionalist) geben SisterOutput zurück ohne zu persistieren, Loom als stateful Persistenz-Schicht; hexagonale trait-basierte Ports mit austauschbaren Adaptern; Eye-Key-Souveränität (HMAC und Fingerabdruck aufgezeichnet, Klartext berührt nie die Festplatte, Schlüssel des Benutzers ist die Rate-Limit-Grenze).