AutoSynthData: エンタープライズエージェント向けトレーニングデータ生成、失敗をカリキュラムへ変える

ServiceNow CoreAIは10月2日、2件のエンタープライズエージェント実験で約4,000件の合成タスクから改善が得られたと報告し、AutoSynthDataを公開した。AutoSynthData: エンタープライズエージェント向けトレーニングデータ生成は、モデルの失敗から出発し、その弱点を実行可能かつ検証可能な学習例へと変換する。対立点は明確だ。合成データは迅速に規模を拡大できる一方、生成されたタスクが誤った振る舞いを学習させる可能性もある。

このためAutoSynthDataは、単にモデルにプロンプトを考案させる仕組みではない。対象エージェント、その実行環境、そしてより強力な教師モデルを中心に、閉じた学習ループを構築しようとしている。採用される各タスクには、初期システム状態、ユーザー要求、成功した軌跡、最終状態を評価する検証器が含まれる。

ServiceNowによれば、この手法はEnterpriseOps Gymの2つのドメインでGemmaの対象モデルを改善した。ただし、この改善は、カリキュラム形成にも使われた同一ベンチマーク群内の統制された実験に基づくものだ。この結果は、静的で人手作成のデータセットに依存するチームに課題を投げかける一方、外部環境への転移や本番環境での信頼性については未解決のままである。

AutoSynthData: エンタープライズエージェント向けトレーニングデータ生成は失敗から始まる

重要な変化は、ServiceNowがエージェントの失敗を、次に生成すべきトレーニングデータの指示として扱っている点にある。

従来の合成データパイプラインは、トピック、テンプレート、またはシード例から始まることが多い。それらをより大規模なコレクションへ展開し、結果をフィルタリングして、残ったサンプルを学習に使う。このプロセスは量を生み出せるが、新しいデータがモデルの実際の弱点に対処していることまでは証明しない。

AutoSynthDataはこの順序を逆転させる。まず対象モデルを運用環境内で評価し、どこで失敗するかを分析する。より強力な教師モデルも同じ診断タスクに取り組み、失敗した振る舞いと成功した振る舞いを比較できるようにする。

このシステムは、関与する能力、必要なツール、ワークフロー構造、成功と見なされる最終状態を分析する。また、根本的な能力を失わずに変更できる詳細も特定する。こうした観察は、ServiceNowがサニタイズ済み能力仕様カードと呼ぶものになる。

これらのカードは、元の評価プロンプト、エンティティ、軌跡、検証器の詳細を公開せずに生成を導く。この分離は、ベンチマーク内容の直接的な漏えいを減らすことを意図している。また、生成器に対し、テスト問題を言い換えるだけではなく、新しい状況を作るよう求めるものでもある。

タスク形式は、相互に結び付いた3つの部分で構成される。システム仕様はポリシー、利用可能なアクション、初期環境状態を定義する。ユーザープロンプトは要求する結果を示し、検証器はエージェントが許容可能な最終状態に到達したかを判断する。

この構造が重要なのは、エンタープライズ業務がテキスト回答で終わることはほとんどないためだ。ITサービスエージェントは、インシデントを調査し、権限を確認し、レコードを更新し、監査証跡を維持する必要があるかもしれない。流暢な応答だけでは、こうしたアクションが正しく実行された証明にはならない。

AutoSynthDataのリリースでは、2つの生成段階が説明されている。target段階では、特定された能力ギャップを中心に、コアとなる例を作成・検証する。multiply段階では、採用済みtargetサンプルから新しいバリエーションを生成する。

各バリエーションには、独自の要求、エンティティ、初期状態、参照軌跡、検証器が付与される。multiplyされたサンプルは、別のmultiplyサンプルのシードにはできない。この制限は、複数世代にわたる合成的な拡張が、検証済みの中核から逸脱することを防ぐために設けられている。

このパイプラインは、中央の生成制御と環境固有の実行を分離している。コントローラーはカバレッジ、品質チェック、データセット構築を管理する。アダプターはツールを実行し、状態を管理し、参照解を再生し、エージェントを評価し、決定論的な検証を適用する。

この分離により、この手法は単一のベンチマークを超える道筋を得る。企業は理論上、共有コントローラーを維持しつつ、自社システム向けのアダプターを作成できる。ただし、新しいアダプターにはそれぞれ、正確なツール、現実的な状態遷移、信頼できる成功基準が必要になる。

