状態の所在がメカニズムであり、エージェントのラベルではない

誠実な建築家による Stateful vs. Stateless Agent Design: Tradeoffs for Scalable Agentic Systems の読解、2026-07-24 に Iván Palomares Carrascosa が MachineLearningMastery.com で公開。

記事の表面の主張は分類である:ステートレス・エージェント vs ステートフル・エージェント、それぞれにコード例が付く。誠実な建築家は分類の下にあるメカニズムを読み取り、6つを見つける。荷重を担うのは状態の所在である:記事の自身の枠組みは「エージェントのメモリはどこに所在するか?」が「任意のロードバランサーが設定される前に回答されなければならない」問いであるというものだ。エージェントのラベル(ステートレスかステートフルか)はマーケティング層である;状態の所在はメカニズム層である。Everythink の HAI Engine における Theorem 3 は同じ形式を主張する:プロパティはそのメカニズムが実装され測定している時に正確に保証される。ここでプロパティは「任意のインスタンスへ水平スケールする」;メカニズムは「サーバー側に状態が存在しない。」である。

本投稿は MachineLearningMastery 記事から6つのメカニズム形式を抽出し、それぞれに Theorem 3 を適用し、Everythink プラットフォームへの領域横断類推を描く。我々のプラットフォームからの各類推は ⚠️ とマークされる — Everythink は民事・防衛的予測で運営され、MachineLearningMastery 記事は開発者教育とエージェントアーキテクチャで運営されるため、類推は構造的であり、我々のシステムが同じ市場に奉仕するという主張ではない。6つのメカニズム形式それ自体は ✅ である — それらは記事自身の証拠から抽出可能である。

メカニズム 1 —— 状態なさが水平スケーリング・メカニズム

記事は「ステートレス・エージェントに基づくアーキテクチャは顕著な ease で水平にスケールできる。ユーザーメモリがバックエンドサーバーに保存されないため、受信リクエストは利用可能な任意のインスタンスに転送できる」と述べる。誠実な建築家はこれをメカニズム主張として読む:任意のインスタンスへの水平スケーリングはサーバー側状態の不在によって保証され、より賢いロードバランサーによってではない。「任意のインスタンスが任意のリクエストを処理できる」を生むメカニズムは「いかなるインスタンスも他のインスタンスが欠く状態を持たない」である。状態がゼロならルーティングは自明;状態が非ゼロならルーティングはそれを尊重しなければならない。✅ 本番 — 記事はメカニズム(バックエンドにユーザーメモリなし)とプロパティ(任意のインスタンスが処理可能)を名指しする。

記事はこれがトレードオフであり、勝利ではないと正直に認める。水平スケーリングを容易にする同じサーバー側状態の不在が、マルチターン連続性を困難にし、それが次のメカニズムである。状態なさはスケーリングを買う;代償は連続性である。

Everythink の HAI Engine への領域横断類推は構造的なもののみである。HAI Engine は SisterOutput を返し自身では Postgres に書き込まない Sisters を実行する — Loom が永続化する。Sisters はステートレス計算ワーカー;Loom はステートフル永続化層。MachineLearningMastery 記事の「ステートレス・エージェントはサーバー側状態がないため水平にスケールする」と Everythink の「ステートレス Sisters は出力を返し永続化しないためスケールする」は同じ形式を共有する:計算ノードはステートレス、永続化は別の場所。⚠️ 部分的 — 類推は構造的;Everythink のステートレス Sisters は民事・防衛的予測に奉仕し、MachineLearningMastery のステートレス・エージェントは開発者教育に奉仕する。異なるドメイン、同じ形式:計算ノードは状態を担わない、だから自由に置換・複製できる。

メカニズム 2 —— クライアント提供の履歴がステートレス連続性メカニズム

記事はステートレス設計において「フロントエンドは各新リクエストと共に会話履歴全体を再送しなければならない。結果として、コンテキストウィンドウは雪玉効果で成長し、トークン使用量を急速に増やす」と述べる。誠実な建築家はこれを連続性主張として読む:ステートレス設計におけるマルチターン連続性はクライアントが履歴を担うことで保証され、エージェントがそれを覚えることによってではない。連続性を生むメカニズムはクライアント提供のペイロードであり、エージェントのメモリではない。代償は正直に名指しされる:ペイロードは雪玉のように成長し、トークン使用量もそれと共に成長する。✅ 本番 — 記事はメカニズム(クライアントが履歴を再送)と代償(雪玉式コンテキストウィンドウ)を名指しする。

