One engine, two models: when to run an agent system vs a player platform

An agent system and a player platform run the same games over the same wallet and the same reporting. What differs is who the business sells to. The agent model sells capacity to people who bring their own players; the player platform sells the games to those players directly. Everything downstream of that one decision (onboarding, limits, marketing, support) follows from it.

That is why the choice is a commercial one before it is a technical one. The platform is capable of both on day one. What a business has to decide is which side of the counter they want to stand on, and whether they have the distribution or the marketing budget to stand there.

In an agent system, the platform issues credit and tools to a tier of agents, who issue them onward to their own sub-agents and players. Acquisition is not the platform's job; it belongs to the tree. The platform's job is the ledger: who owes what to whom, what commission has accrued at each tier, and what happens when a branch stops settling.

The upside is reach without marketing spend. The cost is that the platform's exposure is distributed across people they did not onboard themselves, which puts credit limits, settlement cadence and the ability to freeze a branch at the centre of the product rather than at its edge.

A direct-to-player platform inverts all of that. The business owns the relationship, the deposit and the retention curve. There is no credit to extend and no tree to settle: a player's balance is their own money, held in a wallet the platform controls, and the entire commercial question becomes acquisition cost against lifetime value.

It is the simpler ledger and the harder business. Every player has to be found, verified, funded and kept, which is why this model puts payments, KYC and lifecycle messaging where the agent model puts commission and credit.

The games do not care which model is running. The difference lives one layer up, in what a balance means. On the player side a balance is settled money. On the agent side it is a position inside a hierarchy, with a parent who may be liable for it and a commission that rolls up on every settled round.

Build the wallet so that an account can carry a parent and a tier without requiring one, and both models fall out of the same schema. Build it assuming a flat list of players, and adding agents later means a migration of every balance on the system.

Most teams end up running both, usually because a distribution network turns up an audience worth serving directly, or a direct brand meets a market it can only reach through local agents. Neither should require a second deployment.

The practical requirement is that the mode is a property of the account tree, not of the build. One integration, one reporting spine, one set of game contracts, with the agent-specific machinery inert on accounts that have no parent.

Ask where the players are going to come from. If the answer names people rather than channels, the agent model matches the business already in place. If it names campaigns, the direct platform does. Nothing else in the decision is as load-bearing as that.

The rest is sequencing. Start with the model your distribution already fits, and keep the second one on the same stack so it is a configuration change rather than a rebuild when it comes.