Market-Scanning Trading Agent
A 24/5 agent that maps the trading day, spots setups by an owner-defined rulebook and sends each idea to a review group with a marked-up chart — with order automation built, tested and deliberately switched off.
- Role
- Sole engineer — built on the owner’s specification and prototype
- Team
- Solo; the owner owns every rule, risk and go-live decision
- Timeline
- Oct 2026 – Ongoing
- Organisation
- XEOO (internal)
- Code
- Proprietary (employer)
- Reading time
- 6 min
A Python agent that scans 5-minute candles on gold and two US indices, posts each trade idea with a chart to a Telegram review group and follows every outcome. Built on the owner’s specification and prototype: 24 merged pull requests and four releases in its first week, with the suite growing from 90 to 323 test functions.
Overview
A small trading desk had a written rulebook and a working prototype: levels for the day, the setups worth taking and how to rank them. What it needed was a service that applies those rules every five minutes, around the clock, without ever drifting from them — and proof that the ideas are good before a single order is automated.
The agent maps each trading day, sends every idea to a review group with a marked-up chart, follows it to its result and records everything. Automatic orders exist, are tested and stay switched off until the evidence and the owner say otherwise.
The problem
- The rules belong to the owner and must behave identically live and in replay — any silent change is a defect.
- Market data, broker time zones and daylight-saving changes make “which candle is today’s” surprisingly hard.
- A laptop sleeps, a token is refused, a terminal restarts: the agent must notice, recover and say so.
- Real money is at stake, so automation must be impossible to switch on by accident.
Context & constraints
Work follows the owner’s backlog phase by phase — alerts, then proof by replay, then demo orders, then live trading only with written sign-off — with one ticket per pull request, a changelog line and acceptance evidence for each. The strategy files are frozen: I build around them, never inside them.
Approach
- Feeds — a broker interface with a practice-account price feed and a MetaTrader 5 adapter behind it, plus a high-impact news calendar; “no answer” is never mistaken for “nothing there”.
- Clock and session model — the trading day starts at 17:00 New York, and broker time is a configured rule applied per date across daylight-saving changes.
- Live orchestrator — scans every five minutes, sends the evening playbook and a Friday review, and after any gap re-scans every missed candle exactly as it was at the time.
- Alerts and review — each idea arrives in the group with its chart and plan; outcomes thread underneath as replies, and review buttons plus
/accuracyturn human judgement into a readiness score. - Proof — replay sharing the live engine, holdout months, one-change-at-a-time comparison, weekly live-versus-replay parity and gate reports.
- Execution (off) — interlocks that refuse real or netting accounts, prices checked against the broker before sending, every order read back, broker-side expiry and management every 20 seconds.
- Operations — heartbeats, a separate watchdog, a local dashboard with a kill switch, and one-command deploy kits for Linux (systemd) and a Windows server.
Key capabilities
- 24/5 scanning of 5-minute candles across three markets
- Ideas posted to a review group with a marked-up chart and the plan
- Outcomes tracked and threaded as replies: filled, targets, stopped, expired
- Review buttons and an accuracy readiness checklist
- Catch-up after any gap: missed candles re-scanned as they were
- Strategy switch with the alternatives tracked silently side by side
- Local dashboard: health, live prices, ideas, equity curve and a kill switch
- Order automation with interlocks — built, drilled on demo, switched off
Architecture
Data
Core
Output
Proof & safety
Feeds and a strict clock model feed a frozen rules engine; the orchestrator journals every idea, alerts the review group and proves itself against replay — with execution wired in but switched off. Select a component to trace its connections.
Key decisions
ADR-01Freeze the rules engine behind fingerprints
- Context
- The trading logic is the owner’s, and live behaviour must match replay exactly.
- Decision
- Hash the five engine files and snapshot full replays for six scenarios across three markets; any drift fails CI, and a rule change needs approval, a before/after replay and a deliberate update.
- Trade-offs
- Deliberate friction — even a genuine bug in the frozen code is raised with the owner rather than fixed quietly.
ADR-02Broker time as a rule, not a measurement
- Context
- The prototype inferred the server offset from the latest tick — which is stale during the daily pause, so the evening playbook could be an hour out.
- Decision
- A configured zone and shift, applied to every timestamp by its own date across daylight-saving changes; the live tick only checks the rule.
- Trade-offs
- The rule must be confirmed on the real broker around each clock change.
ADR-03Alerts first, automation later
- Context
- The owner wanted proof of accuracy before paying for a server or risking orders.
- Decision
- An alerts-only test phase on a free cloud tier and practice prices, with readiness gates fixed in advance; the order code stays in place, switched off.
- Trade-offs
- Practice prices are not the broker’s, so levels are re-checked before automation — but nothing built for the test is thrown away.
ADR-04Strategies as settings, measured side by side
- Context
- The owner asked to compare alternative strategies on the same live days.
- Decision
- Strategies are profiles; the dashboard requests a switch that the agent applies between scans, while the ones not running are journaled silently and never sent.
- Trade-offs
- More scanning work for a fair comparison; with orders on, a switch waits until the agent has nothing open.
Challenges
A sleeping laptop lost ideas
Problem. Each scan looked back fifteen minutes, so a simulated week with random sleeps caught only 7 of 15 ideas.
Solution. Re-scan every missed candle — up to twelve hours — as of its own time, send setups that are still tradeable as “late” and summarise the rest. Result: 15 of 15, with journals equal to their replays.
False alarms from a flaky feed
Problem. A single refused token failed a whole scan and sent a warning.
Solution. Retry it like a network error and warn only after ten minutes of failed scans, with a “scanning again” message on recovery.
Tests that failed only on Windows
Problem. A cache file could be stamped milliseconds in the future on Windows, so a fresh cache sometimes looked stale; text files were also read in a different encoding.
Solution. Tolerate two seconds of clock skew, copy fixtures as bytes, and pin CI runners to exact operating-system images.
A terminal that restarts
Problem. The agent connected to the trading terminal only at start-up, so it never recovered from a restart.
Solution. Check and reconnect on every loop, and report the terminal’s state through the health monitor.
Quality & delivery
Testing
- 323 test functions across 38 files, grown from the 90 in the owner’s prototype.
- Golden replay: five fingerprinted engine files and six snapshot scenarios guard against any drift.
- No look-ahead proof: every replayed idea must reappear when the data is cut at its alert candle.
- The owner’s published backtest is reproduced idea for idea from real data.
- CI on Linux and Windows: linting, the full suite, a MetaTrader import check on Windows and syntax checks for the deploy scripts.
Deployment
One-command kits for an Ubuntu server (systemd units for the agent, dashboard, a watchdog timer and nightly backups) and a Windows server (Task Scheduler). Updates run the test suite first and roll back automatically if it fails. Releases are git tags, so rolling back means installing the previous tag.
Outcome
- Test functions
- 323
- Up from 90 in the prototype
- Merged pull requests
- 24
- One backlog ticket each, 16–22 Oct 2026
- Releases
- 4
- v0.1.0 to v0.4.0
- Ideas caught after random sleeps
- 15 / 15
- Previously 7 of 15
The agent runs in its alerts-only test phase: ideas reach the review group, where every one is marked and counted towards the readiness score. Moving to a dedicated server and automated orders waits for the strategy to pass its out-of-sample validation gate — and for the owner’s written sign-off.
Lessons
- When the rules aren’t yours, the most valuable code is the code that proves you didn’t change them.
- Time zones are a domain, not a utility function.
- Build the dangerous feature early, test it thoroughly — and ship it switched off.
Building something similar?
Tell me what you’re working on — I reply to every serious message.
Related work
HR Inbox Agent
A Python agent that reads an HR mailbox through Microsoft Graph, asks a language model for a structured classification and draft reply, and lets deterministic code decide whether to send, save a draft or escalate to Slack.
- Python
- SQLite
- Docker & Compose
- LLM APIs
- Agent guardrails & evals
- AI gateways
- +1