-
-
Opening screen of Wadi showing pre-designed models that the user can choose and modify using the AI agent
-
A fully loaded model that is generated from the design language code that was written by an architect with the help of a coding agent
-
The design language code editor that a trained architect can create or modify directly or with a coding agent
-
A graph of the rooms and connections between them that forms part of the structural constraints that ground the AI agents
-
A detailed diagram of a hip roof construction that is automatically generated
-
Floor plans are also automatically generated
-
Elevation views are generated automatically as well
-
Bill of materials for all of the construction (WIP)
-
Actual house and Wadi 3D model view based on which the house is being constructed
-
Actual house and Wadi 3D model view based on which the house is being constructed
-
Actual house and Wadi 3D model view based on which the house is being constructed
-
Actual house and Wadi 3D model view based on which the house is being constructed
Inspiration
In the Konkan (coastal region of the state of Maharashtra in India), many families build their homes with government housing grants. The grant covers construction, but not an architect, so the design falls to the local contractor and mason, who lay out the house room by room from experience. The owner rarely sees what their home will look like until it is standing.
Wadi is built for exactly this gap. It is a parametric home designer that produces a full 3D model, dimensioned floor plans, elevations, and a roof, from designs that already follow the standard local materials and construction of the region: the laterite walls, Mangalore tiled hip roof, the raised plinth, the verandah on pillars. A homeowner can walk through their house in 3D before a single brick is laid. A contractor can start from a standard layout or sketch their own, and then refine it, without being a trained architect.
That last part is where agents come in, and Wadi uses them for two different people.
An architect (or a coding agent acting as one) designs a full house from scratch through Wadi's offline MCP server, authoring the complete model in Wadi's own design language, checked against structural rules at every step.
Then the family customizes that design in their own browser through WebMCP. A 3D design tool is hostile to an agent: the scene lives in a
<canvas>invisible to the accessibility tree, so the agent is left guessing at buttons. WebMCP fixes that.
The site exposes structured design tools the agent calls directly, so a homeowner or contractor can start from a finished local design and just describe changes in plain language, "add a pooja room off the hall, widen the verandah, put the staircase here", while the agent makes real, sound edits and the family watches the model update.
What it does
Wadi separates the two people who touch a design, over one model and one design language.
An architect designs the full house from scratch through Wadi's offline MCP server. Running inside a coding agent (Claude Code, or any MCP client), the architect authors the complete model in Wadi's .wdl design language, adding floors, rooms, a roof, and a staircase, checking each version against the structural rules and previewing the plans, elevations, and roof, all without the app.
The family then customizes that design in the browser, through WebMCP and a hosted online MCP server, with nothing to install. The homeowner or contractor opens the app, picks the local design closest to what they want, and talks to an in-browser agent (ChatGPT's built-in browser, or Chrome). The agent reads the design, edits it, resize a room, add a bathroom, change the plot, and applies it, and the person watches the 3D model, floor plans, and roof re-flow live. Because a design is a parametric model, changing one number re-flows the whole house.
Both go through the same store the person edits by hand, so agent edits and human edits are the same kind of change, on one live model with one undo history: you can talk a house into shape and then hand-tune it. A live co-editing relay even lets a remote agent edit the model a family is watching, in real time.
How we built it
The core is a Zod HouseConfig schema, a parametric resolver, and a geometry expander. Any number in the model can be a formula over named variables, points, and guide lines, so the whole house re-flows when one value changes. A generated guide, for example, resolves lazily by index:
$$\text{module}.x_i = o_x + i \cdot s_x$$
Every mutation runs through a Zustand store that re-resolves the parametric model, so the 2D and 3D renderers always read resolved numbers.
The edit surface is Wadi's .wdl design language, a small language for a whole house (floors, rooms, walls, roofs, variables, formulas), compiled through the real pipeline. Making the DSL the single edit surface was the key decision: an agent reads the current house with get_wdl, edits the text, and applies it with set_wdl, which compiles it, loads it into the same store the UI uses, and returns a structural check. So the agent is not a second app driving Wadi from outside, it is another hand on the same model.
Because the person customizing is not an architect, that same set_wdl runs a structural constraint linter on every edit, a growing set of rules that keep a spoken change buildable: a plinth on the lowest floor, a roof on the highest, the roof covering the whole top floor, pillars under any cantilever, upper-floor walls aligned over the walls below, plus checks on slabs, floor heights, openings, room overlaps, and passable connections. Each returns a plain-language warning the agent must resolve, so a change from someone with no design training still lands a real, buildable house.
Two MCP surfaces sit on this core. The offline MCP server gives an architect the from-scratch design tools inside their own coding agent (wadi_check, wadi_preview, wadi_reference, wadi_examples); it predates the hackathon. During the hackathon we built the end-user side: a hosted online MCP server (a Cloudflare Container at mcp.wadi.house) so a family's agent (Antigravity, a ChatGPT connector, Gemini) reaches the tools by URL with nothing installed, and the WebMCP layer, which registers the editing tools in the browser with document.modelContext.registerTool (get_wdl, set_wdl, check, list_homes, choose_home, capture_view, undo/redo) so an in-browser agent drives the live model. A Durable-Object relay bridges the two, letting a remote agent co-edit the very model a user is watching. Because the 3D canvas is invisible to an agent, capture_view renders the current model to an image so the agent can see what it changed.
Wadi deploys as a static site (Cloudflare Pages), a Tauri desktop app, and the hosted MCP server; the WebMCP tools register in any WebMCP-capable browser, so ChatGPT's in-app browser or Chrome both drive the live model.
Challenges we ran into
- One shared model, not two apps. Getting agent and human edits to converge on a single live, parametric model (and one undo history) drove the whole tool design.
- Keeping a non-architect's edits buildable. Shared walls, doors on connections, the grid, formula-driven re-flow, and a growing set of structural rules all had to be surfaced to the agent, not hidden behind the UI, so that a spoken request from someone with no design training still produces a real, code-respecting layout.
- The invisible canvas. An agent cannot see WebGL, so we added a capture tool that hands back a rendered view.
- Getting the tools discovered. WebMCP tools have to be registered synchronously at page load, in the top-level document, or an agent's tool detector, which checks once as the page loads, finds nothing and shows no tools, even though the app registered them a moment later.
- A rendering gotcha. A WebGL canvas composites above normal HTML regardless of z-index, so an overlay menu kept hiding behind the 3D scene until we moved it into the browser top layer with the Popover API.
- Ambiguous coordinates and units. Center vs outer wall conventions and the units-per-foot scale had to be pinned down so the agent's numbers land where the contractor expects.
Accomplishments that we're proud of
- Agent and human on one model. Every editing tool goes through the same store mutations as the UI, so the agent's edits and the person's edits are the same kind of change, with shared validation, live re-rendering, and one undo history.
- Architect designs, family customizes, one model. The architect authors a full house from scratch through the offline MCP server; the family refines it in the browser through WebMCP and a hosted online server, both on the same parametric model in the same design language, with a live relay that lets a remote agent edit what a family is watching.
- Structural constraints that let a non-architect edit safely. A growing linter runs on every edit and tells the agent why a plan is unsound, so it fixes its own mistakes instead of producing an unbuildable plan for a family that could not spot the error.
- A real, end-to-end pipeline. Not a demo shell: the same model drives a 3D walkthrough, dimensioned 2D plans, elevations, a roof, and a quantities estimate.
- It reaches a person who could not otherwise get this. A contractor with no design training can produce a sound, locally-styled home, and the family can see it in 3D before construction starts.
What we learned
The biggest lesson was that constraint-awareness is what lets a non-architect design a sound house with an agent. A naive agent editing a design will happily place a room that overlaps another or declare a doorway through a solid wall, and a family with no training cannot catch it. Wadi runs a structural linter on every edit; one of its checks, for a declared connection between two rooms, enforces that they overlap on a wall and are passable, either a door in the overlap or the wall left off both rooms:
$$\text{connected}(A,B) \implies \big(\,\text{overlap}(A,B) \wedge (\text{door in overlap} \vee \text{no shared wall})\,\big)$$
So the agent is told why a connection is not yet valid and can add the door itself. The parametric layer plus these checks let a contractor's spoken changes stay buildable, which a screen-reading bot cannot manage.
We also learned how little glue WebMCP needs when the app already has a clean mutation seam. Re-using the store meant the agent inherited undo, validation, and live re-rendering for free, and the same tools worked from a hosted MCP server and from an in-browser agent with almost no extra code.
What's next for Wadi: design a house with your agent
- Budget and materials. Wadi already estimates wall areas; the next step is a full bill of materials and cost tied to the grant amount, so a family can see whether a design fits what the scheme pays for.
- Speak in the local language. Voice input in Marathi and Konkani so a contractor can dictate changes to the agent on site.
- Compliance help. Agent checks against grant norms and basic building rules (minimum room sizes, setbacks) so the design passes as well as builds.
- More regions. Material and style packs beyond the Konkan hip-roof vocabulary.
- Share the walkthrough. A link the contractor sends the family to explore the 3D home on a phone before work begins.
Log in or sign up for Devpost to join the conversation.