Morph

• 

Inspiration

Most websites assume their designers can predict every task a person will ever bring to them. usually a retailer gives everyone the same product grid. A travel site ranks trips by an advertised duration. A news site presents everyone with the same endless feed.

The information may already exist, but the interface often hides the answer a particular person needs.

Browser assistants usually either operate the controls that already exist or move the useful result into a chat response. I wanted to explore a different possibility: what if a cooperating website could use its own trusted data and native components to become the interface required for the task at hand?

That became Morph.

The idea is simple:

website exposes truth + capabilities + native components → person states goal → assistant composes interface

I chose three deliberately different everyday websites—shopping, travel, and news—to demonstrate that this is an interaction model for the web rather than a feature tied to one industry.

What it does

Morph lets someone describe the interface they need in natural language. Their browser assistant reads the page through WebMCP, selects from the website’s supported components and actions, and asks the website to compose a new interface.

The result remains part of the original website. It is interactive, editable, inspectable, persistent, and governed by the website’s own data.

Three working experiences demonstrate the range:

• Wayline turns 18 conventional travel results into 7 complete journeys. An advertised 1h 10m flight becomes its true 4h 26m door-to-door journey after accounting for walking, waiting, terminal buffers, luggage, and transfers.
• Hearth & Home turns a 28-machine product grid into the 9 washers that satisfy a particular home, budget, delivery window, and ownership-cost calculation.
• The Current turns 30 overlapping articles into 5 distinct developments totaling 9m 48s, while preserving original reporting and the provenance of verified facts.

Wayline demonstrates the complete collaboration loop. A traveler asks for a door-to-door decision interface, saves the 07:16 train, and locks the checked-luggage choice directly on the page. They then change destination and request a disruption stress test. The whole interface recomposes, while the saved train and luggage lock survive.

Ask → page composes → person edits → ask again → page recomposes without losing the person’s choices.

The trust boundary is central to Morph:

• Assistant = composition
• Website = truth
• Human = final authority

The assistant cannot inject arbitrary HTML, invent records, replace formulas, or silently override protected human choices. It decides how supported information should be arranged. The website decides what is true and possible.

The same model could extend to many other cooperating websites: a recipe could become a timed cooking plan for one oven shelf, a government site could show only the rules relevant to someone’s situation, or a store could rank products by true delivered cost instead of sponsored placement.

How I built it

I built three complete React and TypeScript experiences using Vinext and deployed them on Cloudflare. Each one begins as a recognizable conventional website before WebMCP transforms it.

Across the three pages, Morph registers 15 WebMCP tools through document.modelContext.registerTool(). Each experience provides tools that let an assistant:

• read every site-owned record, calculation, supported action, and current interface state;
• create an initial composed interface;
• update or completely recompose the current interface;
• compare site-owned records;
• open exact calculations, journey arithmetic, or source evidence.

Each website has its own registry of native components. These include ranked cards, compact tables, timelines, plots, comparisons, cost breakdowns, stress tests, provenance maps, recommendations, exclusions, and recovery options.

The assistant sends structured composition requests containing supported component types and settings. The website validates those requests, performs every calculation itself, and renders its own React components. Arbitrary markup, scripts, URLs, formulas, and factual claims are rejected.

Human changes are stored separately from assistant-owned composition. Saves, pins, hidden records, comparisons, and locked assumptions persist across later requests. Revision numbers prevent an assistant from changing a stale version of the page, while undo and redo remain available to the person.

The transformation itself is also visible. The existing page stays present while the new interface is prepared, then native components move, disappear, and enter according to the real before-and-after state.

The demonstration data is intentionally fictional and deterministic so every displayed result can be checked. The WebMCP interactions, calculations, persistence, protections, and interface composition are fully functional.

Challenges I ran into

The hardest challenge was balancing flexibility with trust. Allowing an assistant to generate arbitrary interface code would look flexible, but the website would lose control of its behavior and claims. Restricting the assistant to a few whole-page presets would be safe, but would miss the point of a composable web. We solved this with validated, independently configurable native components.

Preserving human intent was another major challenge. A later prompt may legitimately replace the entire layout, but it should not erase a journey someone saved or change a choice they explicitly locked. We separated human-owned state from assistant-owned composition and created semantic operations for changing each one.

I also had to make the project feel general without reducing it to an abstract technical demonstration. Building three unrelated websites forced the model to work with different records, calculations, actions, visual systems, and user needs.

Finally, the transformation needed to feel like the website was genuinely changing shape. React state updates initially made some recompositions appear abrupt. We built a transition system that measures the real component arrangement, preserves scroll position, and animates additions, removals, movement, and reduced-motion fallbacks.

Accomplishments that I'm proud of

I'm most proud that Morph supports an ongoing collaboration rather than ending after one successful prompt.

The saved-train and luggage-lock interaction captures the idea clearly: the assistant can radically reorganize the interface while respecting decisions that belong to the person.

I am also proud that:

• all three experiences use working WebMCP tools rather than scripted transformations;
• every number remains owned and explainable by the originating website;
• compositions are assembled from independent components rather than fixed page presets;
• the same model works across shopping, travel, and news without making the sites look or behave alike;
• the experiences remain usable on desktop and mobile;
• exact calculations, exclusions, provenance, zero-result recovery, undo, redo, and persistence remain available after composition.

The three numerical reveals summarize the result:

28 → 9 viable products
1h 10m → 4h 26m true journey time
30 → 5 meaningful developments

What I learned

I learned that WebMCP’s most interesting potential goes beyond helping agents click existing interfaces more reliably. It can let people request useful interfaces that were never assembled as complete screens beforehand.

I also learned that a tool schema is part of the user experience. The records, operations, constraints, and component vocabulary exposed to an assistant determine how expressive and trustworthy the resulting interface can be.

Most importantly, good human-agent collaboration requires explicit ownership. The assistant needs freedom to compose, the website needs authority over its domain, and the person needs durable control over their decisions.

Persistence changes the relationship completely. A first prompt can feel like generation; a second prompt that respects the person’s intervening edits feels like collaboration.

What's next for Morph

The next step is connecting the model to real first-party systems: live retailer inventory, transit schedules, publisher feeds, public-service information, and other structured websites.

I would also like to make Morph’s component and state model easier for existing websites to adopt, so a site can expose its own native building blocks without redesigning the whole product.

Future experiences could include recipes that become synchronized cooking plans, housing sites that calculate complete moving decisions, education platforms that reorganize material around a learner’s gaps, and public-service sites that adapt complex guidance to a person’s circumstances while preserving the original language.

Over time, people could carry explicit preferences, such as accessibility needs, comparison styles, or information density, between cooperating sites while retaining control over when those preferences are shared.

The larger goal is a web where interfaces do not have to predict every person and every task in advance. A website can remain authoritative, recognizable, and safe while becoming far more useful to the individual currently using it.

Built With

• css
• typescript