進化するマルチエージェント環境では、エージェントに具体的で詳細な ToDo が割り当てられている場合に最も効果的です。そのためには、再利用可能な専門エージェントの多様なネットワークが必要です。ただし、コアとなる課題は、さまざまなソースから取得される可能性のある多数の異種エージェントを調整して、共通のビジネス目標に向けて効果的にコラボレーションすることです。統合プラットフォームを使用しない場合、この複雑さはエージェントの無秩序な増加を招き、ガバナンスの重要な欠如につながります。

これらの AI エージェントは、SaaS プラットフォームへの組み込み、自社開発、または一般的な LLM とのパッケージ化によって急速に増加しています。この乗算により、組織のサイロが切断されます。エージェントはネイティブアプリケーション内で ToDo を最適化しますが、多くの場合、総合的なエンタープライズビューがありません。この可視性の欠如により、エージェントはさまざまなドメインやシステムでアクションを効果的に調整、保護、管理できません。

MuleSoft Agent Fabric は、「エージェントの無秩序な増加」を管理し、その発生源に関係なくさまざまなエージェントのシームレスなオーケストレーションを可能にするという課題に対処します。アーキテクチャのベストプラクティスが確立され、エージェントネットワークを作成するために必要なツールが提供されます。エージェントネットワークとは、連携して複雑な複数ステップのビジネスプロセスを実行する AI エージェント、ツール、リソースの調整されたコレクションです。

MuleSoft エージェントファブリックは、作成場所に関係なく、すべての企業がエージェントを簡単に検出、オーケストレーション、管理、監視できる統合プラットフォームです。

**検出:**エージェント登録では、組織内のすべての AI エージェントとツールの一元化されたカタログが提供されます。これにより、内部で構築されたアセット、SaaS 組み込みアセット、外部アセットの検出と再利用が可能になります。エージェント登録では、すべてのエージェントアセットの情報源を一元化することで、冗長性を排除し、開発者が既存の機能を大規模に活用できます。

**オーケストレーション:**MuleSoft エージェントブローカーは、ToDo を最適なエージェントまたはツールに動的に一致させるインテリジェントなルーティングソリューションです。任意の LLM を搭載しており、エージェントとツール間で連携して、複雑な複数ステップの要求とビジネスプロセスを高い信頼性と追跡可能な結果で実行できます。

ガバナンス:MuleSoft Agent Governance は、Flex Gateway と、モデルコンテキストプロトコル (MCP) および Agent2Agent (A2A) プロトコルのサポートを使用します。Flex Gateway を使用すると、企業はすべてのエージェント-エージェント間およびエージェント-ツール間のやりとりにセキュリティポリシーとコンプライアンスポリシーを適用できます。

**観察:**エージェントビジュアライザーは、エージェントのインタラクションの動的で対話型の地図を通じてリアルタイムの観察機能を提供します。意思決定を追跡し、システムの健全性を監視することで、継続的な最適化とエージェントエコシステム全体の信頼性の高い監視を実現します。

エージェントファブリックは、ユーザーがメタデータ記述子 (「YAML ファイル」) を使用してエージェントネットワークを定義する仕様優先 (YAML) アプローチを支持します。この YAML ファイルは MuleSoft に依存せず、エージェントネットワークの定義を実行から分離します。

各エージェントネットワーク (YAML) では、業務ルールやポリシーなど、エージェントアセットを使用して特定の機能領域を定義します。YAML は、4 つのエージェントファブリックの柱を有効にするために使用されます。

1. 検出:エージェントレジストリに次のような既存のエージェントアセットを入力します。
   1. さまざまなプラットフォーム (MuleSoft など) にリリースされたエージェント
   2. MCP サーバ
   3. LLM プロバイダー
2. オーケストレーション:オーケストレーション用のエージェントブローカーの作成
3. ガバナンス:セキュリティとガバナンスのためにアセットにポリシーを適用する
4. 観察:定義されたアセットへの接続を定義して再利用します。また、エージェントネットワークには観測機能と監視機能を使用できます。

ユーザージャーニーは Anypoint Code Builder で始まります。「MuleSoft an Agent Network Project (エージェントネットワークプロジェクトを作成)」をクリックして、新しいプロジェクトを作成します。このコマンドは、2 つのファイルを含む新しいプロジェクト (「エージェントネットワーク」) を作成します。

