エージェント間エコノミーのためのインフラストラクチャ

エージェント間エコノミーを阻むのは知能ではなく、インフラである

AIエージェントの最大の課題は知能だと考えがちです。長い間、それは事実でした。モデルは推論に苦労し、ツールは脆く、多段階のタスクは簡単に破綻しました。しかし、その段階はほぼ過ぎ去りました。

現代のエージェントはすでに多くのことができます。複数のステップにわたって推論し、ツールを呼び出し、MCPサーバーを起動し、さらには他のエージェントと連携することも可能です。適切なプロンプトとモデルがあれば、多くのチームが驚くほど短期間で印象的なエージェントのプロトタイプを構築できます。デモは説得力があり、初期の結果は魔法のように感じられます。

しかし、これらのシステムが実際の使用に近づくと、静かに、そして混乱を招くような形で失敗し始めます。

これこそが、台頭するエージェント間エコノミーを特徴づけるギャップです。知能の欠如ではなく、インフラの欠如です。

初期のエージェントシステムにおける見せかけの完成度

ほとんどの初期のエージェント実装は、見かけ上は単純なパターンに従っています。ユーザーが入力すると、エージェントがそれを推論し、必要に応じてツールを呼び出し、応答を返します。この線形フローは理解しやすく、デバッグも容易です。また、開発者がアプリケーションについて考えることに慣れている方法ともよく合致します。

しかし、このモデルは現実と接触すると成り立たない仮定を隠しています。それは、エージェントの実行が短命で、孤立しており、自己完結型であるという仮定です。

エージェントが他のエージェントと相互作用し始めるとすぐに、その仮定は崩れます。あるエージェントが別のエージェントに作業を委任します。後でフォローアップアクションがトリガーされます。ツールの呼び出しが二次的な決定につながります。実行パスは分岐し、再結合し、時には完全に一時停止することもあります。

この時点で、システムはアプリケーションの機能のように振る舞うのをやめ、自律的なコンポーネントで構成される分散システムのように振る舞い始めます。

この移行は微妙ですが、極めて重要です。チームは、問題が発生し始めるまで、それが起こったことに気づかないことがよくあります。

失敗が実際にどこから来るのか

エージェントシステムが本番環境で苦戦するとき、失敗は劇的なものではめったにありません。システムが完全にクラッシュすることはありません。その代わりに、信頼がゆっくりと損なわれていきます。

アクションがトリガーされるが、誰もその理由を確信できない。
ダウンストリームのエージェントが実行されるが、不明瞭な権限の下で。
明らかな原因なしにコストが急増する。
ワークフローが途中で停止し、どこで、なぜ停止したのかを説明する明確なトレースがない。

これらは推論の失敗ではありません。エージェントは、持っていた情報に基づいて完全に合理的な決定を下したのかもしれません。問題は、システム全体で何が起こったのかを誰も確実に説明したり、統制したりできないことです。

多くのチームは、プロンプトの調整、モデルの交換、ロジックの追加などによって、本能的にエージェント自体を「修正」しようとします。しかし、問題はエージェントの内部にあるわけではないため、これらの変更が根本原因に対処することは稀です。

それはエージェント間に存在します。

知能の向上が本番環境での運用を可能にしない理由

知能が真の障害であるならば、より優れたモデルが安定した本番システムにつながるという単純なパターンを期待するでしょう。しかし、現実はそうではありません。

その代わりに我々が目にしているのは、エージェントの能力が向上するにつれて、それを取り巻くシステムが管理しにくくなるということです。知能が高まるほど、自律性が増し、分岐する挙動が増え、下流への影響も大きくなります。適切なインフラがなければ、この追加された能力は実際にはリスクを増大させます。

エージェント間のエコシステムは、この効果を増幅させます。エージェントが他のエージェントを呼び出し、共有ツールや環境を横断して動作し始めると、不足しているインフラのコストは急速に増大します。アイデンティティ、連携、ポリシーの強制、可観測性は、オプションの懸念事項ではなくなり、基盤となる要件となります。

エージェントをインフラコンポーネントとして捉え直す

