How to build your first multi-agent trading system

A multi-agent trading system splits trading logic into separate, specialized agents that each handle research, execution, or risk management. Developers connect these agents through a single API with scoped permissions so that no single agent can access every market or spend the entire budget. When built correctly, one agent can discover an opportunity while another enforces position limits and a third manages the exit, all without the owner giving up custody of funds.

What is a multi-agent trading system?

Instead of building one monolithic agent that tries to predict prices, route orders, and monitor risk, a multi-agent system assigns each task to a dedicated service. One agent might scan order books and news feeds to generate signals. Another might translate those signals into orders sized in plain US dollars. A third might continuously check total exposure across stocks, crypto, perpetual futures, options, and prediction markets. The Felix API normalizes venue-specific contract math so that the execution agent does not need to know whether it is trading a perpetual future or an option strategy. It submits a dollar amount and the API handles the normalization. This separation means you can update the research agent's model without touching the risk logic, or replace the execution layer without rewriting the strategy. The system is held together by a common interface and a strict rule that each agent receives only the data and permissions it needs to perform its role. Developers do not need to maintain separate integrations for a stock broker, a crypto exchange, and a prediction market. The single API surface reduces the attack surface and the maintenance burden. Each agent can be written in a different language or framework, as long as it can speak to the API or use the MCP tools. That flexibility matters when teams want to experiment with new models in Python while keeping the execution engine in a language with static types for reliability.

How do you split responsibilities between agents?

The most stable designs follow a pipeline pattern. The research agent sits at the top of the funnel. It reads market data, runs its models, and outputs a structured signal that contains a direction, a confidence score, and a recommended maximum allocation. It does not trade. It should not even hold a key with trading permissions. The execution agent receives the signal and decides whether the market conditions still support the trade. If the spread is too wide or the signal is stale, the execution agent discards it. Otherwise, it submits an order through the API. Some teams add a fourth agent dedicated solely to exit management. This agent watches time based or stop loss conditions and submits reduce only orders. Separating entry and exit logic ensures that a research agent chasing a new opportunity does not cancel a protective stop on an existing position. The risk agent operates independently. It polls the API for open positions, pending orders, and total budget consumption across all agents. If the research and execution agents together push the portfolio beyond a scoped limit, the risk agent can send a flatten command or revoke a scoped key. This split among three agents prevents any single prompt or model failure from causing an uncontrolled position. When you put too much logic into one agent, a single confused reasoning step can issue orders that bypass your own rules. This is why prompt design matters for safety. Keep each agent's prompt narrow and its authority narrower. In addition, consider adding a fifth administrative agent that handles key rotation and logging, so that human operators do not need to manually revoke access during a failure.

Why should each agent have its own scoped key?

Scoped keys are the primary defense in a multi-agent architecture. Each key is created with a specific budget cap, a list of allowed market types, and position limits. A research agent that only needs to read prices should receive a key with no trading permissions. An execution agent that trades perpetual futures should receive a key that cannot access stock brokers or options venues. If one agent is compromised or hallucinates a dangerous action, its key cannot affect the others. The owner approves withdrawal addresses in advance, and the agent can never add a new withdrawal destination. This architecture is non-custodial by construction; funds remain in the owner's wallet, and the agent can only spend within its scope. You can read more about the custody model in our guide to automating without giving up control. When an agent hits its cap, the API rejects further orders until the owner adjusts the limit or the risk agent rotates the key. Budget caps can be configured per day, per week, or per trade. Position limits prevent an agent from opening a second trade before the first is closed. These constraints are enforced by the API, not by the agent, so a bug in the agent code cannot override them. Key rotation is particularly important in a multi-agent system. If the research agent starts emitting nonsense signals, you can rotate its read key without interrupting the execution agent's ability to close existing positions. Each key can also carry a time to live, so that a long running agent must be reauthorized periodically. This prevents a forgotten test agent from running for months in the background.