• **agent-network.yaml:**このファイルでは、マルチエージェントシステムの設定を定義し、外部ツール (MCP 経由) とエージェント (A2A プロトコル経由) を使用して AI エージェントをオーケストレーションできるようにします。この形式では、エージェントの機能、連動関係、インテグレーションを宣言的に定義できます。

• **exchange.json:**すべてのエージェントネットワークプロジェクトにも exchange.json ファイルがあります。このファイルには、エージェントのネットワークアセットが公開された後に Anypoint Exchange で使用できるアセットメタデータが含まれます。

エージェントネットワークの開発は、次の 4 つの主要なフェーズを含む標準のソフトウェア開発ライフサイクル (SDLC) に従います。

1. **環境の設定:**ランタイム環境とゲートウェイの設定
2. プロジェクトの作成と設計:エージェントネットワークプロジェクト仕様の作成
3. **作成と公開：**アセットを作成してエージェントレジストリに公開する
4. **リリース:**特定の環境にエージェントネットワークをリリースまたは昇格する

プロジェクトを作成し、必要な MuleSoft アプリケーションとアセットを生成したら、Exchange で使用できるようにします。Anypoint Code Builder で、「MuleSoft:コマンドパレットから [Publish Agent Broker Project to Exchange (エージェントブローカープロジェクトを Exchange に公開)] コマンドを使用できます。

公開ステップでは、YAML ファイル内の各エージェントアセットを A2A、MCP、または LLM 仕様に変換して Exchange に公開します。

また、新しいエージェントネットワークアセットタイプを使用して、YAML が Exchange に公開されます。このアセットは、エージェントレジストリ UI で表示し、Exchange API を使用して検索できます。

企業のエージェント ネットワークを定義するエージェント ネットワーク ファイルを参照してください。このエージェントネットワークは、Salesforce、Stripe、別の注文履行エージェント、および 1 つのポリシー管理環境を持つ在庫 MCP サーバー全体で注文履行のネットワークを有効化します。

• 検出
  既存のエージェントとツール (Salesforce、Stripe、Order Fulfillment、Inventory など) を Exchange アセットとして公開して再利用します。また、バージョン管理されて共有可能な注文履行定義 (YAML) により、フローを再構築することなくロール、地域、関連子会社に迅速に適応できます。
• オーケストレーション
  エージェントブローカーは LLM を使用して、注文履行プロセスを一連のタスク (顧客の詳細の確認、在庫の割り当て、送料の計算など) に分解します。次に、MCP および A2A エージェントを��ールしてこのワークフローを実行し、必要に応じて Human-in-the-Loop 承認が申請されるようにします。
• 統治
  Anypoint Flex Gateway は、認証、最小権限アクセス、ガードレールを適用します。API マネージャーポリシーにより、すべてのコールとデータ交換で一貫した制御が保証されます。
• 監視
  監視とトレースにより、進行状況、障害、レイテンシーをエンドツーエンドで可視化できます。視覚化により、操作したエージェントとボトルネックが発生した場所が表示されます。
• 信頼とコンプライアンス
  一元化されたログイン情報、監査履歴、ポリシー継承により、セキュリティ、プライバシー、規制要件 (PII の処理、承認、職務の分離) がサポートされます。

次の図は、YAML で定義されたエージェントネットワーク (メタデータ) のさまざまなノードを示しています。

• 目的 は、エージェント、ツール、その他のアセットのカタログです。その主な目標は、異種エージェントの検出、選定、ライフサイクル管理のための単一の管理カタログを提供することで、「エージェントの無秩序な増加」を解決することです。これにより、開発者はエージェントを見つけて再利用し、プラットフォーム所有者は表示を維持し、オーケストレーターは機能を検出できます。
• 設計による異種混在 Exchange で 3 つの新しいアセット (エージェント、MCP、LLM) がサポートされるようになりました。Exchange は、あらゆる種別のエージェントを登録および管理するためのユニバーサルカタログとして設計されています。サード・パーティ製エージェント、Agentforce製エージェント、カスタムMuleSoftエージェントなど、あらゆるソースのA2A準拠のエージェント、MCPサーバ、LLMプロバイダをサポートします。
• コアメタデータ:すべての登録済みアセットには、一意の名前とバージョン、所有権、公開者などの不変メタデータのベースラインセットがあります。ライフサイクル状態 (開発、ステージング、本番、非推奨) も追跡されます。
• 検出:
  • 設計時:開発者は、既存の Exchange UI を使用するか、Anypoint Code Builder 内の Vibes を使用して自然言語検索で登録済みエージェントを検出できます。
