Agent Composability

What is agent composability, and how does it differ from the composability privilege escalation discussed earlier in this series?

The composability privilege escalation discussed earlier in this series addresses a single agent's authorization to multiple independent protocols, where because the protocols are composable underneath, the combined effect exceeds what you originally assessed — this risk's subject is the protocol, with the agent itself being a single executor in this scenario, just one interacting with multiple composable protocols. Agent composability addresses a completely different subject: here it's whether agents themselves can combine and collaborate with each other — Agent A completing a market analysis and directly passing the result to Agent B to execute a trade, Agent B then passing the execution result to Agent C for risk monitoring, forming a collaboration chain made up of multiple independent agents.

This means composability privilege escalation focuses on the risk of one agent facing multiple composable protocols, while agent composability focuses on the benefit and risk that the fact multiple agents can compose with each other brings — the latter is a higher-level architectural topic, the former a specific risk type underneath that architecture.

Why has agent composability become a direction for the DeFAI ecosystem's development, and what problem does it solve?

A single agent's capability range is inherently limited — an agent specializing in market analysis might not be good at concrete trade execution detail; an agent good at trade execution might not have professional risk-monitoring capability. If every DeFAI product required its own agent to have all these capabilities built from scratch, it would lead to massive redundant development and make genuine specialization at every layer very hard.

The solution agent composability offers is letting different teams each focus on building the layer they're best at, then using a standardized communication protocol to let these specialized agents delegate tasks to and call each other, composing into a more complete workflow — similar to the don't reinvent the wheel logic in software development, just with the unit being composed shifted from a code library to an agent with autonomous decision-making capability. This also gives the DeFAI ecosystem a chance to develop finer division of labor, rather than every team being forced to build a complete end-to-end solution itself.

エージェントの組み合わせ可能性は実際どのように機能し、複数のエージェント間はどう協調して協力しますか？

典型的な協業モデルには、エージェント間で共同遵守する通信標準が必要である——この標準は通常、エージェント間でタスクや結果を伝達する際にどんな形式を使うか、相手の身元をどう確認するか（これはまさに本シリーズで前述したエージェントメッセージのなりすましリスクで防ぐ必要がある環節である）、そしてあるエージェントが委任されたタスクを完了できない場合、委任側にどう通知すべきかを定義する。この共同標準があってこそ、元々それぞれ独立して開発されたエージェントが、互いに言い分を主張し合うのではなく、本当にスムーズに協業できる可能性が生まれる。

実務上、この種の協業チェーンには通常「コーディネーター」の役割を果たすエージェントが存在し、全体のワークフローをいくつかのサブタスクに分解し、それぞれ異なる専門エージェントに委任して実行させ、各サブタスクの実行結果を集約して最終的に完全な出力にまとめる責任を負う。このアーキテクチャの下では、コーディネーターエージェント自体の信頼性が、協業チェーン全体の安定性を左右することが多い。

エージェントの組み合わせ可能性は一般ユーザーにどのような実際の影響を与えますか？DeFAI製品の評価にどう応用すればいいですか？

もしあなたが使用しているDeFAI製品が、背後で複数のエージェントが互いに委任し協業している場合、あなたが実際に負っているリスクは、直接やり取りするそのエージェントからだけでなく、この協業チェーンに参加している全てのエージェントからも来ることを意味する——どの環節のエージェントに問題が生じても（判断ロジックの誤り、あるいは本シリーズで前述したメッセージなりすまし手法に騙されることなど）、この協業チェーンを通じて問題が伝播し、最終的にあなたの結果に影響を与える可能性がある。この種の製品を評価する際は、このチームに尋ねる価値がある：この協業チェーンには合計いくつのエージェントが関わっているか、それぞれどのチームが開発したか、互いの身元検証メカニズムは何か。

実際に応用する際、より現実的な心構えは、「この製品が関わる協業チェーンが長く複雑であるほど」を追加の慎重さが必要なリスク増幅要因として扱うことである——協業チェーンに環節が一つ増えるたびに、問題が起こり得るノードが一つ増える。これは本シリーズで前述した攻撃対象領域という概念と通じている：より複雑なシステムには理論上、攻撃されたり問題が起きたりする環節がより多く存在する。この要因もこの製品の全体的なリスク輪郭を評価する際の考慮に組み込む価値がある。