スウォームの問題：Vinkius Gateway が100の同時セッションを失うことなく統合する方法

スウォームの問題：Vinkius Gateway が100の同時セッションを失うことなく統合する方法

先月、私はある顧客が12体のAIエージェントを1つのサプライチェーン最適化タスクにデプロイするのを目の当たりにしました。3日後、エージェントたちは共有在庫状態でデッドロックし、サプライヤーAPIのレートリミットに競いあい、個々のエージェントがすべての請求書修正を元に戻すことができないカスケードを作成していました。顧客の結論は、「エージェントは自分のためにあまりに賢い」というものでした。

それは起こりませんでした。エージェントは賢しすぎませんでした。孤独でした。それぞれのエージェントは自分がセッションを所有していると信じ、それぞれのエージェントは他のエージェントが決して調整できない状態を書き込み、それぞれのエージェントは同じ帯域幅予算を消費し、ピアが存在することを知りませんでした。問題はエージェントの知能ではありませんでした。それはすべてのエージェントが共有しているセッション層の問題であり、誰もが所有していなかったという事実でした。

これがスウォームの問題です。あなたはもはや1人のエージェントを持っていません。あなたはチームを持っています、グループを持っています、スウォームを持っています。財務エージェント、在庫エージェント、調達エージェント、コンプライアンスエージェント。すべてが異なる資格情報を使用して異なるサービスと通信し、同じ帯域幅予算を共有し、5回の呼び出し前に読み取った状態がまだ有効であると信じています。古いモデルは、1人のエージェント、1つのセッション、1つのライフサイクルを前提としていました。新しいモデルは、それらのうちのどれでも前提しません。

Vinkius は、エージェントパターンではなく、ゲートウェイパターンでこれを解決します。 ゲートウェイはセッションの所有者です。 エージェントはゲストです。 この設計を支配する数字は、望気ゆるまないものではありません。 それらはランタイム構成、SSRF ガード、回路遮断器コードから抽出されています。 各々の値は外部制約から派生しています。 数学がどのように機能するか、それを見てみましょう。

セッションを所有する B2BUA

SwarmGateway はバックツーバックユーザーエージェントです。 プロキシではありません。 ロードバランサーではありません。 B2BUA です：呼び出し元の MCP セッションを終了し、各専門家エージェントに対して個別のアウトバウンドセッションを確立します。 ゲートウェイは呼び出し元の代理で話しますが、呼び出し元のセッションはゲートウェイで終了します。

ゲートウェイは、専門家の名前をアップストリームURLにマッピングするレジストリ、共有デリゲーション秘密、一連の運用制限で構成されています。 エージェントがハンドオフをトリガーすると、ゲートウェイは HMAC 署名を使用したスコープ付きデリゲーショントークンを発行します。 トークンにはクレームが含まれています：発行者、被告募者、発行時間、期限、ターゲットエージェントID、オプションの復帰状態、および W3C トレースコンテキスト識別子。これにより、専門家は元のトレースに戻って相関させることができます。

トークンの寿命は60秒です。 これがコード内の定数です： tokenTtlSeconds = 60。 これは任意ではありません。 60秒は、ハンドオフがハンドシェイクを完了し、専門家がゲートウェイを通じて認証を受け、復帰路径が確立されるまでの窓です。 これより長くと、盗まれたトークンは個々のエージェントツアーの注目を超えて有効期限が切れます。 短すぎると、ネットワークジッターによって正当なハンドオフが飛び打ちで殺されます。

非アクティブタイムアウトは5分です。 idleTimeoutMs = 300_000 ゲートウェイ構成内。 委譲されたセッションが5分間非アクティブのままであると、ゲートウェイはトランスポートを閉じ、アップストリームソケットを閉じ、リソースを回収します。 スイープ間隔は15秒なので、ゲートウェイはこのウィンドウ内でセッションが消えたことを知ります。