したがって、このニュースの要点は、ServiceNowが単に合成タスクを生成したということではない。同社は、現在のモデルの弱点に応じてタスクを選ぶプロセスを構築した。その後、弱点の変化に合わせて学習目標を移動させる。

この適応ループは、静的なデータセット開発に異議を唱える。モデルがその大半を解けるようになれば、固定コレクションの価値は低下する。AutoSynthDataは代わりに、例がなお難しい一方で学習可能でもある、モデルの現在の能力境界付近を探索する。

この考え方は、評価での失敗が何を意味するかも変える。単なるスコアやバグ報告になるのではなく、失敗はポストトレーニングの原材料になる。同じ環境で弱点を診断し、標的を絞った練習を生成し、更新済みモデルをテストできる。

このループこそが、AutoSynthData: エンタープライズエージェント向けトレーニングデータ生成の中心的な主張である。ServiceNowは、これが無関係なエンタープライズ環境全体で機能することをまだ示していない。それでも、無差別な合成データのスケーリングに代わる具体的な選択肢を提示した。

静的なエージェントデータセットは今、動く標的に直面している

AutoSynthDataは、各サンプルが不足している能力を教えているかを測定せず、幅広いトレーニングデータを集めるチームに圧力をかける。

エンタープライズエージェント開発者は、難しいデータ問題を抱えている。本番レコードには有用なワークフローパターンが含まれるが、個人情報、機密性の高い事業データ、一貫しない結果も含まれ得る。人手で作成したタスクはプライバシー上の懸念を一部避けられるが、十分に多様で検証可能な例を作るにはコストがかかる。

合成データは規模を提供するが、規模だけで適切な学習課題を選べるわけではない。すでにパスワードリセット要求を処理できるモデルは、類似例を何千件も与えられても得るものが少ない。必要なのは、ポリシーチェック、複数システムにまたがる計画、安全な拒否など、未解決の問題を明らかにするタスクだ。

EnterpriseOps Gymは、ServiceNowの実験に用いられた統制環境を提供する。ベンチマーク論文では、エージェントがツールをまたいで推論し、基盤システムを正しい状態にしなければならないステートフルなタスクが説明されている。これは、最終的なテキスト応答だけを採点するベンチマークとは異なる。

ServiceNowはEnterpriseOps Gymについて、8つの業務ドメインをカバーすると説明している。関連する環境には、512の機能ツールと164の相互接続されたデータベーステーブルが含まれる。これらのリソースは、ITサービス管理、カスタマーサービス、人事などの領域にまたがるワークフローを支える。

ServiceNowによれば、このより広いベンチマークには1,150件のエンタープライズタスクが含まれる。接続されたシステム間での計画、ポリシー準拠、状態変更をテストする。公開データセットにより、外部研究者もベンチマーク資料にアクセスできる。

これらの数値は、なぜ標的を絞った生成が重要なのかを示している。単一のワークフローに複数のツール、レコード、ポリシー、依存関係が組み合わさることがある。初期状態の小さな変化が、有効な手順や、要求されたアクションをそもそも実行すべきかどうかを変え得る。

ServiceNowは以前、専門家によるタスク計画の提供が、難易度の高いエンタープライズドメインでの性能を15%から35%向上させたと報告している。この知見は、エージェントが個々のツールを正しく呼び出せる場合でも、計画が依然として大きな制約であることを示唆する。AutoSynthDataは、このような計画上のギャップを繰り返しの学習機会に変換しようとしている。

最初に圧力を受けるのは、静的評価を担うチームだ。固定テストセットは弱点を特定できるが、それに対処するカリキュラムを自動的に作成するわけではない。研究者は依然として、失敗を多様な例、有効な解、信頼できる採点ロジックへと変換しなければならない。

2つ目の圧力は、汎用モデルの提供者に及ぶ。強いベンチマーク平均は、ローカルポリシー、テーブル構造、ワークフロールールによる失敗を隠し得る。企業が必要とするのは、システムについて質問に答えるだけでなく、自社固有のシステム内でモデルが動作できることを示す証拠だ。

3つ目の圧力は、エージェントプラットフォームを構築する企業に及ぶ。適応型トレーニングが有用と証明されれば、評価インフラは最終的な品質ゲートではなく、モデル開発の一部になる。プラットフォームには、再現可能な環境、タスク生成、実行ログ、状態ベースの検証が必要となる。

