multi-agent workflow そのものが product surface になり始める

workflow graph が code artifact だけでなく shared design surface になった

Foundry の preview は visual workflow builder と YAML definition の往復を前提にし、business 側と engineering 側が同じ graph を別の view で扱えるようにした。multi-agent orchestration が実装者の頭の中だけに閉じなくなる。

変数、schema、expression が orchestration を review 可能にした

local variables、JSON schema output、Power Fx expressions、immutable versioning が出てきたことで、workflow は「prompt をつないだもの」ではなく、出力 contract と branch logic を持つ artifact になった。これが governance と review の前提になる。

observability と evaluators が graph 単位の運用品質を問うようになった

granular tracing、built-in evaluators、custom evaluation logic、scheduled evaluation まで workflow surface に入ったことで、論点は「動くか」から「各 node と全体 flow をどう継続監視するか」へ移った。multi-agent は novelty より operations の勝負になっている。

onboarding と case management

• Foundry post は onboarding を例に、複数 step と human-in-the-loop を持つ flow を visual / YAML で扱う価値を示した。
• 情報収集、担当振り分け、確認、実行を graph として残せるのがポイントだった。

financial approvals と IT service operations

• financial approvals や IT service operations は、specialist agent と reviewer を分ける必要がある典型例として挙がる。
• multi-agent workflow が product surface になると、承認経路や rollback path を仕様として持ちやすくなる。

employee onboarding は multi-agent を業務フローとして見せる好例だった

Foundry workflows post は onboarding を visual builder の代表例として扱っている。たとえば candidate / employee 情報の確認、必要書類の回収、manager approval、アカウント作成、最終通知といった step を graph に落とすと、specialist と reviewer の責務が可視化される。

financial approvals は variables と schema が効く領域だった

workflow が variables、JSON schema output、Power Fx expressions を持つと、金額、部門、例外条件、承認結果を後段 node に安全に受け渡しやすい。これは multi-agent orchestration を chat 的な曖昧さから business process の artifact へ引き上げる。

IT service operations では trace と evaluator が運用品質を左右する

IT service operations のような flow では、node ごとの input / output、variable update、branch path、tool call を追える granular tracing が重要になる。Foundry post が workflow 全体の observability と evaluators を強調したのは、この種の運用を想定しているからだ。