セッション制限は100です。 maxSessions = 100。 これは、ゲートウェイが開始前に追跡する同時委譲セッションの上限です。 100を超えると、ゲートウェイはトークンの発行を停止し、呼び出しエージェントが読み取り、対応できるエラーを返します。

接続タイムアウトは5秒です。 connectTimeoutMs = 5_000。 ゲートウェイがアップストリームの専門家エージェントに接続しようとすると、接続を確立するまで5秒しかないため、諦結しハンドオフをロールバックします。 これは意図的に短いです：遅い専門家は遅く失敗する必要があります。

すべてのこれらの制限は V8 隔離境界を貫通します。 ディスパッチ予算は30秒で、 Limits.ts で DISPATCH_TIME_BUDGET_MS = 30_000 として定義されています。 ブート予算は5秒、 BOOT_TIME_BUDGET_MS = 5_000。 ヒープ制限は128MB、 ISOLATE_MEMORY_LIMIT_MB = 128。 委譲されたセッション内のツール呼び出しでこれらの値を超えると、TimeoutClassifier はそれがアップストリーム E / S 待機かホスト側の計算かを判断し、エラーメッセージには呼び出しエージェント向けの回復策が記載されます。

セッションの隔離：トークンあたり50、2分の非アクティブ

ゲートウェイは、セッションのライフサイクルを独占することはありません。 実行層にある SessionManager は、2つの並行セッション制限を課します。

最初の制限は、トークンあたり50セッションです。 MAX_SESSIONS_PER_TOKEN = 50 SessionManager のコード。 これは、侵害されたり障害のある接続トークンがセッションテーブルを枯渇させないようにするバリアです。 トークンが50個のアクティブセッションに達すると、次回の接続試行は古いセッションを暗黙的に削除するのではなく、明確なエラーで拒否されます。

2番目の制限は時間に基づいています。 通常時の非アクティブタイムアウトは2分、 SESSION_IDLE_TIMEOUT_MS = 120_000。 メモリー圧力下では30秒に短縮されます、 SESSION_PRESSURE_TIMEOUT_MS = 30_000。 スイープは15秒ごとに実行されます SESSION_SWEEP_INTERVAL_MS = 15_000、 セッションが沈黙状態になった場合、そのタイムアウト内の1回のスイープで回収されます。

セッションメタデータは、Redis に150秒の TTL でレプリケートされます、 REDIS_SESSION_TTL = 150。 これにより水平スケーリングが可能になります：セッションのトランスポートをメモリに保持していない実行ユニットでリクエストが到着すると、ルーターは Redis からセッショントークンを照会し、MCP サーバーを即座に再 hydrate できます。 Redis TTL は非アクティブタイムアウトに合わせて意図的に設定されているため、スイープユニットが死んでも期限切れのセッションは自動的に期限切れになります。

メモリー圧力のしきい値は容器の制限の小数として定義されています。 MEMORY_WARN_THRESHOLD = 0.65 ログ警告をアクティブ化します。 MEMORY_PRESSURE_THRESHOLD = 0.80 は積極的なクリーンアップをアクティブ化します。 クリーンアップロジックは非アクティブセッションを回避し、Node ランタイムで許可されている場合はガベージコレクションを強制し、運用者がリアルタイムで圧力曲線を確認できるようにメモリー状態をログに記録します。

ConnectionTracker はトランスポートレベルのキャッシュを管理し、その独自の30分間の非アクティブスキャンを持っています IDLE_TIMEOUT_MS = 30 * 60_000。 これがレベル1の通常の排出経路です。 メモリー圧力下では、第2の層があります：RSS がタスクメモリー予算の75%を超えた場合、アクティブな接続を持たないすべてのキャッシュされた構成を最も古い順に排除し、圧力が65%未満になるまで続行します。 コードは明示的に言います： 「これにより、OOM が発生する前にオートスケーラーに新しいコンテナーをプロビジョニングする時間が与えられます。」