この要件は、運用シミュレーターやデジタルツインを持つ組織に有利に働く。Salesforceは、シミュレーションされたエンタープライズ環境を用いて業務ワークフロー上のエージェントを評価するCRMArena-Proで、関連する方向性を追求している。この重なりは、実行可能で環境に根ざしたエージェントテストへの広範な移行を示している。

ただし、両者の道筋は同一ではない。ベンチマークはモデルを変更せずに比較できる一方、AutoSynthDataはベンチマークでの失敗を使ってポストトレーニング用データを生成する。一方は能力を測定し、もう一方は能力を動かそうとする。

この違いは企業の購入者にとって重要だ。リーダーボードは、明示された条件下で最も強いモデルを特定する。適応型カリキュラムは、より安価または小規模な対象モデルが、組織固有の反復的なタスクで改善できるかを問う。

ServiceNowが報告した結果は、その可能性を具体的に示すが、決着したものではない。対象モデルは学習後も、ITサービスのタスクを少数しか完了できなかった。ベースラインより優れていることは、監督なしの本番アクセスに対応できることを意味しない。

ナレッジの品質も、引き続き実務上の制約となる。エージェントは、欠落している、矛盾している、またはアクセスできないポリシーには従えない。検索可能なナレッジベースを構築するチームは、生成された学習タスクが実際の業務を反映できるようになる前に、明確なソース資料を用意する必要がある。

したがってAutoSynthDataは、ボトルネックをなくすのではなく、移し替える。チームに必要な手作業によるバリエーション作成は減るが、信頼できる環境と正確な検証が必要になる。この交換条件は、エージェントが顧客、従業員、またはインフラのレコードを変更できる場合に決定的となる。

この仕組みは実行可能なタスクと厳格な検証器に依存する

AutoSynthDataが機能するのは、生成された要求、参照解、検証器が成功の意味について一致している場合に限られる。

このパイプラインは、対象モデルとより強力な教師モデルを分けるタスクの特定から始まる。報告された構成では、ServiceNowは、対象モデルが3回の試行で多くても1回しか解けない候補を優先する。より強力なソルバーは、3回の試行で少なくとも2回完了しなければならない。

このフィルターは、有用な難易度帯を狙う。両モデルを打ち負かすタスクでは、信頼できる実演が得られない。両方が一貫して解けるタスクは、明確な弱点を狙わずに学習容量を消費する。

候補がパイプラインに入ると、AutoSynthDataは参照軌跡を実行する。軌跡とは、要求された状態に到達するために用いられるツール呼び出しとアクションの連続である。検証器は次に、タスクの成功条件に照らして結果を検査する。

この肯定的なチェックは、意図した解決策が実際に機能するかを問う。無効な初期状態、利用できないツール、壊れたアクション手順、要求と検証器の不整合を明らかにできる。もっともらしく見える例であっても、実行に耐えられなければ失格となる。

パイプラインはネガティブ検証も実施する。期待される結果を意図的に変異させ、不正な状態が合格しないことを確認する。この工程は重要だ。弱い検証器では、必要な行動を省略したり重要な制約に違反したりするエージェントを高く評価してしまう可能性がある。

影響を受けた従業員との解決確認後にのみITインシデントをクローズするよう求めるケースを考えてみよう。インシデントのステータスだけを確認する検証器では、安全性を欠く近道を許容してしまう。より強力な検証器なら、確認記録と必須の注記も求めるはずだ。

複数の解決策が有効な場合にも、同じ問題が生じる。検証器は、唯一の正確な参照手順を要求することなく、許容される結果を認識すべきである。ServiceNowはこれを、リクエストとの整合性や不正な挙動を適切に拒否することと並ぶ「完全性」と位置付けている。

これらの要件は難しい均衡を生む。過度に寛容な検証器は不完全な作業を評価し、過度に狭い検証器は正当な戦略を罰し、モデルに恣意的な手順の模倣を学習させる。

失敗した候補は、回数を制限した批評・修復ループに入る。批評器はタスク構成、初期状態、解決策、検証ロジックを調べる。システムは対象を絞った修正を適用し、関連するゲートを再実行したうえで、改訂候補を受け入れるか拒否する。

既存候補を修復すれば、有用な作業を保持できる。また、1つのコンポーネントに修正可能な欠陥があるたびに生成を最初からやり直す必要もなくなる。再試行の上限は、成果の少ないタスク群に無制限のリソースを費やすことを防ぐ。

