Booking conflicts belong in the database
Conversational memory cannot guarantee that concurrent callers do not choose the same slot. A unique tenant-and-start-time constraint rejects the second write deterministically.
Loading portfolio
AI and automation / 2026
Voice Operations Agent
Voice bots often demonstrate conversation but omit the difficult operational work: grounded answers, conflict-safe bookings, CRM updates, duplicate provider callbacks, low-confidence escalation, failed human transfer, traceability, and clear authority over external tools.
The voice system accepts provider call state, evaluates grounded FAQ confidence, validates structured tool requests, upserts CRM contacts, books appointments through a protected calendar boundary, and escalates emergency, ambiguous, or weakly supported requests. Duplicate provider events are ignored and failed human transfers fall back to a recorded take-message path instead of silently failing.
- Role
- Designer and engineer (solo)
- For
- Independent or academic work
- Stage
- Maintained
Walkthrough
Watch it run
The voice workflow in deterministic mock mode: a call books a slot, a second request for the same slot is refused, and a failed transfer falls back to taking a message.
My part
What I built
- Designed the call, contact, appointment, provider-event, transcript, tool-history, and outcome models.
- Implemented grounded FAQ retrieval, CRM contact upsert, booking, provider-event deduplication, call completion, and summary state.
- Created the calendar adapter so validated services. Not a model. Own external booking writes.
- Built emergency, unsupported-intent, and low-confidence human escalation with an explicit failed-transfer fallback.
- Integrated the voice workflow into the shared operations console, n8n event handling, CI suite, runbook, and architecture pack.
Decisions
The choices that shaped it
The model never receives calendar authority
The voice provider or model can request a booking, but a validated service adapter owns calendar credentials, idempotency, and the external write.
Escalation is a successful outcome
Emergency language, unsupported intent, and weak evidence produce explicit transfer or take-message states rather than speculative answers or silent workflow failure.
Provider callbacks are untrusted repeats
Every lifecycle callback is registered by provider event ID before processing so retries and duplicated webhook delivery remain safe.
What has been shown to work
- Created two calls that requested the same appointment slot and verified the second request was rejected by the database constraint.
- Repeated one provider callback ID and verified the second delivery was labelled as a duplicate without a repeated action.
- Tested emergency language, successful transfer state, simulated transfer failure, and the bounded take-message fallback.
- Included the voice paths in the same CI run that passed backend tests, Python compilation, frontend build, and workflow JSON validation.
Current stage and limits
- The current portfolio build simulates calls and provides live-provider integration boundaries; it does not claim a deployed production phone line.
- Real telephony, calendar, CRM, recording consent, retention, privacy, and provider acceptance require environment-specific implementation and review.
Screens
From the product
Technical detailOpen the system view
SYSTEM ARCHITECTURE
Voice Operations Agent system view
The voice system accepts provider call state, evaluates grounded FAQ confidence, validates structured tool requests, upserts CRM contacts, books appointments through a protected calendar boundary, and escalates emergency, ambiguous, or weakly supported requests. Duplicate provider events are ignored and failed human transfers fall back to a recorded take-message path instead of silently failing.A Vapi, Retell, Twilio, or equivalent provider creates a platform call and submits validated conversation turns to the FastAPI tool service.
FAQ requests are answered only when retrieval confidence meets the configured threshold; weak or unsupported evidence escalates.
CRM and appointment writes are application-owned tools that validate tenant, contact, time, and current database state.
Appointment slots are protected by a database uniqueness constraint before an external calendar event is treated as confirmed.
Provider lifecycle callbacks pass through duplicate-event registration so repeated delivery cannot repeat downstream actions.
- 01Input / actorconnects toInterface
- 02Interfaceconnects toCore service
- 03Core serviceconnects toOperational boundary
- 04Operational boundaryconnects toState / outcome
Security and privacy
- The public project contains no recordings, real callers, customer data, telephony credentials, calendar credentials, or private transcripts.
- Emergency escalation is an engineering control, not a medical or emergency-service certification.
- The project explicitly avoids HIPAA, GDPR, SOC 2, or other unsupported compliance claims.
Built with
Links
More work
Gazelle's KitchenA WhatsApp business gatekeeper that qualifies genuine orders, enforces business and safety rules, contains off-topic or abusive conversations, and only surfaces the small set of cases that genuinely need the owner.PilotSellavie AIAn independent project: multi-tenant conversational-commerce software that connects social messaging with business knowledge, guarded AI, human handoff, orders, billing, analytics and operations.MaintainedAI Automation Control PlaneA runnable multi-tenant control plane for AI-assisted business workflows, combining FastAPI, Next.js, PostgreSQL, Redis, n8n, provider routing, human approval, idempotency, replay, cancellation, audit traces, and deterministic local demonstrations.Maintained