これらの層のつながりは意図的です。 セッショントランスポートは接続キャッシュエントリと同じではありませんし、固定 IP のアウトバウンドエージェントと同じでもありません。 各要素は独自の所有者、独自のタイムアウト、独自の排出トリガーを持っています。 しかし、すべては同じシグナルに従います：セッションが沈黙状態になったか、コンテナーがメモリーを必要としています。

状態の同期：古い読み込みのない因果関係の無効化

状態同期層は、マルチエージェント調整が希望からプロトコルになる場所です。 Vinkius は、3種類のマークで因果関係の無効化を実装します：不変、一時的、因果的。

不変マークは、状態が固定されていることを意味します。 一度書き込まれると、変更できません。 一時的なマークは、状態が一時的であり、メモリー圧力の下で何時でも排除される可能性があることを意味します。 因果的なマークは、上流の依存先が変更された場合に状態が無効になることを意味します。 これらのマークは V8 隔離内部に保存されません。 ホストの同期層で追跡され、Redis Streams チャネルを通じて無効化シグナルが送信されます。

専門家エージェントがリソースを変更すると、ゲートウェイは適切なストリームに無効化イベントを公開します。 このリソースに因果的マークを保持するすべてのエージェントは、次のツール呼び出しの前に状態を再解決する必要があります。 これにより、Finance-Agent が Inventory-Agent から価格を読み取り、Inventory-Agent が価格を更新し、Finance-Agent が古い価格で顧客に請求するという典型的なマルチエージェント問題を防ぐことができます。

SwarmGateway の復帰状態パターンはこれを強化ます。 ゲートウェイがトークンを生成すると、呼び出し元の意図をトークンのクレームに復帰状態としてエンコードします。 専門家はこの状態を受信し、それに対してaction を実行できますが、ゲートウェイは権威あるコピーを保持します。 セッションがゲートウェイに戻ると、ゲートウェイはゲートウェイレコードに復帰状態を照合し、専門家が触れたすべての因果的マークをスウォーム全体で無効化します。

セッションと暗号監査パスのつながりは、この耐久性を也たらします。 ハッシュチェーンは raw_base64 || previous_hash || sequence_number として構築され、Ed25519 で署名されます。 V8 は暗号学を直接触れません。 StreamingDaemon は単一スレッジのワーカーであり、Redis Streams から読み取り、ハッシュチェーンを鋳造し、Ed25519 で署名し、SIEM 宛先に送信します。 セッショントークンは24時間でローテーションされ、状態変更は Redis Streams にマークされているため、ワーカーがクラッシュしてもチェーンに欠失はありません。

接続プール：4,096 ドメイン、100 ソケット

SSRF ガードは、ペアレドキャッシュを課します：DNS 解決とアウトバウンドプールエージェントはライフサイクルで結合されます。 DNS キャッシュは最大4,096エントリを保持します DNS_CACHE_MAX_ENTRIES = 4_096。 キャッシュが満たると、最も古いエントリが排出されます。 プールエージェントは最大100の接続を保持します AGENT_POOL_MAX = 100。 プールが満たると、最も古いプールエージェントが閉じられ、その DNS エントリも同じ操作で削除されます。

この結合は DNS リバインディング攻撉を防ぐものです。 ガードはリクエスト前に DNS を解決し、解決された IP がプライベート範囲内にないかを検証し、然后その特定の IP を undici Agent のカスタム検索関数に固定します。 SNI と TLS 名は hostname のままなので、証明書検証は引き続き正しく機能します。 初期 DNS 解決後に異なる IP を返すリバインディング攻撃は、ソケットをリダイレクトすることはできません。ソケットは承認されたアドレスにバインドされているためです。

