POKER AGENTS AND MATIZ: RULES, LEARNING AND EXPERIENCE AI Initiative lab Research implementation — A research programme and a browser practice application with distinct purposes. Separate backend experiments should not be presented as one deployed stack. Make decisions under uncertainty inspectable by separating correct game mechanics, learned behaviour, evaluation and the experience a person uses. How do we separate a correct game from a capable decision-maker? Poker provides a bounded setting in which uncertainty, decisions and consequences can be studied. Separating mechanics, policy and presentation prevents a convincing interface or an accurate probability calculation from being mistaken for a stronger agent. BUILDING BLOCKS Game rules and state Represents legal actions, cards, bets and payouts. This is the reference environment in which an agent acts. Receives: The current game state and a proposed action Produces: A legal transition, updated state and payout Observations Gives a policy the information available at a decision. Hidden information and future outcomes must not leak into the decision input. Receives: The information available to the acting player Produces: A policy observation without future or hidden state Reference and learned agents Provides different decision approaches for comparison, including exact references in small settings and learned policies in larger ones. Receives: Permitted observations and a fixed decision approach Produces: An action or action distribution for comparison Evaluation harness Compares agents under controlled conditions and against recorded or reference behaviour. Game correctness and decision strength are assessed separately. Receives: Candidate and reference play under controlled conditions Produces: Comparative results with their assumptions Mathematical tools Calculates hand comparisons, prices and probabilities under stated assumptions. Enumeration and simulation estimates are distinguished. Receives: Cards, rules and stated opponent assumptions Produces: An exact result where feasible or a labelled estimate Practice experience Presents drills, hand checking and app-generated or recorded play so a person can inspect the reasoning and compare choices. Receives: A practice situation, calculations or recorded play Produces: An inspectable experience for the person practising WALKTHROUGH 1. Choose the question Decide whether the work is checking game rules, comparing an agent or helping a person inspect a practice hand. Those questions require different references. A game engine passing a payout check does not show that its agent makes good decisions. 2. Construct a valid situation Validate the cards, bets, rules and available choices. For agent research, expose only the information that the acting player should know. For a hand calculation, record the person’s assumptions so the result remains conditional on them. 3. Use the appropriate decision path The mathematical path calculates under stated assumptions. The policy path produces a decision from a trained model. These are alternative responsibilities: entering a hand for a calculation is not the same as asking a neural agent what to do. 4. Observe the consequence In research, advance the reference environment and record the outcome. In practice, show the calculation, recorded play or agent action so it can be inspected. The research harness, browser application and separate backend experiments are not presented as one integrated deployment. 5. Compare and explain Check rules against independent references and compare policies under controlled situations. Keep uncertainty and opponent assumptions alongside the conclusion. A result can be useful for studying decisions without demonstrating perfect play or readiness for a different real-world task. ILLUSTRATIVE EXAMPLE — Illustrative practice flow A person enters a practice hand and an assumed opponent range. The mathematical path validates the cards and calculates the result under those assumptions, using an estimate where complete enumeration is impractical. The person sees the probability or price calculation and can change the assumptions. The result is conditional on the stated range and rules. It does not establish that the learned agent is strong or that the assumed range describes a particular opponent. Three related paths, with different jobs Research agents learn and are evaluated inside a defined game environment. Their value is examined through controlled comparisons, with game correctness tested separately. The mathematical practice path checks a hand under stated assumptions. It may enumerate outcomes or provide an estimate; the person can inspect and revise the inputs. The learned-policy practice path uses a fixed trained policy for app-generated or selected recorded situations. Ordinary play is not evidence that the application is learning a new opponent model. Separate backend experiments retain their own scope. What is learned, remembered or calculated? Learning: Policies are trained in research processes. The inspected practice app does not learn a new opponent model simply because someone plays it. Memory: Hand histories, session state and saved progress record what happened; they are not the same as a trained skill. Exact computation: Game legality, hand comparisons and enumerable outcomes are calculated. Sampled estimates and uncertain opponent assumptions must remain visible. Separation: A mathematical hand checker is not a neural recommendation engine. Research agents, the browser application and separate backend arena work retain distinct scopes. SCOPE A research programme and a browser practice application with distinct purposes. Separate backend experiments should not be presented as one deployed stack. Policies are trained in research processes. The inspected practice app does not learn a new opponent model simply because someone plays it. Hand histories, session state and saved progress record what happened; they are not the same as a trained skill. Game legality, hand comparisons and enumerable outcomes are calculated. Sampled estimates and uncertain opponent assumptions must remain visible. REMAINING QUESTIONS Perfect play or a general strength guarantee. General exploitability measurement for every large-game setting. Automatic learning during ordinary application use. Real-world decision readiness inferred from game performance. BOUNDARIES AND EVALUATION Mechanics versus policy: A correct payout replay validates mechanics, not the quality of an agent’s choices. Evaluation: Test legal state and payouts against a reference, then evaluate policy decisions in a separate controlled comparison. Imitation versus strength: Imitating recorded actions is different from demonstrating a strong decision policy. Evaluation: Separate imitation fit from performance against appropriate references and report the uncertainty of the comparison. Opponent dependence: A result against one set of opponents can fail against another. Evaluation: Vary the controlled opponent and situation sets, keeping assumptions and uncertainty beside the results. Calculation versus advice: A mathematical hand checker and a learned-policy practice path answer different questions. Evaluation: Trace each input to the calculation or policy path and check that the interface explains which result the person is seeing. Training versus ordinary use: A fixed practice policy should not be described as continuously learning from the user. Evaluation: Distinguish a saved session from a model update; associate any claimed learning with a separate training and evaluation record. Research-to-browser fidelity: A policy can behave differently after export or when its browser input representation changes. Evaluation: Compare research and browser policy outputs for the same permitted observation within a declared tolerance. Treat this as a validation responsibility, not an assumed passing result. These investigations connect human possibility, AI peers and shared environments. A bounded game can make a learning question testable; moving beyond the game requires a new account of the task and its risks. AI Initiative — public architecture guide.