Most AI receptionists are one conversation, hard-coded for one business. This one isn’t.
Assembler runs the same voice runtime for every business. Workflows, rules and real actions live in structured Blueprints — then one engine executes them.
The problem
Every business gets its own app. That doesn’t scale.
Rewriting conversations, rules and integrations for every vertical creates six products to maintain. We built the part that shouldn’t be rewritten.
The differentiator
A prompt tells the model what to say. A Blueprint tells it what it’s allowed to do.
TYPICAL PROMPT
“You are a friendly receptionist. Be helpful, collect the customer’s information and try to schedule an appointment…”
ASSEMBLER BLUEPRINT
One engine
One runtime. Six businesses. Same engine.
Change the Blueprint. The runtime stays put.
Collects
Name · phone · vehicle · issue · urgency
Can do
Service request · availability · booking
Rule in effect
Safety-critical issue → escalate
Production receipt
This actually happened.
One production test, start to finish. Real Calendar, real Sheet, no mocked availability.
Availability checked
11 slots found
09:00 selected
Booking created
Calendar event added
Sheet updated
Automated QA booking
Oct 1 · 09:00 · via Assembler
Architecture
How it fits together.
AssemblyAI handles real-time listening and speaking. Assembler decides what happens because of what it hears.
Try the runtime
Start from a working business, not a blank page.
Pick a live starter, inspect its Blueprint, then hear the same runtime behave like a completely different business.