ブロックされるプライベート IP 範囲は次のとおりです：ループバック (127/8)、プライベート Class A (10/8)、プライベート Class B (172.16 to 172.31/12)、プライベート Class C (192.168/16)、リンクローカル (169.254/16)、ゼロネットワーク (0/8) とその IPv6 対応先 (::1、FC00/7、FE80/10)。 接続が確立される前に、解決された各アドレスに対してこれらをチェックします。

プール内エージェントのキープアライブタイムアウトは65秒です AGENT_KEEP_ALIVE_TIMEOUT_MS = 65_000。 標準的な ALB の非アクティブウィンドウの60秒よりも意図的に長いため、プール内のソケットはエージェント会話の間、ロードバランサーによって静かに閉じられることなく生存します。 undici ライブラリのデフォルトの4秒は、各ターンの間にソケットを閉じ、実質的に毎回の real 呼び出しでの寒い TLS ハンドシェイクを強制します。65秒のタイムアウトにより、通常のエージェント会話の duration 中に接続が維持されます。

非アクティブエージェントをクリーンアップするスキャンは60秒ごとに実行され、ConnectionTracker の30分間の非アクティブスキャンと調整されます。 プールエントリが排出されると、DNS エントリも一緒に死にます。 ライブ接続ポリシーがなければ、認可されたアドレスは次回の使用時に再解決および再検証されます。 コードコメントは明示的に言います： 「DNS の解決は、このホスト名のプールエージェントを保持している間だけキャッシュに格納され、両者は一緒に死にます。」

カスケードを防�制するサーキットブレーカー

サーキットブレーカーは、制御不能なスウォームがサブスクリプションを焼き尽くすのを防ぐ金融的保護です。 Redis で実装されたスライドウィンドウカウンターです。 デフォルト値は、5分間の5,000リクエスト、15分のクールダウンです。 これらの数字はガバナンス構成から来ており、ランタイムコードではありません。 ランタイムコードの CircuitBreaker.ts は、PHP メソッド CheckRequestQuota::checkCircuitBreaker を反映しています。

リクエストが到着すると、サーキットブレーカーは TTL キーをクエリすることで、サーキットが既に開いているかどうかを確認します。 キーの TTL が肯定的である場合、サーキットは開いており、エージェントは機械的に読み取り可能な拒否メッセージを受信します： 「CRITICAL: Financial budget ceiling exceeded. DO NOT RETRY this request.」 エージェントは、ヒューマンユーザーを Vinkius Cloud コンソールに誘導して、再開を承認してもらうように指示されています。

サーキットが閉じている場合、サーキットブレーカーは決定論的キーのカウンターをインクリメントします：アカウントIDと現在のタイムスタンペルの床をウィンドウサイズで割った値。 カウンターが制限を超えると、サーキットが開きます。 開いた状態は、クールダウン期間を TTL として SETEX として Redis に保存されるため、クールダウン後に自動的にリセットされます。

サーキットブレーカーは開くことで失敗します。 Redis が利用できない場合、検証はキャッチされ、ログに記録され、リクエストは承認されます。 これは意図的な設計上の決定です：Redis の障害がエージェントの正当なトラフィックをブロックするべきではありません。 その犠牲は、Redis の障害中にサーキットブレーカーが無効になり、エージェントがサブスクリプションを超える可能性があります。 コードコメントは明示的に言います： 「fail-open prevents blocking legitimate traffic.」

メモリー圧力下でセッションが排出されると、プールエントリが続きます。 カスケードは制御されています：サーキットブレーカーは新しいリクエストを停止し、セッションスイープは非アクティブセッションを消去し、ConnectionTracker は非アクティブキャッシュを排出し、DNS キャッシュはライブ接続を失ったエントリを拒否します。

各セッションを封じる 34+4 ルール

IsolateRunner は、各委譲セッションがサンドボックスから脱出するのを防�止する 34+4 のエンジニアリングルールを課します。 34 ルールはブート、スナップショット、ディスパッチ、およびリジェクトに適用されます。 追加の4つのルールは、メモリー、CPU、ネットワーク、およびディスクの封じ込めです。

