Home / Demos / Inbox triage

Watch an inbox sort itself.

Six emails land in a brokerage inbox on a Tuesday morning. A hot buyer, a listing question, an invoice, a pitch, an angry client, and a showing that needs to move. Press the button and watch the agent read each one, say out loud how it decided, hand it to the right person, and write the reply. Then stop, because a human still has to press send.

Demo

Live demo. Simulated inbox and data. Nothing is sent or stored. Every sender, address, phone number, and property below is invented. There is no mail server, no inbox connection, and no database. The classifying and routing logic runs in your own browser and disappears when you close the tab.

Northgate Property Group Fictional brokerage · demo only
Tuesday morning inbox Step 1
6 waiting

    The agent works top to bottom. Step through it one email at a time if you want to read the reasoning properly.

    Run totals Illustrative
    0 Emails processed
    0 Drafts prepared
    0 Minutes saved, est.

    The minutes figure is illustrative, not measured. It assumes 2 minutes to read and route an email by hand and 4 minutes to write a reply, which is roughly what a front desk spends. Your real numbers would come from your own inbox.

    How the agent decided Step 2
    Reading Nothing yet

    Start the run and six signal checks evaluate top to bottom for each email, stopping at the first one that matches.

    Classified Waiting

    Nobody yet

    The routing table has not run.

    These are deterministic checks on the text of the message, in a fixed order, the same way I would build the first version. A production build layers a language model on top for the messages that do not match a rule cleanly.

    Draft reply Step 3
    Draft Not sent

    No draft yet. Run the triage and the replies compose here, one email at a time.

    A human reviews and sends. The agent never sends alone. Drafts sit in a review queue with the original message attached. Nothing leaves the building without a person clicking approve.

    In this demo the wording of each draft is written into the page ahead of time. In a real build the model writes it from your listing data, your past replies, and your voice, and it lands in the same review queue.

    What this would do in production

    The demo is the honest half of it.

    Everything above is the decision layer, running where you can see it. A real build keeps the same visible reasoning and wires it to the mailbox, the CRM, and the people who own each queue.

    Your actual mailbox

    Reads the shared inbox over the mail API, labels the thread, and leaves the original message untouched so nothing is lost if you disagree with the call.

    Rules first, model second

    Clear cases go through deterministic rules you can read and edit. Only the ambiguous ones cost a model call, which keeps the bill small and the behaviour predictable.

    An approval queue that is real

    Every draft waits for a human. Approve, edit, or reject, and the rejections become training notes so the next batch of drafts sounds more like you.

    Escalation with a clock on it

    Complaints and time-critical requests page the managing broker instead of sitting in a queue. If nobody claims one inside the window, it escalates again.

    An audit trail per message

    Which rule fired, what the model saw, who approved it, when it went out. When a client asks what happened to their email, you have an answer.

    Facts from your data

    Answers about a listing come from the listing sheet, not from the model's memory. If the fact is not in your data, the draft asks a human instead of inventing it.

    Drowning in an inbox like this?

    Triage is one example. The same pattern works on intake, scheduling, document chasing, and every queue where the reading is the bottleneck.

    Tell me what's piling up See the lead router demo