The challenge of capital allocation across bots
Once several bots share the same portfolio, deciding where capital should be available becomes a system-level problem.
Running several bots at the same time creates a problem that barely exists when operating only one.
They ultimately depend on the same finite resource: capital.
At first, it is tempting to treat every bot independently. Give each one a budget, define its rules and let it operate.
The difficulty appears when the portfolio starts behaving like a portfolio rather than a collection of isolated bots.
Independent bots share a constraint
Two bots may be logically independent while still competing for the same capital.
One may be active while another is waiting. One may need additional room while another has unused capacity. A decision that makes perfect sense locally can become inefficient when viewed globally.
This is where architecture and trading logic begin to overlap.
The platform needs enough isolation to keep behaviour understandable, but enough coordination to respect portfolio-wide constraints.
Local decisions need global context
A bot can make a reasonable decision based on its own state and still contribute to a poor portfolio-level outcome if broader constraints are ignored.
That does not mean every bot should understand everything happening elsewhere. Excessive coupling would create a different problem.
The challenge is deciding which information genuinely needs to be shared.
Capital allocation across bots is a good example of how systems become more difficult as they scale: the individual components may remain simple, while the complexity appears in their interactions.
Idle capital is not always wasted capital
One of the subtle parts of allocation is deciding what idle capital means.
Sometimes unused capital is a missed opportunity. Sometimes it is a safety buffer. Sometimes it is only waiting for a better setup. The answer depends on the state of the rest of the portfolio.
This is why allocation cannot be judged only by activity.
A system that keeps every unit of capital busy may look efficient while quietly increasing risk. A system that keeps too much capital unused may be safe but ineffective.
Coordination changes the product
Capital allocation is not only an internal calculation.
It affects what users can understand, configure and trust. If the platform reallocates capital, the rules need to be clear. If it refuses to allocate capital, the reason needs to make sense.
The product experience and the system architecture meet at this point.
Users do not need to see every internal decision, but they do need confidence that the platform is not moving capital arbitrarily.
Looking back
This problem pushed Oblivion further away from isolated bot thinking.
Managing multiple bots is not simply running the same idea several times.
Once the bots share capital, the platform has to reason about the portfolio around them.