記事はこの代償が天井であり、迷惑ではないと正直に認める。任意に長い会話を扱うステートレス・エージェントは任意に長いペイロードを受信しなければならず、だからトークン代償は会話の長さと共に成長する。これは名指しされた天井を持つメカニズムであり、無料の昼食ではない:ペイロードがコンテキストウィンドウまたは予算を超えるまで機能し、それから機能しなくなる。

Everythink の Eye Key への領域横断類推は構造的なもののみである。Eye Key はユーザー自身の資格情報 — HMAC とフィンガープリントが記録され、平文は決してディスクに触れず、鍵はユーザーのレート制限境界である。MachineLearningMastery 記事の「クライアントが履歴を担い、サーバーは何も担わない」と Everythink の「ユーザーが鍵を担い、サーバーは HMAC のみ保存する」は同じ形式を共有する:主権を担う人工物はクライアントと共にあり、サーバーは検証器のみ保存する。⚠️ 部分的 — 類推は構造的;Eye Key は民事・防衛的予測のための API 主権を統治し、MachineLearningMastery のクライアント履歴は開発者教育のためのマルチターン連続性を統治する。異なるドメイン、同じ形式:クライアントが荷重担う人工物を担い、サーバーは派生物を担う。

メカニズム 3 —— サーバー側データベースがステートフル連続性メカニズム

記事はステートフル設計において「エージェントが自らメモリの負担を引き受ける。一方クライアントは新ユーザープロンプトと一意識別子のみを送信すればよい。エージェントはデータベースからセッション履歴またはコンテキストを取得し、新メッセージをそれに追加する」と述べる。誠実な建築家はこれを連続性主張として読む:ステートフル設計におけるマルチターン連続性はセッション識別子でキー付けされたサーバー側データベースによって保証され、クライアントが履歴を再送することによってではない。連続性を生むメカニズムはデータベース検索であり、ペイロードサイズではない。クライアントのペイロードは小さく留まる;サーバーが成長する履歴を保存する。✅ 本番 — 記事はメカニズム(セッション識別子でキー付けされたデータベース)とプロパティ(小さなクライアントペイロードでの連続性)を名指しする。

記事はこれが代償を移動するのであり、排除しないと正直に認める。ステートフル設計はペイロード代償をデータベース代償と交換する:「このソリューションのスケーリングははるかに困難になり、アーキテクチャにおける永続的データベース層の必要性から始まる」。ステートフルさは小さなペイロードとサーバー側トリミングを買う;代償はデータベース層とより困難なスケーリングである。

Everythink の Loom 永続化への領域横断類推は構造的なもののみである。Loom はそのスライス所有の LoomStore ポートを通じてシミュレーションと foresight を永続化し、Sisters は永続化せず SisterOutput を返す — Loom はステートフル層、Sisters はステートレスワーカー。MachineLearningMastery 記事の「エージェントはデータベースから履歴を取得し新メッセージを追加する」と Everythink の「Loom は先行状態を取得し、Sisters にファンアウトし、統合結果を永続化する」は同じ形式を共有する:オーケストレータが状態を所有し、ワーカーが計算を所有する。⚠️ 部分的 — 類推は構造的;Loom は民事・防衛的予測に奉仕し、MachineLearningMastery のステートフル・エージェントは開発者教育に奉仕する。異なるドメイン、同じ形式:永続化層が連続性の運び手、計算層がステートレス生産者。

メカニズム 4 —— セッション識別子がルーティングキー

記事は「セッション識別子は現在の会話における過去の相互作用の関連情報を照会するために使用される」と述べる。誠実な建築家はこれをルーティング主張として読む:ステートフルメモリ取得はルーティングキーとしてのセッション識別子によって保証され、エージェントの回想によってではない。履歴を取得可能にするメカニズムは session_id キーであり、エージェントの内部メモリではない。キーなしではデータベースは未索引の山;キーがあればデータベースは取得可能な履歴。✅ 本番 — 記事はメカニズム(照会キーとしてのセッション識別子)とプロパティ(取得可能な履歴)を名指しする。

記事はセッション識別子がルーティングの関心事であり、メモリの関心事ではないと正直に認める。セッション識別子を失ったステートフル・エージェントは、履歴がまだデータベースにあっても履歴を失う。ステートフル設計はデータベースが存在することではなく、ルーティングキーが存在し一貫していることに依存する。

