Boolut CRM: AI-first CRM with an assistant and an MCP server
An omnichannel CRM for sales teams in the CIS. Its AI assistant, Boot, drafts replies and briefs leads on the Claude API, and its MCP server lets Claude and ChatGPT work with CRM data under each user's own permissions.
The problem
Sales teams in Central Asia sell through WhatsApp, Instagram and Telegram, not email. Their conversations are scattered across phones, leads get lost, and the AI tools on the market either auto-reply coldly or invent facts.
What I built
- Unified inbox for the WhatsApp Business Cloud API, Instagram, Telegram and a website chat widget, backed by a Node.js/Fastify worker with BullMQ queues for webhooks, outbound delivery, scheduled jobs and retries.
- Boot, the AI assistant, built on the Claude API. It drafts replies grounded in the workspace knowledge base, writes short lead briefs, suggests the next step with a “why?”, captures facts the customer stated into the lead record, writes a daily focus digest and handover notes, and transcribes calls.
- An evaluation bench that runs the real production reply drafter on saved test cases and grades the output with an LLM judge, so prompt changes are checked before they ship.
- An MCP server with 15 tools (11 read-only, 4 that write) so Claude and ChatGPT can search and work with leads, deals, tasks and conversations.
- Sales operations: import from HubSpot, Salesforce, Zoho, amoCRM/Kommo, Bitrix24 and CSV (it merges split exports and detects Windows-1251 Cyrillic), rule-based lead routing, cross-channel duplicate merge, conversion and first-reply SLA analytics, and an in-app softphone over LiveKit/SIP.
- Russian, English and Kyrgyz throughout.
Boot’s trust rules
The assistant follows four rules. Boot reads, the rep writes: the model has read-only tools, and every change is a proposal the rep accepts under their own permissions. Boot cites or says nothing: a draft with a price or number that isn’t in the knowledge base or the customer’s own messages is thrown away. Boot shows its work: every run is logged and priced against an AI-credit budget. Boot admits its limits: out of credits, context or confidence, it says so instead of guessing.
The MCP server inherits the app’s security instead of copying it
The obvious design is to use a service-role key and add a workspace filter to every query, which is one forgotten filter away from leaking another company’s data.
Instead, every tool call mints a 120-second token for the connected user and runs through the same Postgres row-level security policies as the web app. The token is never logged or stored. At boot, the worker tests its own signing key, so a key rotation shows up as one clearly named unavailable feature instead of unexplained 401s.
In a later review I added a second layer: RLS answers “may this user see this row”, but a user can belong to several workspaces, so every query is also pinned to the workspace the connection was approved for. The pin can only narrow access, never widen it.
Every MCP call is logged by tool and result for workspace admins, but arguments are never stored, because they contain names and phone numbers. Rate limits return a message the model can read instead of a bare HTTP 429, so the agent slows down instead of reporting that the connector failed.
Results
- Production AI assistant used inside real customer conversations, with a person approving every action
- MCP connector for Claude and ChatGPT shipped in September 2026
- 450+ row-level security policies across 240+ migrations; 575+ test files