AIエージェントのアーキテクチャには、モデルとツールループ以外の要素も必要です。本番設計ではID、ツール、タスク状態、長期メモリ、永続実行、バックエンドサービス、テレメトリーを分けます。それぞれが別の種類の失敗を担うためです。
最も明快なテストは、二つの外部書き込みの間でクラッシュさせることです。システムは、誰が操作し、何が完了し、何が完了した可能性があり、会話テキストからモデルに現実を再構築させずにどこから再開するかを把握できる必要があります。
実行経路から始める
flowchart TB
Trigger[User or event] --> Loop[Model and agent loop]
Loop --> Policy[Identity and policy]
Policy --> Tools[Tool registry]
Tools --> Durable[Durable execution]
Durable --> Backend[Backend services]
Loop <--> State[(Task state)]
Loop <--> Memory[(Long-term memory)]
Loop --> Telemetry[Traces, logs, metrics, evals]
Tools --> Telemetry
Durable --> Telemetry
Backend --> Telemetry
モデルは次のアクションを提案します。ポリシーはそのIDに実行権限があるか判断します。ツールレイヤーは判断を制限付き契約へ変換します。永続実行は外部への効果の前後で進捗を記録します。バックエンドサービスは正式なビジネスデータを保持します。テレメトリーにより、人間は実行を再構築できます。
この流れは広範な本番エージェントスタックに含まれますが、社内の全サービスを描くより、実際のワークフロー一つについて描く方が有用です。
各レイヤーに一種類の事実を持たせる
モデルループは選択するが、認可しない
ループはプロンプト、最近のメッセージ、ツール結果、停止ルールを保持します。ツールを選択できますが、権限は下流システムで強制する必要があります。「請求書は読み取りだけ」というプロンプトは指針であり、アクセス制御境界ではありません。
ツールは制限付きアクションを公開する
ツール契約は操作に名前を付け、引数を制約し、次の判断に必要なフィールドを返します。モデルが希望を説明できるという理由で、広範な管理APIを公開してはいけません。MCPツール設計ガイドでは、選択、スキーマ、安定したエラー、安全な書き込みを扱っています。
IDとポリシーは実行可能なことを決める
テナント、ユーザー、エージェント、委任されたscopeを、アクションを実行するシステムまで伝えます。重大な呼び出しの前にポリシーを確認し、監査記録に判断を残します。認証情報からサーバーが導出できるテナントIDをモデルに指定させてはいけません。
タスク状態は現在の実行位置を記録する
タスク状態には、現在の手順、完了済み操作、保留中の承認、再試行回数、次の予定試行が含まれます。作成元のプロセスが終了しても保持する必要があります。会話履歴は実行への入力ですが、transactionの状態を安定して表現しないため、明示的状態の代わりにはなりません。
メモリは選択した事実を実行間で伝える
メモリにはユーザー設定、以前の要約、取得ドキュメントなどを含められます。誤る可能性のあるコンテキストなので、出典、保持、削除のルールを維持します。「請求書を送信済み」のようなメモリ内の一文だけで不可逆な副作用を記録してはいけません。その事実は正式なバックエンド状態に属します。
永続実行は中断を越えて継続する
永続実行は再試行、チェックポイント、待機、再開を調整します。Temporalは、記録したイベント履歴をreplayし、クラッシュや停止が起きても継続する実行として定義しています。Temporalを導入せず、小規模な操作台帳を実装する場合にもこのモデルは役立ちます。Temporalの永続実行に関する説明と詳細なエージェント永続性ガイドを参照してください。
バックエンドサービスはビジネス上の事実を所有する
注文、支払い、ファイル、権限、顧客記録は、不変条件を強制するよう設計されたシステムに置きます。エージェントはスコープ付きAPIまたはツールを通じてアクセスします。モデルのresponseは注文を説明できますが、正式な注文記録にはなりません。
テレメトリーは経路を再び結び付ける
モデル呼び出し、ツール選択、ポリシーチェック、ツール実行、下流リクエストを一つのトレースで結びます。操作IDとredact済み引数を含めます。イベントにはログ、全体のhealthにはmetric、期待する振る舞いには評価を使います。いずれも他を代替できません。
プロダクトを選ぶ前に失敗を分ける
タイムアウト後にエージェントがメールを重複送信したら、永続実行と冪等性を調べます。翌週に誤った設定を記憶していたら、メモリと出典を調べます。別テナントの記録を読んだら、IDと認可を調べます。delete_projectではなくarchive_projectを選んだら、表示されたツールセットと選択テストを調べます。
一つの「エージェントプラットフォーム」を購入しても、これらの境界は消えません。どのcomponentが所有するかが変わるだけです。プロダクト名の背後にある通常のデータベースやqueueも含め、所有者を明示的に記録してください。
最も複雑なワークフローから描く
読み取り専用chatから始めないでください。2回書き込み、承認を待ち、不安定なAPIを呼び出し、支出できるワークフローを選びます。各副作用の前後で正式な記録を明示します。以下のプロンプトはその経路をアーキテクチャマップへ変換し、現在モデルのcontext windowにしか存在しないレイヤーを示します。