ここで、考え方の転換が必要になります。エージェントは単なるアプリケーションロジックの一部として扱われるべきではありません。真のエージェントエコシステムでは、エージェントはワークフローに参加し、作業を委任し、異なる権限の下で動作する、長期間存続するアクターです。

Platforms like TrueFoundry’s Agent Hub はこの変化を反映しています。エージェントがプライベートな組み込みロジックであると仮定するのではなく、Agent Hubは、それらを明示的なインターフェースと所有権を持つ、登録され、発見可能なコンポーネントとして扱います。エージェントは、アドホックなコードパスを介して直接互いを呼び出すのではなく、共有のコントロールサーフェスを通じて公開、バージョン管理、呼び出しが行われます。

この捉え直しは、エージェントをより賢くするものではありません。それは、エージェントを取り巻くシステムを運用可能にするものです。

エージェント間のエコシステムは、推論におけるブレークスルーを待っているわけではありません。それは、制御を失うことなく自律性をサポートできるインフラを待っています。

エージェントシステムが本番環境に投入されたときにどのように変化するか、そして従来のやり方がなぜ失敗するのかを理解することが、最初のステップです。そこから、コントロールプレーン、ゲートウェイ、明示的な実行APIの役割が不可欠になります。そこからが本当の仕事の始まりです。

エージェントが本番環境に移行する際、単純な部分はすでに解決されている

エージェントシステムが本番環境に到達する頃には、ほとんどのチームは、明白な問題をすでに解決しています。

彼らはLLMにリクエストを送信する方法を知っています。
彼らはツールやMCPサーバーを接続する方法を知っています。
彼らはエージェントを起動し、応答を受け取る方法を知っています。

これらの機能はもはや実験的なものではありません。それらは安定しており、十分に文書化されており、再現も容易です。実際、チームがこれほど早く自信を得るのは、まさにこのためです。初期段階での成功は、システムが「ほぼ完成している」という印象を与えます。

本番環境では、その幻想は打ち破られます。

本番環境は複雑さを加えるのではなく、それを露呈させるものです。

本番環境が本当にしているのは、プロトタイプが都合よく隠しているあらゆるものをさらけ出すことです。

デモでは、エージェントは通常、単独で動作します。単一のリクエストを処理し、わずかなアクションを実行して終了します。実行パスは一つで、結果も一つです。全体のコンテキストが開発者の頭の中に収まるため、デバッグは簡単です。

本番環境では、エージェントはこのようには動作しません。

それらは継続的に稼働します。
それらは後続のアクションをトリガーします。
それらは他のエージェントを呼び出します。
それらは環境、チーム、権限を横断して動作します。

実行は単一のインタラクションではなくなり、 ワークフローとなることがよくあります。

ここでエージェントシステムは分散システムに似てきます。それはマイクロサービスやキューを使用しているからではなく、動作が複数の自律的なアクターに分散されているからです。

突如として重要になる問い

本番環境で問題が発生した場合、チームはエージェントが「十分に賢かったか」とは問いません。その代わりに、分散システムを運用した経験のある人なら誰でもよく知っているような質問をします。

このアクションは何がトリガーしましたか？
どのエージェントがその決定を下しましたか？
どのようなIDで実行されましたか？
なぜここで実行が分岐したのですか？
なぜ完全に停止したのですか？

これらの問いは一見単純に見えますが、インフラのサポートなしに信頼性のある回答を得ることは不可能です。

ほとんどの初期のエージェント設定では、実行コンテキストはエージェント自体の中に存在します。エージェントが別のエージェントを呼び出したり、ツールを起動したりすると、各開発者が慎重に伝播させない限り、そのコンテキストはしばしば失われます。時間が経つにつれて、ログは断片化し、トレーシングは機能しなくなり、システムは不透明になります。

エージェントは出力を生成し続けているかもしれませんが、システム全体としては把握が困難になります。

ローカルな修正がスケールしない理由

この段階での自然な反応は、問題をローカルで修正することです。あるチームはツール呼び出しの周りにログを追加し、別のチームはエージェントを認証チェックで囲み、また別の誰かがいくつかの箇所でリトライを追加します。これらの変更自体はどれも間違っていません。

