A WhatsApp assistant for each broker, with their clients kept separate
Each broker's WhatsApp assistant uses the firm's shared information while keeping their deals and contacts separate. This prototype worked from start to finish on one test number. The planned trial with three brokers had not started.
CreditDesigned and built by our founder, as lead developer for a partner agency.
Follow one request
Each broker uses the same tools but sees only their own clients
A listing search can run on its own. Changing a deal needs the broker's approval first.
Broker A asks for a listing. The signed access key limits the search to the records broker A may see. A proposed change to deal A-17 waits for the broker's approval. After approval, the stage changes to Offer made and the action is logged. No client message is sent.
A deal change waits for approval in the default setting. In the default setting, changing a deal needs a specific draft and a clear approval. Looking things up can run on its own.
About Sahra Properties
The owner wanted each broker to have their own assistant, not one chatbot shared by the whole team.
Sahra Properties is a brokerage in Dubai. Its brokers sell through WhatsApp, voice notes and property portals, and most of their day goes on enquiries, listing checks and viewing times. The plan was to start with three brokers, then add the rest of the team and partner agents.
- Client
- Sahra PropertiesA Dubai real-estate brokerage selling through WhatsApp and property portals
- Industry
- Dubai real estate
- Where brokers work
- WhatsApp, voice notes and property portals
- Test scope
- One WhatsApp test numberTest listings were used. The wider pilot was planned but not started.
The brokerage's problem
Why one chatbot for the whole team would not work
Each broker has their own clients
Brokers work from their own phones. An assistant must not mix everyone's contacts and deals together.
Brokers look up the same things all day
Checking listing details, permits and past sales takes brokers away from their clients. Admin and follow-up get left until later.
Everyone needs the same firm information
Templates and policies should be kept in one place, so every broker works from the same version.
What was built
What the brokers share, and what stays private to each broker
- Shared on purpose
Information every broker shares
A central service gives every assistant the same market data, templates and policies. It carries out lookups and records each action; the AI itself runs in each broker's assistant.
- Kept separate
Records only that broker can see
Each assistant runs on its own server. Signed access keys and database rules limit contacts, deals and listings to that broker.
- The broker's own phone
It works on the broker's own WhatsApp
Text messages and English voice notes were tested on one number. Voice notes are turned into text on the assistant's server. Arabic support was planned.
- The next broker
The next broker can be added the same way
Scripts create the broker's record, issue their access, load their profile and connect their WhatsApp. The server setup is written in code, ready for the next broker in the pilot.
The client chooses the rules
Three settings for how much the assistant can do on its own
Open a setting to see what asks first. Publishing a listing, messaging a client, deleting a record and inviting outside people ask first in every setting. These actions were not connected.
ManualAsk before every action
Every action needs approval: looking things up, small changes, big changes and actions that cannot be undone. Even a listing lookup asks first.
- Listing lookup → asks
- Save a contact → asks
- Change a deal → asks
Auto-editDefaultAsk before big changes
This is the default. Looking things up and small changes, such as saving a contact, can run on their own. Big changes, such as changing a deal, and actions that cannot be undone need approval.
- Listing lookup → can run
- Save a contact → can run
- Change a deal → asks
BypassOnly actions that cannot be undone ask
Looking things up and both kinds of change can run without asking. Actions that cannot be undone still need approval. This mode does not switch on the unfinished publishing or messaging tools.
- Listing lookup → can run
- Save a contact → can run
- Change a deal → can run
Control and safety
The assistant shows the exact change before the broker approves it
In the default setting, reading data and saving a contact can happen without asking. Changing a deal waits until the broker replies “approve” to a specific draft. A casual “ok” without a draft does not count.
- The service checks approval too. The approval rules sit in the assistant's instructions and in the shared service. If a request has not been approved, the service sends back the draft instead of making the change.
- Repeated tasks need an approved schedule. The assistant shows what will run and when before setting it up. This step was tested on WhatsApp without creating a real scheduled task.
- Every action is recorded. The action log saves each request with private details removed. It also records the result and what triggered the request. A manager dashboard was planned but not built.
- The instructions require approval in every setting. Publishing a listing, messaging a client, deleting a record and inviting outside people need approval in every setting. These actions were not connected.
For technical readers
How the system works
A broker's assistant asks the shared service for information over a private network. The service checks who is asking, limits the database search to that broker's records and logs the result. Market data and templates are shared on purpose.
Dashed lines show supporting connections, or parts that are paused or not yet built.
In more detail
Technology used (8 parts)Each part of the system, and why it was chosen.
| Layer | Technology | Why it was chosen |
|---|---|---|
| Assistant | Hermes Agent v0.14 · Baileys | An open-source assistant framework provides memory, skills and the connection to WhatsApp as a linked device. |
| Voice | faster-whisper · local base model | Turns English voice notes into text on the broker's own server. Arabic was planned. |
| Models | Codex (GPT-5.4) · OpenRouter fallback | The assistants use these AI models. A second provider takes over if the main one fails. |
| Shared service | Python 3.11 · FastAPI · Pydantic 2 · PyJWT | Checks each tool request and signed access key, without adding another AI model to the shared service. |
| Data | Supabase Postgres · row-level security · pgvector | Database rules limit who sees which records. A table for firm knowledge exists; searching it by meaning was still the next step. |
| Setup | OpenTofu · cloud-init · systemd | Defines each broker's server, firewall and private network connection in code. |
| Hosting | European cloud servers · private network | The shared service accepts traffic only from the private network. Broker servers accept only secure admin logins (SSH). |
| Checks | pytest · ruff · mypy · GitHub Actions · structlog | Tests the shared service and records how it behaves. Tests against the real setup add to automated tests that run without a database. |
5 engineering decisions that matteredThe problem, what was done, and what it changed.
The broker's identity comes from a signed key
A request cannot choose which broker it acts for. The service checks who issued the key, which service it is for, its signature and its expiry date. It then uses the broker ID inside it. Broker servers do not hold the key used to sign it.
The database itself keeps brokers' records apart
A broker ID is set for one database transaction and cleared when it ends. Row-level security, a database rule that limits which rows each user can see, is switched on and enforced on all 10 tables. Market data, templates and the list of brokers are shared on purpose.
Approval is checked in two places
Manual mode asks before every action. Auto-edit, the default, asks before high-impact changes and actions that cannot be undone. Bypass asks only before actions that cannot be undone. Without approval, the service refuses the request with an HTTP 409 error, and it must be sent again with approval.
Separation was tested before anything else was built
The first day's check used two test brokers and switched between them. Their results had to stay separate before any application code was added. Each deployment backs up the running service and restores it if the health checks fail.
Database checks were made faster
Database advisor tools found security rules that recalculated a setting for every row. The lookup was changed to run once per query, and database functions were restricted to looking up objects in approved locations. The advisors then reported no issues.
Testing and build recordHow it was tested, and the build by the numbers.
Quality and reliability
- 8 automated tests cover login with the access key, registration of all 9 tool routes and the approval rules in two modes. They run without a database, so they do not test separation from start to finish.
- Tests on one WhatsApp test number covered text, listing search, an English voice note, the approval step and the scheduling step.
- GitHub Actions runs code checks (ruff, mypy) and tests (pytest) whenever the shared service changes.
- The service uses a database account with limited rights. More powerful keys stay outside the running services and are used only for database changes and support.
- The assistant is told to report that a task is done only after it sees confirmation in the current conversation.
By the numbers (build)
- 5 days from first commit to the first WhatsApp reply loop on a test number.
- 9 shared tools, 13 broker tasks, 6 migrations and 10 database tables.
- 4 impact levels, 3 approval modes and 5 setup and deployment scripts.
- 16 commits from 21 May to 12 June; about 1,700 lines of Python in the shared service.
Is it a fit?
Could this work for your team?
- Your agents sell through WhatsApp. Brokerages with 10 or more agents need shared information about listings, policies and templates.
- Each adviser has their own clients. Mortgage, insurance and other broker networks need shared rules without putting everyone's clients in one list.
- You want to control what the assistant does. Choose which actions can run automatically and which need a person, then test those rules in a small pilot.
- Start with two or three people. We adapt the tasks, the listing or customer system connections, the approval rules and the languages before a wider rollout.
What should your brokers share, and what should stay private to each of them?
Conducted by Apurva · Not a sales call
Or write to care@brownmind.com