ブート時：ライフサポートポリフィルは、外部状態にアクセスする可能性のある Node の組み込み関数をすべて置き換えます。 ゲストのコールバックレジストリは IIFE が実行される前に登録されます。 二進安全な Fetch はホストブリッジ呼び出し�として注入され、バンドルが置き換える可能性のあるポリフィルではありません。 スクリプトはブート直後に解放されるため、スナップショットキャッシュがブートオブジェクトへの参照を保持することはできません。

スナップショット時：V8 ヒーフスナップショットは、4階層の整合性モデルでディスクキャッシュに保存されます。 ブリッジスタブは無効なトランスポートを取得できないように、ホスト参照に置き換えられます。 状態外部化フックにより、隔離はスナップショットを生存させるべきではない参照を拒否できます。 スナップショットはデプロイメントIDで識別され、デプロイメントが再インポートされると Redis で原子的に無効化されます。

ディスパッチ時： copy: true での構造化クローンにより、隔離からホストに渡されるオブジェクトは深くコピーされ、共有されません。 ディスパッチタイムアウトにより watchdog が起動し、ホストのアップストリームフェッチでハングしていてもスクリプトをkillします。 TimeoutClassifier は続いて、kill がアップストリーム E / S 待機かホスト側の計算かを判断し、エラーには回復策が記載されています。

リジェクト時：AbortController は拒否パイプライン全体にわたって接続されており、進行中のリクエストを中止します。 ギロチンタイマーはゲストによって登録されたすべての setTimeout と setInterval をキャンセルします。 参照は逆順で解放され、disposed ガードはダブルフリーを防ぎます。 セッションが排出されると、その進行中のリクエストは同じ呼び出しで中止され、レスポンスストリーム上のバイトカウンターは10メガバイトに制限されます。

10メガバイトのレスポンス制限は MAX_FETCH_RESPONSE_BYTES = 10MB ランタイム構成内。 バイトカウンターは AbortController に接続されているため、制御不能なレスポンスはストリームの途中で切断され、隔離のヒープが満たされる前に切断できます。 SSRF ガードの safeFetch 関数は、すべてのアウトバウンドリクエストにこのカウンターを課し、ガードは隔離が外部ネットワークにアクセスできる唯一の方法です。 直接的なソケット、DNS-over-HTTPS トンネル、WebSocket アップグレードはありません。

4つの封じ込めルールは以下のとおりです：128MB のヒープ制限、V8 フラグ resourceLimits.maxOldGenerationSizeMB によって強制されます。 30秒のディスパッチウォッチドッグによる CPU 制限、それはソフト制限ではなく、隔離内から延長することはできません。 SSRF ガードによるネットワークの封じ込め、これは、ガードの DNS キャッシュとエージェントプールが外部ネットワークへの唯一の出口であることを意味します。 ディスクは最も困難です：隔離はファイルシステムへのアクセス権がありません。 バンドルは完全にメモリ内で実行され、すべてのファイル操作はホストブリッジを通じて行われます。

エージェントがデータに触れる前の保護

マルチエージェントセッションはデータ漏洩面を増幅します。 1人のエージェントが顧客レコードを読み取り、別のエージェントが会話に参加し、突然、両方のエージェントが読み取り許可のない機密フィールドを見るようになります。 DLP 層は、データがエージェントに到達する前に動作することで、これを防ぎます。

ResponseGuard は、ゲートウェイを出発する前に各レスポンスにマスキングパターンを適用します。 デフォルトパターンには、Email、Password、Secret、Credit Card、SSN、Phone、API Key、Token、Date of Birth、Bank Account、および IBAN のワイルドカード一致が含まれます。 ワイルドカード構文は、 *.email がレスポンスオブジェクト内の任意の深さにあるすべての Eメールフィールドを保護し、 items[*].credit_card が配列要素を特に保護することを意味します。