しかし、それらを合わせると、以下のような脆い接着剤のようなコードの網が生まれます。

• エージェント間で挙動が微妙に異なる
• ポリシーが一貫性なく適用される
• デバッグに属人的な知識が必要となる
• 小さな変更でもリスクが高いと感じられる

これは、チームがスピードダウンを感じ始める時点です。エージェントがこれ以上できないからではなく、何かを変更すると予期せぬ結果が生じるためです。

チームが気づいているか否かにかかわらず、ここで現れているのはコントロールプレーンです。それは偶然に発生し、不十分に定義されているに過ぎません。

インフラストラクチャで実行を明示的にする

ここで、 TrueFoundry のようなプラットフォームが、エージェントのロジックとシステムの責任の間に明確な線を引きます。

With the Agent Hub, agents are no longer invoked implicitly through local function calls or hidden dependencies. They are registered, discoverable, and executed through a shared interface. With the Agent API、エージェントの実行が明示的、文脈的、かつ観測可能になります。

エージェントが密かに別のエージェントを呼び出すのではなく、実行が管理された操作として可視化されます。

# Using TrueFoundry's Agent API with registered MCP servers
import httpx

response = httpx.post(
    "https://{controlPlaneURL}/api/llm/agent/chat/completions",
    headers={
        "Authorization": "Bearer {TFY_API_TOKEN}",
        "Content-Type": "application/json"
    },
    json={
        "model": "openai/gpt-4o",
        "messages": [{"role": "user", "content": "Evaluate risk for transaction txn_123"}],
        "mcp_servers": [{"integration_fqn": "common-tools", "tools": [{"name": "web_search"}, {"name": "sequential_thinking"}]}],
        "stream": True
    }
)

# Connecting to MCP server through TrueFoundry Gateway
from fastmcp import Client
from fastmcp.client.transports import StreamableHttpTransport

async def main():
    url = "https://{controlPlaneURL}/api/llm/mcp/common-tools/server"
    transport = StreamableHttpTransport(
        url=url,
        auth="<tfy-api-token>",
    )
    async with Client(transport=transport) as client:
        tools = await client.list_tools()
        result = await client.call_tool("web_search", {"query": "What is Python?"})
        return result

注記：Agent Hub APIの契約は現在活発に開発中です。最新の構文と機能については、以下を参照してください。 エージェントAPIドキュメント.

これは小さな変更に見えるかもしれませんが、重大な影響を及ぼします。識別情報はリクエストとともに伝達され、実行境界は明確になります。下流のアクションは発生源まで追跡でき、ポリシーはエージェントが実行される前に評価され、問題が発生した後ではありません。

エージェントは引き続き推論し、何をすべきかを決定します。プラットフォームは、その決定が安全に実行される方法を処理します。

真の変化

エージェントが本番環境に導入されると、難しい問題はもはや知能に関するものではなくなります。それらは連携、識別、可視性、そして制御に関するものになります。これらの懸念事項はエージェントのコード内に属するものではなく、エージェント、ワークフロー、チーム全体に適用されるからです。

だからこそ、多くのチームは次に安易な解決策に走ります。エージェントの前にルーターを置き、それで十分だと期待するのです。

しかし、ほとんどそうではありません。

そのアプローチがなぜ失敗するのかを理解することが、真のエージェントインフラストラクチャがどのようなものであるべきかを理解するための次のステップとなります。

エージェント間システムで「ただのルーター」が破綻する理由

チームがエージェントシステムの管理が難しくなっていることに気づくと、最初の直感は通常、実用的なものです。つまり、エージェントの前にルーターを追加することです。

このアプローチは馴染み深いものです。APIゲートウェイやルーターはよく理解されています。マイクロサービスで機能したのだから、エージェントにも同じパターンを再利用しない手はありません。ルーティング層を前に置き、どのエージェントを呼び出すかを決定し、次に進むのです。

短い間は、これでうまくいきます。しかし、その後システムは、ルーターが処理するように設計されていなかった方法で歪み始めます。

ルーターが暗黙のうちに依拠している前提

