Growth by acquisition built the platform out of silos.
Ripple's product suite is a hybrid: homegrown products such as Ripple Payments, the Ripple USD (RLUSD) stablecoin, on- and off-ramps, tokenization, and Over-the-Counter (OTC) trading, plus capabilities absorbed through acquisition: vault, wallet, prime brokerage, and treasury management. Growth came fast; coherence didn't. A customer on two or more of them manages redundant identities tied to legacy records and operates across incompatible data models, with no single view of their global position.
Every product split 'balance' into its own pieces, and no two split it the same way.
The cost is structural. Each product defines its own account, balance, and transaction primitives, so a global view takes manual reconciliation, and the lifecycle the platform exists to deliver runs across products with nothing shared underneath: collect, hold and earn, exchange, pay out, tokenize, settle.
The deeper problem is a mental-model mismatch. The interfaces are action-centric, built around generic Send and Withdraw, but enterprise operators don't think in verbs. Treasury and operations teams anchor on entities and assets first: who they're transacting with, what they hold. The fix isn't more features; it's reorganizing the platform around objects.
One object model, a dual-system architecture, a context-aware shell.
One Ripple is three coordinated bets, made at the architecture level before any pixels. First, a Unified Object Model: one canonical definition for the handful of objects every product already has, replacing per-product schemas with a shared backbone. The data model under the interface is the product.
Standardize the objects underneath, and one coherent platform renders on top.
Second, a dual-system split. The System of Record is the structured, object-centric surface: every account, balance, and transaction as a defined record an auditor can drill into. The System of Action is an agentic layer that turns a stated intent into the right sequence of steps. Slow, deliberate standardization underneath; consumer-grade speed on top. Third, a context-aware shell: one navigation, rendered through a layered rule set of Environment, Entity, Entitlement, and Role, so a customer's surface reflects what they hold and what they're allowed to do.
The bet is alignment-heavy. Convergence means Product and Engineering agreeing on canonical definitions before shipping: slower than letting each team build another silo, and the only path that compounds instead of accruing more debt. I work as the architectural steward of that agreement.
Agents as co-pilots, not autopilots.
The System of Action raises the defining question of the next platform: how much should software act on its own when the actions are irreversible and regulated? My answer is a principle, not a feature. In institutional finance, an agent is a co-pilot. Its autonomy scales with consequence: reading and reporting run unattended, anything that moves value is previewed and approved first, and the most consequential actions stay with a human entirely. Every step is auditable and reversible where the rails allow, and all of it is bounded by the operator's compliance posture and entitlements.
An agent here is a co-pilot: it handles the routine on its own, and it waits for a human yes before anything that moves value.
That reframes the work from automation to governance. The agent is the natural way to orchestrate a workflow that crosses several products at once, but it earns trust by being transparent at every step and by stopping where the stakes call for a human.
Convergence is easy to pitch, hard to architect.
Go behind the build to see how the hard part gets built, the system reacting to who's looking, and where it takes the platform next.