Architecture Overview

This is a real trace from our first verified conversation — one broker message, four tool calls, then the reply:

1. Widget sends the text to /api/chat/stream with the session id and shows a typing indicator (if this is the chat's first message, it mints the session via POST /api/session first — opening a chat alone creates nothing).
2. Gateway appends it to the session's history and calls the model with three things: the skills (as the system prompt, cached), the full history, and the schemas of all 13 tools.
3. Model extracts every piece of information in the message at once — "2BHK in Oberoi 360 West for rent, 1L, 5L deposit" fills five slots in one pass — then asks for the tool calls it needs.
4. Gateway executes each call through the MCP client; the MCP server calls the Rezide API and returns clean JSON (ids + labels together). Validation/preview calls also emit a live preview event — the portal's right-hand "Draft listing" pane fills in as slots are captured.
5. Model reads the results and chains further calls — get_project auto-fills the location block, get_unit_details auto-fills floor, area, BHK, bathrooms, directions. The loop repeats until nothing is missing.
6. Model writes the reply: short text plus, when useful, a ui block — chips for short choices, a list for pickers, a card for confirmation.
7. Gateway saves the turn, separates the ui JSON from the text, and responds with {reply, ui, tool_trace}.
8. Widget renders it. Tapping a chip simply sends that chip's value as the broker's next message — the loop starts again.

Chats are not throwaway: every session is a durable record with a lifecycle, and the Demo page is now a ChatGPT-style portal over exactly that.

• Deferred creation — opening a chat shows the greeting locally; the session is created server-side only when the first message is sent. Abandoned "new chats" leave nothing behind.
• Draft — an in-progress chat. Persisted to Mongo on every turn, so it survives restarts, reloads and gateway redeploys; the widget resumes it exactly where the broker left off, pending chips still tappable.
• Completed — the chat created its listing. It stays readable (transcript + confirmation card replay read-only) and badges green in the sidebar with its listing id.
• Deleted — the ✕ on a sidebar row (or DELETE /api/session/:id) hard-deletes the transcript from memory and the store. Idle sessions can also be auto-purged by the retention window (REZIDE_SESSION_RETENTION_DAYS).
• Listing & deletion are admin-gated — the embed key that ships inside host pages can never enumerate or destroy other brokers' chats; in keyed deployments the sidebar endpoints require REZIDE_ADMIN_KEY.

The agent picks one of three payload shapes automatically, based on what exists in Rezide's masters:

Whatever the variant, two gates always apply before the create call: the agent must show a confirmation card (built from a preview_listing dry-run) listing every value and every default, and the broker must explicitly say yes — create_listing physically refuses without confirmed:true. The result always lands as pending for moderation review.

• Nothing is created without an explicit yes — enforced twice: in the skill's instructions and in the tool's code.
• The agent never invents values — every field comes from the broker, the masters, or a default that's displayed on the confirmation card.
• Writes are environment-gated — creates require REZIDE_ALLOW_WRITES=true and a development host; the guard refuses anything else.
• Our validation is the real gate — probe-proven fact: the listing API accepts any payload, so the composer's completeness check is what guarantees clean data.
• Prices are sanity-checked against the project's own price range from the masters; the broker is warned once, and their confirmation wins.
• Moderation backstop — chat can never publish directly; every listing waits in the same pending queue as form submissions.