BarndoorによるDiaphora買収、ガバナンスを備えたAIワークフローの実力を問う
Barndoorは9月16日、Diaphoraを買収した。両社は、未解決の本番運用上の課題を抱えながらも、エンタープライズAIに対する2つのアプローチを統合する。BarndoorによるDiaphora買収は、Diaphoraの制約付きワークフローエンジンと、Barndoorのアクセス、ポリシー、監査制御を組み合わせるものだ。取引金額は公表されていない。
この取引が重要なのは、BarndoorがAIシステムと企業ツールの接続を統制する役割を超えようとしているためだ。現在は、それらの接続の上に構築されるビジネスプロセスの実行も統制しようとしている。これにより、同社の役割はセキュリティの検問所からワークフロープラットフォームへと拡張される。
対立点は、柔軟なエージェントと予測可能な自動化の間にある。エージェントは状況の変化に応じて計画を調整できるが、その自由度は行動のテストを難しくする。従来のワークフローエンジンは一貫して動作する一方、解釈や判断を要する業務への対応には苦労する。
Barndoorは、Diaphoraの技術が両モデルの橋渡しになると考えている。同社が提案するBlueprintsは、固定されたワークフローステップを定義しつつ、大規模言語モデルによる判断を指定された箇所に限定する。このアプローチは、制約のないエージェントループよりも、決定論的なワークフローシステムに近い。
このアーキテクチャは、セキュリティを重視する企業に適しているように見える。しかし両社は、本番ベンチマーク、導入件数、独立した信頼性測定を公表していない。したがって今回の買収は明確な技術的賭けではあるものの、運用面での成果はまだ証明されていない。
BarndoorによるDiaphora買収が変えるもの
Barndoorは単に別のセキュリティ機能を追加するのではなく、実行レイヤーを取得する。
ニューヨーク拠点のBarndoorは、9月16日の取引発表を通じて買収を発表した。Diaphoraのチーム全員がBarndoorに加わり、両社はこの取引を「spin-in」と説明している。
Diaphoraは、Simone Pezzanoが開発した独立プロジェクトとして始まった。その後、Jay Parisiがこの技術で協力し、BarndoorのCEOであるOren Michelsがアドバイザーとなった。この既存の関係により、両チームは競争的な売却後に初めて顔を合わせたわけではないため、統合リスクの一部は軽減される。
買収の中心となるのは、AIワークフローを構築するためのオープンソースランタイム、Fragsだ。ランタイムとは、定義されたプログラムやワークフローを実行するソフトウェアレイヤーを指す。FragsはFrags Modeling Language、すなわちFMLを用いて、モデル、ツール、構造化ステップをどこに配置するかを指定する。
FMLはドメイン固有言語であり、汎用プログラミング言語としてではなく、限定された種類のタスクを記述する。その公開言語ドキュメントでは、構造化出力、依存セッション、スキーマ、ツール、MCP接続のサポートが説明されている。
MCP（Model Context Protocol）は、AIアプリケーションを外部ツールやデータに接続する標準的な方法を提供する。標準化された接続は統合を簡素化するが、同時に権限管理、監視、ポリシー適用の対象範囲も広げる。
Barndoorはすでに、AIクライアントと接続先リソースの間に位置する存在として自社を位置付けている。同社によれば、各リクエストは認証され、ポリシーに照らして検証され、機密データのスキャン、計測、ログ記録を受けられる。Diaphoraは、アクセスが許可された後に何を実行すべきかを定義する仕組みを加える。
計画中の統合製品では、再利用可能なワークフローをBlueprintsと呼ぶ。各Blueprintは、明示的な一連のステップを通じてツールとデータを接続する。モデルが選択された判断を担い、あらかじめ定められたロジックが残りの実行を制御する。
この違いは運用ワークフローにおいて重要だ。モデルに「この請求問題を解決して」と求めれば、広い解釈の自由を与えることになる。一方でBlueprintは、取得するレコード、検証する条件、モデルによる判断を必要とするアクションを定義できる。
Barndoorによれば、Blueprintは必須ステップを完了できない場合に停止するべきだという。もっともらしい代替案をでっち上げるのではなく、問題を特定すべきだとしている。この挙動は、顧客が多様な本番ワークロードにわたる証拠を公表するまで、企業側の主張にとどまる。
Barndoorによれば、基盤となるFragsランタイムとFMLはオープンソースのまま維持される。そのため開発者は、実行技術を検査、拡張、貢献し続けられるはずだ。
ただし、コードが公開されているからといって、導入済みワークフローが自動的に安全になるわけではない。企業は依然として、構成、認証情報、依存関係、モデルの振る舞い、接続先システムを取り巻くポリシーを精査しなければならない。それでも、完全にクローズドなランタイムと比べれば、ワークフローエンジンをより詳細に検査できる。
買収はBarndoorの商業的な立ち位置も変える。同社は、既存エージェントの統制を求めるセキュリティチームだけでなく、AI自動化を構築する必要があるチームにも提案できるようになる。これは大きな実装負担を伴う一方で、より大きな機会を生み出す。
ガバナンスがワークフロー実行へ移る理由
モデルが単にテキストを生成するのではなく、レコードを変更できるようになると、エンタープライズAIガバナンスの重要性は増す。
回答を下書きするチャットボットは、レビューの問題を生む。顧客レコードを更新するエージェントは、認可の問題を生む。後者のシステムには、アイデンティティ、ツール、データ、アクション、支出をめぐる境界が必要だ。
この違いは、なぜ今BarndoorによるDiaphora買収が行われるのかを説明する。企業は数年にわたり、アシスタントや限定的なデモを通じて生成AIを試してきた。現在、多くの企業は、こうしたシステムにアプリケーション横断の複数ステップ業務を実行させたいと考えている。
Barndoorの当初の製品は、モデルとMCPサーバーに関するアクセスおよび可視性を対象としていた。同社の公開ローンチは、2025年5月に報じられた1,360万ドルのシードラウンドに続くものだった。この資金調達はCrosslink Capitalが主導した。
ゲートウェイは、エージェントがツールを呼び出してよいかを判断できる。また、リクエストをログに記録し、データポリシーを適用することもできる。しかし、これらの制御が、全体のシーケンスが承認済みのビジネスプロセスを表しているかどうかまで決定するとは限らない。
顧客との通話後に行う営業ワークフローを考えてみよう。このプロセスでは、会話の要約、アカウントの更新、フォローアップの設定、社内チームへの通知が行われる可能性がある。個々のアクションはすべて許可されていても、シーケンス全体にはなお誤りが含まれ得る。
要約が誤ったアカウントに紐付けられるかもしれない。推定された日付が誤ったコミットメントを生むかもしれない。通知によって、より広いチャネルに機密情報が公開される恐れもある。したがってガバナンスは、アクセスだけでなく実行ロジックも対象にしなければならない。
この必要性は、確立されたリスクガイダンスとも一致する。米国国立標準技術研究所のAIリスクフレームワークは、導入済みAIシステムの管理においてガバナンスを継続的な要素として扱っている。また、AIシステムが支援するタスクを定義することも強調している。
自律エージェントが実行中に経路を発明する場合、このタスクレベルの焦点を保つことはより難しくなる。安定したワークフロー定義を検査し、権限を制約し、例外をレビューできる場合には、より管理しやすくなる。
Diaphoraのアーキテクチャは、判断と実行を分離しようとしている。モデルが限定された判断を担い、従来型のロジックが既知のステップを処理する。このハイブリッド設計は、すべてのアクションを新たなモデル選択に変えることなく、ある程度の柔軟性を維持する。
このアプローチは、責任分担も明確にする。ビジネスチームは望ましいプロセスを定義し、開発者は技術計画を検査し、セキュリティチームはアクセスを制御できる。その後、監査担当者は同じワークフロー定義に紐付いた記録を確認できる。
Barndoorによれば、従業員は自らの役割で認可されたBlueprintのみを見つけて実行できる。また同社は、自動化がツール、モデル、データに関する制御を継承するとしている。これにより、各従業員に対して各基盤システムへの権限を個別に付与する必要を避けられる可能性がある。
この配布モデルは戦略的に重要だ。1つの自動化を動作させることと、それを組織全体に安全に配布することは異なる。広範な配布は、ユーザー、認証情報、データ経路、例外、潜在的なミスの数を増幅させる。
Barndoorの顧客であるSyndioは、発表における主な裏付けとなる見解を示した。CTOのNimrod Veredは、予測可能な実行と可視性が、同社によるワークフローのより広範な導入に役立つと述べた。この発言は顧客の関心を示すものだが、独立した性能調査ではない。
したがって買収により、Barndoorが直面する問いは変化する。同社は個々のリクエストをブロックまたは記録できることだけを示せばよいわけではない。ガバナンスを備えたワークフローが、エンタープライズ規模で使いやすく、信頼性が高く、保守可能であり続けることを示さなければならない。
Blueprintsはエージェントの自由度を予測可能な制御と引き換えにする
統合アーキテクチャは、反復可能なビジネスプロセスにおいて無制限の自律性を負債として扱う。
Diaphoraの中心的な考えは、大規模言語モデルを排除することではない。モデルが判断できる場所を制限することだ。この境界によって、Blueprintはすべてのステップを動的に選択するエージェントと区別される。
Michelsは、計画と、定義された成果への経路を対比することでこの違いを要約した。彼の主張は、多くのエージェントシステムが意図された計画から始まる一方、Blueprintは実際に実行されるステップを確立するというものだ。
これは今回の買収における主要な技術的仕組みである。ワークフローは、顧客課題の分類のように解釈が価値を持つ箇所でモデルを呼び出せる。一方、必須フィールドの確認のように一貫性が重要な箇所では、決定論的なコードを使える。
結果として生まれるシステムは、従来型のロボティック・プロセス・オートメーションでも、完全自律型のエージェントでもない。確率的な構成要素を含む構造化ワークフローである。確率的とは、類似した入力に対してもモデルが異なる出力を生成し得ることを意味する。
発表内の一例は、請求ミスの修正に関するものだ。典型的なアシスタントは問題を特定し、従業員向けに推奨事項の下書きを作成するかもしれない。Blueprintなら、関連データを取得し、条件を検証し、認可された修正を登録できる。
この例はリスクも示している。請求アクションは、売上、顧客の信頼、財務記録に影響を及ぼし得る。信頼できるシステムには、変更を書き込む前に説得力のあるモデル応答以上のものが必要だ。
ワークフローは、識別子、金額、ポリシー条件、認可を検証すべきだ。また、影響が正当化する場合には承認の境界も設けるべきである。Barndoorはこの例について、詳細なリファレンス実装をまだ公表していない。
別のシナリオには、四半期ごとの顧客健全性レビューがある。このワークフローでは、契約、利用データ、サポート履歴、請求情報を、個別に制御された4つのシステムから取得する可能性がある。
レビューを実行する従業員は、すべての情報源への直接アクセスを必要としないかもしれない。その代わりに、認可されたワークフローが、その特定の目的のために許可された情報を取得できる。この設計は、システム横断の分析を支えつつ、広範な認証情報の使用を制限する。
こうしたワークフローには、慎重な出力制御も必要となる。最終的な健全性評価を閲覧できる権限を持つユーザーが、基礎となるすべてのレコードを閲覧する権限まで自動的に持つわけではない。システムは、取得、推論、提示の全過程を通じて、こうした区別を維持しなければならない。
Barndoorによれば、ロールベースのアクセス制御により、各従業員が発見・実行できるBlueprintを管理する。また、自動化がアクセスしたもの、変更したもの、発生したコストを示す記録を提供すると約束している。
これらの記録は、チームがインシデントを調査し、導入状況を監視するうえで役立つ可能性がある。その有用性は、記録の詳細度、保持期間、エクスポート機能、既存のセキュリティシステムとの統合に左右される。成功したツール呼び出しだけを記録するログでは、重要な推論上の失敗を見逃すことになる。
このアーキテクチャは、バージョニングに関する課題も提起する。ワークフロー、モデル、プロンプト、接続先アプリケーションのスキーマはいずれも変化する。チームが再現可能な調査を行いたいなら、実行記録には関係する正確なバージョンを特定できる情報が必要だ。
モデルの更新は特に難しい問題となる。固定された Blueprint はモデルが動作する範囲を制約できるが、時間が経っても同一のモデル出力を保証することはできない。チームには依然として、すべての判断ポイントに対する評価が必要となる。
Frags はこうした呼び出しに構造を与えられるかもしれないが、構造があることは意味的な正確さと同義ではない。モデルは必要なスキーマに準拠した有効なデータを返しながら、誤った分類を選ぶことがある。
Barndoor の賭けは、周囲のプロセスが制御された状態に保たれるなら、企業は境界づけられた不確実性を受け入れるというものだ。これは、生成モデルに完全な決定性を約束させるより現実的である。
同時に、これは業界全体で推進される広範なエージェント像よりも制約が強い。オープンエンドなエージェントは、タスクを通じた新しい経路を発見できる。Blueprint は、その適応性の一部を犠牲にして、導入を理解しやすく統制しやすいものにする。
反復的なエンタープライズ業務において、このトレードオフは妥当になり得る。プロセスが顧客、従業員、または財務の記録を変更する場合、組織は通常、新規性よりも一貫した実行を重視する。
より難しい問いは、エッジケースに関するものだ。厳しく制約されたワークフローは、現実の状況が設計から逸脱すると頻繁に停止する可能性がある。制約の緩いワークフローは継続できるかもしれないが、リスクはより大きくなる。
本番環境の証拠は、Barndoor がその境界をどこに設定するかを示さなければならない。最良の設計は、自由度か硬直性のどちらかを最大化するものではない。それぞれの種類の判断を、最も適した仕組みに割り当てるものである。
真の競合相手は無制限のエージェント自律性
Barndoor が競合しているのは、より優れたモデルならワークフロー全体を安全に計画・実行できるというアーキテクチャ上の前提である。
エンタープライズ自動化市場には、既存のワークフロー製品、新しいエージェントフレームワーク、統合プラットフォーム、クラウドスイートが含まれる。それぞれのカテゴリは、制御に関する異なる前提から同じ問題に取り組んでいる。
従来型のワークフローエンジンは、定義済みのプロセスから始まる。開発者は遷移、エラー処理、リトライ、権限を指定する。このアプローチはテストと監査を支える一方、誰かがプロセスをモデル化しなければならない。
エージェントフレームワークは、多くの場合、目標から始まる。モデルは利用可能なコンテキストを用いてツールを選択し、次のアクションを決定する。これは構造化されていない業務にも対応できるが、実行経路の予測は難しくなる。
Temporal は、この分断における従来型の側面を示している。同社のagent architectureでは、非決定的な入力と出力を決定的なワークフローコードの外部に置く。この分離は、ワークフロー履歴をリプレイできるため、リカバリーを支える。
Barndoor と Diaphora は、製品設計と対象ユーザーこそ異なるものの、関連する原則に従っている。従来のロジックでより確実に実行できる手順を、モデルが制御すべきではない。
他のプラットフォームは、エージェントのオーケストレーションにトレース、評価、ポリシー制御を組み合わせている。これらの製品は、より広範な開発エコシステムや、より深い統合を提供する場合がある。Barndoor の差別化は、ワークフロー定義と中央集権的なガバナンスを結び付けられるかにかかっている。
このポジショニングは、二つのグループに圧力をかける。ガバナンスベンダーは、アクセス制御だけで十分な価値を提供できるかを判断しなければならない。ワークフローベンダーは、従来型のオーケストレーションが専用言語なしでモデルの判断を取り込めるかを判断する必要がある。
この買収により、Barndoor は一つのプラットフォームから両方の問いに対応できる。顧客は Blueprint を作成し、統制された MCP ツールとして公開し、ロール別に配布し、同じ制御レイヤーを通じて実行を監視できる。
この統合された経路は、別々の製品間で必要な調整を減らせる可能性がある。一方で、プラットフォームへの依存度を高める可能性もある。顧客は、ワークフロー定義が移植可能か、また Frags が Barndoor の商用サービスの外でも有用であり続けるかを評価する必要がある。
オープンソースへのコミットメントはこの懸念への対応に役立つが、その持続性が重要だ。購入者は、リポジトリの活動状況、ライセンス変更、外部コントリビューター、リリース頻度、独立したインフラとの互換性を注視すべきである。
オープンソースは、技術的な検証への道も開く。セキュリティチームはワークフロープランがどのように解析・実行されるかを調査できる。研究者は、クローズドな製品では十分に注目されない可能性がある障害条件をテストできる。
しかし、ガバナンスレイヤーそのものに商業的価値の多くが含まれている。ワークフローランタイムがオープンであっても、ポリシー決定、ID統合、監視、データ損失防止、エンタープライズサポートは管理型の機能として維持できる。
このオープンコアのパターンは、インフラソフトウェアでは一般的だ。コミュニティは検査可能なエンジンを得る一方、企業は中央集権的な運用と制御を購入する。成功は、公開プロジェクトを弱体化させることなく、双方の価値を維持できるかにかかっている。
Barndoor は社内エンジニアリングとも競わなければならない。大企業はすでにワークフローエンジン、IDシステム、APIゲートウェイ、可観測性プラットフォームを利用している。既存のコンポーネントを組み合わせて、統制されたエージェントスタックを構築できる。
統合製品は、別のコントロールプレーンを導入するだけの価値があるほど、統合と保守の工数を削減しなければならない。また、企業が置き換えられないシステムと共存する必要もある。
そのため、相互運用性がこの取引の中心となる。ツール、スキーマ、MCP に対する FML のサポートは、有用な構成要素を提供する。それでも本番環境の購入者は、標準的なIDプロトコル、イベントシステム、承認サービス、既存のワークフローエンジンについて問うだろう。
したがって競争上の論点は、機能比較よりも大きい。企業は、ポリシーをどこに置くか、ワークフローをどこで定義するか、そしてモデルの判断をどこで実行に入れるかを選ばなければならない。
Barndoor の答えは、これらの境界を近接して配置するものだ。各エージェントフレームワークに独自の権限、ワークフローロジック、運用記録を定義させることへの直接的な代替案を提示している。
この買収がまだ証明していないこと
首尾一貫したアーキテクチャがあるからといって、製品がエンタープライズ規模、例外、敵対的な入力を扱えることにはならない。
この発表は、製品説明と顧客による補足コメントを提供している。買収価格、Diaphora の収益、導入件数、独立した利用指標は開示していない。
また、比較可能な信頼性ベンチマークも示していない。読者は、現実的な条件下で Blueprints がどの程度の頻度で正常完了し、安全に停止し、または誤った判断を下すのかを判断できない。
この証拠の欠如は、アーキテクチャを無効にするものではない。未検証のまま残る点を定義するものである。購入者は、製品が意図する挙動と測定された性能を分けて考えるべきだ。
最初の懸念は過剰なエージェンシー、すなわちシステムがタスクに必要な範囲を超える機能や権限を与えられることだ。OWASP guidanceは、ツール、権限、自律性を必要な水準に制限するよう推奨している。
Blueprints はこの原則を軸に設計されているように見える。しかし、明確に定義されたシーケンスにも、過度に強力なツールが含まれ得る。請求ワークフローは、手順が予測可能だからというだけで、無制限のデータベースアクセスを与えられるべきではない。
プロンプトインジェクションは別のリスクを生む。悪意ある指示は、文書、メッセージ、取得されたWebコンテンツの中に現れ得る。モデルはそのコンテンツをコマンドとして解釈し、意図しないアクションを試みる可能性がある。
決定的なワークフローは利用可能な経路を狭めるが、敵対的な入力を自動的に無力化するわけではない。システムは、すべてのモデル判断ポイントで、信頼できないコンテンツと認可された指示を区別しなければならない。
データ漏えいも依然として起こり得る。ワークフローは情報を正しく取得しながら、過剰なコンテキストをモデルに渡してしまう可能性がある。ログ、エラー報告、生成された出力に機密コンテンツを含める場合もある。
Barndoor は、情報がモデルまたはツールに届く前にデータ損失防止を適用できるとしている。顧客には、構造化レコード、添付ファイル、変換済みテキスト、複数のソースから組み立てられたコンテンツを対象とするテストが必要だ。
コスト制御も関連する課題となる。固定されたワークフローには、ループ、リトライ、反復的なモデル呼び出しが含まれ得る。そのため、予期しない入力は、各呼び出しが個別には認可済みであっても、過剰な支出を生み出しかねない。
チームは、最大呼び出し回数、トークン予算、タイムアウト、リトライ規則をテストすべきだ。また、一時的なアプリケーション障害と、リトライすべきではないモデル判断を区別する必要がある。
人による承認は万能の解決策ではない。頻繁なプロンプトは、ほとんど精査されない定型的な確認になり得る。質の高い承認には、提案されたアクションとその影響を説明する十分なコンテキストが必要だ。
最良の承認ポイントは、不可逆的または影響の大きい変更に集中すべきである。低リスクの操作は、定義された制限内で自動的に進められる。すべての手順で確認を求めれば、ワークフローの価値の多くが失われる。
保守は最大の隠れたコストになる可能性がある。エンタープライズアプリケーションは、API、スキーマ、権限モデルを変更する。Blueprint は、その判断の意味を暗黙のうちに変えることなく進化しなければならない。
モデルの置き換えは別の変数をもたらす。一つのモデルでテストされたワークフローが、ルーティング変更後には異なる振る舞いをする可能性がある。したがって Barndoor のガバナンスレイヤーには、アクセスポリシーに加え、バージョンを認識する評価が必要となる。
Diaphora チームの統合も引き続き重要だ。スピンインは既存の戦略的関係にチームを合わせられるが、製品統合には依然として技術面と組織面の選択が必要になる。
Barndoor は、Frags の開発、商用 Blueprints、既存のゲートウェイをどのように組み合わせるかを決めなければならない。基盤となるアーキテクチャが健全であっても、管理、ドキュメント、デバッグに一貫性がなければ、顧客は気付くだろう。
Syndio の声明は、顧客課題について信頼できる説明を提供している。しかし、それは統合製品がその課題を大規模に解決したことを証明するものではない。独立したケーススタディの方が、より強い証拠となる。
したがって Barndoor による Diaphora の買収は、完了した検証ではなく、技術的なコミットメントとして評価すべきである。これは、ガバナンスとワークフロー実行は同じ製品に属するという主張への Barndoor のコミットメントを示している。
統制された自動化が機能するかを示す三つのシグナル
次の試験は、Barndoor が説得力のある制御モデルを、再現可能な本番導入へと転換できるかどうかである。
最初のシグナルは、測定可能な成果を伴う公開済みの本番ケーススタディだ。Barndoor には、複数のエンタープライズシステムにまたがって実際のアクションを実行するワークフローの証拠が必要である。
有用な指標には、完了率、安全停止率、人によるエスカレーションの頻度、誤アクションの頻度が含まれる。購入者が結果を解釈するには、ワークフローのリスク水準とテスト条件も必要だ。
成功したケースは、Blueprints がドラフト作成を超えて実行へ進めるという Barndoor の主張を強化する。運用上の測定値を欠く曖昧な推薦コメントでは、中心的な主張は未解決のまま残る。
二つ目のシグナルは、Frags と Barndoor のガバナンスプラットフォーム間の技術的統合だ。同社は Diaphora の自動化を統制された MCP ツールにできるとしているが、実装の詳細が価値を左右する。
開発者は、バージョン管理されたワークフロー定義、ローカルテスト、ポリシーシミュレーション、エクスポート可能なトレース、承認ノード、明確な障害処理に注目すべきである。セキュリティチームには、権限が初回の呼び出し時だけでなく、各手順に追従することを示す証拠が必要となる。
統合では、モデル、アプリケーション、または認証情報が利用できなくなった場合に、Blueprintがどのように応答するかも示すべきです。リスクの高いワークフローでは、安全な失敗処理は正常な実行と同じくらい重要です。
具体的なドキュメントを伴う透明性の高いリリースは、この買収の意義を強化するでしょう。一方で、緩くつながった製品群にとどまれば、顧客は依然としてガバナンスと実行を別々に管理することになり、その意義は弱まります。
3つ目のシグナルは、FragsとFMLにおける継続的な外部参加です。Barndoorはエンジンをオープンソースとして維持すると約束しており、コミュニティ活動はその取り組みを測る観察可能な指標になります。
外部からのissue、pull request、統合、メンテナーの存在は、Fragsが非公開製品への依存を超えて発展できることを示すでしょう。社内リリースが大半を占める静かなリポジトリでは、プラットフォーム依存に対する保護は弱くなります。
こうしたシグナルは、さらに別のエージェント機能群よりも重要です。企業には、すでにモデルを呼び出し、アプリケーションを接続できるツールが数多くあります。一方で、それらの運用を日常業務に耐えられるほど信頼できるものにするシステムは、より少数です。
BarndoorによるDiaphora買収は、ガバナンスを最後のコンプライアンス確認ではなく、導入を促す仕組みとして位置づけています。これは、従業員が理解も制約もできないシステムへ、重要な業務を安全に委任することはできないため、もっともな転換です。
とはいえ、信頼を得るには運用上の証拠が必要です。組織は、支援付き作業から自律実行へ移行する前に、ワークフローの境界、障害記録、モデル評価、権限範囲を検証すべきです。
同様のシステムを検討するチームは、狭く、元に戻せるプロセスから始めるべきです。まずは管理されたナレッジワークフローを通じて必要な情報を整理し、その後、どの手順に本当にモデルの判断が必要かを特定できます。
実務上の問いは、エージェントが洗練されたデモを完了できるかどうかではありません。同じガバナンスされたプロセスが、数千回の実行、変化する入力、アプリケーションの更新を経ても許容できる形で動作するかどうかです。
Barndoorは今、その問いに答える責任を負っています。購入者は、Blueprintを実証済みのインフラとして扱う前に、最初の測定可能な導入事例、Fragsとの統合、そしてオープンソースプロジェクトの健全性を注視すべきです。