• タグ付けと分類:基本的なキー-値タギングシステムを使用して、種別 (エージェント、MCP、LLM、ブローカー) とドメイン (HR、天気など) でアセットを分類し、動的リンク、検索、選択ポリシーを有効にできます。
• カタログ:リポジトリでは、組織内でエージェントを共有するための非公開カタログモデルと内部カタログモデルの両方がサポートされています。
• 視覚化:ネットワークビューをサポートするビジュアルツールを提供し、絞り込み機能を使用して、組織全体の 1 つのアセットまたはノードとリンクのマップ全体の接続を表示します。

エージェントネットワーク内のブローカーは、Anypoint Exchange に保存されている登録済みのエージェント、MCP サーバー、LLM プロバイダーを参照できます。ただし、まだ登録されていない場合は、エージェントネットワーク (YAML) のメタデータで宣言でき、自動的に登録されます。この例では、複数のエージェント、MCP サーバー、LLM プロバイダーが Anypoint Exchange で宣言および登録されています。

エージェントブローカーは、社内の専門エージェント間で ToDo の委任を調整するインテリジェントなルーティングエージェントです。これは、タスクを完了するために使用するエージェントと MCP サーバーによって定義されます。

ブローカーは、エージェントネットワークアセットを公開し、他のブローカーが再利用した後に Anypoint Exchange に表示される専門エージェントです。

ブローカーは、YAML の「_ブローカー」_セクションで定義します。定義されたブローカーは透過的にアプリケーションに「コンパイル」されます。Mule に関する予備Knowledgeは必要ありません。この生成されたアプリケーションは CloudHub 2.0 (CH2) にリリースされ、堅牢な CH2 インフラストラクチャを活用します。

つまり、エージェントブローカーは、ログ機能や総計値機能など、CloudHub 2.0 の確立されたパフォーマンス特性を活用できます。「運用コスト」や「監視/アラート/ツール」などの運用面は他のワークロードと同じです。

人間の介入が必要なシナリオ (Human-in-the-Loop) では、同時進行の多い環境で効果的な状態管理を行うために設計された分散ソリューションである MuleSoft Object Store を使用して、各インタラクションの状態が維持されます。

ブローカー定義は、カードと仕様の 2 つのセクションで構成されます。

カードセクションは、エージェント間 (A2A) 仕様に従います。特に、ブローカーエージェントの契約、スキル、機能について説明します。カード URL には、値 ${ingressgw.url}/broker-name が自動的に入力されます。リリース時に、${ingressgw.url} プレースホルダーはエージェントの入力要求の前にある Anypoint Flex Gateway の URL に自動的に置き換えられます。

仕様セクションでは、ブローカーの「ソースコード」を設定します。ここで、開発者は使用する LLM、手順、使用可能なツール、エラー処理、そして最も重要なのは、このブローカーで使用できるさまざまなエージェントと MCP ツールを指定できます。

LLM プロバイダー

このセクションは各ブローカーの仕様の一部です。これは、「サービス」セクションで定義された LLM のいずれかへの参照です。1 つの LLM をすべてのブローカーで共有するか、必要に応じて異なるブローカーにその ToDo により適した LLM を使用させるかを選択できます。

ブローカーは LLM プロバイダーを参照できます。ニーズに応じて、これらのプロバイダーのモデルを選択できます。

説明

このセクションは省略可能であり、このブローカーエージェントに固有の手順を指定するために使用できます。これらの手順は、多くの場合、特定のビジネス指向の懸念事項に焦点を当てています。たとえば、顧客が報告したインシデントの管理を調整するカスタマーサービスエージェントを想像してください。

ブローカーが独自に処理するため、「プロンプトを ToDo に分割」や「最適なツールを選択」などの明示的な指示は必要ありません。これらの手順は、特定のビジネスプロセスを説明する場合にのみ必要です。

ツールの設定

