養子縁組

集中管理なしでエージェントをビジネスユニット全体に配置する

大規模な組織は、待ち行列となる中央チームか、統治不能になる自由な導入かの選択に直面しています。どちらも機能しません。そうするバージョンは、明確な境界を持つプラットフォーム チームのように見えます。

Yaju チーム · 2026 年 6 月 3 日

大規模な組織全体にエージェントを配置するには 2 つの標準的なアプローチがありますが、どちらも失敗していることは、よく見れば最初から明らかです。

中央チーム

1 つのグループがすべてのエージェント開発を所有します。ガバナンスは優れており、基準は一貫しているため、4 か月以内に行列ができます。

この仕事を最もよく理解しているチームは事業部門であり、彼らは現在リクエストを提出して待っているところです。リクエストは優先順位付けされ、翻訳中にコンテキストは失われ、最も関心のあるビジネスユニットは、中央チームが提供するために存在するガバナンスの外で、とにかく独自の構築を開始します。

失敗は無能ではありません。それは、中央チームが 12 の異なるドメインのドメイン知識を保持できないということです。

無料

各ユニットは必要なものを構築します。導入は速く、熱意は高く、何が実行されているかについては誰も答えられません。

6 か月目までに、所有者のいないエージェントが存在し、同じ問題を 3 回解決するユニット間での重複した作業が発生し、構成ファイルに資格情報があり、誰も帰属できないコストラインが存在します。最初の重大なインシデントは、すべてを停止させるような反応を引き起こします。

実際に何が機能するのか

レールを所有するプラットフォーム チームとエージェントを所有するビジネス ユニット。

プラットフォーム チームは、ID と資格情報の処理、アクション時点でのポリシーの適用、監査証跡、コストの帰属、評価ハーネス、共有カタログなど、一貫性が必要なことに対して責任を負います。

ビジネス ユニットは、何を自動化するか、どのような優れた出力が得られるか、各エージェントの所有者は誰か、エージェントを実行する価値があるかどうかなど、ドメインの知識が必要な事柄に対して責任を負います。

境界は有用な部分です。これらは選択肢ではなくプラットフォームのプロパティであるため、ユニットは帰属または監査をオプトアウトできません。建築は制約されたリソースではないため、ユニットは何かを建築するために許可を求める必要はありません。

カタログは重複を防ぐものです

3 つのユニットが同じ問題を別々に解決することは、大規模なロールアウトで最も一般的な無駄であり、共有の参照場所がなければまったく目に見えません。

エージェントが参照、フォーク、公開、ロールバックできる内部カタログにより、重複した作業が再利用に変わります。 2 番目のユニットは、最初のユニットの作業から開始して改善し、改善が戻ってきます。

これがエージェント ハブの目的であり、展開の中で最も延期され、最も後悔されることが多い部分です。

予算はユニットに属します

中央予算管理により、キューが財務形式で再作成されます。警告ではなくブロックするユニットごとの予算により、制限されたエクスポージャ内で各ユニットに実質的な自律性が与えられ、取引を判断するのに最適な立場にある人々に取引が見えるようになります。

最初にインストールするもの

ロールアウト中ではなく、ロールアウト前にエージェントごとに所有権。他のものはすべて努力次第で改造できます。誰も構築したことを覚えていない 200 のエージェントにわたって所有権が改造されているのは、このリストの中で最悪のプロジェクトです。

次へ

Agent Hub ページでは、共有カタログ、フォーク、およびバージョン管理について説明します。エージェント オーケストレーション システムのページでは、プラットフォーム チームが所有するレールである属性、ポリシー、予算について説明します。