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
AI Initiative lab
Poker agents and Matiz: rules, learning and experience
Make decisions under uncertainty inspectable by separating correct game mechanics, learned behaviour, evaluation and the experience a person uses.
Research implementation A research programme and a browser practice application with distinct purposes. Separate backend experiments should not be presented as one deployed stack.
The design question
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.
A view of the responsibilities
Follow the question to the right kind of evidence
- 01Choose the questionDefine the question
- 02Construct a valid situationKeep the responsibilities distinct
- 03Use the appropriate decision pathFollow the chosen path
- 04Observe the consequenceInspect what happened
- 05Compare and explainUse the result carefully
Across the flow
Start by choosing the question: checking game rules, comparing an agent or inspecting a practice hand. Each path needs its own reference and assumptions.
What each part is responsible for
The building blocks
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
Following one piece of work
How the flow fits together
01Choose 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.
02Construct 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.
03Use 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.
04Observe 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.
05Compare 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 · not a benchmark result
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 useful result: 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.
Reading the architecture accurately
Scope and status
What the work covers
- 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.
What this work does not establish
- 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.
Where the design must hold up
Boundaries and evaluation
| Boundary | Why it matters | How to examine it |
|---|---|---|
| Mechanics versus policy | A correct payout replay validates mechanics, not the quality of an agent’s choices. | 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. | 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. | 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. | 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. | 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. | 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. |