Integration architecture for operator deployments

Integration of poker bot software into operator infrastructure typically requires three components: a seat-allocation service that decides which account plays where, a kill-switch with a sub-second response budget, and a settlement layer that reconciles the bot's chip movements with the agent network. This page describes each component as a reference architecture, independent of any specific product.

Agent layer

The agent layer is the set of processes that operate player accounts at the table. In a thick-client deployment each agent process bundles perception, policy, and execution. In a server-routed deployment the agent process holds perception and execution, while policy is requested from a central engine. Agent processes are typically isolated per account or per small batch of accounts so that the failure of one process does not cascade to others.

An agent layer is parameterised by the rate at which it can accept new accounts, the rate at which it can reseat existing accounts when tables break, and the cost in operator time of bringing a fresh host online. A complete integration treats these three rates as service-level objectives and monitors them with the same priority as the engine's win-rate.

Seat-allocation service

The seat-allocation service decides which account joins which table. It consumes a stream of table descriptions — stake, format, seat opening — and a roster of available accounts, and emits assignment commands to the agent layer. The service typically optimises against three constraints simultaneously: account fitness for the stake, neighbor composition at the table, and exposure caps that limit how many of the operator's accounts share a table or a session window.

A seat allocator is implemented either as a rule engine over operator-defined heuristics or as a learned model trained on historical outcomes. The two are not mutually exclusive; in practice the rule engine acts as a safety wrapper around the learned component, vetoing assignments that violate exposure caps regardless of expected value.

Kill-switch

The kill-switch is the operator's last-resort mechanism for halting bot activity across the fleet. Its design budget is typically expressed as the worst-case time from operator command to all agents having ceased to act, including time to acknowledge sit-out or table-leave at the poker client.

Two implementations are common. A push-style kill-switch broadcasts a stop command on a dedicated channel that every agent process subscribes to; reliability depends on the channel's delivery guarantees. A pull-style kill-switch requires every agent to revalidate a permission token before each action; reliability depends on the agent's token cache TTL. Push is faster on the happy path, pull degrades more gracefully when network paths are disrupted, and operators often run both.

Settlement and reconciliation

The settlement layer reconciles chip movements observed by the agent layer with the operator's records and with the agent network's accounting. In private-club settings, settlement runs daily or per-session and feeds into the operator's share allocation with downstream agents. The layer is typically the integration's most operator-specific component, since accounting conventions differ across clubs and platforms.

A complete settlement layer produces an immutable per-hand log linking the bot's actions to the resulting chip delta, an aggregated per-account ledger, and an exception report for hands where observed chip movement disagrees with the expected outcome. Exception reports are the most common entry point for fraud and configuration-error investigations after deployment.

Deployment notes

Operators are advised to keep ownership of the kill-switch and the settlement layer in-house, regardless of how the decision engine and agent processes are sourced. Both components encode operator-specific policy and represent the operator's primary lever for risk control after deployment.

This reference describes a generic architecture. Real deployments add components for proxy and identity management, host orchestration, and behavioral telemetry; these are out of scope for this page.