Inside a Multi-Agent System: Architecture Notes for Crypto Builders

Picture a crypto company that sells to businesses and wants software that watches DeFi protocols, weighs liquidity, judges smart-contract risk, rebalances a treasury, flags odd transactions and even places trades under preset policies. One AI agent given all of that ends up carrying too much. It has to read market data, query chain infrastructure, assess risk, call APIs, make money decisions and sign transactions, all inside a single reasoning loop. Testing, scaling and securing a thing like that gets painful fast.

The usual answer is to split the work between specialised agents and put an orchestration layer on top. That's more than several language models chatting with each other. It's a software architecture in which model reasoning, application logic, data, tools, permissions and execution are kept deliberately apart. What follows walks through how the pieces fit and what builders of production systems in this space should weigh.

What counts as a multi-agent system

Several specialised agents cooperating on a task larger than any one of them could handle: that's the definition. A handy formula for a single agent:

Agent = AI model + instructions + context + tools + state + execution loop

Stack a second layer on it for the group:

Agents + orchestration + shared state + communication + policies

A treasury platform might field this cast:

1. A research agent that gathers protocol and market data.
2. A risk agent that judges contract, liquidity and protocol hazards.
3. A portfolio agent that compares opportunities and computes allocations.
4. A compliance agent that applies the company's business rules.
5. An execution agent that prepares and submits transactions.
6. A monitoring agent that confirms on-chain what actually happened.

Take this instruction: put $50,000 of USDC into the safest yield on offer, as long as the protocol satisfies the risk policy and execution costs stay under 0.5%. It needs several distinct skills, so the system turns it into a pipeline:

```text
User Request
     ↓
Orchestrator
     ↓
Research Agent
     ↓
Risk Agent
     ↓
Portfolio Agent
     ↓
Policy Check
     ↓
Execution Agent
     ↓
Blockchain
     ↓
Verification
```

Every agent tackles a small problem and none has to solve the whole workflow.

The layers of a production system

Seven parts show up again and again: an agent runtime, an orchestrator, shared state, a tool layer, a policy and security layer, execution infrastructure, and observability. Each answers a separate engineering question.

Agent runtime

The runtime runs one agent. In production an agent is more than a prompt going in and a response coming out. It behaves like a loop:

  ```text
Input
 ↓
Build Context
 ↓
Ask Model to Reason
 ↓
Choose Action
 ↓
Call Tool / Agent / Return Result
 ↓
Receive Result
 ↓
Update Context
 ↓
Reason Again
```

Say a research agent is asked to compare DeFi lending protocols. It would pull a list of protocols, fetch their current TVL, get lending rates, compare liquidity, pick the strongest candidates and hand them to the risk agent. The model supplies the reasoning, while the application around it controls what really executes. That boundary counts, because a model shouldn't do jobs that ordinary software does better. Multiplying $50,000 by 8.2% needs no LLM, since a plain function is quicker, cheaper and gives the same answer every time.

Orchestrator

The orchestrator is the control centre. It chooses which agent runs, what that agent is told, what runs next, which tasks can go in parallel, when the work is finished and what to do when an agent fails. There are two basic styles.

Model-driven orchestration. A supervising model picks the specialist it needs.

           ```text
        Supervisor Agent
              │
        ┌─────┼─────┐
        ▼     ▼     ▼
   Research  Risk  Analytics
```

The supervisor might think it needs protocol data first, so it calls the research agent, and once the result is back it decides it needs a security assessment and calls the risk agent. That's flexible, though routing can become unpredictable, extra model calls pile up and so do costs.

Code-driven orchestration. The application fixes the sequence.

```text
Research
   ↓
Risk Analysis
   ↓
Policy Check
   ↓
Simulation
   ↓
Approval
   ↓
Execution
```

This version is simpler to test and to keep under control.

Mixing the two. For B2B financial products the strongest setup often blends them. Let the model make judgments and let code apply rules. The model may conclude that protocol A offers the best risk-adjusted yield, while the application insists that anything above $50,000 needs a further approval. The AI recommends and the software enforces.

Shared state

Agents need to see what earlier steps produced. Feeding the whole conversation to each of them wastes effort, so the system keeps a structured record of the workflow instead.

For the USDC request that record would hold the asset (USDC), the amount (50000), the chain (Ethereum), a list of candidate protocols (Aave and Morpho), and three status fields (risk, policy and execution) that begin as pending, pending and not started.

The research agent fills in fields such as candidate protocols, yield results and market data. The risk agent adds a score and its security findings. The execution agent sees only what it needs to do its job. The shape is tidy:

               ```text
                Shared State
                    │
         ┌──────────┼──────────┐
         ▼          ▼          ▼
    Research      Risk     Execution
     Agent        Agent     Agent
        └──────────┼──────────┘
                   ▼
             Updated State
```

A shared record also makes a workflow far simpler to pause, resume, audit and debug.

