Pocket

Poker for humans and agents: WebMCP gives each player’s copilot live, seat-safe game state and returns its advice to the table, while the human makes every move.

Comment

Inspiration

Most web applications are built for people. When an AI agent tries to help someone use one, it often has to reconstruct what is happening from the page, or depend on the user to explain everything correctly.

I wanted to explore a different model: what does an application look like when a user can bring their own agent with them, and the application is designed to work with it?

Poker turned out to be a great environment for testing that idea.

A poker decision can depend on public information like the board and pot, private information like your hole cards, the complete history of the hand, exact rules about which actions are legal, and a game state that may change while an agent is still thinking. There are also multiple people interacting with the same application, each with a different view of what they are allowed to know.

But there is another kind of context too: information that belongs to the player rather than the poker application.

Your agent might know how you like to play, strategies you've been working on, your appetite for risk, previous hands you've discussed, or your own observations about the people you're playing with. Pocket shouldn't need to own that information in order for it to be useful.

That led to Pocket: a playable Texas Hold'em game where every seat can have two minds - the player and their AI copilot.

What it does

Pocket lets you play Texas Hold'em against bots or with other people while using a compatible AI agent as a copilot during the hand.

Normally, asking an AI for poker advice means explaining your cards, the board, pot, stacks, previous betting, and what you can do next. Pocket already knows all of those things, so it exposes them directly through three WebMCP tools:

  • get_current_situation gives the agent the exact current game state, including the player's private cards, board, pot, stacks, whose turn it is, and the legal actions with precise raise limits.
  • get_hand_history gives the agent Pocket's authoritative record of how the hand reached the current situation.
  • stage_recommendation lets the agent send its recommended move and explanation back into Pocket's Copilot panel.

That creates a full application → agent → application loop. Pocket supplies the facts about the game, the agent reasons over them, and its recommendation comes back into the interface where the player is actually making the decision.

The important part is that Pocket doesn't have to be the agent.

A user can bring an agent that has its own context, preferences, memory, or way of reasoning and combine that with authoritative state supplied by the application at the moment it's needed.

Pocket knows the table. Your agent can know you.

That separation is especially interesting to me from a privacy perspective. Personal strategy, notes about other players, previous conversations, and other private context don't need to become part of Pocket's user profile or database just so an AI feature can use them. The application can expose what it knows, while personal context can remain with the user's chosen agent.

I also deliberately did not give the agent a tool for folding, checking, calling, or raising. It can recommend a move, but the player still has to make it.

The goal is a copilot, not an autopilot.

How I built it

Pocket is built with Next.js, React, and TypeScript.

At the center is a Texas Hold'em game engine that owns the authoritative state of each hand and determines which actions are currently legal.

One of the most important architectural decisions was creating a seat-safe view of that state. The engine itself needs to know everyone's cards, but a player's interface, and their copilot, should only receive the information that particular player is entitled to see.

The visible game and the WebMCP tools are both derived from that same player-safe state. That means the agent isn't getting a privileged version of the game behind the scenes.

I kept the WebMCP surface intentionally small. The three tools basically correspond to three useful questions:

  1. What is happening right now?
  2. How did we get here?
  3. What does the agent recommend?

Pocket also tracks the game, hand, and state version. When the agent returns a recommendation, Pocket verifies that it still belongs to the current situation before displaying it. If someone has acted and the table has moved on, the old recommendation is rejected instead of being presented as current advice.

Beyond the WebMCP integration, I built bot games, real-time multiplayer rooms, persistent game sessions, responsive table layouts, game history, visible copilot activity, and a deterministic demo flow so the complete interaction can be experienced reliably.

Pocket is deployed on Vercel, with unit, integration, and browser tests covering the poker flow, privacy boundaries, WebMCP contracts, multiplayer behavior, and the end-to-end demo.

Challenges I ran into

Keeping private information private

Poker made the permission problem impossible to ignore.

The engine has to know everyone's cards, but a particular player obviously shouldn't. I didn't want to expose the raw game state and trust the agent not to use fields it wasn't supposed to see.

Instead, I built a seat-specific projection that only contains information available to that player.

There were some less obvious cases too, like showdown, where cards that were private earlier in the hand may legitimately become public.

Multiplayer also made this feel like more than a theoretical concern. Every player can occupy the same shared game while still having a different private view of it, and potentially a completely different copilot with its own private context.

Keeping recommendations synchronized with a live game

Poker state can change quickly, and the game doesn't stop while the agent is thinking. A recommendation could be correct when the request starts but already be stale by the time it comes back because another player acted or the hand moved to the next street.

I solved that by explicitly versioning the state and binding each recommendation to the game, hand, and exact state it was created from. Pocket validates that again before showing the recommendation.

