VenueMind

Agent-native venue operations: design, validate, approve, run, and audit safer event layouts with humans and WebMCP agents working together.

Comment

Inspiration

I got attached to VenueMind early. I was building solo, and I wanted to take it beyond a good-looking floor plan into a product with working validation, revision history, and tools an agent could use.

Venue planning gave me a problem worth doing that for. Moving a seating block might widen an aisle but reduce capacity. Another change might improve the view of the stage while interfering with something that needs to stay fixed. A drawing can look reasonable while hiding those tradeoffs.

I wanted an agent to help work through a change, with the person responsible for the room able to see exactly what it proposed before accepting it.

What it does

VenueMind is a venue planning and operations workspace where people and agents work on the same versioned floor plan.

The demo follows one request:

Keep 400 seats, widen the center aisle to six feet, improve sightlines, and preserve locked objects.

The agent calls venue.inspect_layout, then venue.preview_revision. Four proposed changes appear as violet ghost shapes over the existing plan. The accepted layout stays unchanged during review.

Next, venue.validate_layout checks access, capacity, circulation, locks, and sightlines. The interface shows the proposed layout alongside the measurements, so the reviewer can judge the consequences.

Approval through the interface commits Plan v3.3. The agent can then inspect the activity ledger, verify replay, and export the validated plan.

The wider product includes proposal branches, conflict handling, undo and redo, operational checks, and several export formats. I also built a documentation site, an SDK, agent skills, and a standalone MCP server.

Why WebMCP fits

A floor plan contains information an agent should not have to reconstruct from a screenshot. Objects have dimensions, stable IDs, relationships, and locks. A proposal also belongs to a particular version of that plan.

WebMCP lets VenueMind expose that information as structured tools inside the page. The agent can inspect the actual layout and request validation results while the person reviews the same state visually.

This avoids a frustrating handoff where an assistant describes a suggested arrangement in chat and someone has to recreate it in a separate editor. In VenueMind, the suggestion becomes a visible proposal with measurable consequences. The reviewer can inspect it where they already work.

How I built it

I built VenueMind with Next.js, TypeScript, and shadcn/ui. Vercel hosts the frontend. A Cloudflare Worker handles the API, with D1 for persistence.

The foundation is a versioned venue model with stable object IDs. Both interface actions and WebMCP tools pass through a shared command bus, so they use the same application logic.

The page registers tools through document.modelContext.registerTool. A shared contract registry defines their schemas and authorization requirements. Tool execution checks inputs and permissions before it reaches the underlying operations.

The agent requests a proposal; application code performs the geometry checks. VenueMind does not ask a language model to decide whether an aisle meets a configured width.

I deliberately left approval out of the agent tool list. The intended workflow asks a person to review the proposal through the interface before committing it.

Codex helped me implement and test the application, refactor the code into TypeScript, and work through browser integration. I used HyperFrames to edit the demo and Kokoro for its narration.

Challenges and lessons

Getting the proposal lifecycle right took more work than drawing the preview. A proposal can look correct and still be based on an outdated plan. Validation, approval, and export need to agree about the version they refer to. That drove the work on conflict checks, command receipts, and replayable history.

Browser integration also needed careful testing. Chromium 149, used for the recording, exposed native WebMCP through navigator.modelContext. The recorder aliases that native object to document.modelContext. I later verified the hosted workflow in Chrome 152 using native document.modelContext directly, without an alias or mocked registry.

Hosted testing caught another issue that local testing missed. Each guest had a separate organization, but the sample projects shared one globally unique project ID. The API correctly rejected the collision, and the frontend incorrectly displayed it as a synchronization conflict. I fixed the sample identity so each organization gets its own stable project ID, then tested separate guest sessions and persistence after reload.

The build made the value of a shared command bus concrete. Every separate implementation of an action creates another place for behavior to drift. Keeping UI and agent operations together made their results easier to compare and test.

I also had to keep the ambition practical. I removed file storage when R2's activation requirements did not fit my available setup.

What the demo proves, and what remains

The 75-second demo shows the working inspection, proposal, validation, commit, history, and export loop using local guest state. Codex operates the approval button to demonstrate the reviewer interface; the recording does not demonstrate an independently authenticated human approval or multi-user cloud synchronization.

Separate testing verified the full workflow on the hosted app in Chrome 152 with WebMCP enabled. Native tool calls completed inspection, proposal creation, validation, ledger inspection, replay, and export, with approval through the interface. D1 retained the committed v3.3 plan after reload. A second guest received an independent sample project and could not access the first guest's project.

Validation checks configured geometry and policies. It does not replace professional venue inspection or safety certification.

My next priority is testing more layouts. I want to find the cases where a proposal looks convincing but fails a constraint, and make those failures easy for the reviewer to understand.

Built With

  • cloudflare-d1
  • cloudflare-workers
  • hyperframes
  • mcp
  • next.js
  • openai-codex
  • react
  • shadcn/ui
  • typescript
  • vercel
  • webmcp
Share this project:

Updates

Submission history