Accelevate

Accelevate answers a business’s phone calls and handles what callers ask for. Appointments are booked, moved and cancelled on the call, in the business’s own diary. Questions are answered from what the business has told it, and anything that needs a person becomes a to-do for staff.

Every call leaves a transcript, a record of what was done and a quality score. One platform serves clinics, salons and admissions offices, each with its own instructions, voice and language.

A call, turn by turn

A call is a handful of specialised services working in a strict order. LiveKit carries the audio, either from a browser or from an ordinary phone number through Twilio. A speech recognition service turns the caller’s words into text, a synthesiser chosen for the business turns the agent’s reply back into a voice, and Claude, running on AWS Bedrock in Sydney, decides what to say and do. Each vendor sits behind its own adapter, so voices and providers change per business without touching the conversation. Conducting all of it is the call gateway, our own service.

The gateway makes the decisions that make it feel like a phone call rather than a walkie-talkie. Deciding when the caller has finished speaking is its job, not the vendor’s: speech recognition reports pauses, and the gateway judges whether the words read as a finished thought or a breath. The model’s reply is streamed into the voice as it is written, so the agent starts speaking before the sentence is composed. When the caller talks over the agent, playback stops and the transcript records only what the caller actually heard.

The recording announcement plays before the agent is allowed to listen, and that order is enforced in code rather than left to the prompt.

Acting through tools, recorded in a ledger

The model acts only by calling tools: find a time, identify the caller, book, add a to-do, end the call. Nothing is inferred from what it says. Each business’s autonomy policy sets what the agent may do on its own, and the gateway checks it on every turn. The booking tool re-checks the diary at the moment of booking rather than trusting that the agent looked earlier.

Every action lands in a ledger tied to the turn that caused it, along with whether it can be undone. The screens staff use show what the system did, from the ledger, never what the agent said it did. The model is treated as untrusted input, not as a security boundary.

Every call is marked

After the call, a second model reads the transcript and scores it against the behaviours the agent is meant to show: asking for the mobile number once, offering choices a listener can hold, never reading a stored detail back to an unverified caller. The same judge marks a corpus of scripted conversations that drives the real turn loop and books through the real diary, so a change to the agent’s instructions is tested before it reaches a caller.

One platform, many businesses

A kind of business is a manifest and a set of tools on a shared core, so new verticals reuse everything else. Each business has its own instructions, voice, pronunciation rules, language and diary integration, configured from the operations app and versioned so any call can be traced to the exact instructions it ran with. Voices are auditioned and chosen from a catalogue spanning several synthesis vendors, and calls can be held in English, Arabic, Hindi, Urdu, French or Spanish. The same platform that books a checkup in Sydney takes admissions interviews in Arabic for a university.

The screenshot below shows the booking tool refusing: the caller is new, so the agent has to collect and confirm a name and email address before it may book. The rule lives in the tool, so the model cannot talk its way around it.

Compliant by construction

Health information is held to a higher standard than a restaurant booking, so each business has a data class derived from what its booking flow actually collects rather than typed in. Retention, encryption, redaction and which vendors may see the data all follow from it, and CI checks those properties when the infrastructure is synthesised rather than relying on discipline.

The system is split on latency. The live call runs on realtime vendors under zero-retention terms and never waits on the main database. Everything after the call, from writing the record to scoring it, runs a second behind on AWS in Sydney, fed by events through queues. Each business gets its own stack, and Postgres row-level security keeps them apart, with the application connecting as a role that cannot bypass it.

The stack

• Calls: LiveKit for realtime audio, Twilio for phone numbers, or straight from a browser
• Speech recognition: Deepgram, with Nova-3 and Flux models
• Voices: Deepgram Aura, Cartesia Sonic and ElevenLabs, behind one synthesiser interface and chosen per business, with voice controls and pronunciation rules
• Models: Claude on AWS Bedrock (Sydney) for the conversation, the call review and the judge, with locally hosted models through Ollama for development
• Backend: TypeScript on Node, Fastify, Postgres (Aurora Serverless) with row-level security, DynamoDB, EventBridge and SQS
• Infrastructure: AWS CDK with cdk-nag, ECS Fargate, Lambda, CloudFront, SES, Auth0
• Front end: React and Vite for the operations app, each business’s own app and the public booking page, with Storybook and Playwright
• Diaries: Acuity Scheduling or Accelevate’s own booking service, behind one booking interface

The codebase is built largely by AI coding agents working under Blint, with every change scoped as a story, reviewed against the project’s patterns and principles, and proven by a gate before it merges.