A year into running automation at real scale — thousands of units across execution, risk, monitoring, and governance — a handful of lessons stood out clearly enough to be worth writing down honestly, including the parts that required rethinking assumptions we started with.
Narrow responsibility scales better than we initially expected
Splitting execution, risk, monitoring, and governance into genuinely separate unit types meant that scaling one layer never required re-architecting the others. Execution capacity grew with market activity and user growth without touching governance logic at all, and monitoring capacity grew independently based purely on the number of accounts being observed. We'd designed the system this way on the theory that it would scale cleanly; a year of real growth confirmed that theory held up under actual load, not just in planning documents.
Governance is where most real changes actually happen, and that turned out to matter more than expected
When a rule needs tightening — a more conservative exposure limit during a specific kind of market condition, a new safeguard after an edge case surfaces — that change happens at the governance layer, deliberately and with a clear record of what changed and why, rather than by quietly editing individual units in the moment they're running. On paper, this seemed like a reasonable architectural principle. In practice, over a year of operation, it turned out to be one of the most valuable properties of the system: every meaningful behavioral change is traceable to a specific governance decision, not buried in ad hoc adjustments to individual execution units under time pressure.
What we changed after the first few months
Monitoring unit density needed to increase faster than our initial capacity planning assumed, once real account growth started compounding rather than growing linearly. We'd underestimated how much observation infrastructure genuinely disciplined oversight requires at scale — it's tempting to treat monitoring as a lighter-weight layer than execution, and we found that assumption didn't hold once account numbers grew meaningfully. We corrected course by decoupling monitoring unit provisioning from execution unit provisioning entirely, letting each scale on its own actual growth curve rather than a shared assumption.
What held up without needing adjustment
The core separation between execution and risk control — the rule that an execution unit cannot override a risk boundary regardless of how a trade setup looks — never needed revisiting. This was the single most load-bearing architectural decision in the whole system, and a year of real trading activity across a large number of accounts didn't surface a case where that separation caused a problem or needed an exception carved into it. If anything, it's the property we'd point to first if asked what makes the architecture trustworthy rather than just efficient.
What this means going forward
Scaling further doesn't require rethinking the fundamental architecture — it requires the same discipline applied to provisioning each unit type independently as account growth continues, informed by what we now know about how each layer's real-world load actually behaves rather than how we initially modeled it. That's a more boring conclusion than a "we rebuilt everything" story, but it's the honest one, and it's the reason the system has stayed reliable through a genuine order-of-magnitude increase in scale over the course of the year.
More detail on how these unit types interact today is in Automation at Scale.