Everythink の「the space is the router」への領域横断類推は構造的なもののみである。Everythink のトポロジーはネットワーク → コミュニティ → ルーム:リクエストは何かが応答する前にルームにルーティングされ、ルームキーが正しい状態を取得可能にするルーティングキー。MachineLearningMastery 記事の「セッション識別子がリクエストを正しい履歴にルーティングする」と Everythink の「トポロジーがクエリを正しいルームにルーティングする」は同じ形式を共有する:ルーティングキーが応答に先行し、ルーティングキーがどの状態が取得可能かを決定する。Everythink の World Monitor は惑星規模で同じ形式を体現する:geo-signal は geohash タイルプレフィックスでルーティングされ、クライアントはアップストリームではなくキャッシュを読む、だからルーティングキー(geohash)が任意のビューポート応答に先行してどのタイル状態が取得可能かを決定する。⚠️ 部分的 — 類推は構造的;Everythink のルーターは公開ルームと geohash タイルのトポロジー、MachineLearningMastery のルーターはセッション識別子。異なるドメイン、同じ形式:ルーティングキーが取得可能性の運び手、ルーティング決定が応答に先行する。

メカニズム 5 —— 局所的健忘がステートフルスケーリング失敗モード

記事は「水平にスケールするインフラでは、Redis による集中メモリキャッシュなどの戦略も『局所的健忘』を避けるために必要になる場合がある。そこではセッションの履歴が以前のターンを処理した単一インスタンスに立ち往生する」と述べる。誠実な建築家はこれを失敗モード主張として読む:ステートフルスケーリング失敗は水平スケールされた艦隊におけるインスタンス局所状態によって保証され、データベースが遅いことによってではない。局所的健忘を生むメカニズムは「状態がそれを書いたインスタンスに存在し、ロードバランサーが session_id でルーティングしない」。修正は正直に名指しされる:Redis による集中メモリキャッシュ、状態がインスタンス間で共有される。✅ 本番 — 記事は失敗モード(局所的健忘)、メカニズム(スケールされた艦隊におけるインスタンス局所状態)、修正(集中キャッシュ)を名指しする。

記事はこれが特定のメカニズムを持つ特定の失敗モードであり、漠然とした「スケーリングは困難」ではないと正直に認める。状態がインスタンス局所でルーティングが状態盲目の時、局所的健忘は起こる;状態が共有されるかルーティングがセッション認識のある時は起こらない。失敗はメカニズムを持ち、メカニズムは修正を持つ。

Everythink の trait ベース六角形ポートへの領域横断類推は構造的なもののみである。Everythink の AppState リポジトリは Arc なのでテストはモックを差し替え、永続化はポートを通じて到達し、決して具体 PgPool ではない — 状態は共有 trait の背後にあり、具体インスタンスに立ち往生しない。MachineLearningMastery 記事の「集中キャッシュで状態がインスタンス間で共有される」と Everythink の「共有 trait で状態が任意のアダプタを通じて到達可能」は同じ形式を共有する:状態は抽象を通じて共有され、具体担い手に立ち往生しない。⚠️ 部分的 — 類推は構造的;Everythink の共有 trait は民事・防衛的予測に奉仕し、MachineLearningMastery の集中キャッシュは開発者教育に奉仕する。異なるドメイン、同じ形式:状態は共有される、だから単一インスタンスは唯一の担い手ではない。

メカニズム 6 —— ワークフロー照合が選択メカニズム

記事は「ステートフルとステートレスのアーキテクチャ設計の選択は、インフラをワークフローに適切に照合することに帰着する」と述べ、基準を与える:ステートレスは「テキスト抽出、要約、単一ターン分類チャットボットのような非常に特定のタスク向けの単純なパイプライン」;ステートフルは「長時間実行アシスタント、コーディングアシスタント、カスタマーサービスのようなマルチターンボット」。誠実な建築家はこれを選択主張として読む:正しい状態モデルは状態の所在をワークフローの連続性需要に照合することによって保証され、より洗練された設計を選ぶことによってではない。正しい選択を生むメカニズムはワークフロー照合であり、技術嗜好ではない。✅ 本番 — 記事はメカニズム(インフラをワークフローに照合)と基準(単一ターン vs マルチターン)を名指しする。

記事はいかなる設計も普遍に優越しないと正直に認める。マルチターンワークフローに強いられたステートレス・エージェントは雪玉式ペイロードを蓄積する;単一ターンワークフローに強いられたステートフル・エージェントは不要なデータベース代償を払う。全局勝者はいない:正しいメカニズムはワークフローに依存し、ワークフローが選択基準である。