マスキングは RAM 内で行われ、ディスク上ではなく、V8 隔離内でも行われません。 ガードは、レスポンスが MCP サーバーに渡される前にホストプロセスで実行されます。 これは、機密データがエージェントが読み取る可能性のあるツールの説明や引数に入る前にマスクされていることを意味します。 ガードはステートレスで決定論的なため、同じレスポンスは常に同じマスキングを生成し、監査パス上のリプレイ攻撗を不可能にします。

各マスキングはカウントされ、割り当てられます。 Security Posture サーフェスは、時間、コネクター、エージェントセッションごとのマスキングの総数を追跡します。 エージェントがマスキングをトリガーすると、サーキットブレーカーのエラー割り当ては、それが DLP であることを知り、アップストリームであることも、エージェントであることもありません。 ログエントリは「Vinkius Err: DLP redaction applied」を読み、回復策は、マスクされたフィールドを明示的に要求するようにエージェントに指示します。

スウォームのトレース：W3C はハンドオフを通じて

エージェントが専門家へのハンドオフをトリガーすると、W3C トレースコンテキストが移動します。 元のリクエストの traceparent ヘッダーは委譲トークンのクレームにエンコードされ、専門家がリクエストを処理すると、トークンからトレースコンテキストを読み取り、トレースを継続します。

ランタイムの TraceContext ヘルパーは、呼び出し元のトレースコンテキストを各サーバーファクトリのリクエストあたりのコンテキストに昇格させます。 コンテキストはすべてのサーバータイプで利用可能です：API プロキシ、YAML、バンドル。 そのため、ツールスパンとリクエストログは、ツールごとのコードなしで、元のトレースへの戻りトレースを相関させることができます。 値が未定義の場合、トレースは根を持たず、デフォルトに暗黙的に結合されません。

監査パスは、トレースコンテキストを端から端まで保持します。 ChainForge は、各監査レコードのハッシュを、生の Base64 ペイロード、前のハッシュ、シーケンス番号から構築します。 トレースコンテキストは、検索可能なメタデータとしてログエントリにエンコードされるため、セキュリティアナリストは、ゲートウェイ、専門家、ゲートウェイへのエージェントの一意のパスを 1 つのトレースで追跡できます。

これが Live Activity ダッシュボードの命です。 各行は MCP サーバー、ツール、セマンティックアクション（query、mutation、destructive）、トークン、結果、および遅延の完全な内訳を示します。 緑はアップストリームが応答したことを意味します。 紫は Vinkius ポリシーが飛行中に作用したことを意味します。 アンバーは呼び出し元が誤ったことを意味します。 赤はプロバイダーが失敗したことを意味します。 各色は異なる障害の所有者に対応し、各障害は Analyst が開いて完全なパスを確認できるトレースを伴います。

戻り道：ゲートウェイが再統合する方法

専門家エージェントが作業を完了すると、SwarmGateway の returnToGateway メソッドが呼び出されます。 これはリダイレクトではありません。 これはステートのリコンシリエーションです。 ゲートウェイはトークンのクレームにエンコードされた復帰状態と、専門家が返した状態を比較し、専門家が触れたすべての因果的マークをスウォーム全体で無効化します。

復帰は、ゲートウェイが専門家のセッションに注入するツールによって仲介されます。 このツールは、プライマリ機能としてエージェントに表示されるわけではありません。 これはリターンチャネルです：エージェントは最終状態でそれを呼び出し、ゲートウェイはそこから続行します。 ツールは _MCPFUSION_handoff_return として識別されており、セッション層がそれを認識して復帰パスをアクティブ化できます。

また、ゲートウェイは専門家のツール名前空間を書き直します。 財務専門家がツールを公開すると、ゲートウェイはそれらに finance. を付加し、呼び出し元が finance.create_invoice と finance.get_balance を見るようにします。 create_invoice と get_balance ではありません。 複数の専門家が同じ会話でアクティブになっている場合の名前の衝突を防ぎ、監査パスを明確にします：各ツール呼び出しは、どの専門家名前空間から来たのかを記録します。

