Docs · Micklegate Lettings demo
How the AI front office works
An assistant that answers a letting agency's enquiries from its website chat and property portal emails (WhatsApp is built and next), books viewings into the real diary, and hands over to a person whenever it should. This page shows what it does, step by step, and what it is built from.
A worked example. Micklegate Lettings is a fictitious York agency. The assistant, the calendar, the inbox and the emails behind it are real and running, so everything on this page can be tried on the live demo.
In one minute
What the agency gets
Interactive workflow
Follow one enquiry through the system
Pick a scenario, then press play or step through it. Each step lights up the part of the system doing the work. Select any box on the board to see what it is.
The board scrolls sideways on a narrow screen. The steps on the right tell the same story in words.
All steps in this scenario
Architecture
What it is built from
Eight layers, from where an applicant writes in to where the work is checked. Every service here is in use on the live demo.
Inside the agent
How one turn is decided
Every message, from any channel, goes through the same small graph of steps. A fast model sorts it, a stronger model writes the reply, and tools fetch facts so the reply never relies on the model's memory.
Selected step
For engineers
One contract for every channel
Each channel adapter turns what arrives into one Envelope. The
agent answers with an AgentReply: messages to deliver, and
actions for the effect worker to carry out. The agent decides; it never
performs a side effect itself.
Briefing
How the assistant is briefed and kept in bounds
Two layers decide how an assistant behaves: a written brief that tells it who it works for and how to speak, and guardrails that hold whatever the brief says. Both are written for each business; pick one below to see how they change. The examples are illustrative, not this demo's own.
Trust
Safeguards built in, not bolted on
An agency's name is on every reply, so the assistant is designed to be cautious first and helpful second.
Security
How the service protects itself
The safeguards above govern what the assistant says. These controls protect the service around it: who can reach it, what a message can do and what is left in the logs.
Not part of this demo
The demo has no user accounts of its own, so there is no login or password reset to attack, and no need for a CAPTCHA. A visitor's chat runs on a signed credential from the chat widget, which the service checks before it shows a conversation. Staff use the chat console's own login.
SSRF does not apply either: no route fetches a URL supplied by a caller, and every destination is fixed on the server.
In a real deployment
- Staff sign in through single sign-on with multi-factor authentication.
- Sessions held in secure cookies.
- Secrets kept in a dedicated secrets manager.
- A web application firewall at the edge.
- A penetration test before going live.
How the FAQ search works (RAG)
- The question is embedded with Amazon Titan.
- A similarity search runs over the approved corpus in pgvector.
- Below a measured floor, the turn becomes a referral to a person.
- Otherwise the answer is grounded only on the retrieved passages.
This is retrieval-augmented generation. Because answers come only from approved content, it also limits what a prompt injection can achieve.
Reference
The settings that shape behaviour
What each setting decides and how to think about it. The right values depend on the agency: its volume, its guidance and how costly a wrong answer is, so each deployment sets its own rather than copying another's.
Questions