続いてAutoSynthDataは、バッチ全体の品質をレビューする。個別には有効な例でも、データセット全体としては反復的になり得る。生成器は、ポリシー、ツール、システム状態の難しい組み合わせを見落としながら、よくあるワークフローを過剰に生成するかもしれない。

コントローラーは、受理・却下されたサンプル、反復パターン、能力カバレッジ、繰り返し現れる批評結果を追跡する。過剰に代表されている領域での生成を抑え、ギャップへと労力を振り向ける。これにより、個々のタスクを超えるレベルのフィードバックが生まれる。

target段階とmultiply段階は、この戦略を支える。targetサンプルは、特定の能力ギャップを中心に検証済みのタスク群を確立する。multiplyサンプルは、先行するバリアントを再帰的に拡張せず、表現、エンティティ、ツールの組み合わせ、環境状態を変化させる。

この設計は、合成データに共通する1つのリスクを低減する。再帰的な生成では、新しいサンプルが別の生成済みサンプルの仮定を継承するたび、小さな誤りが増幅される可能性がある。すべてのバリアントを精査済みのtarget例に固定することで、その連鎖を抑えられる。

このアプローチは、企業にとってより説明可能な監査証跡ももたらす。各トレーニング例は、初期状態、意図したアクション手順、検証器、検証結果と関連付けられる。実行可能な文脈のないプロンプトを集めたフォルダより、はるかに有用だ。

ただし、決定論的なチェックでは、意味のある品質のすべての側面を符号化できない。エージェントが途中で機密情報を露出していても、最終的なデータベース状態は正しく見えるかもしれない。別の軌跡では、期待される状態を復元する前に不要な変更を加える可能性もある。

実行ログとポリシーを意識したチェックは依然として必要である。ServiceNow自身のagent evaluationツールは、データセット、実行記録、複数の品質次元を重視している。AutoSynthDataは、この考え方をトレーニングデータの生成へと拡張する。

この仕組みは教師モデルにも依存する。より強力なモデルは成功した行動を実演できるが、その行動は利用可能なツールとコード化されたポリシーを依然として反映する。危険な近道を選ぶ教師は、その挙動を教師ありファインチューニングへ伝播させる可能性がある。

ここでガバナンスの問題が生じる。企業は、誰が有効な行動を定義するのか、環境がどのポリシーを実装するのか、検証器の変更をどのようにレビューするのかを把握する必要がある。そうでなければ、自動生成は気付かれない仕様の誤りを大規模に拡散しかねない。

AutoSynthData: Generating Training Data for Enterprise Agentsは、実行可能なデータを支持する論拠として最も強い。生成器には注目が集まるが、システムの信頼性の大部分を担うのは環境と検証器である。それらがなければ、合成タスクは証明済みのトレーニング例ではなく、もっともらしい物語にとどまる。

報告された改善は意味があるが、依然として限定的

ServiceNowは明確なベンチマーク改善を報告しているものの、実験は本番環境での信頼性や広範な転移を実証していない。

最初の実験では、EnterpriseOps GymのHybridドメインにおいてGemma-4-26B-A4B-itを対象モデルとして使用した。教師モデルはQwen3.8-27Bだった。AutoSynthDataは約18時間で2,000件の合成トレーニング例を生成した。

ServiceNowは、成功例を模倣するようモデルを学習させる教師ありファインチューニングでGemmaをファインチューニングした。報告された最良のチェックポイントは第5エポックのものだった。エポックは、トレーニングデータセット全体を1回通過することを表す。

同社によると、平均Pass@1は7.2ポイント改善した。ServiceNowはこの変化を35%の相対的改善と位置付けている。検証器の成功率も63.01%から68.55%へ上昇した。

同社によれば、得られたチェックポイントはGemmaと参照モデルの間にあった元のPass@1ギャップの59%を埋めた。これらの結果は、対象を絞った合成例が複数の測定値に影響したことを示している。一方で、テスト環境の外でモデルがどのように振る舞ったかは明らかにしていない。

第2の実験はITサービス管理に焦点を当てた。ここでも対象はGemma-4-26B-A4B-itで、教師にはDeepSeek-V4.1-Flashを使用した。パイプラインは66時間にわたり、1,994件の受理済みサンプルを生成した。

ITSM評価では、平均Pass@1が18.77%から27.18%に上昇した。これは8.41ポイントの増加である。ただし、ベンチマークの採点方法では、訓練済みモデルが依然として初回試行の大半に失敗していることも意味する。

