Skip to main content
Guest-facing Lucia is HelloLucia, LLC’s public concierge product surface. She helps guests warmly before verification, preserves privacy while identity is uncertain, and turns guest conversation into structured operational clarity for the property team.
Source was reviewed as of 2026-08-12 and the deployment identity re-read on 2026-09-10: the Guest Agent is the July agent, unchanged. Live claims on this page are limited to the latest accepted production verification, recorded on 2026-07-18. No fresh production model call was made on 2026-08-12 or 2026-09-10.

​
Current status

Guest-facing Lucia is implemented as the independently deployed Lucia Guest Agent:
The root page is the public lab surface. /lucia-lab/ redirects to /; it is not a separate current product surface.

​
Accepted live evidence

The latest accepted live verification cited by this page is:
This evidence proves that exact deployment, which is still the one published on 2026-09-10. It is not a September 2026 production-freshness claim and does not establish broader production readiness.

​
Where guest-facing Lucia sits in the September order

Sequencing law, founder 2026-09-04 (recorded on A stand-in voice, designed, ALGO-41): Fieldwork and Admin speak one language → the Algorithm proves it understands intake → then the guest agent and its model mix. Guest-facing Lucia is therefore last in the order, on purpose. As of 2026-09-10:
Two September laws already bind the guest surface without changing its code: the names law (Lucia and Villa Valentin with a plain i on every surface, LUCI-238, 2026-09-09) and the guest-mail button rule (rectangles with 4 to 5px corners, centred; the guest-agent button “takes the same shape because it is the same family”, LUCI-237, 2026-09-09). Both are rulings applied on the Engine’s guest-mail family; neither is a shipped change to the Guest Agent at fbf77b6. Nothing on this page writes a plan as shipped.

​
Runtime and model ownership

The Guest Agent owns its generation configuration and OpenAI call path:
Current source contract:
VV_AI_MODEL is a Guest Agent runtime override. It does not inherit from Lucia Engine configuration, and the Engine’s September move to a provider-aware gateway with Fable voicing Focus (ALGO-39) does not reach the Guest Agent. If Engine and Guest Agent use the same model name, each surface still requires its own source and runtime evidence. The ordinary Guest conversation service streams directly through the Responses API when a model-bearing turn is needed. The Guest Agent does not expose or inherit Engine’s runtime-provenance contract.

​
Deterministic paths before the model

A successful Guest request does not prove a model invocation. The Guest function can answer before OpenAI on deterministic paths including:
Only model-bearing conversation turns use the Guest-owned Responses API generation path. Runtime verification separately distinguishes configured model, provider-resolved model, model invocation, deterministic-path state, and fallback state.

​
Version domains

Guest-facing Lucia does not have one global version value. Keep these domains separate: The UI label is not the package version, and neither value replaces the full commit SHA for deployment proof.

​
Current implemented surface

Current Guest Agent source includes:
The interaction should feel like Lucia orienting herself, not like a form.

​
Historical reservation + verification proof — 2026-06-11

On 2026-06-11, a controlled development proof recorded this sequence:
That dated receipt proves the bounded seed/test sequence observed on 2026-06-11. It does not establish deployment or verification after that date. The sequence was not a public booking engine, payment system, Lodgify replacement, authentication system, or production OTA integration.

​
Identity Orientation Options

Guest-facing Lucia begins by asking the guest to orient the relationship:
These are not decorative buttons. They are the first step in privacy-safe context collection.

​
Product Doctrine

Guest-facing Lucia may help before verification. Guest-facing Lucia may collect claims. Guest-facing Lucia may not expose booking-private details or mutate booking records until identity/linkage is verified or operator-linked. Core public-facing doctrine:
Guest-facing Lucia should remain:
Guest-facing Lucia must not become:

​
Verification, privacy, and action boundary

The browser can provide orientation and claim context, but it cannot establish a verified identity. The Guest server preserves that boundary and rejects browser attempts to claim verified status. Verification truth comes from Engine-owned current state. Before that proof, names, dates, booking IDs, and relationship labels remain guest claims. A verified relationship permits bounded booking-specific planning; it does not grant unrestricted booking mutation. Guest-facing Lucia must not expose:
The source also sets an explicit operator boundary: the Guest Agent has no guaranteed automatic operator handoff. It must not claim that it alerted, notified, messaged, sent, connected, or confirmed with the team. When configured, the server may send an authenticated, privacy-reduced operational signal for operator review. That delivery is not guest-visible proof that a person acted, and the Guest response must still offer an honest contact or next step.

​
Guest evaluation status

​
Implemented: Guest Verification Check

Eval Labs has an implemented Guest Facing Agent Verification Check separate from operator-facing Lucia evals. It targets Guest Agent Production at https://guest.hellolucia.ai and runs a bounded deterministic booked-guest verification scenario pack. Exact internal Eval Labs routes and case payloads are intentionally omitted from public documentation. The implementation claim is bounded to Eval Labs owning source and the deployed Eval Labs release identity 6cbfd15f75330c414bfe79e0d2fab51ef8115102, reviewed on 2026-08-12. That review established the check surface and target contract; it did not execute the scenario pack, inspect a fresh authenticated result, or produce new Guest Agent runtime evidence. The check’s presence is not proof that it currently passes or that the broader guest-facing battery below is implemented or launch-ready.

​
Requested/future: broader Guest-facing battery

The broader first-class Guest-Facing Lucia Eval Track remains Requested with capability status future. Purpose:
Required validation coverage includes identity orientation, booked-guest claim parsing, claim fragments across turns, insufficient versus eligible claims, ambiguous/no-match cases, magic-link eligibility, verification-email privacy, one-time verification/replay/expiry behavior, current verification-state behavior, guest operational signals, expected downstream Admin review visibility with separate dated proof, no cross-record drift between explicitly synthetic guest labels, and warm hospitality tone.

​
Knowledge Center Map

Start here, then read:

​
Current boundary

Implemented does not mean production-hardened. The accepted evidence does not prove:
Canon should record implemented state, doctrine, and roadmap separately.