Keeping the WebMCP lifecycle stable

This caused one of the more frustrating bugs during development. The table's React state changes constantly as players act, turns advance, and cards are dealt. My first implementation tied the WebMCP tool registration too closely to that changing state, which meant tools could be repeatedly removed and registered during normal gameplay.

I eventually separated the stable tool lifecycle from the changing game data. The tools stay registered while the table is active, but read the latest authoritative state whenever they are invoked.

Deciding what the agent should actually be allowed to do

I could have exposed a tool that lets the agent make the poker move itself. Technically, that would have been pretty easy. But that isn't the interaction I wanted Pocket to demonstrate.

There is an important difference between giving an agent useful capabilities and handing over every consequential action. stage_recommendation became that boundary: the agent can participate visibly in the live application, but the final move still belongs to the player.

Making the integration visible without turning Pocket into a developer demo

A technically correct tool exchange isn't automatically understandable to the person using the product.

I spent a lot of time iterating on how the table, game history, player controls, WebMCP activity, and Copilot panel fit together. I wanted someone looking at Pocket to understand that an agent is actually participating in the application without making the entire product look like a tool inspector.

Accomplishments that I'm proud of

I'm most proud that Pocket doesn't just demonstrate an agent calling a tool. It demonstrates a much richer relationship between an application, a user, and the agent that user chooses to bring with them.

Pocket is a real multiplayer game with real hidden information, changing state, history, rules, permissions, and decisions. That gave me a chance to explore several things I find genuinely exciting about WebMCP in one product.

A player's copilot doesn't have to guess what is happening from the screen. Pocket can give it the exact state of the game and the exact actions that are legal. At the same time, that agent only receives the private information its player is entitled to see. In a multiplayer game, every person can be looking at the same shared table while their agent receives a different, permissioned view of it.

The application can provide the things it is authoritative about; the cards, pot, stacks, rules, hand history, and current state, while the player's own agent can bring context that may be far more personal: how they like to play, strategies they are working on, previous hands they have discussed, observations about other players, or anything else they have chosen to share with that agent.

Pocket never needs to become the database for all of that personal context just to provide a useful AI experience.

I also wanted the integration to genuinely go both directions. The agent isn't just reading structured data and replying in a separate chat window. It can send its recommendation back into Pocket, where it appears in the context of the decision the player is making.

And even then, Pocket keeps a clear boundary around authority. The agent can understand the situation and participate in the interface, but it cannot make the poker move. The human still decides.

The smaller technical details reinforce the same idea. Legal actions come from the game engine rather than model interpretation. Recommendations are tied to an exact game state and rejected if the table has moved on. Hidden cards stay hidden. The hand history gives the agent access to how the current situation developed instead of just a snapshot of the present.

Taken together, those pieces made Pocket feel like a demonstration of something much bigger than AI poker.

Pocket is an early example of what software can look like when applications expose trustworthy, permissioned capabilities to user-chosen agents, without requiring the application to own the agent, the agent to scrape the interface, or the human to give up control.

What I learned

The biggest thing I learned is that giving an agent structured data is only the beginning.

Once an agent is participating in a real application, you have to answer several different questions:

  • What does the application know?
  • What does the user or their agent know?
  • Which information is this particular agent allowed to receive?
  • Which system is authoritative when they disagree?
  • Is the information still current?
  • What should the agent be allowed to send back or change?
  • Which decisions should remain with the person?

Poker concentrates all of those questions into a single hand.

I also became much more convinced that good agent tools should represent meaningful concepts in the product rather than low-level UI operations.

For Pocket, the useful interface ended up being surprisingly small: What's happening? How did we get here? What do you recommend?

The agent doesn't need DOM access to every chip or button. It needs a trustworthy interface to the concepts that matter.

That's probably the broader WebMCP idea I'm taking away from the project: applications can have an interface for people and, alongside it, a deliberately designed interface for the agents those people choose to use.

What's next for Pocket

Poker is the example, but the interaction model behind Pocket is the part I'm most interested in.

A lot of AI features today assume the application itself also needs to own the assistant, its memory, and the user's relationship with it. Pocket explores a different possibility.

The application can be really good at the things it uniquely knows: its current state, rules, permissions, history, and available capabilities.

The user's agent can bring the things that belong to the user: their preferences, personal history, accumulated context, and way of thinking.

WebMCP can provide the boundary between them.

That starts to make "bring your own agent" feel less like attaching a chatbot to every website and more like a different way for software to work together.

Pocket is my attempt to make that idea concrete.

The application supplies the truth. The agent brings the context and intelligence. The human makes the move.

Built With

Share this project:

Updates

Submission history