Onoots AI — the conversational layer
Onoots AI is a chat interface (like Claude.ai) sitting on top of the platform. You talk in plain language; an LLM (Claude) calls tools that read and write your Onoots data with your identity, so RLS keeps everything scoped to your brokerage. The model’s API key lives only on the server — it never reaches the browser.
It comes in three surfaces.
1 · Operator console — /dashboard/ai
For agents and brokers, inside the dashboard. It can:
- Query your live data — leads, listings, deals, cap progress, conversations.
- Operate the swarm — enable/disable AI swarm agents (brokers).
- Onboard autonomy — set, per act, what the AI does on its own.
- Act on the CRM — create a lead; send a follow-up email to a lead.
Every state-changing action is preview → confirm: the assistant shows you exactly what it will do and only executes after you confirm. Config actions are broker-only, enforced server-side.
Onboarding by conversation
Tell it your goal and it configures the system. Example:
“Publish to social on its own, but I approve visits.”
→ it enables the Marketer + Scheduler agents and sets post_social = full_auto, schedule_showing = ai_prepare_human_approve — then previews, you confirm, it applies. Legally-restricted acts require an explicit acknowledgment before loosening.
Outbound runs through the Guardian
When it sends a follow-up email it passes through the Compliance Guardian, which honours your autonomy policy: full_auto → it sends; ai_prepare_human_approve → it prepares it but does not send; blocked → it refuses. The policy you set governs what the assistant may send.
Conversation history
The console saves your chats (Claude.ai-style). The left sidebar lists every conversation: click one to open it, “New” to start another, the pencil to rename, the trash to delete. Each chat persists per agent, so you can close the panel, reload, or switch devices and pick up where you left off — and if your connection drops mid-answer, that answer is still saved. The title comes from your first message (you can change it).
History is operator-console only. The public concierge (/ai) doesn’t save
conversations.
2 · Buyer concierge — /ai (public)
The prospect-facing front door — Mr. Nelson, no login. It searches the catalog and shows real options, and captures what the buyer wants as a Dream (see Dreams) so Onoots emails them when a matching listing appears.
3 · MCP server — connect from Claude Desktop / a CLI
Onoots is also a Model Context Protocol server at https://onoots.com/api/mcp, so external clients (Claude Desktop, a CLI) can use Onoots read tools — your client brings its own model; Onoots only exposes data, scoped to your brokerage.
| Tool | What it returns |
|---|---|
search_listings | Active catalog listings — optional city / maxPrice filters. |
list_leads | Your most recent CRM leads (name, contact, source, date). |
get_lead | A single lead’s full detail by leadId (message, source, claim state). |
list_deals | Recent pipeline deals (stage, sale price, commission, compliance, est. close). |
brokerage_summary | Quick counts: total leads, new leads in the last 7 days, total deals. |
All tools are read-only and scoped to your brokerage (RLS on the Supabase-token path; explicit brokerage_id filter on the long-lived-token path).
Get a durable token (once): from the dashboard, POST /api/auth/mcp-token returns a long-lived onoots_mcp_… token (shown once; revocable). Then in claude_desktop_config.json:
{
"mcpServers": {
"onoots": {
"command": "npx",
"args": ["mcp-remote", "https://onoots.com/api/mcp",
"--header", "Authorization: Bearer ${ONOOTS_TOKEN}"],
"env": { "ONOOTS_TOKEN": "onoots_mcp_…" }
}
}
}Restart Claude Desktop → the Onoots tools appear, scoped to your brokerage.
Tokens are stored hashed (the plaintext is shown only once) and bound to your
brokerage. Revoke with DELETE /api/auth/mcp-token?id=…. A short-lived Supabase
access token also works as the Bearer for quick tests (~1h expiry).
Resilience — provider-agnostic by design
Onoots AI is not tied to a single model vendor. Every AI feature asks for a role (reasoning, cheap, or compliance), and the platform routes it through a gateway with an ordered fallback chain across providers. If the primary model is down, rate-limited, or changes pricing, requests automatically fail over to the next provider — no code change, no outage for you.
The Compliance Guard™ fails closed: if every model in the chain is unavailable, it never silently approves a document — it holds it and flags it for manual review. Availability never overrides compliance.