Automated Investing — Target Architecture (founder’s mental model)
Captured from an iMessage conversation on 2026-04-10 after PM1 shipped. This is the long-term shape the project should grow into. The current single-threaded, single-process implementation is a staged step toward this, not the end state.
The five-agent vision
| # | Agent role | Responsibility |
|---|---|---|
| 1 | Strategy research agent | Brainstorm, prototype, and explore new strategy ideas. Reads the vault for prior work, pulls new data sources, runs exploratory analysis |
| 2 | Paper-testing agent | Take a candidate strategy from #1 and prove it out via backtesting / walk-forward / live paper trading. Applies the bias audit, the permutation test, and the discipline gates. Only promotes strategies that clear the gates |
| 3 | Execution agent | Run proven strategies on live capital. Handles the event loop, order routing, fill reconciliation, and real-money state |
| 4 | Monitor/risk agent | Watch executing strategies in real time. Sizes positions via Kelly (fractional), stops or retires strategies that blow through drawdown/variance limits, rebalances capital across active strategies |
| 5 | Reporting agent | Ongoing financial dashboards, P&L attribution, monthly summaries, tax-relevant records. Keeps the founder informed without requiring him to pull reports |
Principle: single-threaded now, multi-agent later, same interfaces
The founder’s explicit guidance: “single threaded staged approach is good for now though.” The current build is deliberately in one process, but the component boundaries line up with the future agent boundaries so a migration is additive, not a rewrite.
Current stack mapped onto the vision
| Future agent | What exists today | Gap to close |
|---|---|---|
| Strategy research | Me (Ray COO) + the autoinv package’s research utilities (data, stats, validation, portfolio). Vault has the roadmap, Halls-Moore, and the PM1 baseline doc | Needs: a “strategy candidate” schema so ideas can be handed off to the paper-tester without re-explaining them. Candidate format: question + hypothesis + entry/exit rules + data sources + expected Brier/Sharpe |
| Paper testing | autoinv.engine.Backtest event-driven orchestrator + autoinv.validation.BiasAudit + autoinv.stats.permutation_test + demo template script. Each strategy today is a ~100-line script plugging into the shared plumbing | Needs: walk-forward windowing (currently in-sample only), automated gate evaluation (Brier < 0.12, permutation test p < 0.05, bias audit PASS), a registry that tracks paper-trading history per strategy |
| Execution | autoinv.engine.SimulatedExecutionHandler (commission + slippage). The abstract ExecutionHandler base is already defined so a live version slots in without touching strategy code | Needs: concrete PolymarketExecutionHandler (requires wallet auth — out of scope until a strategy passes the gate), BrokerageExecutionHandler for equities, order state tracking, fills reconciliation, real-money idempotency guarantees |
| Monitor/risk | autoinv.metrics.drawdown_report + strategy_report. Nothing live-monitoring yet | Needs: Kelly-criterion position sizing (Halls-Moore Ch 12, deferred during consolidation pass), real-time drawdown watchdog, kill-switch criteria, per-strategy capital allocation with auto-rebalance |
| Reporting | Vault log.md + manual experiment writeups + iMessage/Discord updates | Needs: automated P&L dashboard, monthly summary generator, tax-relevant transaction log, performance attribution by strategy component |
Migration path — how single-agent becomes multi-agent
At each stage, the boundary that gets crossed is clear.
Stage 0 (now): Single process, single Ray session. I do all five roles manually. The autoinv package is the shared library everything uses. Consolidation pass complete.
Stage 1 (after first strategy passes the paper-test gate): Extract the paper-testing loop into a dedicated script that a scheduled job (/loop 1d /paper-test-active-strategies) can run without me in the loop. Monitor agent is still me, reporting is still vault writeups.
Stage 2 (after first real-capital deployment): Build the Monitor/risk role as a dedicated agent — small, stateless, runs on a schedule, reads the live execution state, makes stop/retire decisions. This is where the Kelly sizing lives. Execution is still a human-in-the-loop for the first few strategies.
Stage 3 (multiple live strategies): Execution agent becomes autonomous. Research is still manual (I do it in main session). Reporting gets a dedicated agent because the founder shouldn’t have to ask “how’s the portfolio doing.”
Stage 4 (mature system): Research agent is automated — pulls new data sources on a schedule, generates strategy candidates, hands them to the paper-tester. I supervise at a higher level.
Why this shape — and what it buys us
Halls-Moore’s event-driven architecture already decomposes backtesting along three of these five lines (Strategy, Portfolio, ExecutionHandler). The founder’s vision extends the decomposition upward (Research) and sideways (Monitor, Reporting). Both are natural.
The property we want to preserve: no single role should be load-bearing for the others. If the research agent goes down, existing strategies keep running. If the execution agent halts, the monitor agent detects it and alerts. If reporting crashes, nothing else cares.
This is the same property that lets me get away with single-threaded execution today: each concern is a separable module, so when we eventually fork them into processes/agents, the interfaces don’t change.
What NOT to do next (per founder)
- Don’t over-engineer upfront. Founder’s explicit note: “I tend to overengineer up front. As long as we have a path to mature this I’m good.” The staged approach is the right call.
- Don’t build agents for agents’ sake. Each agent split has to be justified by either (a) a load/scheduling constraint that demands parallelism, (b) a failure-isolation boundary, or (c) a specialization that the shared library can’t provide.
- Don’t skip paper-testing to chase live capital. The five-agent separation exists partly so the “execution” role can’t accidentally start before the “paper testing” role has cleared a strategy through the gates.
Related
- infrastructure-plan — the current tactical plan; this doc is the strategic vision above it
- Consolidation pass — what we’ve actually built so far
- PM1 baseline — the first real measurement against the discipline gate
- Halls-Moore — the event-driven architecture that the paper-testing and execution agents inherit
- SOUL.md — this vision respects the “skills → loops → dedicated instances → agent teams” layered execution model from SOUL, mapping most cleanly onto Layer 4 (agent teams)