How to build a multi-agent trading system through a single API

A multi-agent trading system runs several specialized AI agents through one API, with each agent handling a distinct market or strategy while operating under its own scoped permissions and budget limits. The owner keeps full custody of funds, and every agent is restricted by hard controls that prevent it from exceeding its assigned role or withdrawing capital. This setup lets different models or strategies work in parallel without interfering with each other, provided the key architecture and safety boundaries are defined before any live order is placed.

What is a multi-agent trading system?

Instead of relying on a single program to watch every market and make every decision, a multi-agent system splits the work across separate agents that each own a narrow slice of the problem. One agent might monitor macro news and place trades in a prediction market, while another runs a delta-neutral strategy in perpetual futures, and a third rebalances a long-only stock allocation. Each agent connects to the same underlying infrastructure, but they are not the same program. They may run on different servers, use different models, or follow different prompt sets. The unifying layer is the API, which normalizes order sizing in plain US dollars and translates those instructions into venue-specific contracts. This means the agent does not need to learn contract multipliers, tick sizes, or margin formulas for each venue. It submits a dollar amount, and the API handles the rest.

This separation is not simply about code organization. It is a risk control. If one agent hallucinates a signal or encounters a logic bug, the damage is contained to the budget and markets assigned to that agent alone. The rest of the portfolio continues to operate. This is a fundamental difference from traditional trading bots, which are often monolithic scripts that touch every market from a single loop. How trading agents differ from trading bots step by step covers that distinction in more detail. In a multi-agent setup, the owner remains the sole custodian of funds, and no agent can unilaterally change withdrawal addresses or move capital outside the system. The architecture is non-custodial by construction, which means the API provider never takes control of the wallet, and neither does any individual agent.

How do you assign roles and markets to each agent?

Before any agent receives a key, you should write a short charter for each one that defines its universe, its objective, and its hard constraints. The charter is not code. It is a plain-language contract that the developer, the risk layer, and the agent itself can reference. A typical charter states the eligible asset classes, the maximum number of concurrent positions, the allowed order types, and whether the agent may hold overnight exposure. If an agent is meant to trade prediction markets, its charter should say so explicitly, and it should not have access to options or stock brokers. The charter should also state the conditions under which the agent must pause, such as a drawdown threshold or a macro event, so that the API limits are not the only thing preventing it from trading into a storm.

When you divide labor, you have two common patterns. The first is market segmentation, where each agent is bound to a single asset class. The second is function segmentation, where one agent generates signals, another sizes positions, and a third handles execution. Function segmentation is more complex because it requires state sharing between agents, which introduces latency and coordination risk. For most developers starting out, market segmentation is the safer path. It limits the blast radius of a mistake and keeps the interaction graph simple. You can always add functional specialization later, once you have proven that the basic safety controls work.

A clear role definition also prevents agents from working against each other. Without it, you might find that a perps agent opens a short while a prediction market agent holds a correlated long, leaving the portfolio net flat but paying funding on both sides. Or two agents might spot the same signal and double the intended size because neither knows the other acted. Charters and market boundaries are the first line of defense against these conflicts. They also make debugging easier, because when an agent breaks its rules, you know exactly which charter was violated and which key to revoke.

• ·Define the exact markets and instruments the agent may touch.
• ·State the maximum number of positions and the maximum time any position may remain open.
• ·List the allowed order types and prohibit anything outside that set.
• ·Specify whether the agent can act autonomously or must wait for human confirmation above a threshold.
• ·Document the model version and prompt strategy so the behavior is reproducible.

How do scoped keys keep each agent within its own boundary?

Each agent in the system receives its own scoped key rather than sharing a master credential. The scope is the boundary that turns a single API into many isolated lanes. A key can be restricted by market type, by notional budget, by position size, and by operation type. For example, a key assigned to a prediction market agent might permit buy and sell orders up to five hundred dollars in notional value, with no withdrawal privileges and no access to perpetual futures. The API translates the plain dollar amount into the correct contract size at the venue, but the agent never sees that math. It simply submits a dollar value. This abstraction removes an entire class of errors where an agent miscalculates contract size and accidentally requests a position that is ten times too large.

This approach is non-custodial by construction. The funds live in a wallet the owner controls, and the scoped key only allows spending within the approved limits. Withdrawal addresses are owner-approved only, so an agent that is compromised cannot send funds to itself. Even if an attacker gains control of one agent's key, the scope limits the damage to that agent's budget. The other agents continue to trade, and the owner can revoke the compromised key without rotating the entire system. How to scope API keys for a trading agent that handles real money explains the mechanics of setting these boundaries.

Scopes also make auditing straightforward. Because each agent uses a distinct key, the owner can review which agent placed which order, how much of its budget was consumed, and whether it violated its charter. The logs are separated by key, so you do not need to untangle a shared history to find the source of an error. This separation is essential when you are running more than one strategy, because the failure modes of a momentum model and a mean-reversion model are different, and you want to identify them quickly. You can also rotate or retire one agent without generating new credentials for the rest of the system.

