--- type: Website Page title: "Maisy Technical Architecture | Voice, Chat and CRM Integration | Pixeldust" description: "A technical explanation of Maisy's voice, chat, knowledge, orchestration, security and CRM integration architecture, including Boss CRM and custom business systems." resource: "https://pixeldust.net/services/maisy-technical-architecture" tags: [pixeldust, website] status: stable sources: - id: canonical-page resource: "https://pixeldust.net/services/maisy-technical-architecture" title: "Maisy Technical Architecture | Voice, Chat and CRM Integration | Pixeldust" --- # Maisy Technical Architecture | Voice, Chat and CRM Integration | Pixeldust > A technical explanation of Maisy's voice, chat, knowledge, orchestration, security and CRM integration architecture, including Boss CRM and custom business systems. ## Source - [Open the canonical human-readable page](https://pixeldust.net/services/maisy-technical-architecture) - [Browse the Pixeldust knowledge index](https://pixeldust.net/okf/index.md) ## Page content Maisy technical architecture # One intelligence layer. Two conversational channels. Maisy combines realtime voice, website chat, approved business knowledge and server-controlled tools. The model handles conversation. Pixeldust application code controls what the system knows, which actions it may take and where verified results are stored. [Discuss an implementation →](https://pixeldust.net/inquiry?service=maisy-technical-review) [See the product overview](https://pixeldust.net/services/maisy-ai-receptionist) Architecture map production pattern VOICE → Twilio SIP → OpenAI Realtime CHAT → Website UI → Cloudflare API KNOWLEDGE → Approved site sources → ranked context TOOLS → Node orchestration → validated actions CRM → Boss CRM or adapter → verified handoff CHANNEL 01 Realtime telephone voice CHANNEL 02 Website conversation CONTROL PLANE Pixeldust orchestration SYSTEM OF RECORD Boss CRM or client CRM System topology ## Conversation is only the front end. The useful product is the complete path from a caller or visitor to an approved answer, a qualified request and a confirmed handoff. Each boundary is explicit so conversational freedom never becomes unrestricted system access. 01 / INPUT ### Voice or chat A phone call enters through SIP. A website message enters through the Pixeldust guide interface. Each channel preserves its own timing and interaction model. 02 / MODEL ### Realtime conversation The model listens or reads, maintains conversational context and decides when an approved knowledge lookup or business tool is necessary. 03 / CONTEXT ### Approved knowledge A bounded set of relevant content is selected from reviewed website pages, FAQs, service facts, policies and structured business information. 04 / CONTROL ### Trusted application Server-side code validates tool inputs, protects credentials, applies business rules, handles timeouts and records observable results. 05 / OUTCOME ### CRM and workflow Boss CRM or another approved system receives structured contact data, intent, context, status and the next action for the team. Current reference stack ## The actual components behind Maisy. These are the technologies in Pixeldust's reference implementation. The architecture keeps provider-specific pieces behind configuration and adapters, so the business workflow can evolve without rebuilding the entire product. Voice transport Twilio + SIP ### Telephone entry Twilio owns the public number and routes inbound voice through SIP. The same telephony layer can support forwarding, missed-call coverage, inbound SMS and approved notification messages. Realtime AI OpenAI Realtime ### Speech and dialogue The current voice runtime uses an OpenAI Realtime model with audio input, transcription, server-side voice activity detection, natural speech output and typed function tools. Voice control plane Node.js + Express + WebSocket ### Server-side orchestration An AWS-hosted Node.js service verifies signed events, accepts calls, attaches a sideband WebSocket, executes tools, coordinates responses, records operational events and controls call completion. Website runtime Cloudflare Workers + Responses API ### Chat delivery The website chatbot runs through the Pixeldust Site API. It uses the OpenAI Responses API, bounded conversation history, current-page context, ranked site knowledge and a strict short-answer policy. Knowledge layer Versioned snapshot + API fallback ### Reviewed business context The Site source is canonical. The phone runtime loads a generated local snapshot for low-latency retrieval and uses the live Pixeldust knowledge API as a fallback when the local match is not confident. Data and CRM Supabase + PostgreSQL ### Structured handoff Boss CRM uses Supabase functions and PostgreSQL records for contacts, submissions, messages and activity. Row-level controls prevent direct public access to private CRM tables. Business messaging Twilio + email services ### Notifications and replies Lead alerts, inbound text messages, outbound email, replies and scheduled follow-up can be connected to the same contact history without making the conversation model the system of record. Production operations TLS + health checks + service manager ### Managed runtime The voice service is isolated behind HTTPS, bound privately, restarted on failure and checked independently from the public website. Configuration and secrets remain outside the application package. Two runtime paths ## Shared knowledge does not mean duplicated infrastructure. The phone assistant and website chatbot share approved facts and business intent, but each uses a runtime designed for its channel. Voice prioritizes turn-taking and latency. Chat prioritizes concise text, page-aware links and browser delivery. Telephone voice path LOW LATENCY - Inbound call Twilio sends the call through the configured SIP route. - Signed call event The Pixeldust service verifies the incoming OpenAI webhook before accepting the call. - Realtime session Instructions, voice settings, transcription, VAD and tool schemas are attached to the call. - Server sideband A private WebSocket receives tool calls and returns validated results without exposing credentials to the model. - Verified disposition The lead or action is reported as successful only after the connected system confirms it. Website chat path PAGE AWARE - Visitor message The browser submits the current page and bounded conversation history to the Site API. - Source selection Deterministic ranking chooses the most relevant approved pages and structured facts. - Response generation The model answers only from supplied facts under strict identity, length and pricing rules. - Action links The interface separately supplies approved links instead of asking the model to invent routes. - Lead conversion Buying intent can move the visitor into an estimator, inquiry workflow or CRM-backed contact path. Knowledge architecture ## Maisy answers from approved company knowledge. Website content, service details, FAQs, process information and policy statements remain the source of truth. A build process prepares that information for retrieval. At runtime, a deterministic selector scores the question against titles, known questions, keywords, descriptions and page text, then sends only the strongest excerpts to the model. The phone service reads a versioned local snapshot first. If no local document reaches the confidence threshold, it calls the live knowledge API. If neither source supports the answer, Maisy says she cannot confirm it instead of improvising. 01 Canonical Site source Reviewed pages, FAQs and structured product facts source 02 Build-time extraction Normalized documents, questions, keywords and links snapshot 03 Deterministic ranking Coverage and relevance before model generation select 04 Bounded context Only the most relevant approved excerpts context 05 Natural answer Channel-specific response rules and safe fallback respond Tool execution ## The model may request an action. It cannot simply take one. Maisy's tools use explicit JSON schemas and narrow server-side handlers. The model can propose a knowledge lookup, lead save or other approved operation, but application code decides whether the request is valid and whether the result is trustworthy. 01 / DEFINE ### Narrow tool schemas Every action has named fields, required values, length limits and a defined purpose. The tool receives structured data rather than unrestricted access. 02 / VALIDATE ### Business rules in code Phone numbers, email addresses, websites, required contact methods and caller-ID confirmation are normalized and checked outside the model. 03 / AUTHORIZE ### Credentials stay server-side Provider keys, CRM access and webhook secrets are loaded by the trusted runtime. They are never placed in prompts or returned to the caller. 04 / EXECUTE ### Bounded network calls Integrations use explicit endpoints, timeouts, least-privilege credentials and controlled payloads. Failures remain failures instead of becoming optimistic dialogue. 05 / VERIFY ### Results before promises Maisy confirms a lead, message, booking or ticket only when the connected system returns the expected success result. 06 / RECOVER ### Safe failure paths Timeouts, duplicate events, incomplete calls and unavailable systems follow defined fallback behavior, including partial lead capture where appropriate. Boss CRM integration ## The handoff lands where the team can use it. Boss CRM is Pixeldust's lightweight, customizable CRM and the reference system of record for Maisy. Voice calls, text messages, website forms and AI chatbot conversations can enter the same contact history as structured submissions. Maisy sends the confirmed identity, business, website, contact methods, request and concise conversation summary through a server-side contact function. Boss CRM connects that intake to pipeline stage, notes, messages, replies, follow-up and activity history. Boss CRM contact record structured handoff INTAKE ### Contact + request Name, business, website, phone, email, source and the reason for contact. CONTEXT ### Submission history Voice summary, chatbot intake, form content, SMS body and supporting details. WORKFLOW ### Stage + next step New, qualified, contacted, proposal, won or lost, with private notes and ownership context. CONVERSATION ### Messages + follow-up Outbound email, inbound replies, editable AI drafts and per-contact drip sequences. Other CRM systems ## Boss CRM is native. The adapter pattern is portable. A client can use Boss CRM or keep an existing CRM. Pixeldust maps Maisy's normalized conversation result into the destination system's fields, permissions, duplicate rules and workflow triggers. REST / GraphQL ### Direct API adapter Authenticate with OAuth or a service account, map fields, create or update the correct record and retain the external ID for later actions. WEBHOOK / EVENT ### Event-driven handoff Send a signed, versioned payload to a client endpoint or event queue and process retries without creating duplicate leads. FUNCTION / DATABASE ### Server-side function Use a controlled database function when the authoritative workflow already lives in a platform such as Supabase or another managed backend. EMAIL / PLATFORM ### Structured intake Use structured email or an integration platform when a direct API is unavailable, while preserving validation, monitoring and a clear failure path. Customization surface ## Customization reaches every layer that matters. Maisy is not customized by changing a logo and pasting in a prompt. Each implementation can alter the channel behavior, knowledge, qualification logic, tools, handoff schema, security rules and operating controls. Layer What can be customized Technical implementation Identity and conversation Name, greeting, disclosure, tone, brevity, vocabulary, escalation language and sales approach Version-controlled system instructions, channel policies and behavioral tests Voice behavior Voice, pacing, silence threshold, interruption handling, call duration and end-of-call behavior Realtime session configuration, VAD settings, audio output and orchestration timers Business knowledge Services, locations, hours, policies, process, FAQs, product detail and approved pricing Canonical content sources, generated snapshot, ranking metadata and fallback API Qualification Required fields, question order, urgency rules, service area, lead criteria and confirmation logic Prompt rules plus deterministic validation and normalized data schemas Business actions Lead creation, scheduling requests, tickets, tasks, transfers, notifications and lookups Typed function tools with dedicated server-side handlers and explicit permissions CRM mapping Objects, fields, pipeline stages, owners, tags, deduplication and follow-up triggers Boss CRM functions or a destination-specific adapter with idempotent writes Routing and handoff Business hours, overflow, departments, locations, callbacks, transfers and failure destinations Telephony configuration, application rules and verified downstream outcomes Privacy and retention Transcript logging, raw audio policy, redaction, retained fields, access and deletion rules Runtime configuration, storage controls, restricted credentials and documented retention Operations Health checks, alerts, audit detail, dashboards, quality review and release process Structured events, service monitoring, integration verification and real-call testing Security and reliability ## Useful autonomy needs hard boundaries. The architecture assumes that models are conversational components, not trusted databases or credential stores. Sensitive capabilities remain behind verified events, server-side code and narrow permissions. SIGNED INPUT ### Verify the caller path Incoming provider webhooks are cryptographically verified before the application accepts the event or attaches tools to the call. LEAST PRIVILEGE ### Limit every connector Each service receives only the credentials and operations required for its approved workflow. Public clients do not receive direct CRM-table access. OBSERVABLE OUTPUT ### Log outcomes, not guesses Tool calls, failures and handoffs produce operational evidence. Health checks alone are not treated as proof that a phone conversation or CRM write worked. HUMAN REVIEW ### Control the source of truth Calls can reveal missing knowledge, but they do not automatically rewrite business facts. A person reviews and approves changes before release. Implementation sequence ## Build the smallest complete path first. A successful implementation proves the conversation and the downstream result together. Adding more tools before the first handoff is reliable only creates a larger debugging surface. 01 / DISCOVER ### Map the workflow Document caller intent, knowledge, required fields, existing systems, permissions, exceptions and the human escalation point. 02 / MODEL ### Define contracts Create the conversation policy, knowledge sources, tool schemas, normalized lead object and exact success conditions. 03 / CONNECT ### Build adapters Connect telephony, knowledge and Boss CRM or the client CRM using bounded credentials and explicit field mapping. 04 / VERIFY ### Test the full path Exercise normal calls, interruptions, silence, wrong details, duplicate events, system failures and readback from the destination CRM. 05 / OPERATE ### Release and tune Monitor real outcomes, review knowledge gaps and improve the workflow without weakening the validated boundaries. Technical discovery ## Bring us the workflow, the systems and the awkward edge cases. Pixeldust can map a Maisy implementation around Boss CRM or the CRM you already use, then define the exact voice, chat, knowledge, integration and operational architecture. [Plan the technical architecture →](https://pixeldust.net/inquiry?service=maisy-technical-review) Architecture in practice ## See what Maisy can do for your team. The same voice, chat, knowledge and integration architecture supports three roles. Explore the problems each solves and how the conversation becomes a useful handoff. [AI Receptionist →](https://pixeldust.net/services/maisy-ai-receptionist-use-case) [AI Customer Service Agent →](https://pixeldust.net/services/maisy-ai-customer-service) [AI Sales Agent →](https://pixeldust.net/services/maisy-ai-sales-agent) [^canonical-page]: Content derived from the canonical Pixeldust Interactive page linked above.