Skip to Content

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.

ToolWhat it returns
search_listingsActive catalog listings — optional city / maxPrice filters.
list_leadsYour most recent CRM leads (name, contact, source, date).
get_leadA single lead’s full detail by leadId (message, source, claim state).
list_dealsRecent pipeline deals (stage, sale price, commission, compliance, est. close).
brokerage_summaryQuick 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.

Last updated on