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.
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.
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 01Realtime telephone voice
CHANNEL 02Website conversation
CONTROL PLANEPixeldust orchestration
SYSTEM OF RECORDBoss 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.
Realtime conversation
The model listens or reads, maintains conversational context and decides when an approved knowledge lookup or business tool is necessary.
Approved knowledge
A bounded set of relevant content is selected from reviewed website pages, FAQs, service facts, policies and structured business information.
Trusted application
Server-side code validates tool inputs, protects credentials, applies business rules, handles timeouts and records observable results.
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.
Twilio + SIPTelephone 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.
OpenAI RealtimeSpeech 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.
Node.js + Express + WebSocketServer-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.
Cloudflare Workers + Responses APIChat 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.
Versioned snapshot + API fallbackReviewed 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.
Supabase + PostgreSQLStructured 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.
Twilio + email servicesNotifications 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.
TLS + health checks + service managerManaged 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 pathLOW LATENCY
- Inbound callTwilio sends the call through the configured SIP route.
- Signed call eventThe Pixeldust service verifies the incoming OpenAI webhook before accepting the call.
- Realtime sessionInstructions, voice settings, transcription, VAD and tool schemas are attached to the call.
- Server sidebandA private WebSocket receives tool calls and returns validated results without exposing credentials to the model.
- Verified dispositionThe lead or action is reported as successful only after the connected system confirms it.
Website chat pathPAGE AWARE
- Visitor messageThe browser submits the current page and bounded conversation history to the Site API.
- Source selectionDeterministic ranking chooses the most relevant approved pages and structured facts.
- Response generationThe model answers only from supplied facts under strict identity, length and pricing rules.
- Action linksThe interface separately supplies approved links instead of asking the model to invent routes.
- Lead conversionBuying 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 sourceReviewed pages, FAQs and structured product facts
source02
Build-time extractionNormalized documents, questions, keywords and links
snapshot03
Deterministic rankingCoverage and relevance before model generation
select04
Bounded contextOnly the most relevant approved excerpts
context05
Natural answerChannel-specific response rules and safe fallback
respondTool 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.
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.
Business rules in code
Phone numbers, email addresses, websites, required contact methods and caller-ID confirmation are normalized and checked outside the model.
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.
Bounded network calls
Integrations use explicit endpoints, timeouts, least-privilege credentials and controlled payloads. Failures remain failures instead of becoming optimistic dialogue.
Results before promises
Maisy confirms a lead, message, booking or ticket only when the connected system returns the expected success result.
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.
Contact + request
Name, business, website, phone, email, source and the reason for contact.
Submission history
Voice summary, chatbot intake, form content, SMS body and supporting details.
Stage + next step
New, qualified, contacted, proposal, won or lost, with private notes and ownership context.
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 / GraphQLDirect 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 / EVENTEvent-driven handoff
Send a signed, versioned payload to a client endpoint or event queue and process retries without creating duplicate leads.
FUNCTION / DATABASEServer-side function
Use a controlled database function when the authoritative workflow already lives in a platform such as Supabase or another managed backend.
EMAIL / PLATFORMStructured 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.
Verify the caller path
Incoming provider webhooks are cryptographically verified before the application accepts the event or attaches tools to the call.
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.
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.
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.
Map the workflow
Document caller intent, knowledge, required fields, existing systems, permissions, exceptions and the human escalation point.
Define contracts
Create the conversation policy, knowledge sources, tool schemas, normalized lead object and exact success conditions.
Build adapters
Connect telephony, knowledge and Boss CRM or the client CRM using bounded credentials and explicit field mapping.
Test the full path
Exercise normal calls, interruptions, silence, wrong details, duplicate events, system failures and readback from the destination CRM.
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.
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.