Lilith.
⌕
編集イラスト: StacklokはエージェントをPCからKubernetesへ移し、企業の統制も取り戻す
Lilithのイラスト · 編集リミックス

Stacklokは、1台のPC上の単一プロセスに閉じたエージェントループを、企業が運用できる基盤へ移そうとしている。open sourceプロジェクトのMecatlは、クライアント、モデル提供者、状態保存、機密性の高いツール実行環境を分離する。

Mecatlはデスクトップのエージェントをクラウドサービスへ分解する

同社を率いるのはKubernetesの共同開発者、Craig McLuckieとJoe Bedaだ。6月に始まったopen sourceプロジェクトのMecatlは、エージェントループをメモリ、session state、tool calling、shellコマンドから切り離す。状態をローカルディスクのJSONLファイルに置き続ける必要がなく、機密操作は別の管理環境で実行できる。

Stacklokはすでに、MCPサーバーをローカルまたはKubernetes上で運用、統制するToolHiveを提供している。さらに、アクセス、予算、レポート、プロバイダー間のroutingを管理するAI Gatewayを加える。このgatewayはまだopen sourceではなく、現時点ではタスクに応じたモデル選択も行わない。

プラットフォームチームは通常のサービスと同じ統制手段を得る

デスクトップ型エージェントは、コード、文脈、権限、状態を集中管理しにくい場所に抱え込む。クラウド型ならworkloadにIDを与え、ツールを制限し、呼び出しを記録し、人間の判断を待つ間に安全に停止できる。主役はチャット画面ではなく、この運用規律だ。

すでにKubernetesを使う企業には分かりやすい提案である。エージェントを社員のPC上の例外ではなく、既存ルールに従う別のworkloadとして扱える。Stacklokは同時に、アプリケーションを特定のhyperscalerやfrontier labから切り離すという、クラウドで使われた戦略を再現しようとしている。

Kubernetesは運用を整えてもエージェントの判断までは保証しない

Mecatlはlifecycle、監査、隔離を改善できるが、正しい計画や安全なモデル出力を保証しない。中央管理された誤りも誤りであり、ログがきれいになるだけだ。企業はprompt、ポリシー、ツール、利用可能なデータを誰が変更できるかも決める必要がある。

事業モデルは、ID、認可、ポリシー、監査でopen source部品を結ぶenterprise control planeに置かれている。Stacklokは2023年に1,750万ドルのSeries Aを調達し、その後software supply chain securityからエージェント基盤へ軸足を移した。経験豊かなチームだが、製品の方向はまだ固まりきっていない。

本当の試験は複数のクラスターとクラウドで始まる

小規模なチームならopen source部品を比較的簡単に動かせる。Stacklokによれば、難題は複数のクラスターとクラウドへ広げたときに現れる。ID、バージョン、ポリシー、責任の境界がずれるからだ。分離型の設計が運用負荷を下げるかは、そこで決まる。

長いsessionの障害復旧、人間の承認を待つ安全な停止、監査記録の質、モデル提供者をまたぐ移植性が重要な指標になる。プラットフォームチームを迂回せずに動けば、agent harnessは基盤に近づく。動かなければ、壊れやすいエージェントの下に複雑な層が一つ増える。

Lilithの判定

Stacklokが目指すのは、社員の鞄に入ったエージェントをプラットフォームチームの管制室へ移すことだ。安全に停止し、追跡し、復旧できて初めて、クラウドはモデルへ伸びた長いケーブル以上の意味を持つ。

外部リンクは最後に置いています。まずここで簡潔に解説 — 他人のサイトを探し回る必要はありません。

元の記事 ↗ ↗