AIエージェントスタックには、推論、ツール、ID、メモリ、実行環境、アプリケーションインフラ、テレメトリーを担う個別のレイヤーがあります。有用な境界はベンダーの分類ではありません。一つのシステムの責務が終わり、別のシステムがその結果を検証できる地点です。
小規模なアプリケーションでは、一つのプロセスに複数のレイヤーを実装しても構いません。認可、状態、再試行、制限について責任を持つ箇所が明確なら問題ありません。
スタックの全体像
flowchart TD
U[User goal] --> A[Agent loop and model]
A --> T[Tools and integrations]
P[Identity and policy] --> T
T --> R[Execution runtime]
T --> B[Application backend]
M[Memory and durable state] <--> A
M <--> R
R --> B
A --> O[Telemetry and evaluations]
T --> O
R --> O
B --> O
これはリクエストのパイプラインではありません。ツールはバックエンドを直接呼び出せます。ワークフローはツールを選ぶ前にメモリを使えます。テレメトリーはすべての分岐を観測します。矢印は、明示的な契約を必要とする依存関係を示しています。
推論とオーケストレーション
モデルは目標を解釈してアクションを提案します。エージェントループはモデルへ渡すコンテキストとツールを決め、選ばれた呼び出しを実行し、結果を記録し、実行を停止します。モデルの選択は振る舞いに影響しますが、タイムアウト、ステップ数の上限、終了条件はループが管理します。
これらの制限はプロンプトの外に置いてください。10回の呼び出し後に停止するというモデルへの指示より、11回目を拒否するランタイムの方が確実です。
ツールと連携
ツールはエージェントの判断を外部の機能へ変換します。タスクを表し、入力を検証し、安定した結果を返し、呼び出し元に見せてはいけない認証情報を隠す必要があります。MCPはツール仕様を通じて、検出と呼び出しの標準契約を提供します。
このプロトコルは、delete_workspaceを用意すべきか、承認を必須にすべきかまでは決めません。それはアプリケーションとポリシーが判断します。REST APIをMCPに変換するチュートリアルでは、既存APIをラップしながらこの境界を保つ方法を紹介しています。
IDとポリシー
IDは誰が操作しているかを示し、ポリシーはそのIDが現在できることを決めます。MCPゲートウェイが先にツールを絞り込んでいても、最終的な認可ルールは下流サービスが強制しなければなりません。
破壊的または金銭的な効果の前に承認を求めるのも、このレイヤーの役割です。ツール呼び出し後の承認は監査記録であり、ゲートではありません。
メモリと永続状態
メモリは、後のモデル呼び出しで関連情報を利用できるようにします。永続状態は、完了した作業、保留中の作業、外部への効果を記録します。この二つを混同すると、取得したコンテキストを操作台帳として使えないため、復旧時に問題が起きます。
ベクトルインデックスはメモの取得に役立ちますが、支払いが完了したことを示す唯一の記録にはできません。エージェントメモリのフィールドガイドでは、作業コンテキスト、セマンティックメモリ、エピソード履歴、ワークフロー状態を分けて解説しています。
実行ランタイム
ランタイムはループと生成コードを実行します。キュー、チェックポイント、再試行、サンドボックス、ネットワーク制御、ライフサイクル制限を提供する場合もあります。永続実行とサンドボックスは別の問題を解決します。一方は中断後も処理を継続し、もう一方はアクセス範囲を制限します。
Temporalによる永続実行の説明では、障害が起きてもワークフローの進捗を維持します。それでもサンドボックスには、プロセス、ファイルシステム、ネットワーク、シークレット、時間について別個の境界が必要です。
アプリケーションインフラ
エージェントが構築するアプリケーションにも、Postgres、オブジェクトストレージ、認証、ホスティング、メール、検索、外部APIが必要です。エージェントネイティブ・インフラストラクチャは、構造化されたプロビジョニングとスコープ付きプロジェクト認証情報を通じて、これらのリソースを公開します。
Cohesivityが担うのはこのレイヤーです。上流プロバイダーの認証情報をサーバー側に保持しながら、対応するバックエンドリソースに一つのプロジェクトコンテキストからアクセスできるようにします。AIエージェント・インフラストラクチャの総合ガイドでは、このレイヤーとスタック全体のつながりを説明しています。
テレメトリーと評価
テレメトリーは、ユーザーの目標、モデル出力、ツール判断、ポリシーの結果、実行、バックエンドへの効果を一つのトレースに結び付ける必要があります。評価では固定タスクをリプレイし、デプロイ前に振る舞いの変化を検出します。
OpenTelemetryのGenAIセマンティック規約は、モデルとエージェントの動作に共通属性を定義しています。この動作を実際の効果へ結び付けるには、アプリケーション側で安定したテナント、エージェント、操作、ポリシーの識別子も用意する必要があります。
レビューすべき継ぎ目
次の3つの継ぎ目は、問題を繰り返し引き起こします。
- エージェントループとツールラッパーの両方が再試行するため、一つの論理アクションから複数の書き込みが発生する。
- ゲートウェイはツールを絞り込むが、下流APIは広すぎる認証情報を信用し、リソースを認可しない。
- メモリレイヤーはアクションの要約を保存するが、そのアクションが完了したかを示す永続的な操作記録がない。
一つのワークフローを描き、それぞれの動作に一つの責任箇所を割り当ててください。以下のプロンプトはコードを変更せずに、責務の欠落と重複を見つけます。