StayWeave

Inspiration

In an independent hotel, one changed request (an extra night, a sea view, two more guests) ripples through the room, housekeeping, linen, breakfast and the team's day. Owners are often off-site and reconcile all of this by hand across several screens. As travelers start using their own AI agents, hotels need an operations layer that understands intent and still keeps only the promises the property can actually fulfil.

What it does

StayWeave is an agent-native operations workspace. The owner (or a guest's agent through a REST API) writes in plain language, e.g. "Priya wants Nov 24-26, two guests, a sea view is a must. Marco, same dates, would like a quiet room if possible."

1. Understands: NVIDIA Nemotron 3.5 Super, served by Nebius Token Factory, extracts guests, dates and party size, and separates required conditions (sea view) from preferences (quiet room), with quoted evidence from the message.
2. Asks only what is missing: arrival time and breakfast, at most two questions at a time, keeping everything already said.
3. Coordinates: a deterministic planner evaluates several pending requests together against the 36-room demo hotel, protects confirmed stays and purchased rights, and checks housekeeping minutes, staff roster, free linen sets and breakfast capacity. If nothing satisfies a required condition, it says so instead of inventing a promise.
4. Respects consent: each guest chooses the current terms (simulated guest roles in the demo); the owner never silently accepts on a guest's behalf.
5. Executes and reads back: the reservation and its cleaning, linen, breakfast and roster changes are written atomically and read back into chat, a calendar and an optional 3D hotel view.
6. Handles operations too: "Jules is absent today" or "we have 8 clean linen sets" are interpreted, applied within owner policy, and only real exceptions (handover, budget, shortages) are escalated.

How we built it

• Model layer: nvidia/Nemotron-3.5-Super-VL via the Nebius Token Factory OpenAI-compatible API. Prompts request strict JSON; outputs are schema- and evidence-validated (types, dates, known rooms/reservations, exact quoted substrings). Invalid outputs are rejected and never change state.
• Decision layer (code, not the model): coordination, matching and planning modules own availability, joint allocation, price, capacity, approvals and idempotent atomic saves. The model cannot create inventory, prices, approvals or completion.
• Observability and cost control: every call records model ID, latency, prompt/completion tokens and estimated cost, shown in the chat. A cumulative inference budget guard refuses calls beyond a configured cap.
• Front end: React + Vite conversation-first workspace with a live room grid, reservation calendar and a Three.js 3D hotel; responsive for phone, tablet and desktop.
• Agent API: guest agents can submit and answer offers through a capability-based REST API.
• 119 automated tests cover partial collection, invalid model output, stale revisions, atomic multi-guest publication, retries, authorization and protected amendments.

Challenges we ran into

• Keeping a tentative offer distinct from a booking, and a preference distinct from a purchased right, while declines, expiry and cancellations trigger fresh feasibility checks.
• Model output that looks grounded: a quoted substring is not proof of correct meaning, so the owner reviews the normalized card and the guest confirms current terms.
• Latency of long multilingual responses (one Korean follow-up hit the output limit; we raised the cap and kept the failed attempt in the metrics).

Accomplishments that we're proud of

One continuous, inspectable workflow: one sentence -> only the necessary questions -> joint coordination of several guests -> explicit guest choice -> saved and read-back operating changes. In a verified rehearsal, Jamie chose room 106 (+45 cleaning minutes, +60 team minutes, 2 linen sets reserved) and Alex chose 405 (no extra preparation, breakfast 2 -> 4 covers), while existing reservations and tasks were preserved.

What we learned

Let the model interpret and let code decide. A ready room legitimately creates zero new cleaning work, and a convincing demo should show that instead of manufacturing activity. Showing measured per-call cost and latency next to state changes made trade-offs concrete.

How we used NVIDIA Nemotron and Nebius Token Factory

All language understanding runs on NVIDIA Nemotron-3.5-Super-VL through Nebius Token Factory (catalog verified via /v1/models). Nemotron extracts structured booking and operating intent with evidence, classifies operating reports into tools, and drafts clarifying questions. Token Factory let us use a strong open NVIDIA model without operating GPU serving, and per-response usage powers per-call token and cost display. Measured in the demo video: 2 calls, 7.4 s, $0.0037 estimated for the first extraction; 1 call, 6.9 s, $0.0031 for the follow-up. These are small development samples, not an SLA or invoice.

What's next for StayWeave

Pilot with 3-5 independent properties, one authorized PMS/channel-manager integration with readback, staff task acceptance and completion on the floor, deployment on Nebius Serverless Endpoints, and routing fast calls to Nemotron Nano with Super/Ultra for harder reasoning.

Limitations (honest scope)

Local prototype with synthetic demo data. OTA/PMS write-back, payments and outbound guest messages are not connected; channel adapters are simulated. Guest choices in the demo are made through clearly labelled simulated guest roles.

Built With

• cloudflare
• express.js
• nebius-token-factory
• node.js
• nvidia-nemotron
• react
• three.js
• vite