Floortris

• 

• 

• 

• 

• 

Inspiration

I started Floortris late in the challenge with a practical question: why can an AI describe a room layout but struggle to work directly with the room planner already open in front of it?

Before implementing WebMCP, I was surprised by how difficult it was for an AI agent to use the website reliably. It had to interpret controls visually, infer the state of the room and hope that each interaction had worked. Even when the result looked reasonable, the agent could miss important details such as door swings, walking routes, furniture orientation or the measurements of items someone already owned.

I wanted to explore a better approach: a room planner designed from the beginning for a person and an agent to use together. The agent should understand the same measured room shown on screen, work under the same rules and produce a visible proposal—while the person retains control of every final change.

What it does

Floortris is a local-first room planner for people and agents.

A person can enter a measured room, add doors and windows, record furniture they already own, lock its dimensions or position and edit the layout directly. An agent can use 16 native WebMCP tools to inspect the same document, construct a separate Proposal, arrange furniture, change finishes and check the resulting layout.

The agent works in Proposal, while the accepted room remains in Yours. It does not switch the person’s view or apply its own work. Apply, room-input confirmation, discard, unlock and view switching remain human-only actions.

Floortris checks more than whether two rectangles overlap. Its shared rule engine evaluates:

• door swings and open door leaves;
• hard and preferred walking clearances;
• routes between entrances and activity zones;
• TV positioning and seating relationships;
• coffee-table gaps;
• usable bed sides;
• storage and window access;
• linked desks and chair pull zones;
• radiators and wall-mounted objects;
• measured curtains, blinds and lighting fixtures.

An agent can recreate rectilinear rooms with alcoves, recesses, nooks and L-shaped outlines from dimensioned information. The same measured outline is then used by the 2D board, 3D scene, collision rules, ceiling checks, walking routes and placement search.

Agents can also create measured custom furniture inside a Proposal, including genuine connected L- and U-shaped sectionals. These use a closed, validated geometry format instead of arbitrary code or remote 3D assets. They remain subject to the same placement rules and human approval boundary as catalogue furniture.

Why WebMCP

The floor plan itself is the product. A hidden API response or a paragraph describing where furniture should go is not enough—the measurements, furniture, warnings and proposed changes need to remain visible and reviewable.

Floortris registers 16 native tools through document.modelContext. These include generateRoom, getRoomState, createProposal, createCustomFurniture, placeFurniture, updateFurniture, findPlacements, setAppearance and checkLayout.

These tools give the agent structured access to the same room state and rule engine used by the visible interface. Instead of guessing what a button does or interpreting the page from pixels, the agent can request exact measurements, submit a revision-bound change and receive structured feedback explaining whether the layout is healthy.

WebMCP made the agent much more reliable, but I deliberately avoided giving it complete authority. It can perform substantial spatial work, but its result remains a Proposal until a person reviews and applies it.

How I built it

Floortris is built with TypeScript, React, Next.js on the vinext runtime, Three.js, Vite and Cloudflare Workers.

At its centre is a shared rule engine operating on a measured 20 cm grid. Human controls and WebMCP commands pass through the same document store and validation logic. This prevents the visible room and the agent’s representation from developing different versions of spatial truth.

Each WebMCP tool has a strict JSON Schema, explicit metadata, revision checks and abort-aware execution. Placement searches are bounded, and candidates are ranked by functional quality rather than simply returning the first coordinate without a collision.

I also added seven difficult benchmark rooms, three checked planning strategies, static accommodation-provider packs, advisory accessibility planning packs, a local evaluation dashboard, furniture-schedule exports, printable move-in sheets and server-free share links carried in the URL fragment.

Room, evaluation and share data is not sent to an application data backend. Share data only leaves the device when the person explicitly shares the generated URL. A Cloudflare Worker serves the client application; there is no application database or remote LLM service.

Challenges I faced

The hardest technical challenge was maintaining one spatial truth across every part of the application.

A custom cut-out in an L-shaped room could not simply be hidden in the 2D view. It also had to be absent from collision cells, walking routes, ceiling placement, search candidates and the 3D shell. Custom sectional furniture created a similar problem: an L- or U-shaped sofa needed to behave as one connected object without treating its empty internal area as occupied floor space.

Furniture rules were more relational than I initially expected. Whether a coffee table works depends on the sofa’s true facing edge and measured gap. Whether a desk works depends on its chair and pull zone. Whether shelving is correctly placed depends on which edge is actually its back—not merely whether some part of its bounding box touches a wall.

I also encountered problems with door clearances, TVs appearing behind doors, shelving facing the wrong direction, disappearing 2D labels and stuttering 3D shadows. Fixing these required the rule engine and renderers to use explicit geometry rather than visual assumptions.

Another challenge was protecting human work while an agent was operating. Proposal branches, revision-bound commands, immutable snapshots and exact-revision review checks prevent a delayed agent action from silently overwriting a newer human edit.

What I learned

I was most surprised by how difficult it was for an AI agent to use the website before I implemented the WebMCP tools. A page that feels obvious to a person can still be ambiguous to an agent when its capabilities and state are only communicated visually.

That changed how I think about building websites. In future projects, I want to consider agent-native compatibility from the beginning rather than treating it as something added afterwards. As the world becomes increasingly reliant on AI, websites should expose clear, structured and constrained capabilities that allow agents to help without taking control away from people.

I also learned that useful agentic interfaces need visible state, explicit authority and reversible proposals—not simply more tools. Geometry needs to be centralised as well. Once the 2D plan, 3D scene, placement search and validation engine all used the same measurements, complex room shapes and custom furniture became much easier to support correctly.

I am proudest of how quickly I produced a working prototype despite starting late, while documenting the development publicly on TikTok at the same time. Building in public forced me to explain each problem clearly and showed how quickly an initial prototype could develop into a much more capable agent-native application.

Floortris ultimately became more than a furniture visualiser. It became an experiment in how people and agents can share one visible, rule-checked document while the person retains ownership of the final decision.

Built With

• cloudflare
• next.js
• node.js
• openai
• react
• sites
• three.js
• typescript
• vinext
• vite
• webmcp
• workers