Communication: handoffs and agents as tools

Agents collaborate in two useful ways. In a handoff, control passes from one agent to the next.

```text
Research Agent
↓
Risk Agent
↓
Portfolio Agent
```

Handoffs suit moments when responsibility changes: once market research is done, the risk agent owns the evaluation of the candidates. When an agent is used as a tool, one agent calls another and keeps control.

     ```text
      Supervisor
      /    |   \
 Research Risk Analytics
```

The supervisor can ask the risk agent to test a protocol against the company's criteria, get a structured answer and carry on. This helps when a single central agent has to merge several specialist opinions.

Tool layer

An agent can't touch a blockchain or database by itself. Tools are the connection. A crypto agent might be given blockchain RPCs, market data APIs, DEX aggregators, indexers, risk databases, wallet infrastructure and internal treasury systems, exposed through operations like get_balance(), read_contract(), estimate_gas(), simulate_transaction() and submit_transaction().

Give each agent the least access that lets it work. A research agent may only require read_market_data() and read_protocol_data(). An execution agent might get simulate_transaction() and submit_transaction(). Nothing justifies handing wallet or transaction rights to every agent, and narrow permissions limit the damage when one misbehaves or is compromised.

The line between AI and the chain

This may be the most significant design point for crypto products. Model output is probabilistic, whereas blockchain execution is deterministic and frequently can't be undone. So no agent should control the final transaction directly. A safer path runs like this:

```text
Agent Decision
     ↓
Schema Validation
     ↓
Policy Check
     ↓
Risk Check
     ↓
Transaction Simulation
     ↓
Authorization
     ↓
  Signing
     ↓
Blockchain
```

Imagine the agent decides to swap $50,000 of USDC for ETH. The execution layer should independently check whether USDC is an approved asset and ETH an approved destination, whether the amount sits within the user's limit, whether slippage is acceptable, whether the recipient is right, whether the transaction simulates cleanly and whether the user must sign off. The agent suggests an action, and a deterministic layer decides whether it may happen. Financial systems rest on that division.

Guardrails and failure handling

Wrap deterministic limits around every AI decision. A config might say: maximum transaction $50,000, maximum slippage 0.5%, minimum liquidity $5M, allowed chains Ethereum, Arbitrum and Base. A model can't talk its way past those numbers by phrasing an answer differently.

Remember too that valid structure isn't proof of correct content. An output like {"risk_score": 0.04} may be perfectly formed and still rest on completely faulty reasoning. A production system should check the format, the business rules, how fresh the data is, how reliable the sources are and the results of the final tool calls:

```text
Agent Output
     ↓
Schema Validation
     ↓
Business Validation
    ↓
Data Validation
    ↓
Tool Execution
    ↓
Result Verification
```

Idempotency. Consider a submission that times out. The agent may decide the transaction failed and try again, yet the first attempt might have gone through, which would duplicate a financial action. The execution service should give every request a unique id, say exec_829192, and tie it to the transaction that results. If the same request comes in again, the service returns the existing outcome and doesn't submit anything new. In money workflows this property is not optional.

Observability

Plain logs fall short for agent systems, because engineers need the whole decision path. For each step, capture which agent ran, which model it used, which tools it called with what parameters, what came back, which policies fired, how long each step took and which transaction finally went out. When a transaction fails, you should be able to say who made the decision, on what data, which policy approved it, how the transaction was built and what actually happened on-chain. Without that level of visibility, running these systems in production becomes guesswork.

Around the core, a production deployment has to add identity and access control, key custody, a store for state, throttling, monitoring, evaluation runs and an audit trail. A demo never shows these, yet they decide whether the thing works at enterprise scale.

Distributed systems with LLMs inside

The clearest way to see the challenge is to stop treating a multi-agent system as a bunch of chatbots. It's a distributed system where some decisions are made probabilistically by a model, so the classic concerns all still apply: state management, authentication, authorization, concurrency, retries, idempotency, failure recovery, data validation and observability.

The model is the reasoning layer and the architecture is the control layer. When real assets and irreversible transactions are at stake, that difference matters a great deal. A well-built system doesn't chase unlimited autonomy. It chases controlled autonomy: agents free to reason, cooperate and adapt, while deterministic software stays in charge of permissions, financial limits, validation and execution.

The takeaway

The value isn't in having several models. It lies in breaking complicated workflows into smaller, specialised units that can be controlled. For B2B crypto the principle can be stated plainly:

• Reasoning belongs to the agents.
• Data retrieval and operations belong to the tools.
• Coordination belongs to the orchestrator.
• Business rules are enforced by policies.
• Transactions pass through the execution layer, which controls them.
• Final settlement happens on the blockchain itself.

Once those responsibilities are separate, the system is easier to scale, test, secure and audit. The goal isn't to make AI look clever. It's to make complex AI-driven workflows dependable enough for production.