TL;DR — Practices like Arini, Viva and Dentina ship single-tenant agents. Build the same outcome multi-tenant with 4 specialists (intake, scheduling, recall, billing) talking to Dentrix or OpenDental, plus a shared FAQ. Booking refs follow a DT-YYYYMMDD-### pattern modelled on CallSphere's salon convention.

What you'll build

A 4-agent dental front desk: triage → (new-patient intake | scheduling | recall reactivation | billing). Reads/writes to OpenDental via mod_xfer, sends SMS confirmations, and emits structured ref IDs.

Prerequisites

1. OpenDental or Dentrix instance with API enabled.
2. OpenAI Realtime + Twilio Voice + SMS.
3. Python 3.11, openai-agents[voice], fastapi.
4. A list of recurring intents from your last 200 calls.
5. SMS opt-in language reviewed by office manager.

Architecture

flowchart TB
  C[Caller] --> TR[Triage]
  TR --> IN[Intake]
  TR --> SC[Scheduling]
  TR --> RC[Recall]
  TR --> BL[Billing]
  IN --> ODT[(OpenDental)]
  SC --> ODT
  RC --> ODT
  BL --> ODT

Step 1 — Triage

```python triage = RealtimeAgent( name="triage", instructions="""Greet warmly. Within 2 exchanges, classify into new-patient, schedule-existing, recall, or billing. Hand off.""", handoffs=[intake, scheduling, recall, billing], ) ```

Step 2 — Scheduling specialist

```python @function_tool async def find_dentist_slots(provider_id: str, day: str) -> list[dict]: return await odt.appointments.open_slots(provider_id, day)

@function_tool async def book_dental(patient_id: str, provider_id: str, slot_iso: str, reason: str) -> dict: appt = await odt.appointments.create(patient_id=patient_id, provider_id=provider_id, slot=slot_iso, op=reason) ref = f"DT-{slot_iso[:10].replace('-','')}-{appt.id:03d}" await sms.send(appt.patient.phone, f"Confirmed {slot_iso}. Ref {ref}") return {"ref": ref, "appt_id": appt.id} ```

Step 3 — New-patient intake

```python @function_tool async def create_patient(name: str, dob: str, phone: str, email: str, insurance_payer: str | None) -> dict: p = await odt.patients.create(name=name, dob=dob, phone=phone, email=email, insurance=insurance_payer) return {"patient_id": p.id} ```

Step 4 — Recall reactivation (outbound)

```python @function_tool async def list_due_recalls(weeks_ahead: int = 4) -> list[dict]: return await odt.recall.due_within(weeks_ahead)

Outbound run loop

async def run_recall_campaign(): for r in await list_due_recalls(4): twilio.calls.create( to=r.phone, from_=BUSINESS_NUMBER, twiml=f'', ) ```

Step 5 — Billing specialist

```python @function_tool async def lookup_balance(patient_id: str) -> dict: return await odt.billing.balance(patient_id)

@function_tool async def send_payment_link(patient_id: str, amount_cents: int) -> dict: pl = stripe.PaymentLink.create(line_items=[{"price_data": { "currency": "usd", "product_data": {"name": "Dental balance"}, "unit_amount": amount_cents}, "quantity": 1}]) p = await odt.patients.get(patient_id) await sms.send(p.phone, f"Pay your balance: {pl.url}") return {"sent": True} ```

Step 6 — Twilio bridge

Standard Realtime bridge — pass patient_id and intent as URL params; the triage agent uses them to skip classification when known.

Step 7 — Reporting

```sql SELECT date_trunc('day', occurred_at) AS day, agent_name, count() FILTER (WHERE outcome = 'booked') AS booked, count() FILTER (WHERE outcome = 'transferred') AS transferred FROM call_sessions GROUP BY 1, 2 ORDER BY 1 DESC; ```

Common pitfalls

• Insurance verification at intake. Use a clearinghouse tool, not the model's claim.
• Provider preference. Patients sometimes specify a hygienist; always pass provider_id.
• Time-zone bugs. Always store ISO with offset.

How CallSphere does this in production

Explore a live demo and compare current plans to find the right fit for your business.

FAQ

HIPAA? Yes — sign BAAs and add audit logging.

Multi-location? Pass location_id in every tool.

Spanish-speaking patients? Realtime supports Spanish natively.

Insurance? Add an eligibility tool that hits Change Healthcare or Availity.

Recall ROI? Practices report 25–40% reactivation lift over postcards.

Sources

• Arini Y Combinator
• Viva AI
• OpenDental API
• /demo

How this plays out in production

If you are taking the ideas in Build a CallSphere-Style Multi-Agent for a Dental Practice and putting them in front of real customers, the constraint that decides everything is ASR error rates on long-tail entities (drug names, street names, SKUs) and the post-call pipeline that must reconcile what was actually heard. Treat this as a voice-first system from the first prompt: the agent's persona, its tool surface, and its escalation rules all flow from that single decision. Teams that ship fast tend to instrument the loop end-to-end before they tune any single component, because the bottleneck is rarely where intuition puts it.

Voice agent architecture, end to end

A production-grade voice stack at CallSphere stitches Twilio Programmable Voice (PSTN ingress, TwiML, bidirectional Media Streams) to a realtime reasoning layer — typically OpenAI Realtime or ElevenLabs Conversational AI — with sub-second response as a hard SLO. Anything north of one second of perceived silence and callers either repeat themselves or hang up; that single number drives the whole architecture. Server-side VAD with proper barge-in support is non-negotiable, otherwise the agent talks over the caller and the conversation collapses. Streaming TTS with phoneme-aligned interruption keeps the cadence natural even when the user changes their mind mid-sentence. Post-call, every transcript is run through a structured pipeline: sentiment, intent classification, lead score, escalation flag, and a normalized slot extraction (name, callback number, reason, urgency). For healthcare workloads, the BAA-covered storage path, audit logs, encryption-at-rest, and PHI-safe transcript redaction are wired in from day one, not bolted on at compliance review. The end state is a system where every call produces a row of structured data, not just a recording.

FAQ

What changes when you move a voice agent the way Build a CallSphere-Style Multi-Agent for a Dental Practice describes?

Treat the architecture in this post as a starting point and instrument it before you tune it. The metrics that matter most early on are end-to-end latency (target < 1s for voice, < 3s for chat), barge-in correctness, tool-call success rate, and post-conversation lead score distribution. Optimize whatever the data flags as the bottleneck, not whatever feels slowest in your head.

Where does this break down for voice agent deployments at scale?

The two failure modes that bite hardest are silent context loss across multi-turn handoffs and tool calls that succeed in dev but get rate-limited in production. Both are solvable with a proper agent backplane that pins state to a session ID, retries with backoff, and writes every tool invocation to an audit log you can replay.

How does the salon stack (GlamBook) keep bookings clean across stylists and services?

GlamBook runs 4 agents that handle booking, rescheduling, fuzzy service-name matching, and confirmations. Every appointment gets a deterministic reference like GB-YYYYMMDD-### so the salon, the customer, and the agent all reference the same object across SMS, email, and voice.

See it live

Book a 30-minute working session at calendly.com/sagar-callsphere/callsphere-llc-meeting and bring a real call flow — we will walk it through the live salon booking agent (GlamBook) at salon.callsphere.tech and show you exactly where the production wiring sits.