ルーターは非常に特定の状況のために構築されています。リクエストは短命であり、実行パスはほとんど線形であり、識別情報は均一であるか、エッジで一度解決されると仮定しています。トラフィックを効率的に転送しますが、意図を理解しません。

エージェント間システムは、これらの前提にほぼ即座に違反します。

エージェントはリクエストに応答するだけではありません。アクションを開始し、他のエージェントに作業を委任し、時間とともに展開する副作用をトリガーします。単一の決定が複数の下流の実行に分岐し、即時実行されるものもあれば、遅延実行されるものもあります。識別情報はもはや単一のヘッダーではなく、ホップを越えて保持され、推論される必要があるものです。

ルーターはリクエストを転送できます。しかし、説明することはできません。 なぜ そのリクエストが存在するのかを。

ルーティングロジックが本来の範囲を超え始める時

エージェントシステムが成長するにつれて、チームはルーターにより多くの責任を負わせるようになります。認証ルールが追加され、モデル選択がルートに組み込まれ、ポリシーチェックがルーティングロジックにハードコードされ、コンテキストはヘッダーと慣習を用いてまとめられます。

これらのどれも、単独で見れば間違っているとは感じられません。しかし、時間が経つにつれて、ルーターは本来処理すべきではない懸念事項の掃き溜めと化します。そして、以下のような脆いボトルネックになります。

• 識別情報が明示的ではなく推測される
• ポリシーが散在しており、監査が困難である
• 動作の変更には協調的な再デプロイが必要となる
• 障害が最初のホップを超えると追跡が困難である

皮肉なことに、システムを簡素化するはずだったルーターが、全員の作業を遅らせるものになってしまいます。

ガバナンスがルーターの役割ではない理由

より根深い問題は、エージェントシステムがトラフィック管理だけでなく、ガバナンスも必要としているということです。

セキュリティおよびコンプライアンスチームは、どのルートがヒットしたかを尋ねません。彼らは、誰が、何を、どのような権限で、なぜアクセスしたかを尋ねます。プロダクトチームは、リクエストがどこに行ったかを知りたいだけでなく、決定がエージェントやツール間でどのように伝播したかを理解したいと考えています。オペレーターは、コストと動作がエッジだけでなく、ワークフロー全体でどのように変化するかを確認する必要があります。

これらの質問は、ルーティングだけでは答えられません。なぜなら、それらは意図、委任、および派生的なアクションに依存するからです。これらの概念は、ルーターには本来備わっていません。

明示的な制御によるルーティングからの脱却

ここで、ルーターとコントロールプレーンの区別が明確になります。

「 TrueFoundryのAgent Hubでは、エージェントはルーティングテーブルの背後にある匿名のエンドポイントではありません。それらは、明示的なインターフェースと所有権を持つ、名前が付けられ登録されたエンティティです。あるエージェントが別のエージェントを呼び出す際、それは不透明なネットワークホップではなく、管理された実行レイヤーを介して行われます。

エージェントAPI はこの分離を強化します。実行はルーティングの裏に隠されているわけではなく、ID、メタデータ、ポリシー評価が組み込まれた明示的な操作です。ゲートウェイは一貫してルールを適用し、エージェント間のやり取り全体でコンテキストを維持します。

これは柔軟性を奪うものではなく、むしろそれを取り戻すものです。ルーティングをトラフィックに集中させ、ガバナンスを専用のインフラストラクチャに移すことで、チームはルーティング層を脆弱なモノリスに変えることなく、エージェントの動作を進化させることができます。

避けられない結論

「単なるルーター」が失敗するのは、実装が不十分だからではなく、間違った問題を解決しようとしているからです。エージェント間システムは、より賢いエンドポイントを持つリクエストルーターではなく、自律的な動作を持つ分散システムなのです。

チームがそれを一度受け入れれば、次の認識は自然と導き出されます。エージェントシステムは分散システムのように振る舞いますが、より高いリスクを伴うということです。

エージェントシステムのためのコントロールプレーンとしてのエージェントハブ