この残るギャップは重要な文脈である。この実験は、対象を絞った合成ファインチューニングがモデルを改善し得るという主張を支持する。しかし、得られたエージェントが業務システムで独立して稼働する準備ができているという主張までは支持しない。

ServiceNowによると、Hybrid生成器には元の評価プロンプト、エンティティ、軌跡、検証器の詳細は一切与えられなかった。代わりに、評価時の挙動から抽出した能力仕様が与えられた。この分離により、テストセット汚染の明白な形態の1つは低減される。

しかし、カリキュラムは依然としてEnterpriseOps Gym内で観察された失敗から導かれている。したがって、トレーニングと評価は環境、ツール構造、一般的なタスク分布を共有していた。その環境内での改善は、無関係なソフトウェアや企業独自の構成への転移を示すものではない。

報告された数値も、システムを設計したチームによるものである。独立した再現実験が結果を強めるだろう。研究者がパイプラインを再現するには、十分なコード、生成設定、受理済みサンプル、評価の詳細が必要になる。

Artificial Analysisは現在、EnterpriseOps Gymに基づく独立したリーダーボードを運営している。その評価も、状態を持つ複数ステップの作業と最終的なデータベース条件を重視している。この外部ハーネスは、訓練済みチェックポイントをより独立してテストする場の候補となる。

環境をまたぐ評価は、さらに多くの情報をもたらす。あるITSM構成で訓練されたモデルを、変更されたポリシー、名称変更されたツール、変更後のスキーマ、未知のレコード分布に対してテストできる。そのような変化下での性能は、モデルが能力を学習したのか、環境パターンを記憶したのかを示すだろう。

安全性についても別途測定が必要だ。ServiceNowは以前、利用できないリソース、欠落した権限、ポリシー違反を伴う30件の実行不可能なベンチマークタスクを説明していた。報告によれば、同社がテストした最も強力なモデルでも、その約半分しか実行不可能と認識できなかった。

AutoSynthDataはこうした失敗を対象にできるが、現在のリリースでは専用の安全な棄権に関する結果は示されていない。モデルが拒否すべき場面でも行動しやすくなるなら、タスク完了率の改善は新たなリスクを生む可能性がある。

教師と対象モデルの関係も精査に値する。Hybrid実験では比較的近いモデル規模の組み合わせが使われた一方、ITSMの実行でははるかに大きい教師モデルが使われた。生成時間には大きな差があり、その一因はServiceNowによれば、先行するITSM実行がスループット最適化の前に行われたためだという。

こうした違いにより、直接比較は難しくなる。2つのドメインでは教師、処理時間、そしておそらく能力分布も異なっていた。この証拠が示すのは2つの設定にわたる再現可能性であり、システムの各コンポーネントを統制して比較した研究ではない。

アブレーション研究がないことも解釈を制限する。公開結果では、失敗ターゲティング、教師による実演、検証器によるフィルタリング、タスクの増殖、バッチレベルのバランシングのうち、どれがどの程度の改善をもたらしたのかを切り分けていない。各コンポーネントはもっともらしく聞こえるが、それぞれの寄与は依然として不明確である。

商業的な数値を付さなくとも、コストとリソース使用量も未解決の問題である。数千のタスクを生成するには、繰り返しのモデル呼び出し、環境実行、ソルバー試行、批評、修復、検証が必要になる。受理済みデータセットは出力だけを表しており、試行された作業量の総計ではない。

企業はこの作業量を代替手段と比較しなければならない。人間が作成した例はより遅いかもしれないが、レビューは容易である。検索やオーケストレーションの変更によって、モデルの重みを更新せずに一部の失敗を修正できる可能性もある。

ワークフローが失敗するのは、モデルに推論能力がないからではなく、知識が不完全だからという場合もある。より良いknowledge blendingは、一部のギャップにより直接的に対処できるかもしれない。トレーニングが、エージェント実行の失敗すべてに対するデフォルトの対応になってはならない。

慎重に読めば、それでも有望である。AutoSynthDataは、観察された弱点に基づいて選択されたタスクから、測定可能な改善を生み出した。適応的な合成カリキュラムがより安全な本番エージェントへ一般化するという、より強い主張は依然として実証されていない。

AutoSynthDataがベンチマークを超えて重要かを決める3つのシグナル

次に必要な証拠は、元の環境内でのさらなる高スコアだけでなく、再現性、転移性、より安全な挙動を示すものだ。

