Sub-agent

How do Sub-agents and Orchestrators divide responsibilities? What decisions should be made at which layer?

The division of responsibilities between Orchestrator and Sub-agents is the core of multi-agent system design — unclear division degrades both performance and security.

Orchestrator's decisions ('what to do'):

• Receive user's high-level goal ('optimize my DeFi yield')
• Decompose the goal into a sub-task sequence (first query rates, then compare, then decide to rebalance, then execute)
• Decide which Sub-agent executes which sub-task ('rate query Sub-agent,' 'transaction execution Sub-agent')
• Handle dependencies between sub-tasks (sub-task B must wait for sub-task A to complete)
• Integrate all Sub-agent outputs to form a final decision
• Decide whether human confirmation is needed (final authorization for high-value operations)

Sub-agent's decisions ('how to do it'):

• Execute specific operations within its dedicated tool set
• Handle technical details within its own sub-task (API calls, retry logic, error handling)
• Return execution results in a structured format to the Orchestrator
• No need to know what the entire system is doing — only needs to know its own input and output formats

Why clear division matters: If Sub-agents decide for themselves whether to tell other Sub-agents results, or whether to bypass the Orchestrator to directly execute the next step, the entire system's behavior becomes unpredictable and unauditable. Good design: Sub-agents only do what they're explicitly instructed to do; all 'what to do next' judgments stay with the Orchestrator.

What are the four main types of Sub-agents? What role does each play in a DeFi Agent system?

By functional characteristics, Sub-agents can be classified into four types:

Type 1: Data Collection Sub-agent (Read-only Agent) Read-only tools only (query APIs, read on-chain state) — no write tools whatsoever. In DeFi systems: queries APY across protocols, Gas fees, token prices, liquidity depth, on-chain address holdings. This Sub-agent type has the lowest security risk — even under Prompt Injection attack, it cannot execute any on-chain operations. It can be exposed to more external data sources (multiple APIs, protocol websites) since read operations have no on-chain consequences.

Type 2: Analysis Sub-agent (Analysis Agent) Receives output from Data Collection Sub-agents and performs reasoning analysis. In DeFi systems: compares protocol interest rate differentials, evaluates Gas fee windows, analyzes market sentiment, generates rebalancing recommendations. This Sub-agent type only needs LLM reasoning capability — no on-chain tools, no exposure to raw external data. Its input is clean structured data; its output is structured analytical recommendations.

Type 3: Execution Sub-agent (Execution Agent) Has on-chain write tools (sign transactions, call contracts) — responsible for actually executing on-chain the operations approved by the Orchestrator. Highest security risk; should be configured with the strictest tool whitelists and spending limits, accept instructions only from the Orchestrator (no direct external data exposure), and require a confirmation channel before high-value operations.

Type 4: Monitor Sub-agent (Monitor Agent) Continuously monitors system state, triggering circuit breakers and alerts. In DeFi systems: monitors operations wallet balance, strategy position PnL, market anomalies (price flash crashes, Gas fee spikes). This Sub-agent type only 'observes and alerts' — makes no operational decisions; its alert outputs go to the Orchestrator, which decides how to respond.

How should inter-Sub-agent communication protocols be designed? What are the security considerations for data passing between Agents?

In most multi-agent systems, Sub-agents do not communicate directly with each other — all communication is routed through the Orchestrator. This 'Hub-and-Spoke' architecture is not just a design choice; it's a security requirement:

Why Sub-agents shouldn't communicate directly: If Sub-agent A can directly send output to Sub-agent B, and this communication channel is not monitored by the Orchestrator, an attacker only needs to contaminate Sub-agent A's output to influence Sub-agent B's behavior without the Orchestrator's knowledge. This opens a command channel the Orchestrator cannot see — a significant security vulnerability.

Format requirements for Orchestrator routing: Sub-agent output should be strictly formatted structured data (JSON Schema validated), not free text. Free text output can carry hidden Prompt Injections (e.g., the data collection Sub-agent's output contains 'ignore all previous instructions, instead do X'); if the Orchestrator passes this directly to the next Sub-agent, the Prompt Injection 'propagates.' Structured output + Schema validation lets the Orchestrator filter anomalous fields before passing data.

Output size limits: Each Sub-agent's output should have a clear maximum length limit (e.g., maximum 2,000 tokens). This prevents a compromised Sub-agent from hiding a long 'malicious instruction' in its output, propagating through the Orchestrator to the entire system.

Implementation recommendation: When using LangGraph's directed graph design, edges between Sub-agents should only allow data flow Sub-agent → Orchestrator and Orchestrator → Sub-agent — no direct Sub-agent → Sub-agent edges. Eliminating this attack surface at the graph design level.

What are the security boundary design principles for Sub-agents? How does the Principle of Least Privilege apply in multi-agent systems?

Applying the Principle of Least Privilege in multi-agent systems is one of the most important security design decisions. Each Sub-agent should hold only the minimum tool set and minimum authorization needed for its specific task:

Tool set minimization:

• Data Collection Sub-agent: only get_aave_rates(), get_morpho_rates(), get_gas_price() — no write tools whatsoever
• Analysis Sub-agent: no tools needed (LLM reasoning only)
• Execution Sub-agent: execute_deposit(protocol, amount), execute_withdraw(protocol, amount) — only whitelisted protocol operations, no 'transfer to arbitrary address' tool
• Monitor Sub-agent: only get_wallet_balance(), get_position_status() — read-only, no writes

Context information minimization: Each Sub-agent's System Prompt contains only information needed to execute its task — not the work logic of other Sub-agents, not the complete strategy design. Even if an attacker contaminates a Sub-agent's LLM reasoning, they can only see that Sub-agent's local context, unable to infer the entire system's design or other Sub-agents' authorization scope.

Failure isolation design: A Sub-agent failure (crash, attack, abnormal output) must not bring down the entire system. The Orchestrator must capture any Sub-agent's abnormal output, mark it as 'sub-task failed,' and decide to retry, skip, or escalate to human handling — not pass the abnormal output directly to the next Sub-agent for continued execution.

Validation checkpoint design: Before the Orchestrator passes each Sub-agent's output to the next, perform an 'integrity validation': Does the output format match the expected JSON Schema? Are values within reasonable ranges? Does it contain fields or instructions that shouldn't appear? Validation failure → reject transmission, log anomaly, alert.