Everythink の trait ベース六角形ポートへの領域横断類推は構造的なもののみである。Everythink のアーキテクチャは各ポートが異なる問いに答えるポートの集合であり、ユースケースクレートは trait に依存し、決して具体アダプタに依存しない — 正しいポートは問いによって選ばれ、実装嗜好によってではない。MachineLearningMastery 記事の「状態モデルをワークフローに照合する」と Everythink の「ポートを問いに照合する」は同じ形式を共有する:選択は需要によって、供給によってではない。⚠️ 部分的 — 類推は構造的;Everythink のポート選択は民事・防衛的予測に奉仕し、MachineLearningMastery の状態モデル選択は開発者教育に奉仕する。異なるドメイン、同じ形式:選択メカニズムは需要照合であり、供給嗜好ではない。

これがスコープと限界に意味すること

MachineLearningMastery 記事は開発者教育とエージェントアーキテクチャについてである。Everythink のプラットフォームは民事・防衛的予測についてである。本投稿の領域横断類推は構造的 — それらはメカニズム形式を共有し、市場を共有しない。誠実な建築家はこの理由で類推を ⚠️ とマークする。

Everythink 自身の商業エージェントツール向け go-to-market は 🔵 Roadmap — プラットフォームはプレ収益であり、ここで描かれた類推の商業応用は提供される前にその Roadmap 状態と Howey 審査に服する。アーキテクチャ類推は独立に成り立つ;商業主張はそうではない。

記事が主張しないこともマークに値する。ステートレスが優越すると主張しない — 雪玉式ペイロード代償を名指しする。ステートフルが優越すると主張しない — データベース層代償と局所的健忘失敗を名指しする。トレードオフが解決可能だと主張しない — 照合基準を名指しする。これらのスコープ限界は記事の誠実さであり、本投稿はそれを保存する。

主要ポイント

• 任意のインスタンスへの水平スケーリングはサーバー側状態の不在によって保証され、より賢いロードバランサーによってではない。状態の所在がスケーリング・メカニズム。✅ 本番。
• ステートレス設計におけるマルチターン連続性はクライアントが履歴を担うことで保証され、雪玉式ペイロード代償を伴う。クライアントペイロードが連続性運び手。✅ 本番。
• ステートフル設計におけるマルチターン連続性はセッション識別子でキー付けされたサーバー側データベースによって保証され、データベース層代償を伴う。データベースが連続性運び手。✅ 本番。
• ステートフルメモリ取得はルーティングキーとしてのセッション識別子によって保証される。ルーティングキーが取得可能性運び手。✅ 本番。
• ステートフルスケーリング失敗は水平スケールされた艦隊におけるインスタンス局所状態によって保証される;修正は共有状態またはセッション認識ルーティング。失敗はメカニズムを持ち、メカニズムは修正を持つ。✅ 本番。
• 正しい状態モデルは状態の所在をワークフロー連続性需要に照合することによって保証される。ワークフローが選択メカニズム。✅ 本番。
• Everythink の HAI Engine(ステートレス Sisters、ステートフル Loom)、「the space is the router」(ルーティングキーが応答に先行)、World Monitor(キャッシュがステートフル層、ポーラーがステートレス供給器)、Eye Key(クライアントが荷重担う人工物を担う)、六角形ポート(共有 trait、需要照合による選択)への領域横断類推は構造的なもののみ — 異なる市場、同じメカニズム形式。⚠️ 部分的。
• Everythink の商業エージェントツール向け go-to-market は 🔵 Roadmap — プレ収益、Howey 審査に服する;アーキテクチャ類推は成り立つ、商業主張はそうではない。

Sources

• Iván Palomares Carrascosa,Stateful vs. Stateless Agent Design: Tradeoffs for Scalable Agentic Systems,MachineLearningMastery.com、2026-07-24 公開。https://machinelearningmastery.com/stateful-vs-stateless-agent-design-tradeoffs-for-scalable-agentic-systems(2026-08-23 取得)。
• Everythink プラットフォームアーキテクチャ:HAI Engine は 2016 年から本番稼働;Theorem 3(プロパティはそのメカニズムが実装され測定している時に正確に保証される);トポロジー「the space is the router」(ネットワーク → コミュニティ → ルーム);World Monitor(geo-signal は geohash タイルプレフィックスでルーティング、クライアントはアップストリームではなくキャッシュを読む);Oracle アンサンブル正規化、各マージで nats 単位のエントロピーをスタンプ;typed Sisters(analyst、contrarian、disruptor、historian、institutionalist)は永続化せず SisterOutput を返す、Loom がステートフル永続化層;trait ベース六角形ポート、アダプタ交換可能;Eye Key 主権(HMAC とフィンガープリントが記録、平文は決してディスクに触れない、ユーザーの鍵がレート制限境界)。