Inspiration
AI agents are becoming increasingly capable of suggesting and executing changes, but consequential design decisions still need clear human control. In kitchen and bath planning, even a seemingly simple suggestion—moving a fixture, changing an appliance, or adjusting a room layout—can affect cost, accessibility, clearances, utilities, and usability.
We built Handshake to explore a better collaboration model: an AI agent can inspect a shared design, search for products, evaluate constraints, and propose improvements, but it cannot silently change the approved plan.
Our guiding principle became our tagline:
Design together. Approve with proof.
What it does
Handshake is a WebMCP-enabled kitchen and bath co-design workspace where a person and an in-browser AI agent collaborate on the same room plan.
The agent can:
- Read the current room and design state
- Search a synthetic kitchen and bath product catalog
- Evaluate budget, geometry, clearances, openings, and planning guidelines
- Propose placing, moving, swapping, or removing products
- Propose changes to room dimensions and openings
- Explain warnings before a decision is made
- Generate a bill of materials from the approved design
- Retrieve evidence receipts for protected actions
The agent cannot approve its own proposal or bypass the page’s consent controls. Every proposed change is versioned and shown to the person for review. Approval is bound to the exact proposal contents using a canonical hash, so an approved proposal cannot be silently replaced with something different.
Consequential actions pass through an additional human-only confirmation step. Successful actions produce evidence receipts that record what was approved, which checks were shown, and what happened.
How we built it
Handshake is a TypeScript monorepo built with pnpm and deployed around a Cloudflare architecture.
A Cloudflare Worker serves the application and API. Each synthetic design session is owned by a Durable Object, which maintains the authoritative room state, proposal versions, idempotency records, confirmations, and audit events.
The browser exposes a governed WebMCP tool surface. Tools can read state, search the catalog, create proposals, apply an already-approved proposal, request protected actions, and retrieve receipts. Human approval and confirmation endpoints are deliberately excluded from the agent-callable tool surface.
The policy layer is deterministic and side-effect free. It handles:
- Canonical proposal hashing
- Proposal expiry and state transitions
- Expected-version checks
- Idempotency and replay prevention
- Actor and authorization boundaries
- Budget and room-boundary evaluation
- Fixture overlap and approach clearance
- Door and appliance-opening conflicts
- Kitchen work-triangle guidance
- Work aisles, walkways, and landing areas
- Service-location warnings
- Accessibility-oriented turning-space checks
- Bill-of-materials calculation
Rule thresholds are represented as named, reviewable constants with source information rather than unexplained numbers embedded in the implementation. The current project uses synthetic data and presents its checks as planning guidance—not as building-code certification.
We use Vitest for unit and policy testing, Playwright for browser verification, GitHub Actions for continuous integration, and Wrangler for Cloudflare development and deployment workflows.
Challenges we ran into
The hardest challenge was preserving meaningful human control without making the agent collaboration feel artificial.
It was not enough to place an “Approve” button beside an unrestricted mutation endpoint. We needed to prove that:
- The person reviewed the exact proposal that would be applied.
- The proposal was still valid for the current room version.
- The agent could not approve or confirm its own work.
- Replayed requests could not apply the same change twice.
- A protected action could not proceed without fresh, explicit confirmation.
- The resulting receipt accurately described the approved action.
Another challenge was keeping the product claim aligned with the implementation. Handshake was described as a kitchen and bath workspace, but the earliest catalog and rules were primarily bathroom-oriented. Rather than hide that gap, we documented it and expanded the domain model to include kitchens, doors, windows, service anchors, appliance interactions, work-triangle evaluation, landing areas, and a bill of materials.
We also had to distinguish authorization from design guidance. Authorization rules fail closed, but planning warnings should remain reviewable. A person may knowingly approve a design that carries a recommendation-level warning; Handshake’s job is to ensure that the warning was visible and recorded, not to pretend the agent owns the final decision.
Accomplishments that we're proud of
We are proud that Handshake treats consent as part of the architecture rather than a decorative UI step.
The project now includes:
- A versioned proposal state machine
- Canonical hashes that bind approval to exact proposal contents
- Human-only approval and confirmation endpoints
- Replay-resistant and idempotent state transitions
- A shared, server-authoritative design session
- A governed WebMCP tool surface
- Protected-action evidence receipts
- Deterministic budget and geometry checks
- Kitchen and bathroom planning-rule support
- A derived bill of materials
- Negative-path tests for replay, self-approval, stale versions, expired consent, and altered proposals
- Continuous-integration validation for formatting, types, and tests
We are especially proud that the system is explicit about its limits. It uses synthetic project data, does not claim code-compliance certification, and does not treat a green automated check as proof that deployment or final submission is complete.
What we learned
We learned that trustworthy agent experiences require more than permission prompts. The approval must be attached to the exact state transition, and the system must preserve enough evidence to explain the decision afterward.
We also learned that deterministic policy code and generative agent behavior work best when they have separate responsibilities. The agent can help interpret goals and propose creative changes. The policy engine owns authorization, consistency, geometry, and repeatable checks.
A third lesson was that missing information should not be invented. If a room has no modelled door, Handshake does not fabricate one and claim to have checked its swing. Evidence is only useful when it clearly distinguishes what was evaluated from what remains unknown.
Finally, we learned that human control does not have to eliminate useful automation. The agent can still inspect, search, calculate, and prepare a complete proposal. The boundary is simple: the agent proposes; the person decides; the system records the proof.
Inspiration
AI agents are becoming increasingly capable of suggesting and executing changes, but consequential design decisions still need clear human control. In kitchen and bath planning, even a simple suggestion—moving a fixture, replacing an appliance, or changing a room layout—can affect cost, accessibility, clearances, utilities, and usability.
We built Handshake to explore a safer collaboration model: an AI agent can inspect a shared design, search for products, evaluate constraints, and propose improvements, but it cannot silently change the approved plan.
Our guiding principle became our tagline:
Design together. Approve with proof.
What it does
Handshake is a deployed WebMCP-enabled kitchen and bath co-design workspace where a person and an in-browser AI agent collaborate on the same room plan.
The agent can:
- Read the current room and design state
- Search a synthetic kitchen and bath product catalog
- Evaluate budgets, geometry, clearances, openings, and planning guidelines
- Propose placing, moving, swapping, or removing products
- Propose changes to room dimensions and openings
- Explain warnings before a decision is made
- Generate a bill of materials from the approved design
- Retrieve evidence receipts for protected actions
The agent cannot approve its own proposal or bypass the page’s consent controls. Every proposal is versioned and displayed for human review. Approval is bound to the proposal’s exact contents using a canonical hash, preventing an approved proposal from being silently altered or replaced.
Consequential actions pass through an additional human-only confirmation step. Successful actions generate evidence receipts recording what was approved, which checks were displayed, and what happened.
How we built it
Handshake is a TypeScript monorepo built with pnpm and deployed on Cloudflare.
A Cloudflare Worker serves the application and API. Each synthetic design session is owned by a Durable Object, which maintains the authoritative room state, proposal versions, idempotency records, confirmations, and audit events.
The browser registers a governed WebMCP tool surface. These tools allow an agent to read state, search the catalog, create proposals, apply already-approved proposals, request protected actions, and retrieve receipts. Human approval and confirmation endpoints are deliberately excluded from the agent-callable tool surface.
The deterministic policy layer handles:
- Canonical proposal hashing
- Proposal expiry and state transitions
- Expected-version checks
- Idempotency and replay prevention
- Actor and authorization boundaries
- Budget and room-boundary evaluation
- Fixture overlap and approach clearance
- Door and appliance-opening conflicts
- Kitchen work-triangle guidance
- Work aisles, walkways, and landing areas
- Service-location warnings
- Accessibility-oriented turning-space checks
- Bill-of-materials calculation
Rule thresholds are represented as named, reviewable constants with source information rather than unexplained numbers embedded in the code. Handshake uses synthetic data and presents its evaluations as planning guidance—not as building-code certification.
We use Vitest for unit and policy testing, Playwright for end-to-end browser verification, GitHub Actions for continuous integration, and Wrangler for Cloudflare development and deployment.
After completing the implementation and release checks, we deployed Handshake to Cloudflare and verified the complete demo journey in the live environment.
Challenges we ran into
The hardest challenge was preserving meaningful human control without making agent collaboration feel artificial.
It was not enough to place an “Approve” button beside an unrestricted mutation endpoint. We needed to prove that:
- The person reviewed the exact proposal that would be applied.
- The proposal was still valid for the current room version.
- The agent could not approve or confirm its own work.
- Replayed requests could not apply the same change twice.
- A protected action could not proceed without fresh, explicit confirmation.
- The resulting receipt accurately described the approved action.
Another challenge was aligning the product claim with the implementation. Handshake was described as a kitchen and bath workspace, but its earliest catalog and planning rules were primarily bathroom-oriented. Rather than hide that gap, we expanded the domain model to include kitchens, doors, windows, service anchors, appliance interactions, work-triangle evaluation, landing areas, and a bill of materials.
We also had to separate authorization from design guidance. Authorization rules fail closed, while planning warnings remain reviewable. A person may knowingly approve a design carrying a recommendation-level warning. Handshake’s responsibility is to ensure that the warning was visible and recorded—not to pretend that the agent owns the final decision.
Deploying a stateful WebMCP experience introduced another challenge: the browser, Worker, Durable Object, and deterministic policy layer all had to agree on the same versioned state and consent boundaries. We tested the complete journey after deployment to confirm that the live environment preserved those guarantees.
Accomplishments that we're proud of
We are proud that Handshake treats consent as part of the architecture rather than as a decorative interface step.
The completed project includes:
- A deployed WebMCP application running on Cloudflare
- A verified end-to-end demonstration journey
- A shared, server-authoritative design session
- A governed WebMCP tool surface
- A versioned proposal state machine
- Canonical hashes binding approval to exact proposal contents
- Human-only approval and confirmation endpoints
- Replay-resistant and idempotent state transitions
- Protected-action evidence receipts
- Deterministic budget and geometry checks
- Kitchen and bathroom planning-rule support
- Door, opening, appliance, and service-location evaluation
- A derived bill of materials
- Negative-path tests for replay, self-approval, stale versions, expired consent, and altered proposals
- Browser and accessibility verification
- Continuous-integration validation for formatting, types, and tests
- Cloudflare deployment and live runtime verification
We are especially proud that the system is explicit about its limits. It uses synthetic project data, does not claim building-code certification, and distinguishes automated evidence from human approval.
What we learned
We learned that trustworthy agent experiences require more than permission prompts. Approval must be attached to the exact state transition, and the system must preserve enough evidence to explain the decision afterward.
We also learned that deterministic policy code and generative agent behavior work best when they have separate responsibilities. The agent can interpret goals and propose creative changes. The policy engine owns authorization, consistency, geometry, and repeatable checks.
A third lesson was that missing information should not be invented. If a room has no modelled door, Handshake does not fabricate one and claim to have checked its swing. Evidence is only useful when it clearly distinguishes what was evaluated from what remains unknown.
We also learned that deployment is an important part of validating architectural assumptions. Running the complete experience on Cloudflare helped us verify the interaction between the browser, Worker, Durable Object, policy engine, consent flow, and evidence receipts.
Most importantly, human control does not have to eliminate useful automation. The agent can inspect, search, calculate, and prepare a complete proposal.
The agent proposes. The person decides. The system records the proof.
What's next for Handshake
Our next milestone is a private beta that moves Handshake from a verified demonstration toward a product tested by real users in controlled environments.
For the beta, we plan to:
- Invite a small group of kitchen and bath designers, remodelers, and homeowners
- Observe how people collaborate with the agent and review proposed changes
- Improve onboarding and make the proposal-and-approval flow easier to understand
- Add richer kitchen and bathroom templates
- Expand the synthetic catalog with more fixtures, appliances, finishes, and price ranges
- Improve room editing, measurements, openings, and service-location controls
- Add clearer visual explanations for warnings and planning recommendations
- Improve the bill of materials and create printable design summaries
- Add saved projects and secure multi-session user accounts
- Strengthen mobile and accessibility support
- Collect structured feedback, usability metrics, and error reports
- Test compatibility across more WebMCP-capable environments
- Continue security, reliability, performance, and consent-boundary testing
The beta will remain evidence-first. Planning checks will be clearly presented as guidance, protected actions will continue to require explicit human confirmation, and receipts will preserve what the person reviewed and approved.
Longer term, Handshake could support richer room geometry, real manufacturer catalogs with permissioned data, configurable planning-rule packs, collaboration between multiple specialists, and portable evidence packages for professional review.
The larger vision extends beyond kitchen and bath design. Handshake demonstrates a reusable pattern for responsible human-agent collaboration: agents should be able to contribute meaningful work without receiving silent authority over consequential decisions.
Built With
- cloudflare-durable-objects
- cloudflare-workers
- css
- github-actions
- html
- playwright
- pnpm
- typescript
- vitest
- webmcp
- wrangler
Log in or sign up for Devpost to join the conversation.