ツールはエージェントに外部機能を提供します。ブローカーが外部システム (別のエージェント (既存の API や SaaS サービスなど) にアクセスする必要がある場合は、常に MCP (モデルコンテキストプロトコル) サーバーにアクセスします。

MCP サーバーは、取引所アセットの名前で参照されます。接続の詳細は、[サービス] セクションで指定します。

デフォルトでは、ブローカーは MCP Server で使用できるすべてのツールにアクセスできます。最新の LLM では、コンテキストあたり約 20 ～ 25 個のツールしか処理できないため、不正確なツールが生成され始めます (コンテキストが失われます)。そのため、一般的に、使用可能なツールは必要最小限に制限することをお勧めします。その絞り込みは許可リストで適用できます。

エージェントリンク

このセクションは、定義全体で最も重要な部分です。リンクセクションでは、エージェント間のコミュニケーションとオーケストレーションを有効にします。つまり、このブローカーはここにリンクされたエージェントに依存して適切なアクションを実行し、ユーザーのゴールを完了します。

実際には、このセクションではコラボレーション用のエージェントネットワークを定義します。

エージェントガバナンスは、エージェントファブリックの重要な柱であり、信頼できるエージェントネットワークを構築し、セキュリティとコンプライアンスを確保するために不可欠です。

ガバナンスのために、非公開スペース内に合計 2 つの Flex Gateway (1 つの入力と 1 つの出力) が必要です。

ガバナンスにより、エージェント開発ライフサイクル (ADLC) 全体を安全に拡張するために必要な構造、制御、証拠が確立されます。具体的には、ガバナンスでは、エージェント認定、カタログ化、ライフサイクルの意思決定、ランタイムポリシーの適用などの主要なプロセスを実装します。

• カタログ：
  • Exchange:エージェントの目的、所有者、環境、データと分類の境界の記録をサポートします。また、機能、ツール、リソース、プロンプト、外部連動関係もバージョンに登録されます。
• バージョン管理とライフサイクル:
  • エージェント開発ライフサイクル全体で、エージェント、ツール、アセットのセマンティックバージョンを文書化して管理します。
  • バージョン管理は、エージェントの非推奨タイムラインの管理に役立ち、デュアルラン (可能な場合) をサポートしているため、移行がスムーズです。
• ポリシー適用:
  • エージェント型 AI アーキテクチャにより、攻撃対象領域 (会話インターフェース、プロンプト、MCP などの新しいプロトコル) が拡張されます。コンポーネントが侵害されると、プロトコル、プロンプト、API、ツールなどのコンポーネントを提供する複数のシステムに影響が連鎖する可能性があります。
  • このような自律的で予測できない環境では、本質的にエージェント間のやりとりによって攻撃対象範囲が広がるため、エンタープライズエージェントの AI リリースを��護するには、特殊なアプローチが必要です。静的システムの既存のセキュリティツールは不可欠ですが、それだけでは不十分です。企業は、エージェント型 AI に関連する重要なビジネスリスクに直接対応する 4 つの特定のセキュリティソリューションを積極的に計画して実装する必要があります。
  • Flex Gateway:すべての A2A および MCP トラフィックは、ターゲットシステムが保護されていない場合でも Flex Gateway を介してルーティングされ、すべてのエンドポイントにポリシーが適用されます。このルーティングは、エージェントの通信を保護し、認証サーバーと統合するために不可欠です。
  • 保険契約バンドル:ユーザーは、実行前に定義済みポリシーのバンドルを定義してワークフローに適用し、一貫したセキュリティポリシーと運用ポリシーを適用できます。
  • 保険契約の種別:このプラットフォームでは、次のようなさまざまな受信および送信ポリシーがサポートされています。
    • A2A ポリシー:エージェントカード、PII Detector、Prompt Decorator、スキーマ検証。
    • MCP ポリシー:属性ベースのアクセス制御、スキーマ検証、MCP サポート。
    • LLM/AI ポリシー プロンプトデコレーター、AI プロンプト保護 (有害なコンテンツのフィルタリング)、AI プロンプトテンプレート (定義済みテンプレートの適用)、AI 基本トークンレート制限。
    • テレメトリポリシー および MCP テレメトリーを使用して、ログデータの収集とエクスポートのためのオープンテレメトリーソリューションを拡張します。
• ロギング:自動トレーシングにより、エージェント ネットワーク全体のログを使用して、すべてのエージェント操作を追跡し、動作について説明し、Trust を構築できます。

この例では、エージェントネットワークメタデータを使用して設定されるメッセージロギングのポリシーを示しています。注文履行ブローカーは、Salesforce エージェントと呼ばれる既存のエージェントを参照し、メタデータを使用してメッセージングのポリシーを設定します。エージェントファブリックは、Flex Gateway の「spec」セクションで説明されているすべてのポリシーを自動的に設定します。追加の手順は必要ありません。

LLM エージェントとマルチエージェントリリースの非確定性および複雑さを考慮すると、可観測性と監視は重要です。

• 基本的なログとトレース:理由とツール実行追跡はログを介して提供されます。ワークフロー実行のログとトレースは、ランタイムマネージャーで実行後に表示できます。
• 総計値:初期フェーズでは、a2a_total_calls と mcp_total_calls が表示ラベル (パス、状況、メソッド、ツールなど) 付きのカウンタとして公開され、通話の合計数、成功数、失敗数がわかります。これらの総計値は、Envoy (Flex Gateway) のネイティブ統計インターフェース (mcp_support_policy や a2a_agent_card_policy などの既存のポリシーを使用するのが望ましい) を使用してポリシーコードから公開されます。
• オブザーバビリティの向上 (将来):今後のバージョンでは、Open Telemetry を使用して分散トレースを実行する予定です。より高度なオブザーバビリティには次のものが含まれます。
  • 詳細な要求トレーシング:プロンプト、プランナープロセス、呼び出されたアクション、サブエージェントとのやりとりなど、要求に関するエンドツーエンドの可視性を実現します。
  • エージェント状態監視:エージェントのアップタイム、応答遅延、スループット、エラー率、基盤となるリソース使用率 (CPU、メモリ、ネットワーク、GPU) を監視します。
  • マルチエージェント協調監視:エージェント間のやりとりの成功率と失敗率を取得し、循環呼び出しパターン (ループ) を検出して、ToDo の完了や呼び出し数などのエージェントごとの評価指標を追跡します。
  • コスト追跡:ダッシュボードとアラートを使用して、各 LLM コール (エージェントごとが理想的) のトークンの使用状況と関連コストを追跡する。
  • コグニティブ トレーシング:内部思考プロセスやすべてのツールコールなど、エージェントのセッションの詳細な追跡を取得して表示し、不変の監査履歴として機能させます。
  • エージェントセッションの再生:エージェントの認知トレースをステップごとに視覚的に「再生」して詳細なデバッグを行うことができる UI。
  • DAGの視覚化:複雑なマルチエージェントインタラクションのエージェントワークフロー実行をダイレクトアサイクリックグラフ (DAG) で視覚化します。

エージェントビジュアライザーは、エージェントネットワークの各部分を特定し、それらの連携を確認するために使用されます。

• ノード種別 (エージェントと MCP サーバー) を区別します。
• エッジを表示して、宣言されたインタラクションとランタイムインタラクションを確認します。
• レイヤーを使用して特定の環境にビューを絞り込む
• 詳細カードを開いて、ノードのメタデータと総計値、およびアクセスログとトレースを調べる
• Flex Gateway 保護や適用済みポリシーなどのガバナンスインジケーターを確認します。

Agent Visualizer のコンポーネントについての詳細は、こちらを参照してください。

この 4 つの柱を組み合わせることで、MuleSoft エージェントファブリックのセキュリティと制御が、組み込みのガバナンスを使用するすべてのエージェントに拡張されます。A2A (Agent to Agent) や MCP (Model Context Protocol) などの新しいプロトコルを活用してビジネスプロセスを構築および拡張することで、エージェントがあらゆる場所で行動できるようにします。アプリケーション、データ、システムなど、すべてを接続して、エージェントがビジネス全体で行動するときにエージェントを支援し、統制します。インテリジェントなツールは、AI をネイティブで使用するか、サードパーティの AI ツールを使用して、ビジネスプロセスまたは API の作成と拡張をサポートします。

4 つの柱をすべて一緒に使用することは必須ではありませんが、お勧めします。必要に応じて柱を個別に選択できます。たとえば、オーケストレーションレイヤーを使用せずに、レジストリとガバナンスにエージェントファブリックを活用できます。同様に、ブローカーを使用して、別のプラットフォームで管理されるエージェントを調整できます。

次の図は、4 つのすべてのコンポーネントがどのように相互作用するかを示しています。

1. Anypoint Code Builder でエージェントネットワーク YAML にエージェントネットワーク (ブローカー、エージェント、MCP サーバー) を定義したら、検出と再利用のためにエージェントアセットを Anypoint Exchange に公開します。
2. エージェントアセットを CloudHub 2.0 (ランタイムマネージャーで管理) にリリースします。
3. ブローカーエンドポイントと API エンドポイントの前にある入力 Flex Gateway を使用して、ネットワークへの着信トラフィックにポリシーを適用します。
4. 出力 Flex Gateway を使用して、ポリシーを適用し、接続を管理し、テレメトリデータを送信します。このゲートウェイは、ブローカーやエージェントから外部サービスへのアウトバウンドパスに配置されます。
5. Anypoint Monitoring で Flex Gateway およびランタイムからログ、評価指標、トレースを収集します。

すべての専門エージェントがフラットで制限のないアーキテクチャですぐにアクセスできるようにし、1 人のオーケストレーターがすべての AI アセットにアクセスできるようにすることで、あらゆる作業に対応できるようにしたいと考えています。ただし、このアプローチでは、システム全体の効率と信頼性がすぐに損なわれます。過剰な個々のツールに適用される原則と同様に、多くのエージェントオプションでは、中央ブローカーエージェント (またはオーケストレーター) に大きなノイズと複雑さが生じます。この複雑さの増加は、ブローカーの意思決定 (ジョブに適したエージェントの選択) の精度とシステムの応答の決定性 (類似するクエリの予測可能で一貫した結果) の両方の低下に直接つながります。ブローカーエージェントは実質的にオプションの麻痺に苦しみ、ルーティングが遅くなり、信頼性が低下します。

エージェント ネットワークを構造化するには、フラットな構造ではなく、複数レベルの階層アプローチを強く推奨します。この組織原則には、多くの重要な利点があります。まず、本質的にトレーサビリティと管理が優先されます。階層構造には、確立された組織のベストプラクティスが反映されているため、要求のフローの監査、障害レイヤーの特定による問題のデバッグ、特定のエージェントまたはサブネットワークの導入と廃止の管理が容易になります。

次に、これらのエージェントを強化する大規模言語モデル (LLM) のコンテキストで重要なのは、階層によってコンテキストのサイズを劇的に抑えることができることです。エージェント状況を区分することで、特定のレイヤーのブローカーエージェントは、その直下の限られたエージェントまたはサブブローカーのセットのみを考慮します。この構造により、プライマリ オーケストレーターが_各エージェント_の説明、機能、履歴コンテキストを作業メモリに読み込むのを防ぎ、LLM のコンテキスト ウィンドウの制限をすぐに超えてしまい、莫大なコストと遅延が発生するリスクを回避します。

エージェントネットワークは複数の方法で実装できます。そのうちの 2 つは次のとおりです。

1. Conway’s Law (コンウェイの法則) - 実際の階層構造に対応付ける直感的な方法。
2. ドメイン駆動型設計 - ビジネスドメインにより重点を置く

オプション 1実世界階層構造とのマッピング

階層組織では、コミュニケーションはマネージャーから部下まで縦方向に流れ、意思決定は多くの場合一元化されます。コンウェイの法則に従う:

• このような組織が構築するシステムやソフトウェアアーキテクチャも階層化および階層化される傾向にあります。
• 各チームは、独自の境界と権限を反映するサブシステムを設計する傾向にあります。
• システム間のインターフェースは、部門間のコミュニケーションチャネルを反映します。

エージェントネットワークは、Conway の法則に従う大企業の実際の階層構造に直感的に対応付けることもできます。

• **概念モデル:**会社に個別のディビジョン、部門、管理レイヤー (経営幹部、統括責任者、取締役、マネージャーなど) があるのと同じように、特定のドメイン内で業務を行うエージェントネットワークを並列組織図としてモデル化できます。
• **ノードと脱退:**次の階層:
  • ツリー構造の葉は、スペシャリスト エージェントまたは MCP です。これらは、実際の作業を実行する機能単位です (「データベースクエリエージェント」、「顧客認証エージェント」、「センチメント分析エージェント」など)。組織の個々の寄稿者または作業単位を表します。
  • 階層内のその他のすべてのノード (ルートレイヤーと中間レイヤーを含む) は、ブローカーエージェント (またはサブオーケストレーター) です。これらのエージェントは最終タスクを実行しませんが、特定のドメインまたはレイヤー内のルーティング、委任、集計、競合の解決を担当します。上位レベルのブローカーは「Sales Domain Broker (営業ドメインブローカー)」に ToDo を委任し、続いて「Opportunity Management Broker (商談管理ブローカー)」が「Opportunity Status Update Agent (商談状況更新エージェント)」 (リーフ) を介して ToDo を実行します。

この構造により、複雑さがローカルで管理され、コンテキストが含まれ、システムが予測可能かつ確実に拡張されます。新しいスペシャリストエージェントを組織ツリーの特定の適切なブランチに導入できます。

デジタル作業の組織図のたとえを考えてみます。各 YAML ファイルは、各内部組織 (従業員サクセス、セキュリティ、財務など) を表します。各組織 (エージェントネットワーク) には、アクターがコラボレーションしたり、ジョブが ToDo に分割されたり、割り当てられたりするための階層構造があります。上記の図では、コミュニケーションは上から下へ流れます。また、葉は一連のブローカーエージェントによってのみ消費が制限されません。

人間の組織図に基づいてエージェントネットワークをモデル化すると、特に頻繁に組織を再構築する会社では、頻繁に再構築が必要になるリスクがあります。別のアプローチとして、エージェントを機能ドメイン別に整理することもできます。このグルーピングでは、従来の人間の組織の境界を超えることが必要になる場合があります。たとえば、新入社員のオンボーディングでは、ハードウェアとユーザーのプロビジョニングに関する IT 業務を行い、営業活動では業務とマーケティングの両方を行います。

Nikhil Aggarwal は Salesforce のプリンシパルアーキテクトで、MuleSoft および Salesforce Automation Cloud のアーキテクチャをリードしています。Nikhil は、大規模な製品の提供に 18 年以上の経験を持ち、拡張性の高いアーキテクチャ、直感的な開発者エクスペリエンス、ハイパフォーマンスなチームの構築に情熱を注いでいます。Salesforce 以前は、Microsoft Power Platform、Dataverse、Office 365 の複数のイニシアチブを構想から立ち上げまで主導していました。彼の仕事は、AIファースト時代において、現代の企業がシステムを接続し、ワークフローを自動化し、ビジネス価値を引き出す方法を形成し続けています。

Mariano Gonzalez は 2011 年に MuleSoft に入社し、ミッションクリティカルな分散システム、インテグレーション、PaaS、クラウドコンピューティングを専門としていました。現在、Mariano は、ガバナンス、オーケストレーション、検出、およびオブザーバビリティに特に注意を払い、AI プラットフォームの高度化に重点を置いています。IT 業界に 20 年以上携わってきた Mariano は、農業、エネルギー、政府、IT、通信、コンテンツ管理の各セクターで BPM、ERP、インテグレーションソリューションを設計し、提供しています。

Pedro Colunga は、API とメタデータアーキテクチャを専門とする Salesforce のソフトウェアエンジニアアーキテクトです。Pedro は、プラットフォームのライフサイクル全体に重点を置き、組織によるシステムインテリジェンス、セマンティクス、メタデータ駆動型ソリューションの活用方法の形成に重要な役割を果たしています。Pedro の 20 年間のキャリアには起業家経験が含まれており、Fuego、BEA Systems、Oracle、TekGenesis (後に MuleSoft が買収した会社) などの企業を渡り歩き、一貫してプラットフォームベースのアーキテクチャを推進し、BPM、RAD、インテグレーションなどの分野に深い専門知識を提供しています。

Gulal Kumar は、Salesforce のソフトウェアエンジニアリングアーキテクトで、データおよびインテグレーションアーキテクチャに重点を置いています。インテグレーションと API、モダナイゼーションプログラム、セキュリティ、AIML イニシアチブで 20 年以上の経験があり、豊富な専門知識を備えています。Gulal は、ビジネス変革イニシアチブを推進し、セキュリティと耐障害性を強化し、アーキテクチャの卓越性を促進し、さまざまなドメインで AIML イニシアチブをリードしてきました。