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.

How does agent composability actually work, and how do multiple agents coordinate with each other?

A typical collaboration model needs a shared communication standard agents collectively follow — this standard usually defines what format to use when passing a task or result between agents, how to confirm the other party's identity (exactly the agent message spoofing risk discussed earlier in this series that needs guarding against), and how an agent that can't complete a delegated task should notify the delegating party. With this shared standard in place, originally independently developed agents can genuinely collaborate smoothly, rather than talking past each other.

In practice, this kind of collaboration chain usually has an agent playing a coordinator role, responsible for breaking the overall workflow into several subtasks, delegating each to a different specialized agent for execution, and consolidating each subtask's execution result into a complete output. Under this architecture, the coordinator agent's own reliability often determines the overall stability of the entire collaboration chain.

What's the practical impact of agent composability for everyday users, and how should it apply to evaluating DeFAI products?

If a DeFAI product you're using involves multiple agents delegating to and collaborating with each other behind the scenes, it means the risk you actually carry doesn't just come from the agent you directly interact with, but from every agent participating in this collaboration chain — a problem in any single link's agent (incorrect decision logic, or being deceived by the message spoofing technique discussed earlier in this series) could propagate through this collaboration chain to ultimately affect your outcome. When evaluating this kind of product, it's worth asking this team: how many agents does this collaboration chain involve in total, which teams developed each of them, and what's the identity verification mechanism between them.

In practice, a more practical mindset is treating how long and complex the collaboration chain this product involves is as a risk-amplification factor requiring extra caution — every additional link in the collaboration chain is one more node that could go wrong, echoing the attack surface concept discussed earlier in this series: a more complex system theoretically has more links that could be attacked or go wrong, worth factoring into your overall risk-profile assessment of this product too.