チームがルーターだけでは不十分だと気づく頃には、別のパターンが自然と現れ始めます。小さな調整ロジックが至るところに現れ始めるのです。あるエージェントはツールを呼び出す前に権限チェックを追加し、別のエージェントはダウンストリームエージェントを呼び出す際にリトライロジックを組み込み、3番目のチームはアクションがトリガーされた後に何が起こったかを追跡するためにカスタムロギングを追加します。

これらの変更のどれも間違ってはいません。実際、それらは現実の問題に対する実用的な対応です。しかし、それらを総合すると、より深い問題を示唆しています。システムには コントロールプレーンが欠けているのです。

コントロールプレーンは、作業を行うことではありません。それは、 どのように 作業が行われることを許可するかどうかを決定することです。

エージェントシステムがコントロールプレーンを必要とする理由

エージェント間システムには、エージェントロジックの内部には単純に属さない疑問があります。

誰がこのエージェントを呼び出すことを許可されているのか？
どのような条件下で？
どのツールまたはMCPサーバーを使用して？
どの程度の可視性と監査性で？

これらの決定がエージェントに直接組み込まれると、それらは重複し、時間とともに乖離していきます。同じように動作すべき2つのエージェントが、徐々に異なる振る舞いをするようになります。ポリシーの適用に一貫性がなくなり、システムが実際にどのように統制されているかを反映する場所が一つもないため、デバッグは当てずっぽうになります。

これこそがまさに問題であり、 TrueFoundryのAgent Hub が解決するために設計されています。

エージェントを第一級のインフラコンポーネントとして

Agent Hubはエージェントを、プライベートな実装の詳細としてではなく、 登録され、発見可能なエンティティとして 共有システム内で扱います。Agent Hubは、以下のような機能を提供します。 

• モデルとMCPサーバーを使用したエージェント開発
• 非技術系ユーザー向けのエージェントアプリ 
• サブエージェントによるマルチエージェントワークフロー 
• 外部で構築されたA2A互換エージェントの統合
• チーム間でのエージェント共有とオーケストレーション 

各エージェントは、明確なインターフェース、所有権、実行境界を持って公開されます。他エージェントが、場当たり的なコードパスを介してその内部に直接アクセスすることはありません。それらは明示的にエージェントを呼び出します。

これにより、エージェント間の相互作用の性質が変わります。隠れた依存関係ではなく、関係性が可視化されます。暗黙の信頼に頼るのではなく、実行は管理されたレイヤーを通じて行われます。

これを視覚化するのに役立つのは、Agent Hubをシステムの中心に配置することです。

意図的なマルチエージェントワークフローの構築

システムが成長するにつれて、ワークフローが単純なままであることは稀です。あるエージェントは情報検索に特化し、別のエージェントは評価に、また別のエージェントは意思決定に特化するかもしれません。これらのエージェントは互いに置き換わるものではなく、協調して動作します。

Agent Hubは、サブエージェントとマルチエージェントワークフローを通じて、これを明示的にサポートします。単一の「メガエージェント」内にオーケストレーションロジックをハードコーディングするのではなく、チームはエージェントを制御された方法で連結することでワークフローを構成できます。

これには2つの重要な効果があります。1つ目は、個々のエージェントの焦点を絞り、理解しやすく保つことです。2つ目は、連携ロジックを一元化することで、エージェント間の相互作用の変更があっても、関連するすべてのエージェントを書き直す必要がなくなることです。

システムは進化しやすくなり、難しくなることはありません。

シャドーエージェントの台頭を防ぐ

一元化されたコントロールプレーンのもう一つの隠れた利点は、可視性です。多くの組織では、ガバナンスよりも速いペースでエージェントが増殖します。チームは必要なものを構築し、認証情報をコピーし、可能な限りどこにでもエージェントをデプロイします。時間が経つにつれて、どれだけのエージェントが存在し、どのようなデータにアクセスし、誰がそれらを所有しているのか、誰も正確には把握できなくなります。

Agent Hubは、エージェントが登録され、発見される共有の場を提供します。これはチームの作業を遅らせるものではなく、安全なデフォルト設定を提供します。公式の経路が簡単で可視化されていれば、隠れてエージェントを構築する動機ははるかに少なくなります。

開発を一元化せずに制御する

