"Thousands of autonomous units" can sound like marketing shorthand for "a big server somewhere." It isn't. It describes a real architectural choice: instead of building one monolithic bot that tries to do everything — decide, execute, watch itself, and enforce its own limits — ZeroLoss splits automation into narrow, single-purpose components that scale independently and can't exceed the authority they've been given.
Five kinds of units, five distinct jobs
Execution units do exactly one thing: place and manage trades within strict, predefined parameters. They don't decide whether the current market conditions justify more risk, and they don't report on their own performance — they execute, full stop. Risk control units run in parallel, enforcing exposure limits and protecting system boundaries independently of whatever execution is doing in the moment. Stability & health units handle uptime, exchange connectivity, and failover, so a single dropped connection or a brief exchange outage doesn't take down an account's automation entirely. Monitoring units observe and report on everything happening across the system, without ever having the ability to intervene. Governance units sit above all of it, enforcing policy and rule adherence at the system level.
Why split responsibility this way
The value of this separation is structural, not cosmetic: no single unit has enough authority to do something the system as a whole hasn't sanctioned. An execution unit cannot override a risk limit, no matter how favorable a trade setup looks in isolation. A monitoring unit cannot place a trade, no matter what it observes. If a rule needs to change — a tighter exposure limit during volatile conditions, a new safeguard after an edge case is discovered — that change happens at the governance layer, deliberately and traceably, not by quietly editing what an individual execution unit is allowed to do in the heat of the moment.
This also means failure is contained. If something goes wrong in one execution unit, it doesn't cascade into governance or into another account's execution units, because they were never architecturally connected in a way that would allow that.
Scaling without a bottleneck
Because units are narrow, they can scale independently of each other rather than as one indivisible system. Execution capacity grows with market activity and user growth. Monitoring capacity grows with the number of accounts being observed. Governance doesn't need to grow at anywhere near the same rate, because its job is oversight, not throughput. Nothing is sized for a worst case that rarely happens, and nothing becomes a single point of failure for everything else running on the platform.
What this looks like day to day
From your side, none of this complexity is something you need to manage or even think about. You connect an account, and the system routes your automation through the appropriate execution, risk, and monitoring units automatically. What you get is the outcome of that architecture — consistent, disciplined execution — without needing to understand the plumbing behind it. Understanding the plumbing is optional; it exists so that if you want to know how the reliability is actually achieved, the answer isn't "trust us," it's a specific, inspectable division of responsibility.
Read more about how this scales in practice in Automation at Scale.