重要な数字

このシステム内のすべての制限は名前が付けられています。 コンフィギュレーションファイルに秘密の数字はありません。 各定数の横には、その導出が文書化されています。

名称	値	ソース
セッション非アクティブタイムアウト	2分	SessionManager.ts、SESSION_IDLE_TIMEOUT_MS
メモリー圧力タイムアウト	30秒	SessionManager.ts、SESSION_PRESSURE_TIMEOUT_MS
トークンあたりのセッション上限	50	SessionManager.ts、MAX_SESSIONS_PER_TOKEN
セッションスイープ間隔	15秒	SessionManager.ts、SESSION_SWEEP_INTERVAL_MS
Redis セッション TTL	150秒	SessionManager.ts、REDIS_SESSION_TTL
メモリー警告しきい値	65%	SessionManager.ts、MEMORY_WARN_THRESHOLD
メモリー圧力しきい値	80%	SessionManager.ts、MEMORY_PRESSURE_THRESHOLD
接続非アクティブ排出	30分	ConnectionTracker.ts、IDLE_TIMEOUT_MS
DNSキャッシュ最大エントリ	4,096	SsrfGuard.ts、DNS_CACHE_MAX_ENTRIES
エージェントプール最大	100	Limits.ts、AGENT_POOL_MAX
エージェントキープアライブ	65秒	Limits.ts、AGENT_KEEP_ALIVE_TIMEOUT_MS
ディスパッチ時間予算	30秒	Limits.ts、DISPATCH_TIME_BUDGET_MS
ブート時間予算	5秒	Limits.ts、BOOT_TIME_BUDGET_MS
1回の Isolate ヒープ上限	128 MB	Limits.ts、ISOLATE_MEMORY_LIMIT_MB
セッショントークンローテーション	24時間	StreamingDaemon.ts、SESSION_KEY_TTL_MS
サーキットブレーカーウィンドウ	5,000リクエスト/5分	ガバナンス構成
サーキットブレーカークールダウン	15分	ガバナンス構成

スウォームの問題は、エージェントを賢くすることで解決されません。 セッション層を権威的にすることで解決されます。 ゲートウェイは委譲トークン、セッションライフサイクル、ステート同期、および帯域幅予算を所有しています。 エージェントはゲストです。 ゲートウェイはホストです。 エージェントが時間を超えた場合、ゲートウェイはそのセッションを排出します。 プールが満たると、ゲートウェイはハンドオフを拒否します。 予算を超えた場合、サーキットブレーカーが開き、スウォームは停止します。

AI エージェントとしての新しい消費者 の投稿では、MVA アーキテクチャ：Model、Presenter、Tools について説明しました。 V8 隔離の投稿 では、サンドボックスとスナップショットの整合性モデルについて説明しました。 AI ガバナンスの投稿 では、12の表面とサーキットブレーカーについて説明しました。 この投稿では、すべてが依存するが誰もが言及しない層、つまり100体のエージェントが互いの足を踏むことなく100体のエージェントを防止するセッション層について説明します。 このシリーズの次の投稿では、Capability Lockfile について説明します。 mcpfusion.lock ファイルが、git-diff可能な diff と CI ゲートで破壊的変更を強制する方法です。

上記の数字は推定ではありません。 コードが与えるものです。 Limits.ts、SessionManager.ts、SsrfGuard.ts、および CircuitBreaker.ts をクラウドランタイムで読み取ることができます。 各値は命名されており、文書化されており、外部制約から派生しています。 これが、進化するプラットフォームと倒壊するデモンストレーションの違いです。

同時エージェントを管理するセッション管理、クォータ強制、サーキットブレーカーは、ソースコードで回答されていますエンタープライズAI質問。