コントロールプレーンが何ではないかを明確にすることが重要です。それはすべてのロジックが存在する場所ではなく、チームがあらゆる変更について交渉しなければならないボトルネックでもありません。Agent Hubはエージェントに何を考えるべきかを指示しません。エージェントがシステムにどのように参加するかを定義します。

エージェントは依然として独立して推論します。チームは引き続き迅速にリリースします。しかし、エンゲージメント、ID、呼び出し、および連携のルールは、エコシステム全体で一貫して処理されます。

この分離こそが、エージェントシステムが成長するにつれて持続可能になる理由です。

コントロールプレーンが存在すれば、パズルの最後のピースが明らかになります。それは、実行がランタイムで強制され、監視される必要があるということです。ここでゲートウェイと明示的なエージェントAPIが登場し、次にそれらについて見ていきます。

エージェントAPIとゲートウェイ：エージェントの実行を管理可能にする

コントロールプレーンが存在すると、一つの疑問が避けられなくなります。 その制御は実際にどこで強制されるのか？

エージェントシステムでは、ID、ポリシー、ルーティングに関する決定は、エージェントが動作しようとするまさにその瞬間にランタイムで適用されない限り、意味がありません。ここでゲートウェイと明示的なエージェントAPIが重要になります。それらがなければ、コントロールプレーンは単なる助言に過ぎません。それらがあれば、現実のものとなります。

実行が明示的であるべき理由

エージェントシステムで最も一般的な失敗モードの一つは、目に見えない実行です。あるエージェントが別のエージェントをローカル関数として呼び出します。そのエージェントがツールを呼び出します。副作用が発生します。すべてが「機能している」ように見えますが、何がなぜ起こったのかを明確に把握できる人はいません。

問題は実行が間違っていることではありません。それが隠されていることです。

TrueFoundryの Agent API は、エージェントの実行を明示的にします。コードに埋め込まれた暗黙的な呼び出しの代わりに、エージェント間の相互作用はファーストクラスの操作となります。各呼び出しには、ID、コンテキスト、および意図が伴い、常に同じインフラストラクチャを経由します。

# TrueFoundry Agent API - explicit, governed agent execution
import httpx

response = httpx.post(
    "https://{controlPlaneURL}/api/llm/agent/chat/completions",
    headers={
        "Authorization": "Bearer {TFY_API_TOKEN}",
        "Content-Type": "application/json"
    },
    json={
        "model": "openai/gpt-4o",
        "messages": [{"role": "user", "content": "Search for information about Python"}],
        "mcp_servers": [
            {"integration_fqn": "common-tools", "tools": [{"name": "web_search"}]}
        ]
    }
)

注記：Agent Hub APIの契約は現在活発に開発中です。最新の構文と機能については、以下を参照してください。 Agent APIドキュメント。

この呼び出しは単純に見えるかもしれませんが、アーキテクチャ上の大きな転換点を示しています。エージェントはもはや単独で動作するわけではありません。その実行は仲介され、追跡され、管理されます。

ゲートウェイは単なるプロキシではなく、強制ポイントとして機能する

従来のシステムでは、ゲートウェイはしばしばトラフィックルーターとして扱われます。エージェントシステムでは、その捉え方は狭すぎます。ゲートウェイは単にリクエストを転送するだけでなく、 意図を強制する。

TrueFoundryのAIゲートウェイは、エージェント、モデル、MCPサーバーの間に位置します。すべてのエージェントの実行は、このゲートウェイを経由します。これにより、システムは何か起こる前にポリシーを評価できます。具体的には、エージェントが実行を許可されているか、どのツールにアクセスできるか、どのモデルを使用すべきか、そして何をログに記録または制限すべきか、といった点です。

すべての実行が共有ゲートウェイを経由するため、強制はデフォルトで一貫したものになります。すべてのエージェントがアクセスチェック、リトライ、ロギングを再実装する必要はありません。これらの懸念事項は、エージェントのロジックの外、本来あるべき場所に存在します。

安全なツールおよびMCPサーバーへのアクセス

