StayOps

01_stayops_dashboard (manager-view)
02_stayops_info_distracted (manager-view)
03_stayops_agentworkflow ( judge-view)
04_stayops_arize_monitor (judge-view)

Inspiration

Hotels do not usually lose guest trust because one person forgot one task. The bigger problem is that promises get scattered across sales emails, guest messages, internal notes, and team handoffs. A front desk agent may say “we’ll prioritize a quiet room,” sales may mention projector setup, and operations may never see the exact commitment until the guest complains. We wanted to build something for the duty manager: a tool that asks, “Can we safely make this promise?” before the hotel commits, and “Where exactly did this promise break?” after something goes wrong.

How to use it

Platform Guidance doc:

https://docs.google.com/document/d/1iTGh8or4v8Vt-Lmuc8w0hgaqtlFICO2kB_iYq4zRf1k/edit?usp=sharing

GIVE IT A TRY:

https://stayops-mzcsrz357a-uc.a.run.app/

What it does

StayOps audits guest-facing promises before arrival. For a hotel booking, it reads the message history, extracts the promises, checks hotel operation evidence such as room readiness, SOPs, event space setup, billing details, and transport requirements, then classifies each promise as verifiable, risky, missing information, needs approval, or cannot confirm. The manager can see which promises are safe to confirm, which ones need human approval, and which ones should only get a cautious reply. If a complaint comes in later, StayOps traces it back to the exact promise, approval, task, and failure point. Our demo case follows a corporate offsite booking with six promises, including early check-in, a quiet king room for a VP, gluten-free breakfast, projector setup, airport transfer, and company invoice details.

How we built it

We built StayOps with Next.js, React, TypeScript, Tailwind, Gemini, Google Cloud ADK / Agent Builder, and Arize Phoenix. Gemini is used to understand guest messages and propose promise decisions with evidence. The ADK service is the main orchestration path when configured, and the app falls back to an in-app Gemini loop and then deterministic rules if needed. A deterministic policy layer makes the final call. This was important to us because the agent should not be allowed to turn a risky or missing-info request into a confirmed promise just because the language sounded confident. We also added Arize Phoenix tracing so we can inspect the agent’s reasoning, tool calls, and policy guardrails after an audit. Phoenix is used for observability and self-review, not as the business decision maker. The demo uses seeded hotel operation data in CSV files so the judging flow is reproducible.

Challenges we ran into

The hardest part was keeping the agent useful without letting it overpromise. A hotel assistant that simply turns every guest request into a task is not enough. Some requests are safe, some are risky, and some are impossible to confirm without more information. We had to separate “the guest asked for this” from “the hotel can safely promise this.” Another challenge was making Gemini actually matter. Early versions was like a rule engine with an AI wrapper. We changed the flow so the agent reads the real message content, extracts promises, calls tools, and proposes evidence-backed decisions, while the policy layer still keeps final control.

Accomplishments that we're proud of

We are proud that StayOps feels like an operations tool, not just a chatbot. The system can show a manager why a promise is safe, risky, or missing information. It can block unsafe confirmation language. It can also trace a later complaint back to the exact broken promise and failed task. We are also proud of the “Gemini proposes, policy decides” architecture. It lets us use Gemini for understanding messy guest messages without giving up operational control.

What we learned

We learned that agent systems need clear boundaries. The model is good at understanding context and extracting intent, but final commitment decisions need evidence, policy, and human approval. For this kind of workflow, observability is not optional. If a manager is going to trust an agent, they need to see what it read, what tools it used, and why it reached a decision.

What's next for StayOps

Next, we want to connect StayOps to real hotel systems instead of seeded demo data: PMS, housekeeping, event planning, billing, and guest messaging. We also want to improve the Arize Phoenix integration with per-promise trace links, expand the evaluation set with more human-written hotel cases, and finish hardening the Cloud Run deployment path. Longer term, StayOps could become a shared promise ledger for hotel teams: sales, front desk, F&B, events, concierge, and duty managers all working from the same verified source of truth.