最初のシグナルは、独立して再現可能なリリースである。ServiceNowはEnterpriseOps Gymの資料を公開しているが、研究者にはAutoSynthDataの実装と完全な実験レシピが必要だ。そのパッケージには、能力カードの構築、生成設定、検証器テスト、却下基準、チェックポイント評価を含めるべきである。

独立したチームは、同じ診断上の失敗から比較可能なデータセットを再生成できるべきだ。複数の実行で同様の改善が見られれば、都合のよいサンプリングへの懸念は薄れる。却下されたタスクの統計を公開すれば、最終データセットにどの程度のフィルタリングが必要だったかも明らかになる。

このシグナルの最も強い形には、アブレーションが含まれる。研究者はネガティブ検証、バッチバランシング、増殖、失敗ターゲティングを、一度に1つずつ取り除ける。その結果生じる性能差は、どのメカニズムが改善を生むのかを特定するだろう。

独立した再現に成功すれば、ServiceNowの中心的な技術的主張は強化される。改善幅が実行ごとに大きく変動するなら、パイプラインが生成器、教師、選択に依然として敏感であることを示すだろう。

第2のシグナルは、環境をまたぐ転移である。訓練済みモデルは、基礎となる能力は維持しながら、ツール、エンティティ、ポリシー、スキーマが変化したワークフローに直面すべきだ。そのテストは、一般的な学習とEnterpriseOps Gymの構造への慣れを区別する。

有用な実験としては、あるITSM環境で訓練し、追加のファインチューニングなしで別の環境で評価する方法が考えられる。別の実験では、単一ドメインのワークフローから、顧客、従業員、資産のデータを必要とするクロスドメインのタスクへ移行できる。

企業は、ServiceNow向けシステム以外のアダプターにも注目すべきだ。AutoSynthDataのコントローラー・アダプター・アーキテクチャは移植性を示唆しているが、ソフトウェア設計だけで実運用上の互換性が保証されるわけではない。新しい環境ごとに、実行可能なアクションと信頼できる検証が必要となる。

クロスプラットフォームでの成功が確認されれば、この手法ははるかに広いエージェント市場にとって意味を持つ。移行性が低ければ、その役割は厳密に定義された環境向けの効率的なカスタマイズ・パイプラインに限定されるだろう。

3つ目のシグナルは、拒否とポリシー遵守を損なうことなくタスク完了率が向上するかどうかだ。エンタープライズ向けエージェントは、行動すべきでない場面を理解しなければならない。権限が不足している場合や指示が矛盾している場合でも自信を持って実行するよう学習が促されるなら、Pass@1スコアの向上だけでは不十分である。

今後の評価では、実行不可能なタスクの検出、未許可の状態変更、ポリシー違反、不必要なツール呼び出しを報告すべきだ。また、最終的なデータベースの状態だけでなく、中間アクションも調査する必要がある。最終状態が復元されていても、安全でない一連の操作が隠れている可能性がある。

影響の大きいワークフローでは、人によるレビューが依然として重要だ。レビュアーは、従業員記録、アクセス制御、顧客の利用権限、セキュリティインシデント、取り消し不能な変更に関わるサンプルを精査すべきである。自動検証器はこのプロセスを支援できるが、説明責任を伴う監督なしにポリシーを定義すべきではない。

したがって、今後1〜3か月で、実行可能なパイプラインコード、環境横断テスト、安全性に特化した結果という、3つの具体的な証拠が示されることが期待される。それぞれが、今回のリリースに残る異なる不確実性に答えるものとなる。

AutoSynthData: Generating Training Data for Enterprise Agentsは、評価での失敗を的を絞った訓練へと変換するための、信頼に足る仕組みを提示している。報告された改善は、特に実行可能なワークフロー環境を持つチームにとって、このアイデアが注目に値することを示している。

より大きな判断は、いまやエンタープライズAIの開発者たちに委ねられている。自らのエージェントの失敗を、再現可能な状態、有効な軌跡、検証可能な結果として表現できるかを問うべきだ。そうでなければ、タスクを増やしても曖昧さを拡大するだけになる。

こうした基盤が存在するなら、適応型カリキュラムは評価を大幅に有用なものにできる。何が失敗したのかを示し、焦点を絞った訓練を生成し、同じ弱点が残っているかを測定できる。次に必要な証明は、このループが、それを生み出した環境の外でも機能し続けることを示すことだ。