ツールへのアクセスは、エージェントシステムが危険になることが多い点です。ツールはデータを書き込んだり、外部システムをトリガーしたり、元に戻せないアクションを実行したりできます。エージェントがツールを直接呼び出すと、認証情報やアクセスロジックがコピーされがちになり、セキュリティおよびコンプライアンスのリスクが生じます。

Agent APIはゲートウェイを介してMCPサーバーを統合します。これは、ツールが制御された条件下で呼び出されることを意味します。MCPサーバーがプラットフォーム内に登録されているか、外部から提供されているかにかかわらず、アクセスは仲介され、認証され、監視可能です。エージェントは、秘密情報を保持したりポリシーを迂回したりすることなく、必要な機能を利用できます。

これは、エージェント間のワークフローにおいて特に重要です。そこでは、あるエージェントの決定が下流の複数のツール呼び出しに連鎖する可能性があります。

オブザーバビリティとコストを第一級のシグナルとして

明示的な実行のもう一つの利点は、可視性です。エージェントの呼び出しが共有APIとゲートウェイを経由するため、動作をエンドツーエンドで追跡することが可能になります。チームは、どのアクションをどのアージェントが開始したか、どの下流のエージェントやツールが関与したか、実行にどれくらいの時間がかかったか、そしてどこでコストが発生したかを確認できます。

エージェントシステムにおいて、コストは単なる請求上の懸念事項ではなく、行動のシグナルです。推論のわずかな変更が、多数の呼び出しに波及する可能性があります。オブザーバビリティがなければ、チームはその増幅を理解したり制御したりする能力を失います。

明示的な実行は、その理解を取り戻します。

自律性を運用可能なものに変える

エージェントAPIとゲートウェイの目標は、エージェントができることを制限することではありません。それは、自律的な振る舞いを 運用可能.

エージェントは依然として独立して推論し、協調し、タスクを委譲します。しかし、それらはルールを強制し、結果を説明し、時間とともに安全に進化できるシステム内でこれらを行います。

この時点で、核となるパターンが明らかになります。エージェント間システムは、知能だけではスケールしません。自律性が、それを統治できるインフラストラクチャと組み合わされたときにスケールするのです。

そこで最後の疑問です。長期的に見て、エージェント間エコノミーにおける成功を実際に決定するものは何でしょうか？

インフラストラクチャがエージェントエコノミーを現実のものにする

エージェントの能力が向上し続けるにつれて、知能はシステムの最も面白くない部分になるでしょう。より良いモデルはアクセスしやすくなり、プロンプト技術は急速に広まります。今日高度だと感じるものは、明日には標準となるでしょう。

真の差別化要因は、個々のエージェントがいかに賢いかではありません。それは、周囲のシステムが制御を失うことなく自律性をサポートできるかどうかです。

エージェント間エコノミーは、新たな種類の複雑さをもたらします。決定はエージェント全体に伝播し、アクションは下流に影響を及ぼします。コストとリスクは、人間が介入できるよりも速く増幅します。インフラストラクチャがなければ、これらのシステムは不透明で、脆弱で、信頼しにくいものになります。

エージェントシステムを持続可能にするのは、エージェント内部のロジックを増やすことではなく、 関心の明確な分離：

• エージェントは推論とタスク実行に集中する
• コントロールプレーンはエージェントがどのように相互作用することを許可されるかを定義する
• ゲートウェイはランタイム時にID、ポリシー、アクセスを強制する
• 実行は観測可能で、追跡可能で、説明可能である

ここにプラットフォームの重要性があります。

TrueFoundryのAgent HubとAgent APIは、エージェントをより賢くしようとはしません。これらは、エージェントシステムが予測不能なスクリプトの集合体ではなく、適切に管理された分散システムのように振る舞うことを可能にする、欠けているインフラストラクチャ層を提供します。エージェントは発見可能で、構成可能で、運用可能になります。自律性はチームが信頼できるものになるのです。

エージェント間エコノミーは、ポイントソリューションや巧妙なデモによって勝利するものではありません。それは、スケールで自律性を信頼できるものにするプラットフォームによって構築されるでしょう。知能はコモディティ化し、インフラストラクチャが差別化要因となるのです。