Realty Support
A fictional brokerage support workspace with client/staff views, private notes, property exploration and human-approved appointment changes.
Role: Independent builder
AI stack
Guided record-based support · Optional gpt-4.1-mini · Human-approved writes · No embedding / vector index
Realty Support joins a client portal and a staff inbox around the same fictional case. I built it to make support handoffs and appointment changes visible without giving the conversational model authority to commit them.
Product preview
The public hosted app opens in a fictional Demo workspace. It demonstrates the client and staff experience; it is not connected to a real brokerage operation.
Under the hood
Flow: select client → guided support or optional record-based answer → pending change request → staff decision → transactional schedule checks.
The hosted classroom version uses guided support without an external model key. An optional model is part of the code, not evidence that the hosted demonstration is making live AI calls.
Records, embeddings and context
Seeded clients, knowledge articles and the property catalogue are structured fictional records. There is no embedding model, document chunker, vector index, keyword/dense fusion or reranker in the assistant path. Property filters do not establish semantic retrieval. Sensitive document uploads are intentionally unavailable.
Optional OpenAI support defaults to gpt-4.1-mini using Chat Completions. Its context contains the selected client record, approved sample knowledge and the last six public messages. Other clients and staff-only notes are excluded before the call. This is record-based prompting rather than retrieval over a document corpus.
Answer flow and operational tools
Guided rules handle property facts, documents and next steps. Advice, uncertainty and requests for a person route to the assigned agent inside the demonstration. Optional answers must return the expected text, source and escalation fields; source references are filtered to known knowledge articles. Provider failure or invalid JSON falls back to guided support. Known-source membership does not establish semantic faithfulness.
There is no LangGraph agent or autonomous model tool. The model cannot approve an appointment, execute a database write or send an external notification. The application owns replies, notes, listing inquiries and change requests; escalation is a persisted in-app flag.
Transactions and safeguards
A request retains the confirmed time while awaiting staff approval. Approval binds the request to its original appointment state and checks staff schedule collisions. Receipts make repeated decisions idempotent. SQLite stores a per-browser workspace, and model generation happens outside the write transaction to avoid locking the inbox while a provider responds.
The optional call has a twenty-second timeout, a 500-token output limit and no SDK retries. Concurrent duplicate messages can still reach generation before receipt checks prevent repeated persistence, so this is not exactly-once provider billing. There is no verified cumulative spend ledger equivalent to the sibling research apps.
Signed sessions, owner-scoped records, CSRF/origin checks and staff authorization protect demonstration workflows. The role switcher is a demo control, not enterprise identity. Real brokerage use would require authorized data, authentication and operational/privacy controls; no live listings, CRM, calendar, email or SMS connection is claimed.
Evaluation and recorded decisions
Stubbed service and browser tests cover client/note isolation, stale and duplicate approvals, double booking, message idempotency and property workflows. No answer-accuracy dataset, LLM judge, retrieval benchmark or user-impact result was established.
The project documents guided fallback, read-only model context and retaining the old appointment until approval as its control boundary. The simple JSON workspace defers normalized data and organization membership. That makes the demonstration inspectable, while leaving production identity and scalable knowledge search as separate work.
A request is not an approval
A client can request a change. Staff approval checks conflicts and stale state before updating the appointment. Repeated approval requests do not repeat the action. Public replies and internal notes follow separate paths, and the client response excludes staff notes and other client records.
The working demonstration
The interface includes property filters, saved lists, comparisons, viewing inquiries, document checklists and transaction progress. SQLite persists a separate workspace for each browser. Guided support runs without a model key; optional conversational answers use the selected sample record and public conversation. Model responses cannot approve appointments or write the database.
Evidence and limits
Tests cover record isolation, note privacy, approval authorization, idempotency and stale requests. Earlier browser checks cover support and property workflows across themes and small screens. The screenshots here were captured from the current local demonstration; they do not establish production readiness.
A hosted demonstration is linked above. All clients, properties and transaction details are illustrative. The role switcher demonstrates an experience and does not authenticate real staff. There is no live listing feed, calendar, CRM, email or SMS connection. A viewing inquiry remains a request inside the demonstration.