Agents recommend. Code calculates. Risk controls veto. Humans authorise. The execution service trades.
Why not one autonomous bot
The safest and most useful design is not a single autonomous trading bot. It is a controlled team in which specialist agents research and challenge ideas, while deterministic software enforces portfolio limits, validates orders and communicates with the broker.
Language models can produce persuasive explanations even when the underlying evidence is weak. Several agents may repeat the same assumption, so a majority vote is not a reliable safety mechanism. Risk limits must remain enforceable even when models, prompts or data feeds fail. And broker credentials should never sit with an agent that also researches ideas. The pattern this page describes is a multi-agent team - the same shape we use for other business functions, but with far stricter controls around money movement.
No agent should be able to both propose and authorise the same trade.
The recommended operating model
- A Chief Investment Officer (CIO) agent coordinates research and produces formal proposals.
- Independent research agents cover fundamentals, technical and quantitative signals, news and macro conditions.
- A red-team agent searches for contradictory evidence and hidden assumptions.
- A backtesting agent checks whether the strategy survives realistic historical testing.
- A portfolio manager assesses exposure, concentration and correlation with existing holdings.
- An independent risk engine can reduce or veto any proposed order.
- A restricted execution service - not an open-ended language model - connects to the broker.
- A monitoring and audit agent records decisions, fills, performance and policy breaches.
Where to start
Begin with end-of-day or swing trading, paper execution and mandatory human approval. That allows time to validate data and reasoning, reduces dependence on low-latency infrastructure, and creates an evidence base before any limited automation is considered.
Minimum viable team
| Capability | Initial component | Primary responsibility |
|---|---|---|
| Orchestration | CIO agent | Coordinate the process and create the final proposal |
| Research | Data, fundamental, technical and news agents | Produce independent, timestamped evidence |
| Challenge | Red-team agent | Find reasons the proposal may fail |
| Validation | Backtesting service | Check robustness, costs and bias |
| Capital allocation | Portfolio manager | Assess position size and portfolio impact |
| Safety | Deterministic risk engine | Approve, reduce or veto |
| Trading | Execution and reconciliation service | Submit approved orders and confirm broker state |
| Oversight | Human approval and audit | Retain accountability and review outcomes |
The eleven agent roles
1Chief Investment Officer (CIO)
Sets the permitted investment universe, time horizon and strategy rules. Assigns research tasks, checks that all required evidence is present, resolves conflicts between reports and writes the formal trade proposal. Does not override hard risk controls.
- Define eligible exchanges, sectors, liquidity and holding periods.
- Require evidence from all mandatory specialists.
- State the thesis, catalyst, invalidation condition and expected holding period.
- Reject incomplete or internally inconsistent proposals.
2Market data agent
The gatekeeper for prices, volume, corporate actions, financial statements, earnings dates and reference data. Other agents consume the same validated dataset rather than independently collecting figures.
- Attach source and timestamp metadata.
- Detect stale prices, missing bars, stock splits and abnormal values.
- Normalise identifiers, currencies and trading calendars.
- Stop the workflow when critical data is missing or stale.
3Fundamental analyst
Evaluates the economic quality and valuation of a company. Output is structured data plus a concise narrative, not an unbounded essay.
- Revenue, earnings, margins and cash-flow trends.
- Balance-sheet strength and debt serviceability.
- Valuation against history, peers and expected growth.
- Catalysts, competitive position and material company-specific risks.
4Technical and quantitative agent
Calculates trend, momentum, volatility, liquidity, factor exposure and entry/exit conditions. The mathematical work runs in tested code; the agent interprets the results.
- Relative strength and trend regime.
- Volatility, drawdown and liquidity measures.
- Support, resistance and thesis-invalidation levels.
- Correlation with current positions and factor crowding.
5News, sentiment and macro agent
Reviews company announcements, filings, earnings-call changes, sector developments and macro events. Must distinguish the publication date of an article from the date of the underlying event.
- Identify genuinely new information.
- Compare management language and analyst revisions over time.
- Flag scheduled announcements and event risk.
- Assess whether a catalyst may already be reflected in price.
6Red-team agent
Attempts to disprove every proposed trade. Searches for contradictory data, stale assumptions, crowded positioning, unrecognised event risk and plausible alternative explanations.
- What evidence contradicts the thesis?
- What would make the apparent signal disappear?
- Is the catalyst already priced in?
- What specific observation would invalidate the proposal?
7Backtesting and validation
Tests the strategy rather than merely checking whether the selected share rose historically. Models a decision process that could actually have been run at the time.
- Out-of-sample and walk-forward testing.
- Look-ahead and survivorship-bias controls.
- Delisted securities and realistic universe construction.
- Fees, spreads, slippage and execution timing.
- Parameter sensitivity and performance across market regimes.
8Portfolio manager
Converts individual ideas into a coherent portfolio. A sound trade may still be rejected if it adds excessive sector, currency, style or correlation exposure.
- Recommended allocation and capital usage.
- Sector, geography, currency and factor concentration.
- Correlation with existing holdings.
- Whether a new position should replace or reduce another.
9Independent risk engine - absolute veto
Applies deterministic policies stored outside model prompts. Approves, reduces or rejects an order. A language model can explain a risk decision, but must not be able to bypass it.
- Maximum position and strategy exposure.
- Maximum risk per trade, daily loss and portfolio drawdown.
- Minimum liquidity and maximum spread/slippage.
- Earnings, suspension and other event-risk restrictions.
- Duplicate-order, stale-price and kill-switch controls.
10Restricted execution service
Receives only validated, approved order instructions. Rechecks account state, market status, price freshness, approval identifiers and position limits before sending the order.
- Least-privilege broker credentials.
- Only approved instruments and order types.
- Records acknowledgements, fills, fees and slippage.
- Reconciles broker positions against the internal ledger.
11Monitoring and audit
Tracks open positions and the health of the whole system. Flags breached assumptions, unexpected exposure, data failures, reconciliation differences and agent decisions that require review.
- Monitor thesis and stop conditions.
- Produce daily P&L and exposure summaries.
- Track model, prompt, code and policy versions.
- Compare expected versus realised execution and performance.
The controlled decision workflow
Every proposed order passes through the same auditable sequence. A failed or missing stage stops the process rather than being silently ignored.
- Define permitted universe. Eligible exchanges, sectors, liquidity, holding period.
- Validate and timestamp data. All required data present, timestamped, within freshness limits.
- Run independent analyses. Fundamental, technical and news evidence, independently produced.
- Red-team the thesis. Objections answered or explicitly accepted as residual risk.
- Create formal trade proposal. Structured record with every required field.
- Backtest and validate. Strategy passes minimum robustness criteria.
- Assess portfolio impact. Position does not create unacceptable concentration or correlation.
- Risk approval or veto. Every hard limit passes; otherwise reduced or vetoed.
- Human approval. Human confirms instrument, side, size, price and rationale.
- Execute and reconcile. Broker order exactly matches the approved instruction.
- Monitor and audit. Internal positions, cash and fills match the broker record.
The formal trade proposal
Agents exchange structured records. Free-form prose may accompany a decision, but the following fields are mandatory so that risk, execution and audit services can validate the proposal automatically.
| Required field | Purpose |
|---|---|
| Instrument | Symbol, exchange, currency and instrument identifier |
| Action | Buy, sell, reduce, close or do nothing |
| Strategy ID | The approved strategy and version producing the idea |
| Thesis | Concise explanation of why the opportunity should exist |
| Evidence | Key fundamental, quantitative and news observations |
| Catalyst | Expected event or condition that may unlock value |
| Holding period | Expected minimum and maximum duration |
| Entry condition | Price or signal required before an order may be sent |
| Invalidation condition | Observable fact that proves the thesis is wrong |
| Exit plan | Profit-taking, time-based and risk-based exit conditions |
| Proposed allocation | Suggested capital and maximum loss |
| Portfolio impact | Sector, currency, factor and correlation changes |
| Residual risks | Risks that remain after controls |
| Confidence | Calibrated probability or confidence band |
| Data timestamp | Freshness and source lineage |
| Approvals | Research, validation, risk and human approval identifiers |
Example execution instruction
{
"symbol": "ABC",
"exchange": "LSE",
"side": "BUY",
"quantity": 100,
"order_type": "LIMIT",
"limit_price": 12.45,
"time_in_force": "DAY",
"strategy_id": "MOMENTUM_01_V3",
"risk_approval_id": "RISK-18267",
"human_approval_id": "HUM-90411"
}
Proposal acceptance checklist
- All market, financial and event data is timestamped and within freshness limits.
- The red-team objections and thesis-invalidation condition are recorded.
- A valid backtest or strategy-validation identifier is attached.
- Portfolio impact and every deterministic risk check have passed.
- The human approval matches the instrument, side, quantity and price limits.
- Approval identifiers are current and the execution instruction is schema-valid.
Risk controls and governance
Risk rules are explicit, version-controlled and enforced in code. Start conservative; modify only through a recorded governance process. These are design categories, not recommended investment limits.
| Control group | Examples |
|---|---|
| Pre-trade | Instrument whitelist, market-open check, stale-quote threshold, available cash, duplicate-order lock, position and sector limits, maximum spread, event restrictions. |
| Order | Permitted order types, maximum price deviation, time-in-force restrictions, approval expiry, idempotency key and order-rate limits. |
| Portfolio | Gross/net exposure, concentration, currency exposure, factor exposure, correlation clusters, daily loss and drawdown limits. |
| Operational | Broker/API health, data-feed status, clock synchronisation, reconciliation tolerance, credential rotation and emergency shutdown. |
| Model | Approved model/version list, prompt change review, confidence calibration, test fixtures, drift monitoring and rollback capability. |
| Human governance | Named owner, approval thresholds, incident procedure, periodic review, and a clear distinction between research and regulated client services. |
Mandatory kill-switch conditions
- Broker position differs materially from the internal ledger.
- Required market data is stale or unavailable.
- Unexpected orders or duplicate submissions are detected.
- A daily loss, drawdown or exposure limit is breached.
- The execution service cannot verify the active policy and approval versions.
- System clocks, authentication or audit logging are unreliable.
Regulatory boundary
A system used solely to support decisions about the owner’s own portfolio is different from a service that manages client money, arranges transactions, provides personalised recommendations or distributes commercial signals. Obtain UK regulatory advice before offering any of those services to others.
Deployment roadmap
| Stage | Exit criterion |
|---|---|
| 1 - Research mode | Agents produce reports and ranked watchlists. No orders are created. |
| 2 - Historical simulation | Run the complete decision process against time-consistent historical data. |
| 3 - Paper trading | Send simulated orders to a broker paper account and reconcile every fill. |
| 4 - Shadow mode | Run beside manual trading; compare proposed decisions with actual outcomes. |
| 5 - Human-approved live | Every live order requires explicit approval after risk validation. |
| 6 - Limited automation | Automate only specific, proven strategies within small, immutable limits. |
| 7 - Broader automation | Consider expansion only after a substantial live record and independent review. |
Practical first 30 days
- Week 1. Define the investment universe, holding period, data providers, trade schema and initial risk policy.
- Week 2. Build the data service, research agents and an append-only decision log. Generate reports only.
- Week 3. Add backtesting, portfolio exposure calculations, red-team challenge and deterministic risk checks.
- Week 4. Connect a paper broker account, implement order reconciliation and run daily supervised trials.
Metrics from day one
- Decision coverage - percentage of proposals with every required field and agent report.
- Data quality - stale, missing or conflicting records detected.
- Signal quality - hit rate, payoff ratio and calibration by confidence band.
- Portfolio quality - exposure, correlation and drawdown compared with policy.
- Execution quality - slippage, rejects, partial fills and reconciliation differences.
- Operational quality - failed workflows, manual interventions and time to recover.
Sources and further reading
- Financial Conduct Authority - Multi-firm review of algorithmic trading controls.
- FCA Handbook - PERG 13: Guidance on investment services and activities.
- FCA Handbook - MAR 7A: Algorithmic trading systems and controls.
- Interactive Brokers Campus - API order types.
- Interactive Brokers Campus - Client Portal Web API documentation.
Recommended design decision
Build the first version as a supervised swing-trading research and paper-execution system. Keep a human approval gate for every order. Require the system to demonstrate reliable data, reproducible decisions, realistic backtests and accurate reconciliation before live capital is introduced.
Related reading
- The agent roles we run - the specialist workers we lease into small businesses (PA, accountant, ops coordinator, content writer, bookings clerk).
- How it works - the three-step onboarding, from discovery to live agent team.
- What is an agent lease? - why leasing beats building your own team from scratch.
- Agent lease vs build-yourself - total cost, timeline and risk comparison.
- FAQ - common questions on cancellation, confidentiality and how briefing works.