Agent を定義し、deploy し、直接実行する基盤。

問い合わせ調査の prompt、FAQ、MCP tool、顧客確認手順が担当者ごとに違い、成功したやり方を部門で再利用できない。

1. 調査目的、system prompt、利用 tool、出力 schema を AgentDefinition として保存する
2. v1 draft をレビューし、publish した immutable version を cloud environment に deploy する
3. 問い合わせを input として invoke し、tool call、result、修正理由を run history に残す

未承認 draft の deploy、highly_restricted data を扱う agent、許可されていない MCP server、owner 不明 agent を止める。

agent definition、published version、deploy 履歴、run event、tool call、回答修正率、担当者が採用した result を提示する。

CS 責任者には回答時間と再利用性、情シスには tool 境界、管理部門には部門展開できる catalog として説明できる。

審査 agent が途中で人間判断を必要としても、チャット上で止まり、誰が何を判断したか、どこから再開したかが履歴に残らない。

1. agent が tool call 結果をもとに判断待ちを検出し、Invocation を waiting_input にする
2. 担当者が承認、差戻し、追加指示を送ると follow-up event として保存する
3. worker は durable event から再開し、running から completed までの状態遷移を残す

承認なしの確定操作、判断待ちを飛ばす retry、期限切れ invocation、担当者不明の follow-up を止める。

waiting_input になった時刻、担当者の判断、再開 event、最終 result、cancel / timeout の扱いを audit で確認する。

agent を本番運用する時の最大の不安である『人間判断の欠落』を、状態遷移と audit で説明できる。

各 workflow が model、sandbox、Managed Agents session id、credential を直接扱い、provider 変更や runtime 障害のたびに全体が壊れる。

1. 上位 workflow は Foundry SDK の AgentRef と invoke だけを使う
2. correlationId で workflow run と agent invocation を stitch する
3. runtime provider、credential、session event の詳細は Foundry adapter 内に閉じる

workflow 側から provider credential を直接参照する実装、correlationId なし invocation、audit.read 権限外参照を止める。

SDK contract、agent readiness、correlationId、workflow run と invocation の紐づき、provider 変更時に workflow が変わらないことを示す。

AI platform は runtime を標準化し、業務 product は orchestration に集中できるため、複数部門への横展開がしやすい。