Lifecycle 01 is one agent class on one asset class. The research question that follows is how a swarm that has proven itself on one lifecycle extends to the next without starting over. Our answer has three phases, and the second is where the interesting work is.
Phase one: prove one
The first phase is what we have described in this series. A single lifecycle, a single asset class, live capital, ten confirmed sessions. The purpose of phase one is to earn the right to phase two by demonstrating that the council, the ledger, the execution layer, and the post-trained model work together under real conditions.
Phase two: master and copy
The second phase introduces what we call the master and copy agent model. A master agent is one that has proven itself on a lifecycle, with its permission scope, its council policy, its tool bindings, and its exception history recorded in the ledger. A copy is a replication of that agent onto a new asset or strategy under the same control plane.
The insight is that most of what makes an agent trustworthy is not asset-specific. The gate structure is the same whether the ETF holds Bitcoin, gold, or equities. The council policy differs in its parameters, not its shape. The execution state machine is identical. The ledger is shared. What changes is the signal layer's models and the specific rules the post-trained model must internalize.
So the replication problem reduces to two research tasks. First, adapt the signal intelligence to the new asset's regime behavior. Second, extend the post-training set with the new lifecycle's rules and exceptions while preserving what the model already knows. Everything else copies.
The roadmap runs from Bitcoin ETFs to gold, equities, and futures basis, all on a single control plane with a single council and a single ledger. The customer sees one system running multiple lifecycles with consistent governance, not a collection of independent bots.
Phase three: open rails
The third phase opens the platform. Third parties deploy their own agents and their own lifecycles on OpenEXA rails, using the same council for governance and the same ledger for audit. Our own first general partner is the first customer of the platform, not the only one. The infrastructure is built to be licensed to additional managers.
This is the phase where the lifecycle test does its real work. Any process that passes all six traits can run on the rails, whether it is a letter of credit in trade finance, a securitization waterfall, an energy settlement, an order-to-wafer flow with export controls, or a pharmaceutical batch release. The architecture does not know or care that Lifecycle 01 was in finance. It knows that the process was multi-party, regulated, structured, exception-heavy, gated, and audit-bound, and it provides a layer for each.
What stays constant
Across all three phases, four things never change. Agents decide and code executes. No single agent sees the whole job. Nothing an agent believes can move what it is not permitted to. And anything that settles is written to a ledger nobody can edit.
Those four principles are the research contribution. The product is what happens when you hold them constant and let the lifecycles vary.