皆が飛ばす部分
誰も引き受けたがらない問題
フレームワークはひとつのエージェントを作る手助けにはなります。しかし、エージェントが現実世界に触れた瞬間に重要になる部分は助けてくれません。つまり、他の人のためにエージェントを動かし、その人のお金を使い、データに触れ、重大な行動を取りながら、顧客間でデータを漏らさず、取り返しのつかない誤りを犯さないようにする部分です。
4つの前線
テナンシー
ある顧客のエージェントは、共有ツールを経由しても、別の顧客のデータに到達できません。
自律性
エージェントにチャットだけでなく行動させること。自発的に行動するものも含め、壊滅的な行為を止める手段を備えたうえで。
ガバナンス
重要な操作はすべて認可ゲートを通過します。お金と予約は常に人の判断を待ちます。それ以外は、アシスタントの固定ポリシーが許可した場合にのみ実行され、そうでなければ待機します。
経済性
各テナントの支出には上限があり、価値はテナント間でアトミックに移動できます。メーターは単なる請求ではなく、スロットルであり決済レイヤーです。
1 から 6 まで
解決する難しい問題
01 組み合わせても崩れない分離
テナント A が所有するツールをテナント B が呼び出した場合、A ではなく B のスコープで実行されます。証明済み：A が所有していないツールを経由しても、A は B を読み取れません。
02 重大な結果を伴う操作を、安全に
ケイパビリティエンベロープ、承認キュー（承認してから実行）、キルスイッチ、信頼されて初めて自律へ移行するソフトローンチ、そして危機対応プロトコル。これらがすべてのエントリポイントに組み込まれています。
03 信頼レベルを混ぜない合成
内部 = インプロセスのレジストリ（高速、テナントスコープ）。外部 = MCP、双方向、SSRF対策済みのトランスポート経由。MCPが内部バスになることはありません。
04 動作が証明できる出力
品質ゲート: 生成 → 検証 → 修復 → 出荷。モデルが提案し、バックエンドがスキーマを強制します。
05 プロダクトではなくプラットフォーム
新しい業種を加えるとは、既存のものを組み合わせることであり、作り直すことではありません。互いに無関係なレジデントが 1 本の背骨に乗っており、純粋性 lint がコミットのたびにそれを証明します。
06 安全のプリミティブとしての経済性
クレジットはアトミックに減算され、クライシス支援窓口へ誘導されたターンは返金されます。苦境にある人に課金はしません。同じプリミティブがテナント間で価値を移動させます。有料のテナント間呼び出しは、アトミックで残高超過を起こさない 1 つのステップで、呼び出し側に課金し提供側に支払います。
メッセージを送信すると何が起きるか。
ホームページのノートブックにある各回答には、通過したチェックが表示されます。それぞれが保証であり、それぞれがフェイルセーフに失敗します。
SET LOCAL app.current_tenant がそのターンの RLS をバインドテナントコンテキストなし ⇒ 0 行信頼しなければならないポリシーではなく、読んで確認できる安全性: UPDATE … SET credits = credits - :n WHERE credits >= :n、アドバイザリーロック付きのbook_if_free。そのうち2つが保たれる様子をライブで見る →
話しましょう
誰もこの問題を引き受けたがりません。私は引き受けました。
テナント分離、ガバナンス、メータリングがエージェントを本番に出す上での障壁なら、その部分はすでに構築済みです。お話ししましょう。
AI が行動できるときに何が問題になるか、そして PANTHEON がそれにどう対処するかを質問してください。
- AI が行動できるとき、何が問題になりますか？
- データ漏洩を何が防いでいますか？
- まだ人が必要なものは何ですか？