はじめに

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

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

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

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

MuleSoft エージェントファブリックの柱

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

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

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

監視: エージェントビジュアライザーは、エージェントのインタラクションの動的でインタラクティブな対応付けにより、リアルタイムの監視機能を提供します。意思決定を追跡し、システムの健全性を監視することで、継続的な最適化とエージェントエコシステム全体の信頼性の高い監視を実現します。

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

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

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

ユーザージャーニーは Anypoint Code Builder で始まります。コマンドパレットで使用できる新しいコマンド「MuleSoft: Create an Agent Network Project (MuleSoft: エージェントネットワークプロジェクトを作成)」を使用して、新しいプロジェクトを作成します。このコマンドは、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」コマンドを使用して、ビルドおよび公開プロセスをトリガーします。

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

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

企業のエージェント ネットワークを定義するエージェント ネットワーク ファイルを参照してください。このエージェントネットワークは、Salesforce、Stripe、別の注文履行エージェント、および在庫 MCP サーバーを通じて、単一のポリシーに基づく体験のもと、注文履行ネットワークを有効化します。

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

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

  • 目的: Exchange は、エージェント、ツール、およびその他のアセットのカタログです。その主な目標は、異種エージェントの検出、選定、ライフサイクル管理のための単一の管理カタログを提供することで、「エージェントの無秩序な増加」を解決することです。これにより、開発者はエージェントを見つけて再利用し、プラットフォームオーナーは可視性を維持し、オーケストレータは機能を検出できます。
  • 異機種混在設計: Anypoint 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 に関する予備知識は必要ありません。この生成されたアプリケーションは 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 をすべてのブローカーで共有するか、必要に応じて異なるブローカーにそのタスクにより適した 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 検出器、プロンプトデコレーター、スキーマ検証。
      • MCP ポリシー: 属性ベースのアクセス制御、スキーマ検証、MCP サポート。
      • LLM/AI ポリシー: AI プロンプトデコレーター、AI プロンプト保護 (有害なコンテンツのフィルタリング)、AI プロンプトテンプレート (定義済みテンプレートの適用)、AI 基本トークンレート制限。
      • テレメトリポリシー: ログデータの収集とエクスポートのためにオープンテレメトリソリューションを拡張するための A2A および 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) を監視します。
    • マルチエージェント協調監視: エージェント間のやりとりの成功率と失敗率を取得し、循環呼び出しパターン (ループ) を検出して、タスクの完了や呼び出し回数などのエージェントごとの評価指標を追跡します。
    • コスト追跡: ダッシュボードとアラートを使用して、各 LLM コール (エージェントごとが理想的) のトークンの使用状況と関連コストを追跡します。
    • コグニティブ トレーシング:内部思考プロセスやすべてのツール コールなど、不変の監査履歴として機能するエージェントのセッションの詳細なトレースを取得して表示します。
    • Agent Session Playback (エージェントセッション再生): エージェントの認知トレースをステップごとに視覚的に「再生」して詳細なデバッグを行うことができる UI。
    • DAG の視覚化: 複雑なマルチエージェントインタラクションのエージェントワークフロー実行を DAG (Directed Acyclic Graph) で視覚化します。

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

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

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

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

4つの柱をすべて一緒に使用することは必須ではありませんが、推奨されます。必要に応じて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 およびランタイムからログ、評価指標、トレースを収集します。

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

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

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

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

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

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

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

エージェントネットワークは、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 イニシアチブをリードしてきました。