How do you size budgets and set kill switches for multiple agents?

Every agent should receive a budget cap that is a subset of the total portfolio, not a share of an open pool. If the total capital available is one hundred thousand dollars, and you run four agents, you might allocate twenty thousand to each and leave twenty thousand unallocated as a reserve. Once an agent consumes its allocation, the API rejects further orders from its key. This is a hard limit, not a warning. The agent cannot borrow against another agent's allocation or against the reserve. The reserve exists so that you have headroom to adjust allocations or absorb an unexpected drawdown in one strategy without liquidating another.

Position limits work the same way. An agent might be capped at two concurrent positions, or at a maximum notional of five thousand dollars per position. These limits are enforced at the API level, so even if the agent's logic requests a larger size, the request is blocked before it reaches a venue. For leveraged instruments like perpetual futures, the limit applies to notional exposure, not margin. A cap of five thousand dollars means five thousand dollars of notional value, regardless of the leverage offered by the venue. How an AI agent trades perpetual futures within hard limits it cannot cross describes how those boundaries are enforced.

Each agent should also have an exit plan and a panic switch. The exit plan is a set of conditions that trigger an automatic flattening of positions, such as a drawdown threshold or a time-based rollover. The panic switch is a manual or automated kill command that revokes the agent's key and cancels open orders. In a multi-agent system, the kill switch should be per-agent. If one strategy deteriorates, you can flatten it without touching the others. A global kill switch is also useful, but it should be a separate mechanism reserved for systemic risk. The key is to avoid a single point of failure where one agent's panic spills into unrelated strategies. You should test both switches in paper mode before you authorize live keys.

How do agents share state without interfering with each other?

When agents must coordinate, they need a shared source of truth that is not controlled by any single agent. A lightweight coordinator, which can be a simple database or a small state machine, holds the aggregate portfolio snapshot. Each agent reads the current exposure before it acts, and it writes its intended trade to a pending queue rather than sending it directly. The coordinator checks for conflicts, such as duplicate signals or offsetting positions, and then releases the approved orders to the API. This prevents race conditions where two agents act on the same signal within seconds of each other. The coordinator can also enforce a total portfolio exposure limit that is lower than the sum of the individual agent caps, ensuring you do not become overconcentrated even if every agent is within its own boundary.

The coordinator should not be another trading agent with its own budget. It should be stateless and deterministic, with no ability to place orders. Its only job is to sequence and validate. If it fails, the system should default to a safe mode where agents pause and await manual review. You do not want a coordinator that can override scopes or bypass keys. The API still enforces the scoped limits, so even if the coordinator makes a mistake, the individual agent keys act as the final gate. This layered defense is what keeps the system safe when complexity increases.

In practice, many multi-agent systems do not need a real-time coordinator. If the agents are segmented by market, they can run independently and report their positions to a dashboard that the owner reviews periodically. The owner then adjusts the charters or rebalances the budgets manually. This slower loop is easier to reason about and reduces the risk of automation conflicts. How to evaluate a multi-market portfolio managed by an AI agent offers a framework for reviewing that aggregated view without overcomplicating the architecture. Start with manual oversight, and add automation only when you have proven that the agents behave predictably.

What does the setup look like in practice?

The exact request schema is in the docs; the shape looks like this. A developer creates a scoped key for each agent, then attaches the key to the agent's environment. The agent interacts with the API through an MCP tool or a direct REST call, passing its key in the header and submitting orders in plain dollar amounts. The API handles the normalization, venue routing, and limit checks. The response tells the agent whether the order was accepted, rejected for exceeding a scope, or queued for review. The agent should handle each case explicitly rather than assuming success.

# Create a scoped key for Agent A (prediction markets only)
curl -X POST https://api.felix.trade/v1/keys \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "agent-prediction-markets",
    "market_types": ["prediction_markets"],
    "max_budget_usd": 5000,
    "max_position_usd": 1000,
    "allow_withdrawal": false
  }'

# Agent A places an order via MCP or REST
# The agent sends the notional amount in USD.
curl -X POST https://api.felix.trade/v1/orders \
  -H "Authorization: Bearer AGENT_A_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market": "prediction_markets",
    "side": "buy",
    "notional_usd": 250
  }'

This example shows the principle, not the final specification. The real fields and endpoints are documented in the docs. The key point is that each agent carries its own credentials, the API enforces the budget in US dollars, and the owner can revoke or modify the scope without changing the agent's code. Before going live, you should run the entire ensemble in paper trading mode. Paper trading exists for testing, and live trading requires explicit owner authorization of each key. Only after you observe the agents interacting correctly under simulated conditions should you authorize the keys for real money. Remember that trading can lose money, including everything, and multiple agents do not reduce that risk. They simply containerize it. Containerization is valuable, but it is not a guarantee of profit. The goal is to limit the scope of failure, not to amplify gains.