NextPlay

Call the play. Lock your vision. Let AI replan the rest.

Comment

NextPlay

Call the play. Lock your vision. Let AI replan the rest.

Inspiration

Basketball play design is collaborative by nature: a coach sketches an idea, tests the timing, changes a screen or route, and keeps refining until the sequence works.

But most AI tools break that workflow. They generate a diagram, description, or recommendation somewhere outside the actual product. Once the coach edits the board, the AI no longer understands the current state—or which decisions are intentional and must not be overwritten.

We built NextPlay around a simple question:

What would a basketball tactics board look like if the coach and an AI agent could work on the same live play?

WebMCP made that possible. Instead of relying on screenshots or a hidden copy of the play, the page exposes structured tools that let the agent read and modify the exact state the coach is viewing.

What It Does

NextPlay is a browser-native basketball tactics board for human–AI collaboration.

A coach can ask an agent to create a sideline out-of-bounds play for a right-corner three. The agent:

  1. Reads the current formation, clock, actions, locks, and revision.
  2. Adds six structured basketball actions.
  3. Validates the play against deterministic execution constraints.
  4. Animates the result directly on the court.

Then the coach can intervene through the normal interface.

In our core demo, the coach:

  • Moves A3’s screen to the right_elbow.
  • Locks A3.
  • Locks O2’s route in A4.
  • Shortens the clock from 4.2 seconds to 2.0 seconds.

That creates a clock-overflow error because A6 finishes too late.

The agent then rereads the live page, sees the coach’s edits and locks, and retimes only the unlocked pass and shot in A5 and A6. A3 and A4 remain unchanged, the repaired play passes all seven validation checks, and the final animation completes within the new two-second clock.

That second turn is the heart of NextPlay: the AI does not start over or overwrite the coach. It adapts around the coach’s decisions.

Why WebMCP Matters

The important state in NextPlay is live and page-local:

  • Current player positions
  • The action timeline
  • The shortened clock
  • The selected action
  • Coach-made edits
  • Locked actions
  • Validation results
  • The current play revision

A generic assistant would have to infer that state from pixels, manipulate small controls, or work from an outdated description.

NextPlay instead exposes exactly five semantic WebMCP tools:

  1. get_play_state
  2. add_play_actions
  3. validate_play
  4. animate_play
  5. update_play_action

There is deliberately no agent tool for locking or unlocking actions. Locks are a coach-only authority boundary.

This means the coach remains in control while the agent handles structured construction and replanning.

How We Built It

NextPlay is built with React, TypeScript, Zustand, Zod, Vite, and Vercel.

We designed the application around one architectural rule:

Every persistent mutation—whether initiated by the coach or the agent—must pass through the same command and transaction layer.

The WebMCP tools do not maintain a separate copy of the play. Their handlers call the same application commands used by the visible coach interface. As a result, agent changes immediately appear on the:

  • Court
  • Timeline
  • Action inspector
  • Validation panel
  • Activity rail

Each successful content mutation increments the play revision exactly once. Write tools can include an expected revision, allowing NextPlay to reject stale updates when the page has changed since the agent last read it.

We also implemented atomic action batches. When the agent creates the initial play, all six actions are accepted together or none are committed.

The validation engine checks deterministic structural properties such as:

  • Whether all actions fit within the clock
  • Whether one player has incompatible overlapping actions
  • Whether referenced players and actions are valid
  • Whether possession order is consistent
  • Whether the play contains the required inbound pass and shot
  • Whether locked coach actions were preserved

NextPlay does not claim that a play is tactically optimal, likely to score, or physically realistic. It validates the structure and timing of an animated tactical diagram.

Challenges We Faced

Preserving Human Authority

The hardest product question was not how to let the agent edit the play—it was how to stop the agent from erasing intentional human decisions.

We solved this with coach-only action locks. Before every agent mutation, NextPlay snapshots locked actions and verifies that they remain unchanged. Attempts to modify a locked action return an ACTION_LOCKED error without changing the play revision.

Keeping the Agent and Interface Synchronized

It would have been easy to build a demo where the agent edits hidden JSON while the UI displays something similar.

Instead, we made the visible application state the source of truth. Tool success is returned only after the updated state has been committed through the same data model used by the coach interface.

Handling Stale Agent State

A coach may change the play after the agent reads it. Without concurrency protection, the next agent write could accidentally overwrite a newer version.

Revision-aware writes let the application detect that situation and ask the agent to reread the play before continuing.

Making Validation Honest

We wanted the validator to be useful without making exaggerated basketball claims.

That required carefully separating deterministic facts like timing, possession order, references, and lock preservation from subjective questions like whether the play would fool a real defense.

Building a Reliable Live Demo

A hackathon project has to work repeatedly, not just once.

We reduced the scope to one polished sideline out-of-bounds scenario, kept the WebMCP surface to five tools, added strict runtime schemas, tested fresh-context production flows, and included an honest manual fallback for browsers that do not support WebMCP.

What We Learned

The biggest lesson was that giving an agent more autonomy is not always the same as making it more useful.

In collaborative software, an agent needs three things:

  1. Semantic access to the real application state.
  2. Clear authority boundaries defining what it may change.
  3. Observable, revision-aware actions that both the user and the system can verify.

WebMCP turns the page from a visual interface the agent must guess at into a structured collaboration environment.

We also learned that the most compelling agent experiences are not single-prompt generation demos. They are iterative workflows where a human changes the constraints and the agent successfully adapts without losing prior intent.

What We Are Proud Of

NextPlay demonstrates a complete human–agent loop:

Intent → structured construction → validation → animation → human intervention → constraint violation → agent repair

The coach remains the decision-maker. The agent accelerates execution.

That is the interaction model we believe will matter far beyond basketball: humans defining intent and protecting critical decisions while agents operate directly inside live, structured applications.

Built With

Share this project:

Updates

Submission history