How do you coordinate agents without shared state?

Shared mutable state is a common source of bugs in distributed systems, and trading is no exception. If two agents maintain their own local cache of position size, one can easily double the intended exposure while believing it is flat. The safest approach is to treat the API as the single source of truth for balances, positions, and open orders. Agents communicate through an immutable event log or a lightweight message queue. The research agent publishes a signal event. The execution agent reads the event, queries the API for current exposure, and then decides. The risk agent subscribes to the same stream and compares the intended action against its own rule set. If the risk agent sees that the execution agent already opened a position in a correlated asset on a different venue, it can publish a block event before the next order is sent. This design means agents do not need to trust one another; they only need to trust the API's state and the event ordering. Avoid letting agents write to a shared database that can drift during network partitions. Stateless agents are easier to reason about. If an agent crashes, it can replay the event log from the API and resume without requiring a local backup. This also makes it easier to run multiple instances of the same agent for redundancy, because each instance reads from the same API and event stream rather than fighting over a local lock file.

What does a basic implementation look like?

A minimal system can run as three separate processes or containers. The research agent runs on a schedule, emits signals to a queue, and sleeps. The execution agent waits on the queue, validates the signal against its own sanity checks, and calls the API. The risk agent runs continuously, checking aggregate exposure and budget burn. In practice, you should define the following for each agent:

• ·A narrow prompt that describes exactly one task
• ·A scoped key with permissions limited to that task
• ·A hardcoded maximum order size that is lower than the API cap
• ·An append only log for every decision and API response
• ·A health check endpoint or heartbeat that a watchdog monitors

The execution agent does not need to understand contract sizes, tick sizes, or margin tiers. It passes a plain dollar amount, and the API translates that into the correct quantity for the underlying venue. The risk agent might pass a reduce only flag to close a position without opening a new one. The exact request schema is in the docs; the shape looks like this.

{
  "key": "YOUR_KEY",
  "market_type": "perpetual_futures",
  "symbol": "EXAMPLE-PERP",
  "direction": "long",
  "usd_size": 200.00,
  "reduce_only": false
}

In practice, if the execution agent receives a signal to buy but the API returns an error because the scoped key has already reached its cap, the agent should log the failure and halt rather than retry aggressively. Retry logic that ignores rate limits or budget caps is a common source of unexpected losses. The execution agent should also validate that the usd_size in the signal is within its own hardcoded maximum, so that even a malformed message from the research agent cannot cause an outsized order. The risk agent should periodically emit a heartbeat message. If the heartbeat stops, the owner or an external watchdog should trigger the panic switch.

How do you test and shut down safely?

Before any agent touches a live market, run the entire system in paper trading mode. Paper trading lets you verify that the research agent emits signals, the execution agent formats them correctly, and the risk agent intervenes when limits are breached. Treat paper trading as a rehearsal for the kill switch, not just for profit and loss. Trigger the panic switch during a test session and confirm that every scoped key is revoked and all positions are flattened. Live trading requires explicit owner authorization of each key, and you should authorize only one agent at a time when you first transition. Do not flip every agent to live on the same day. Start with the risk agent in live read only mode, then add the execution agent with a small cap, and finally connect the research agent. The transition from paper to live is covered in detail in our guide to taking an AI trading agent live with MCP. You should also test correlated scenarios. Suppose the research agent sends three bullish signals at once for assets that tend to move together. The risk agent should catch the aggregate concentration and block the third signal. If your testing only checks one signal at a time, you will miss the most dangerous failure mode. Document the exact sequence of key authorizations. If you need to shut down a single agent while leaving others running, you must know which key belongs to which service. Labeling keys by agent name and creation date prevents accidental revocations. Remember that even with perfect automation, trading can lose money, including the entire allocated budget. The panic switch exists because markets move faster than any agent can reason. Test it until the shutdown sequence is boring, because in a real emergency you will not have time to debug.