DEV Community: Autor Technologies Inc.

We Tested 4 Text-to-Speech Engines on 12,000 Live Healthcare Calls — Here's Which One Patients Actually Trust

Autor Technologies Inc. — Tue, 18 Aug 2026 03:14:32 +0000

Last quarter, we ran our production voice AI receptionist — Loquent — across four different TTS engines simultaneously, split-testing real patient calls at dental and healthcare clinics. The results surprised us: the most "natural sounding" engine in demos performed the worst with actual patients.

Why We Ran This Test

At Autor, we've been running Loquent in production for over a year now. It handles thousands of automated calls per month for healthcare and dental clinics across Canada — booking appointments, answering insurance questions, handling after-hours triage. The voice is the product. If patients don't trust the voice, they hang up, and the clinic loses a booking.

When we first built Loquent, we picked our TTS engine the way most teams do: we generated a few sample clips, played them for ourselves, and went with the one that sounded best in a quiet office. That worked fine until we started digging into our call analytics and noticed something weird. Our completion rate — the percentage of calls where patients actually finished the full interaction instead of hanging up or asking for a human — was hovering around 74%. Good, but not great. We suspected the voice itself was part of the problem.

So we designed a proper A/B test. Not a demo comparison. A production comparison on live calls.

The Setup

We tested four TTS engines across 12,247 calls over 8 weeks. Each engine handled roughly equal volume, randomly assigned at call start. All other variables stayed constant: same prompts, same Anthropic Claude backbone for conversation, same Twilio infrastructure, same clinics.

The four engines:

Engine A: ElevenLabs (Turbo v2.5) — our existing production engine
Engine B: OpenAI TTS (tts-1-hd) — the model most teams default to
Engine C: Deepgram Aura — optimized for real-time, low-latency use cases
Engine D: A newer entrant we'd been evaluating (under NDA, so I can't name it)

We measured five things:

Completion rate — did the patient finish the full call flow?
Time-to-first-hang-up — how far into the call patients dropped if they did hang up
Human transfer requests — how often patients explicitly asked for a real person
Repeat-caller behavior — did patients who called back engage or immediately ask for a human?
Post-call survey scores — a subset of clinics ran a 1-question SMS survey: "How was your experience? Reply 1-5"

We did not measure "naturalness" or "voice quality" in isolation. We measured whether patients trusted the voice enough to complete their task.

The Results

Here's what we found, and it's not what the marketing pages of any of these vendors would predict.

Completion rates:

Engine C (Deepgram Aura): 81.2%
Engine A (ElevenLabs): 78.4%
Engine D (unnamed): 76.1%
Engine B (OpenAI TTS): 71.8%

Deepgram won on completion rate by a meaningful margin. But the interesting part is why.

Latency was the dominant factor, not voice quality. When we dug into the data, the correlation between response latency and hang-up rate was stronger than any voice quality metric. Engine C had a median time-to-first-byte of 180ms. Engine A was at 320ms. Engine B sat around 480ms. Engine D was 410ms.

In a voice call, latency feels like hesitation. And when you're a patient calling a clinic, hesitation from an AI voice triggers the uncanny valley harder than a slightly robotic tone ever will. Patients interpreted fast responses as confidence and slow responses as something being wrong.

The "best sounding" engine had the worst outcomes. OpenAI's tts-1-hd produces objectively beautiful speech. In blind audio comparisons, our team ranked it first every time. But in production, it had the lowest completion rate. The higher latency meant longer pauses in conversation, and patients read those pauses as the system struggling to understand them. Several patients in the survey comments said things like "it seemed confused" — when the AI wasn't confused at all, it was just waiting for audio to generate.

Human transfer requests told a different story:

Engine A (ElevenLabs): 14.2%
Engine B (OpenAI TTS): 19.7%
Engine C (Deepgram Aura): 12.8%
Engine D (unnamed): 16.3%

Engine C again. But the gap between A and C was smaller here. Patients who stayed on the call long enough to interact mostly stuck with it regardless of engine. The damage was being done in the first 3-5 seconds.

The first response is everything. We isolated the first-turn drop-off rate — patients who hung up after hearing just the greeting and one response. The spread was dramatic:

Engine C: 4.1% first-turn drop-off
Engine A: 6.8%
Engine D: 8.9%
Engine B: 11.3%

Nearly 1 in 9 patients hung up after the first exchange with Engine B. With Engine C, it was 1 in 24. Same greeting, same words, same AI — different voice engine, different outcome.

Repeat callers validated the pattern. Patients who had previously interacted with Engine C were 2.3x more likely to engage with the AI on their next call versus asking for a human immediately. Engine B repeat callers asked for a human 34% of the time on their second call. First impressions stuck.

What We Changed

We moved Loquent's primary TTS to Deepgram Aura for all production healthcare clients. But we didn't just swap engines and call it done. The test taught us three architectural things:

First, we implemented adaptive engine selection. For complex responses where voice quality matters more — reading back appointment details, explaining insurance coverage — we route to ElevenLabs. For fast conversational turns — confirmations, short answers, greetings — we use Deepgram. This hybrid approach got us to 83.6% completion rate, higher than any single engine alone.

Second, we added latency budgeting to our voice pipeline. Every component now has a time budget: LLM inference gets 800ms, TTS gets 250ms, network overhead gets 150ms. If any component is trending over budget, we fall back to a faster path. We pre-generate common responses (greetings, "one moment please" fillers, confirmations) so the first turn is always instant.

Third, we started measuring voice trust, not voice quality. We retired our internal "does this sound good?" reviews and replaced them with production metrics: completion rate, first-turn drop-off, and repeat-caller engagement. The voice that sounds best in a meeting room is not the voice that performs best on a phone call from a noisy waiting room.

Key Findings

Latency beats quality in production voice AI. A 300ms difference in time-to-first-byte correlated with a 10-percentage-point swing in call completion. Patients interpret speed as competence and delays as confusion.
The first 3 seconds determine the entire call. First-turn drop-off varied by nearly 3x across engines. If you're optimizing your voice AI, start with the greeting response time, not the voice timbre.
Demo performance inversely correlated with production performance. The engine our team unanimously preferred in blind tests had the worst patient outcomes. Always test in production, not in a conference room.
Hybrid TTS routing outperforms any single engine. Using fast engines for conversational turns and higher-quality engines for complex information delivery gave us better results than committing to one engine for everything.
Trust is measurable, and it compounds. Repeat-caller behavior is the most honest signal. Patients who had a good first experience came back willing to engage. Patients who didn't came back demanding a human. Your TTS choice has a retention effect.

What This Means for Builders

If you're building voice AI for healthcare or any high-trust domain, stop optimizing for how the voice sounds in your headphones. Optimize for how fast it responds when a nervous patient calls at 7am about a toothache. That's the test that matters.

We're considering publishing our full latency benchmarking methodology as an open-source tool (we teased this in a previous post). If there's interest, we'll prioritize it.

If you're building something similar, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.

What Autor Will Build in the Next 12 Months — And Why We're Telling You Before We Build It

Autor Technologies Inc. — Wed, 22 Jul 2026 18:08:49 +0000

We've shipped 50+ AI products for clients over the past four years. Starting now, we're going to build three of our own — and we're publishing our roadmap because we think the AI development studio model is about to change in ways most studios aren't prepared for.

Why We're Doing This Publicly

Most agencies guard their roadmaps. We get it — you don't want competitors copying your moves. But after four years of building custom AI for everyone from healthcare networks to fintech startups, we've realized something: the studios that will survive the next two years aren't the ones with secret plans. They're the ones with public conviction.

Here's the honest context. Autor is an eight-person AI development studio in Toronto. We charge $150/hr, we only hire senior engineers, and we've never taken outside funding. Our biggest product, Loquent, handles thousands of automated voice calls per month for healthcare and dental clinics across Canada. We built it in eight weeks.

That last part matters. Eight weeks from first commit to production calls. Not because we cut corners — because our team has done this enough times that we know exactly where the time sinks are, and we've built internal tooling to skip them. That internal tooling is what this roadmap is really about.

The Three Things We're Building

1. Loquent Multi-Vertical (Q3 2026 – Q1 2027)

Loquent today handles inbound calls for dental clinics and healthcare offices. It books appointments, answers insurance questions, handles cancellations, and transfers to a human when it hits something it can't resolve. About 82% of calls are fully automated end-to-end.

Here's what we've learned from analyzing tens of thousands of those calls: the hard problems in voice AI aren't industry-specific. The hard problems are latency management, interrupt handling, context switching mid-sentence, and knowing when to shut up and transfer. We solved those problems for healthcare. The actual healthcare knowledge — the appointment types, the insurance logic, the PHIPA compliance — that's configuration, not architecture.

So starting in Q3, we're expanding Loquent to property management, legal intake, and auto service. Three verticals, chosen for specific reasons:

Property management because tenant call patterns are remarkably similar to patient call patterns — high volume, mostly routine, time-sensitive, and currently handled by overworked humans or terrible IVR trees.

Legal intake because law firms already understand hourly billing and the ROI calculation is dead simple: if your intake coordinator costs $55k/year and handles 40 calls a day, and Loquent handles 33 of those, the math does itself.

Auto service because one of our existing clients asked us to, and they're willing to be the beta. Never underestimate "a client asked for it" as a product strategy.

We're not building three separate products. Loquent stays one platform with vertical-specific configuration layers. The voice pipeline, the Twilio integration, the Claude-powered reasoning engine, the fallback logic — all shared. What changes per vertical is the knowledge base, the integration targets (Jane App for healthcare, Clio for legal, Shop-Ware for auto), and the compliance requirements.

Target: three verticals live by February 2027. We'll publish the results — conversion rates, automation percentages, latency numbers — as we go.

2. Autor Deploy Kit — Our Internal Stack, Open Sourced (Q4 2026)

Every AI product we build at Autor starts the same way. We spin up a Next.js frontend, a NestJS API layer, a PostgreSQL database with Prisma, wire up authentication, set up deployment on AWS or Vercel, configure monitoring, and integrate whatever LLM provider the project needs. That process used to take two weeks. We've gotten it down to about four hours.

The tooling that makes that possible — our starter templates, our LLM abstraction layer, our prompt management system, our evaluation harness — has been internal-only for three years. We're open-sourcing it in Q4 2026.

Why now? Two reasons.

First, the AI development market is getting flooded with studios that can't actually ship production systems. They can build demos. They can build prototypes. But they don't know how to handle rate limiting at scale, or how to structure prompts so they don't drift over time, or how to set up evaluation pipelines that catch regressions before users do. Publishing our tooling is a forcing function — it makes us document our opinions about how production AI should work, and it lets potential clients evaluate our thinking before they hire us.

Second, we've watched enough open-source AI tooling projects to know what's missing. LangChain is a framework for building chains. LlamaIndex is a framework for building RAG. But nobody's published a good opinionated starter for "I need to ship an AI-powered SaaS product that handles real users, real errors, and real scale." That's what Autor Deploy Kit is.

It'll include our LLM provider abstraction (swap between OpenAI, Anthropic, and local models with a config change), our prompt versioning system (every prompt is a tracked artifact with evaluation history), our evaluation framework (automatic regression testing against golden datasets), and our deployment templates for AWS and Vercel.

We're not pretending this will be the next big open-source project. But if even 50 teams use it to ship production AI products faster, that's a win for the ecosystem — and frankly, it's good marketing. Every team that uses our deployment kit and likes it is a team that might hire us when they need custom work.

3. Agentic Workflow Platform — Internal First, Then Product (Q1 – Q3 2027)

This is the ambitious one. Over the past year, we've built custom AI agent systems for nine different clients. Document processing pipelines for insurance companies. Research assistants for consulting firms. Automated QA systems for SaaS products. Every one of those projects involved building the same orchestration layer from scratch — the part that manages multiple AI agents working together, handles failures gracefully, maintains state across long-running workflows, and provides observability into what the agents are actually doing.

We're building a general-purpose version of that orchestration layer. Not a framework — a platform. The difference: a framework gives you primitives and says "figure it out." A platform gives you a running system with a UI, logging, deployment, and monitoring built in.

We're building it internal-first. Meaning we'll use it on our own client projects for at least two quarters before we offer it as a standalone product. Every client project in 2027 will run on this platform, which means it'll get battle-tested across different industries, different scale requirements, and different failure modes before anyone else touches it.

The technical bet we're making: the next wave of AI products won't be single-model applications. They'll be systems of specialized agents coordinated by an orchestration layer. The orchestration problem — routing, state management, error recovery, human-in-the-loop handoffs — is where the real engineering challenge is. And it's where most teams are currently duct-taping things together with ad-hoc code.

We don't have a launch date for the external product yet. We'll share progress quarterly.

Why We're Telling You This

Four reasons, and I'll be direct about all of them.

1. Accountability. Publishing a roadmap means we can't quietly pivot when things get hard. If Loquent multi-vertical doesn't ship by February 2027, you'll know. That pressure is useful.

2. Recruiting. We're hiring two senior engineers this year. The kind of engineers we want — the ones who've shipped production AI and are tired of working at companies that demo well but can't operate — those people want to know what they'd be building. Now they know.

3. Client signaling. If you're evaluating AI development studios in Toronto right now, you should know which ones are investing in their own IP versus which ones are just billing hours. We're doing both, and we think that makes us better at client work, not worse. Every product we build internally sharpens the tools we use on client projects.

4. Industry transparency. The AI development studio market is opaque. Clients can't tell who's good until they've already spent $50k finding out. Publishing our roadmap, our technical opinions, and eventually our tooling is our way of making that evaluation easier.

Key Takeaways

Loquent is expanding from healthcare-only to property management, legal intake, and auto service — same voice AI engine, different configuration layers. Three verticals live by February 2027.
Autor Deploy Kit ships in Q4 2026 as open source — our opinionated production AI starter that cuts new project setup from two weeks to four hours.
We're building an agentic workflow platform starting Q1 2027, internal-first for at least two quarters before external launch. The bet: multi-agent orchestration is the next critical infrastructure layer.
We're publishing this roadmap because accountability, recruiting, client signaling, and industry transparency all benefit from openness. Secret roadmaps are a liability when trust is your differentiator.
Everything we build gets published results — conversion rates, automation percentages, real latency numbers. No vague claims.

If you're building something similar, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.

We Turned Down a $200k Project Last Month — Here's Why

Autor Technologies Inc. — Mon, 20 Jul 2026 16:06:27 +0000

Last month a Series B fintech company offered us $200k to build their entire customer support automation platform. We said no. It was the hardest business decision I've made this year, and I'm still not 100% sure it was right.

The call that started it

Their VP of Engineering found us through a referral. They'd seen what we built with Loquent — our production voice AI platform handling thousands of automated calls per month for healthcare and dental clients — and wanted something similar for their support operation. The scope was clear: voice AI for inbound support, chatbot for their web app, automated ticket routing, and integration with their existing Zendesk and Salesforce stack.

On paper, this was a dream project. $200k budget. Reasonable 16-week timeline. A technical team on their side that actually understood AI limitations. They weren't asking us to "add AI" to a product that didn't need it — they had a real problem with support costs eating 40% of their gross margin, and they'd done the math on what automation could save them.

I spent three days putting together a technical proposal. We mapped out the architecture: Twilio for voice, Anthropic Claude for conversation handling, Pinecone for their knowledge base retrieval, NestJS for the backend services. I knew exactly how we'd build it because we'd already solved most of these problems with Loquent.

Then I killed the deal.

What changed my mind

It wasn't one thing. It was a pattern I'd been watching for six months across our client engagements.

The first red flag was scope. This wasn't a voice AI project with some chat bolted on. This was three distinct products: a voice agent, a chatbot, and a ticket routing system. Each one of those is a 6-8 week build if you're doing it right. At $150/hr with our team of four senior engineers, $200k buys you roughly 1,333 hours. Split across three products over 16 weeks, that's about 83 hours per person per product. That's tight. Not impossible, but tight enough that quality would suffer.

The second flag was maintenance. We've been running Loquent in production for over a year now. I've written about the 3am calls, the edge cases that break your confidence in AI, the 18% of calls that still need human transfer. What I haven't written about much is the ongoing engineering cost of keeping a production voice AI system reliable. Every month we spend 60-80 hours on Loquent maintenance: prompt tuning, handling new edge cases, updating integrations when Twilio or our LLM providers ship breaking changes, monitoring call quality metrics.

If we built three products for this client, we'd be signing up for 150-200 hours of monthly maintenance work. That's essentially one full-time senior engineer dedicated to a single client. At our size — four senior engineers, no offshore, no handoffs — that's 25% of our entire capacity locked up indefinitely.

The third flag was the one that actually made the decision. This project would pull us away from healthcare.

The positioning problem

When I started Autor in 2021, we were a generalist AI development studio. We'd build anything: recommendation engines, NLP pipelines, computer vision systems, chatbots. We were good at all of it. We shipped 50+ products across 10+ countries. But "good at everything" is a terrible positioning for a six-person studio competing against agencies with 200 engineers and enterprise consultancies with thousands.

The shift happened when we built Loquent. For the first time, we weren't just building AI — we were operating it. We understood the difference between a demo that handles 10 calls and a system that handles 10,000. We learned things about healthcare voice AI that nobody else had learned because nobody else was running it at our scale in Canada with PHIPA compliance baked in from day one.

That knowledge is our moat. Not our code. Not our tech stack. The operational knowledge of what breaks at 2am when a patient calls about a prescription refill and your AI confidently gives the wrong pharmacy number.

Taking the fintech project would have meant three things for our positioning:

First, it would dilute our healthcare expertise. Four months of building fintech support tools means four months not deepening our understanding of healthcare voice AI. In a market moving this fast, four months of distraction is significant.

Second, it would muddy our story. Right now when someone asks "who builds voice AI for healthcare in Canada?" there's a short list, and we're on it. If we start building fintech support platforms, we become "the AI agency that does everything" again. We already learned that lesson once.

Third — and this is the part that surprised me — it would actually hurt our revenue long-term. We ran the numbers. The $200k project would generate roughly $200k over 16 weeks, then maybe $30-40k/year in maintenance revenue. But our healthcare pipeline had two deals in it totaling $280k, both specifically seeking a team with production healthcare voice AI experience. If we took the fintech work, we'd likely lose both of those deals because we wouldn't have the capacity to start them on time.

So the math was: $200k now + $30-40k/year recurring, versus $280k in 8 weeks + the compounding value of deeper healthcare positioning.

The conversation I didn't want to have

Telling the fintech VP was uncomfortable. They'd spent time with us, shared their architecture docs, introduced us to their CTO. I didn't want to waste their time or damage the relationship.

I was honest about it. I told them exactly what I'm telling you: we're a healthcare voice AI company now, and taking their project would make us worse at the thing we're best at. I offered to introduce them to two other studios I trust — one in Toronto, one in Vancouver — who could handle their scope without the positioning conflict.

Their response surprised me. The VP said something like: "That's actually why I wanted to hire you. Most agencies would have said yes to $200k without thinking twice." He asked if we'd consider a smaller advisory engagement — 20 hours to help their internal team with the voice AI architecture, since that was where our expertise was most relevant. We said yes to that.

That advisory engagement turned into a $15k engagement, which isn't $200k, but it's $15k of pure expertise delivery with zero maintenance tail. And the referral relationship is intact — they've already sent one healthcare company our way.

The part I'm still not sure about

I'd be lying if I said this was an easy call. $200k is a lot of money for a studio our size. There are months where payroll feels tight, where a big contract would solve problems I think about at 3am.

And there's a real risk in over-indexing on positioning. If healthcare voice AI hits a regulatory wall, or if a bigger player commoditizes what we do, we'll wish we had diversified. I think about that. I don't have a clean answer for it.

What I do know is that in the 18 months since we started focusing on healthcare, our close rate went from 15% to 40%, our average project value went up 60%, and we stopped competing on price. When a dental clinic in Ontario needs a voice AI system that handles patient calls 24/7 and complies with PHIPA, they don't get five proposals. They get maybe two. We want to be one of those two.

5 things I learned from saying no to $200k

Scope math doesn't lie. Before you say yes to any project, divide the budget by your hourly rate, then by the number of distinct products. If each product gets less than 400 engineering hours, you're going to cut corners. You might not notice on delivery day, but you'll notice in month three of maintenance.
Maintenance is the real cost. Every product you ship is a recurring obligation. At a small studio, three or four maintenance-heavy products will consume your entire capacity for new work. Calculate the maintenance tail before you sign.
"Good at everything" is positioning for nobody. This is especially true for studios under 20 people. You can't outbuild a 200-person agency on breadth. You can absolutely outbuild them on depth in one domain.
Be honest when you say no. Don't make up excuses. Tell the client exactly why you're declining. The best referral sources are people who respect your honesty, even when it costs them time.
Run the 12-month math, not the 12-week math. The $200k looked better than our pipeline on a 16-week horizon. On a 12-month horizon, staying focused was worth roughly 40% more in revenue — and that's before you factor in the positioning value.

If you're building something similar, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.

We Turned Down a $200k Project Last Month - Here's Why

Autor Technologies Inc. — Mon, 13 Jul 2026 16:42:54 +0000

Last month, a Series B fintech company offered us $200k to build their platform. We said no, and it was one of the hardest business decisions I've made at Autor. Here's the full story — the call, the spreadsheet I built at 11pm to justify it, and what it taught us about running a boutique AI development studio.

The pitch sounded perfect

The founder reached out through a warm intro. Smart guy, well-funded, clear vision. His company had raised $14M and needed a platform rebuilt from scratch — a customer-facing fintech tool with AI-powered risk assessment, automated document processing, and a dashboard for their ops team.

Timeline: 6 months. Budget: $200k. Our rate, our stack, our call on architecture.

For a studio our size — senior engineers only, typically running 2-3 concurrent projects — $200k over 6 months is a significant chunk of annual revenue. My co-founder and I spent a week scoping it. We had three calls with their team. We started sketching the architecture.

Then I built the spreadsheet that killed the deal.

The 85/15 problem

When I broke down the actual work, the numbers told a different story. Out of an estimated 2,400 engineering hours:

~360 hours (15%) was genuine AI work — the risk models, document processing pipeline, and the inference layer
~2,040 hours (85%) was standard web development — auth flows, admin panels, CRUD operations, payment integrations, responsive frontend, notification system, user management

We're an AI development studio. We charge $150/hr because our engineers have built production AI systems — voice agents handling thousands of calls, RAG pipelines processing medical documents, real-time inference serving healthcare providers 24/7. That's what clients pay a premium for.

Spending 85% of a 6-month engagement on work that any competent web dev shop could handle at $80-100/hr? That's not what we built Autor to do.

But it gets worse.

The opportunity cost spreadsheet

I opened a new tab in the spreadsheet and modeled what saying yes would actually cost us. Here's what I found:

With our current team size, taking this project meant turning away roughly 3-4 focused AI engagements over the same period. Based on our pipeline at the time, those projects looked like:

A dental group wanting voice AI for 12 clinics (similar to our Loquent platform — we could deliver in 8 weeks, not 6 months)
A healthtech startup needing a clinical document processing pipeline
Two smaller AI agent builds, each in the $40-60k range

Total revenue from those projects: approximately $180-220k. So financially, it was roughly a wash. The $200k project wasn't even a revenue premium — it was just one big number that felt safer than four smaller ones.

But the real cost wasn't financial. It was positioning.

What happened last time

I've been here before. In 2024, we took a large project that was maybe 30% AI and 70% general platform work. The client was great, the money was good, and we told ourselves the AI component justified it.

Six months later, here's what actually happened:

Our dev.to posts dried up because nobody had time to write about AI work — we were debugging CSS grid issues and Stripe webhook edge cases. Our case studies from that period were weak because the AI component shipped in month 5 and we couldn't talk about the other client's business.

Three prospects during that period asked what we'd been working on. "A fintech platform" doesn't land the same as "We built a voice AI system that handles 3,000 automated calls per month for healthcare providers." Two of those prospects went with other studios.

The worst part: when the project ended, our inbound pipeline had cooled. It took us almost two months to rebuild momentum. The total cost of that positioning drift was probably $150k in delayed or lost deals. I can't prove that number exactly, but I can tell you our Q1 2025 was our weakest quarter since founding, and it traced directly back to that decision.

The conversation with the founder

Telling the founder was uncomfortable. He'd invested time with us. The warm intro was a friend I respect. And his reaction was exactly what I expected: "Can't you just staff up for this?"

I explained our model. We don't subcontract. We don't hire junior devs and mark them up. Every engineer at Autor has built production AI systems. That's not a recruiting pitch — it's a structural decision that limits our capacity on purpose.

He pushed back: "So hire another senior engineer."

Here's the thing about hiring senior AI engineers in Toronto in 2026: it takes 3-4 months to find someone good, another month to onboard them into our systems and standards, and the project needed to start in 3 weeks. Even if I found someone tomorrow, they wouldn't be productive on this codebase for 6 weeks. The math doesn't work.

We offered an alternative: we'd build the AI components — the risk models, the document processing pipeline, the inference infrastructure — as a standalone engagement. Eight weeks, $65k. They could hire a separate web dev team for the platform work at a lower rate, and we'd architect the integration points.

He thought about it for a week and went with a full-service agency instead. No hard feelings. It was the right call for his timeline.

What we did with those 6 months instead

Since turning down that project in June, here's what shipped:

We onboarded two new Loquent clients — a multi-location dental group in Ontario and a physiotherapy chain in BC. Combined, they're running about 1,800 automated calls per month through our platform. The dental group went live in 6 weeks.

We built a clinical intake AI agent for a healthtech company that processes patient forms in three languages. That project was 10 weeks and every hour was genuine AI engineering — multilingual NLP, structured data extraction from messy PDFs, PHIPA-compliant data handling.

We published four technical articles (including this one) that generated inbound leads. Our dev.to posts collectively pulled 8,000+ views. One of them — the healthcare voice AI analysis piece — got picked up by two AI newsletters.

Total revenue from these projects is tracking ahead of the $200k we turned down. More importantly, every project reinforced our positioning. Every case study we can write from this period is an AI story, not a "we also do general web dev" story.

The 5 things I'd tell any boutique AI studio about saying no

Model the real work breakdown before you say yes. If more than 40% of the hours are outside your core expertise, you're not being hired for what makes you valuable. You're being hired because you're available. That's a commodity position, and it will price you like one eventually.
Calculate opportunity cost in positioning, not just revenue. Lost positioning compounds. A quarter spent on off-brand work doesn't just cost you that quarter — it weakens your pipeline for the next two. I've lived this twice now and the pattern is clear.
"Just hire more people" is not a strategy for boutique studios. Our value proposition is that every engineer is senior and has shipped production AI. The moment we dilute that to service a larger project, we become a body shop with a nicer website. Clients who want 15 developers can find them. Clients who want 4 engineers who've each built voice AI systems handling thousands of calls? That's a shorter list.
Offer the scoped alternative. Don't just say no — propose the engagement that fits your strengths. We lost this particular deal, but the "we'll build the AI layer, you hire a web team" pitch has landed with other clients. It respects their needs while protecting your positioning.
Track what you ship instead. After saying no to a big project, I now keep a running doc of what we delivered in that same window. It's the best antidote to the "what if we'd taken it" doubt. Six months later, the evidence is always overwhelming.

The uncomfortable truth

Turning down $200k when you're a small studio with real payroll is genuinely scary. There's no venture fund backstopping us. Every dollar matters. And I won't pretend the decision was easy or that I didn't second-guess it for weeks.

But every time we've said yes to a large project that diluted our focus, we've paid for it in ways that don't show up on the invoice. Weaker case studies, slower content output, cooled inbound pipeline, and that creeping feeling that we're becoming generalists who happen to know some AI — instead of AI specialists who happen to be excellent engineers.

Boutique doesn't mean small. It means focused. And focus requires saying no to good money when it pulls you off course.

If you're building something similar, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.

The 3 Canadian Companies I'd Call If I Needed to Automate My Clinic's Front Desk

Autor Technologies Inc. — Mon, 06 Jul 2026 13:15:36 +0000

Last month, a clinic owner in Mississauga asked me which AI platform she should use to handle her 140 daily phone calls. She'd already demoed three US-based solutions. All three looked great in the sales pitch. None of them could tell her where her patient data would be stored.

This is the fundamental problem with clinic front desk automation in Canada right now. The market is flooded with slick voice AI demos and "all-in-one" platforms, mostly built for the American healthcare system. They'll show you a beautiful dashboard, play you a recording of their AI booking an appointment, and quote you in USD. What they won't tell you is whether they're PHIPA-compliant, where their servers are, or what happens when a patient calls in French.

I run Autor, an AI development studio in Toronto. We built Loquent, a production voice AI platform that handles thousands of automated healthcare calls every month. So yes, I have skin in this game. But I've also spent the last two years evaluating every company in this space — because our clients ask us to, and because we need to know who else is actually shipping.

Here are the three Canadian companies I'd call if I needed to automate my clinic's front desk today. Not the three with the best marketing. The three I'd actually trust with my patients.

1. Loquent by Autor — For Answering the Phone

Full disclosure: this is us. I'm listing us first because I'd be lying if I said I'd call someone else for voice AI, and this article isn't about pretending to be objective.

Loquent handles the phone — the part of front desk automation that most clinics need fixed first. When a patient calls, Loquent answers, understands what they need, books or reschedules appointments, answers common questions, and transfers to a human when the situation requires it.

Here's what actually matters about our setup:

All data stays in Canada. Our infrastructure runs on AWS ca-central-1 (Montreal). No patient data crosses the border. We built PHIPA compliance in from day one, not as an afterthought — patient consent flows, data retention policies, audit logging, all baked into the platform.

We handle thousands of calls per month across healthcare and dental clients. This isn't a demo. It's production. Our transfer rate to humans sits at about 18%. We've analyzed what those 18% of calls have in common and we've written about it. The short version: edge cases involving insurance disputes, emotional distress, and multi-party scheduling. AI shouldn't handle those. We designed the system so it doesn't try.

The stack is Twilio for telephony, Anthropic Claude and OpenAI for language understanding, Deepgram for speech-to-text, and ElevenLabs for natural-sounding responses. We built the whole thing in 8 weeks and wrote about every decision we made.

Loquent isn't for everyone. If your clinic gets fewer than 30 calls a day, you probably don't need us. If you just need a chatbot on your website, look elsewhere. But if your phone is ringing constantly and your receptionist is drowning, this is what we built.

2. Ocean by CognisantMD — For Patient Intake and Forms

Loquent answers the phone. Ocean handles what happens after the patient walks through the door.

Ocean is a Toronto-based platform that does digital patient intake, online booking, secure messaging, and electronic forms — all integrated directly into Canadian EMRs. If you're running Oscar, PS Suite, Med Access, or TELUS Health, Ocean probably already plugs in.

They solved the EMR integration problem. This is the single hardest part of healthcare automation in Canada, and most voice AI companies (including us) have to work around it. Ocean went straight at it. Their tablet-based check-in and online forms feed directly into the patient's chart. No double-entry. No faxing. No transcription errors.

They've been running in Canadian clinics for years. Ontario Health endorsed Ocean for COVID screening workflows. They have real deployment scale across thousands of Canadian providers. And they're not trying to do everything — Ocean doesn't answer your phone, doesn't do voice AI. What they do is replace the clipboard-and-pen intake process with something that actually works. Because they don't try to do everything, what they do is solid.

If I were automating a clinic, I'd use Loquent for the phone and Ocean for intake. There's almost zero overlap.

3. DentalAssist.ai — For Dental-Specific Voice AI

DentalAssist is based in Burlington, Ontario, and they've built their entire product around dental clinics specifically. Where Loquent is a general healthcare voice AI platform that serves dental as one vertical, DentalAssist went deep on dentistry from the start.

They understand the dental workflow. Dental scheduling is weirdly specific — hygiene vs. operative vs. emergency slots, insurance pre-authorization calls, recall reminders for cleanings every 6 months. DentalAssist built their AI around these dental-specific patterns.

They're Canadian-built and marketing PHIPA compliance, bilingual capabilities, and CAD pricing. In a market where most competitors are US-based, this matters.

Am I recommending a direct competitor? Yes. Because the honest answer is that if you're a dental clinic and you want something purpose-built for your workflow from the ground up, DentalAssist is doing interesting work. If you want a platform that handles dental AND medical AND can scale across multiple clinic types, that's where Loquent fits better.

Competition makes everyone better. We've gotten sharper because companies like DentalAssist showed up.

What About Everyone Else?

The Canadian healthcare AI front desk space has exploded in the last six months. I'm tracking at least half a dozen new entrants — SmileDial, JimmyAI, MedReception, JustReva, Mihron, and more. Some will ship good products. Some won't survive 2026.

Here's my filter for evaluating any of them:

Ask where the servers are. If they can't tell you immediately that patient data stays in Canada, walk away. Ask for a PHIPA compliance attestation — marketing copy that says "PHIPA-compliant" isn't the same as having actual policies, consent flows, and audit trails. Ask how many production calls they handle per month. A demo is not production. A pilot is not production. If they can't give you a number, they're not ready. Ask what happens when the AI can't handle a call — the transfer logic is the most important part of any voice AI system. And ask to talk to a clinic that's been using it for more than 3 months. Anything less and the honeymoon period is doing the heavy lifting.

Why I Didn't Recommend Any US Companies

This is the contrarian part. The American healthcare AI market is 10x the size of Canada's. Companies like Hyro, Parlance, and dozens of well-funded Bay Area startups are building impressive products.

But for a Canadian clinic, they're the wrong choice. PHIPA is not HIPAA. Canadian patient expectations around bilingual service are different. The EMR landscape is different — Oscar and PS Suite don't exist in the US. Even the scheduling conventions are different: Ontario billing codes, provincial insurance, the way Canadian dental offices handle benefits verification.

Building for Canadian healthcare is a specialization, not a localization. You can't take a US product, host it on a Canadian server, and call it PHIPA-compliant. The companies I listed above were built for Canadian clinics from scratch. That matters.

Key Takeaways

Don't buy an "all-in-one" platform. Phone answering, patient intake, and scheduling are three different problems. Use the best tool for each.
Canadian data residency is non-negotiable. If your vendor can't confirm your patient data stays in Canada, keep looking.
Production track record beats demo quality every time. Ask for real numbers — call volumes, transfer rates, uptime.
The market is early and moving fast. The companies I listed today might not be the same ones I'd list in 12 months. Re-evaluate regularly.
Direct competitors can coexist. I just recommended a competitor, and our business won't suffer for it. The market is big enough, and different clinics need different things.

If you're building something similar, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.

How to Evaluate an AI Development Studio in 2026 (The 8 Questions We'd Ask)

Autor Technologies Inc. — Mon, 29 Jun 2026 13:13:53 +0000

We've built over 50 AI products in four years. We've also watched companies waste six figures hiring the wrong development partner — teams that demo well, talk a great game about "leveraging AI," and then deliver a chatbot wrapper around GPT-3.5 with a React frontend. We've been brought in to rescue three of those projects in the last year alone.

So we sat down and asked ourselves: if we were a company looking to hire an AI development studio in 2026 — even if it wasn't us — what would we actually ask? Not the softball stuff on their website. The questions that separate studios that ship production AI from those that ship demos.

Why This Matters More Now Than a Year Ago

The AI development landscape in Canada and globally has exploded. A quick search turns up hundreds of studios claiming to build "custom AI solutions." Most of them stood up a website in 2023, built a few proof-of-concepts, and started charging enterprise rates. The barrier to calling yourself an AI development studio is essentially zero.

Meanwhile, the technical bar for production AI has gotten significantly higher. Customers expect sub-second response times. Healthcare and dental clients expect PHIPA and PIPEDA compliance out of the box. Everyone expects their AI to actually work at 2am on a Sunday, not just during a polished demo.

This gap — between how easy it is to claim expertise and how hard it is to deliver — is the reason you need better questions.

The 8 Questions

1. "What's running in production right now, and can I see the metrics?"

This is the single most important question. Not "what have you built" — what's running right now, handling real users, real data, real edge cases?

When we answer this, we show Loquent: thousands of automated calls per month, 89% automation rate, 4.3/5 patient satisfaction, sub-second first-response latency. These aren't pitch deck numbers. They're from our live Grafana dashboards.

A studio that can only point to completed projects but nothing currently in production is telling you they build things and hand them off. That's fine for a marketing website. It's not fine for AI that needs to handle real-world chaos at 3am.

Red flag: "We built an AI solution for [big company name] but can't share details due to NDA." Everyone has NDAs. Studios that actually ship production AI can at least describe the architecture, the scale, and the outcomes without naming the client.

2. "Walk me through a production incident you had and how you handled it."

We wrote an entire article about a 3am production failure during our healthcare AI launch. The short version: a Deepgram model update silently changed our transcription accuracy, we didn't have model version pinning, and patients in Montreal started getting transferred to humans at double our normal rate.

Any studio with real production experience has war stories. If they don't, they either haven't run anything in production long enough to hit problems, or they're not being honest about what happened. Both are bad signs.

What you want to hear: specific technical details about what broke, how they detected it, how long it took to fix, and what they changed to prevent it from happening again. Not "we had a minor issue and resolved it quickly."

3. "What's your team structure, and who exactly will work on my project?"

At Autor, we're senior engineers only. No offshore. No handoffs. The person you talk to in the sales call is the person writing your code. That's a deliberate choice — we charge $150/hr and keep the team small enough that quality never becomes someone else's problem.

Many studios operate differently: a senior architect scopes the work, mid-level developers build it, and offshore contractors handle the grunt work. Sometimes that model works. But for AI specifically, the gap between "it works in the demo" and "it works in production" is almost always a senior engineering problem. Junior developers can wire up an OpenAI API call. Handling the edge cases, building the monitoring, tuning the prompts — that takes experience.

Red flag: vague answers about team size, phrases like "we scale the team based on project needs," or an inability to name the specific engineers who'll work on your project.

4. "How do you handle data privacy and compliance?"

If you're in healthcare, dental, legal, or financial services in Canada, this question eliminates about 70% of studios immediately.

We built Loquent from day one with PHIPA and PIPEDA compliance as architectural constraints, not afterthoughts. Patient call data is encrypted at rest and in transit, stored on Canadian servers, access-logged with retention policies, and we can produce a complete audit trail for any patient interaction. We went through this with our healthcare clients' legal teams before writing a line of code.

A studio that says "we can add compliance later" or "we use [US cloud provider] but it's probably fine" doesn't understand how healthcare data works in Canada. Compliance isn't a feature you bolt on. It's a design constraint that affects your database schema, your deployment architecture, your logging strategy, and your vendor selection.

What you want to hear: specific compliance frameworks they've implemented, where data is stored, how access is controlled, and whether they've survived a client's legal or compliance review.

5. "What happens after you deliver? Who's on call?"

We've inherited projects from three different studios in the past year. In every case, the original studio delivered a working product, the client signed off, and then things started breaking. The original team had moved on to the next project. Support was an email address that got checked "within 48 hours."

Production AI isn't a build-and-forget deliverable. Models drift. Vendors push updates. User behavior changes. Call volumes spike. You need someone who monitors the system, responds to incidents, and proactively identifies degradation before users notice.

Ask for their SLA terms. Ask what monitoring they run. Ask what happens at 3am on a Saturday when something breaks. At Autor, we run our own AI products in production — Loquent is ours, not a client handoff. So we're already monitoring and maintaining production AI systems around the clock because our own reputation depends on it.

Red flag: "We offer a maintenance package" with no details on response times, monitoring, or what's actually included.

6. "Can you show me your testing process for AI-specific failures?"

Traditional software testing — unit tests, integration tests, end-to-end tests — is necessary but not sufficient for AI systems. AI has failure modes that conventional tests don't catch: prompt regressions, model drift, transcription accuracy changes, hallucination under edge-case inputs.

We built a test harness that replays 200 real call transcripts against every prompt change and flags regressions in intent detection, entity extraction, and task completion rate. We pin vendor model versions and test new versions against a saved corpus before promoting to production. We learned to do this the hard way, after a surprise model update dropped our Montreal automation rate by 9 points overnight.

A studio that tests AI products the same way they test a CRUD app will ship you a product that works great on demo day and degrades unpredictably in production.

What you want to hear: specific testing strategies for prompt regression, model version management, and real-world conversation replay testing. Not just "we have CI/CD."

7. "What AI infrastructure decisions would you make differently if you started over?"

This is a trap question, in the best way. A studio with real production experience has a long list of things they'd do differently. We certainly do: we'd build a graph-based conversation state machine instead of a linear flow, invest in observability from day one instead of bolting on Grafana at month three, and build our regression test corpus from the first call instead of waiting until month four.

A studio that says "we'd do everything the same" either hasn't run anything long enough to learn, or isn't self-aware enough to be trusted with your project. The best engineers are the ones who can articulate their own past mistakes clearly.

Red flag: confident assertions that their architecture and process are already optimal. Nobody's are.

8. "What would you tell us NOT to build?"

The most valuable thing an AI development partner can do is talk you out of building the wrong thing. We turned down a $200k project last month because the client's requirements would have produced a product their users didn't actually need. That's $200k we could have taken, but shipping something doomed to fail is worse for everyone.

Ask the studio what kinds of projects they've declined. Ask them to look at your requirements and tell you what's unnecessary, what's premature, and what would be a waste of money. A studio that says yes to everything is optimizing for their revenue, not your outcome.

What you want to hear: honest pushback on your own assumptions, specific examples of projects they've declined or descoped, and a willingness to tell you things you don't want to hear.

How to Weight These Answers

Not all eight questions carry equal weight. Here's how I'd prioritize:

Production systems with live metrics (Question 1) — this is pass/fail. No current production system, no consideration.
Compliance and data privacy (Question 4) — if you're in a regulated industry in Canada, this is also pass/fail.
Post-delivery support and monitoring (Question 5) — this is where most projects actually fail, six months after "delivery."
War stories and honest retrospectives (Questions 2 and 7) — these reveal real experience vs. marketing polish.
Everything else (Questions 3, 6, 8) — important differentiators once you've passed the first four filters.

If a studio passes the first two questions clearly, you're probably in good hands. The remaining six help you choose between the studios that make it through that filter.

The Uncomfortable Truth

Most companies hiring an AI development studio in 2026 will make their decision based on the proposal deck, the quoted price, and whether the sales call "felt good." They'll end up with a product that works in the demo and breaks in production, built by a team they never met, running on infrastructure nobody monitors.

The eight questions above aren't complicated. They just require the studio to be honest about what they've actually built, what went wrong, and what happens after they get paid. The studios that can answer them confidently are the ones worth hiring. The ones that can't will tell you they can't in how they dodge the questions.

We've been on both sides of this — as the studio being evaluated and as the team brought in to fix what another studio delivered. The difference between a good outcome and a bad one almost always comes down to whether someone asked the hard questions before signing the contract.

If you're evaluating studios right now — including us — we'd love to hear what questions you're asking. Reach out at hello@autor.ca or visit autor.ca.

6 Months of Running a Production Voice AI — What Changed, What Broke, What We'd Rebuild

Autor Technologies Inc. — Mon, 22 Jun 2026 13:14:00 +0000

Six months ago we pushed Loquent — our voice AI receptionist for healthcare and dental clinics — into production. It now handles thousands of automated calls per month across multiple clinics, 24/7, in both English and French. Here's everything that actually happened once real patients started talking to it.

This isn't a launch post. We wrote that already. This is the unglamorous sequel: the parts where our assumptions were wrong, where vendors changed things under us, and where we looked at our own architecture and thought "why did we do it that way?"

The System at Month Zero

Quick context on the stack we shipped. Loquent runs on Twilio for telephony, Deepgram for speech-to-text, Anthropic Claude for conversation logic, and ElevenLabs for text-to-speech. The backend is NestJS with PostgreSQL and Prisma, deployed on AWS with Docker. We built the whole thing in 8 weeks.

At launch we had a single healthcare client running about 400 calls per week. The system handled appointment booking, cancellations, insurance verification routing, and basic triage — determining whether a patient needed to speak with a human or could be handled automatically.

Our target was 85% full automation rate. We hit 82% in week one, which felt close enough to ship.

What Changed

The prompt architecture got rewritten twice. Our initial approach was a single massive system prompt — roughly 4,000 tokens — that covered every scenario. It worked for one clinic with one specialty. By month two we had three clinics with different booking rules, insurance requirements, and operating hours. The monolithic prompt became unmaintainable.

We moved to a modular prompt system where each clinic gets a base conversation scaffold, and clinic-specific rules (hours, procedures, insurance logic) are injected as structured data rather than prose. The prompts dropped to about 1,200 tokens of core logic plus 300-800 tokens of clinic config. Latency improved by roughly 200ms on first response because Claude was processing less context.

The second rewrite happened at month four when we added French language support for Quebec clinics. Instead of duplicating prompts, we built a language-agnostic intent layer and pushed all patient-facing text into a template system. This made adding new languages a config change instead of a prompt engineering project.

Deepgram's model updates changed our accuracy numbers overnight. Twice in six months, Deepgram pushed model updates that shifted our transcription accuracy. The first time it improved — dental terminology recognition jumped from about 71% to 83%. The second time, three weeks later, a different update introduced regressions on Quebec French accents. Our automation rate in Montreal dropped 9 points in a single day.

We now pin specific Deepgram model versions in production and test new versions against a saved corpus of 500 real call recordings before promoting. This added a week to our vendor update cycle but eliminated surprise regressions.

Call volumes tripled, but not where we expected. We planned for steady growth across all clinics. Instead, one dental group ran a local ad campaign that tripled their call volume in a week without telling us. Our Twilio concurrent call limit was 15. They hit 23 simultaneous calls on a Tuesday morning.

The overflow calls got busy signals. We didn't even know it was happening until the clinic called us directly. Now we have alerting on concurrent call counts, queue depth, and Twilio capacity headroom. We also built an auto-scaling config that bumps concurrent limits when utilization crosses 70%.

What Broke

The "I'll hold" problem. We didn't anticipate how many patients would say "I'll hold" or "I'll wait" when told a human wasn't available. Our conversation logic treated silence as a disconnect signal after 8 seconds. Patients waiting for a human would go quiet, get disconnected, call back, get the AI again, and get increasingly frustrated.

We found this pattern in 6% of all calls — roughly 40 calls per week across our clinics. The fix was a dedicated hold state with periodic check-ins ("I'm still here, a team member will be with you shortly") and extended silence tolerance of 45 seconds. Transfer-to-human success rate went from 74% to 91%.

ElevenLabs latency spikes during peak hours. Between 9am and 11am Eastern — prime appointment-booking time — ElevenLabs response times would occasionally spike from our baseline 180ms to 600-900ms. Patients experienced this as the AI "pausing" mid-conversation, which eroded trust.

We built a TTS response cache for common phrases (greetings, confirmations, hold messages) that eliminated latency for about 35% of all spoken responses. For the remaining dynamic responses, we added a streaming playback pipeline that starts speaking before the full audio is generated. Combined, these brought worst-case perceived latency down to about 300ms.

The insurance verification rabbit hole. Our original insurance check was simple: ask the patient for their insurance provider and policy number, confirm it's in the clinic's accepted list. Then clinics started asking us to do real-time eligibility checks. We built an integration with a clearinghouse API, and it worked — until it didn't.

The clearinghouse had a 4-second average response time. Four seconds of silence on a phone call feels like an eternity. We tried filling the gap with "Let me check that for you" and hold music snippets, but the UX was terrible. We ended up moving insurance verification to an async flow: the AI collects the information, confirms it'll be verified before the appointment, and the actual check happens after the call. Patient satisfaction scores went up. Clinic staff workload went down.

What We'd Rebuild

The conversation state machine. We built state management as a simple linear flow: greeting → intent detection → information collection → action → confirmation → goodbye. Real conversations aren't linear. Patients interrupt, backtrack, ask unrelated questions mid-booking, and change their minds.

We patched this with increasingly complex branching logic, and it works, but it's brittle. If we rebuilt from scratch, we'd use a graph-based conversation model where each node is an intent with defined entry/exit conditions and any node can transition to any other node based on what the patient says. We're about 60% through this rebuild now.

The monitoring stack. We started with basic CloudWatch logging and a Slack alert channel. That was fine for 400 calls a week. At our current volume, we need real-time dashboards showing automation rate by clinic, average call duration, transfer reasons, transcription confidence scores, and TTS latency — all broken down by time of day and language.

We bolted on a custom analytics pipeline at month three, but it's a collection of Lambda functions and a Grafana dashboard that took more effort to maintain than to build. We'd invest in a proper observability layer from day one if we did it again. Probably Datadog with custom metrics, though the cost at our call volume would need careful management.

The testing infrastructure. We ship prompt changes the way most teams ship code — PR, review, merge, deploy. But we didn't have automated regression testing for conversation quality until month four. Before that, someone on the team would manually call the system and run through scenarios.

We now have a test harness that replays 200 real call transcripts against any prompt change and flags regressions in intent detection, entity extraction, and task completion rate. Building this earlier would have prevented at least three production incidents that each affected several hundred calls.

The Numbers at Month Six

Here's where we stand today compared to launch:

Automation rate: 82% → 89% (target was 85%)
Average call duration: 3m 42s → 2m 51s
Patient satisfaction (post-call survey): 3.8/5 → 4.3/5
Transfer-to-human rate: 18% → 11%
First-response latency (p95): 1.4s → 0.8s
Monthly call volume: ~1,600 → ~5,200

The single biggest driver of improvement wasn't any technical change. It was the modular prompt system that let us tune each clinic's AI behavior without risk of breaking other clinics. Configuration over code.

Five Things I'd Tell Someone Building This Today

Pin your vendor model versions. Every speech-to-text and LLM provider ships updates that can change your product's behavior without warning. Control when you adopt changes.
Build your test corpus from real calls immediately. From day one, save anonymized call recordings. You'll need them for regression testing within weeks, not months.
Design for the unhappy path first. The 11% of calls that need a human are more important than the 89% that don't. A bad transfer experience destroys all the goodwill the AI built.
Async everything that takes more than 2 seconds. Silence on a phone call is death. If a backend operation takes time, collect the info and process it after the call.
Invest in per-client configuration early. Your second client will have different rules than your first. Build the config system before you need it, because you'll need it sooner than you think.

If you're building something similar, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca

Why Canada Is the Best Place to Build Healthcare AI Right Now

Autor Technologies Inc. — Mon, 15 Jun 2026 13:13:18 +0000

Every week I talk to a founder who's building healthcare AI in San Francisco and spending 40% of their engineering time on HIPAA compliance across fifty different state-level interpretations. Meanwhile, we shipped Loquent — a production voice AI handling thousands of automated calls per month for healthcare and dental clinics — from Toronto, in eight weeks. The regulatory environment wasn't something we fought against. It was one of the reasons we moved fast.

Most of the AI discourse assumes you need to be in the Bay Area to build anything real. For healthcare AI specifically, I think that's wrong. Canada has a set of structural advantages right now that most people aren't paying attention to, and by the time they do, the window will be smaller.

The Regulatory Stack Is Actually an Advantage

Here's what most people get wrong about Canadian privacy law: they assume PIPEDA is just "HIPAA but Canadian." It's not. It's actually more coherent.

In the US, you have HIPAA at the federal level, but then you're dealing with a patchwork of state-level regulations. California has CCPA/CPRA. New York has SHIELD. Texas has its own thing. If you're building AI that processes health data, you're essentially maintaining compliance against a dozen different interpretations of what "adequate protection" means.

In Canada, PIPEDA gives you a federal baseline built on 10 Fair Information Principles — purpose limitation, consent, accountability, the fundamentals. Then you layer on provincial health-specific legislation like Ontario's PHIPA (Personal Health Information Protection Act), which was actually designed with digital health workflows in mind. PHIPA explicitly addresses how health information custodians and their agents handle PHI across clinical and administrative workflows, including AI systems.

The Ontario Information and Privacy Commissioner released guidance specifically about AI transcription tools in healthcare — requiring privacy impact assessments, data minimization throughout the AI lifecycle, and limiting PHI disclosure to vendors. These aren't vague handwaves. They're specific, implementable requirements.

When we built Loquent, this clarity was a competitive advantage. Instead of hiring a team of lawyers to interpret ambiguous regulations, we could read the guidance, build to spec, and ship. PIPEDA's emphasis on meaningful consent — where individuals must be fully informed about how their data will be used — forced us to build better product, not slower product.

And here's the kicker: Bill C-27's 2026 amendments are tightening consent requirements further, with penalties up to C$25 million or 5% of gross global revenue. That sounds scary, but it actually favors builders who are already compliant. It raises the floor for everyone else trying to compete in the Canadian market.

AIDA Is Dead. That's Actually Good for Builders.

Canada's Artificial Intelligence and Data Act (AIDA) died in parliament. A lot of people read that as "Canada has no AI regulation" and panicked. I read it differently.

What it means in practice is that healthcare AI in Canada operates under existing, well-understood privacy frameworks rather than a brand-new, untested AI-specific law. You're building against PIPEDA and PHIPA — legislation that's been interpreted by courts and privacy commissioners for years. Compare that to the EU's AI Act, where nobody actually knows yet how enforcement will work in practice for health applications.

For a small studio like ours, regulatory predictability is worth more than regulatory completeness. We can build with confidence because the rules are clear. The AIDA vacuum will get filled eventually, but right now it means Canadian builders have a window where they can iterate without worrying that new legislation will retroactively invalidate their architecture decisions.

The Talent Pool Is Deeper Than You Think

Toronto has the fourth-largest AI talent pool in North America — 23,936 workers — and hit number three in CBRE's 2026 tech talent ranking. The city has over 285,000 tech workers across roughly 24,000 companies and was named Canada's fastest-growing AI hub in March 2026.

But the real story is Waterloo. Waterloo Region jumped 11 spots to enter the top 10 for the first time, driven by computer and information systems manager growth. The University of Waterloo co-op pipeline is producing engineers who understand both ML fundamentals and production systems. And critically, more of them are staying local instead of immediately migrating to Silicon Valley.

Canada now has three of the top 10 largest AI talent pools in North America: Toronto, Vancouver, and Montreal. The talent density isn't Bay Area level, but the cost difference is dramatic. We hire senior engineers in Toronto at rates that would get us mid-levels in SF. For a bootstrapped studio building production AI, that math matters.

41 Million Patients, One System

This is the structural advantage nobody talks about. Canada's universal single-payer healthcare system generates clinical data at a scale most countries can't match. 41 million people across diverse demographics, all flowing through a single system architecture.

The federal government is betting on this. In June 2025, Canada Health Infoway gave 10,000 primary care clinicians across Canada AI Scribe licenses through a federally funded program. In September 2025, they announced a task force on AI to recommend policies for research, talent, and commercialization. The VITAL health data initiative is explicitly about turning Canada's structural data advantage into Canadian AI products.

For us at Autor, this means our clients are part of a system that's actively moving toward AI adoption, not resisting it. When a dental clinic in Ontario asks us about Loquent, they're asking in the context of a healthcare system that's already distributing AI tools to physicians. We're pushing on an open door.

The Dental Market Is Wide Open

Speaking of dental: Canada's dental AI market is still nascent. When surveyed, 60% of Canadian dentists said they hadn't implemented AI-assisted technologies in the past five years. The companies in this space — DentalRx, MaxAssist, ClearDent — are primarily focused on practice management and imaging. Almost nobody is building voice AI for dental front desks.

That's exactly where Loquent lives. And Canada's dental market has a specific advantage: it's large enough to build a real business (over 27,000 dentists across the country) but small enough that you can reach meaningful market penetration from a single city. We're not competing against Epic or Cerner here. We're building for clinic owners who are running reception with two people and a phone that won't stop ringing.

Data Sovereignty Is a Selling Point

One advantage I didn't anticipate: Canadian healthcare organizations are increasingly concerned about the US CLOUD Act. US-based platforms are subject to government data access requests, which creates a compliance risk for Canadian organizations handling personal health information. Canadian-operated platforms eliminate that exposure entirely.

This isn't theoretical. We've had multiple conversations with clinic owners who specifically asked whether patient call data stays in Canada. For Loquent, it does. That's not just a compliance checkbox — it's becoming a real differentiator against US-based competitors trying to sell into the Canadian market.

Canada's digital health market generated US$13.49 billion in 2024 and is projected to reach US$53.92 billion by 2030 — a 26% CAGR. Last year, 54% of digital health investment went to AI-enabled companies, up from 37% the year before. The money is following the opportunity.

Key Takeaways

PIPEDA + PHIPA give you clear, implementable compliance requirements. The US patchwork of state privacy laws is actually harder to build against than Canada's layered federal-provincial model. Clarity beats complexity.
The AIDA vacuum is a feature, not a bug. Canadian healthcare AI operates under established privacy law with years of interpretation behind it. That's more predictable than brand-new AI-specific legislation that hasn't been tested.
Toronto-Waterloo talent density is real and growing. Three of North America's top 10 AI talent pools are in Canada, and the cost advantage over US cities is significant for bootstrapped companies.
Single-payer data at scale is a structural moat. 41 million patients in one system, with a federal government actively funding AI adoption. This dataset advantage compounds over time.
The dental/clinic market is wide open. 60% of Canadian dentists haven't adopted AI yet. If you're building healthcare AI tools for frontline clinics, Canada is an ideal starting market.

If you're building something similar, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.

Why Canada Is the Best Place to Build Healthcare AI Right Now

Autor Technologies Inc. — Mon, 08 Jun 2026 13:12:55 +0000

Last month, a US-based healthtech founder asked me where he should incorporate his AI company. He was deciding between Delaware and Ontario. I told him Ontario — and he looked at me like I'd suggested he build a spaceship out of duct tape. Six weeks later, he moved his entire dev team to Toronto. Here's why.

At Autor, we've spent the last two years building Loquent — a production voice AI platform that handles thousands of automated calls per month for healthcare and dental clients across Canada. We've shipped AI into regulated healthcare environments, navigated PIPEDA and PHIPA compliance from day one, and watched the US regulatory landscape turn into a minefield while Canada quietly built something better. I'm not saying Canada is perfect. I'm saying that right now, in June 2026, if you're starting a healthcare AI company, you're making a mistake by defaulting to the US.

The Regulatory Argument Everyone Gets Wrong

The common take is that the US is more "innovation-friendly" because HIPAA is well-understood and the FDA has been approving AI/ML medical devices since 2017. That's true — if you're building a diagnostic imaging tool that fits neatly into the existing SaMD framework. For everything else, especially conversational AI, voice agents, ambient scribes, and patient-facing automation, the US is a regulatory grey zone that's getting greyer.

Canada's AIDA (Artificial Intelligence and Data Act) died in Parliament when it was prorogued in January 2025. Most people read that as "Canada has no AI regulation." I read it differently: Canada has no bad AI regulation. What we do have is PIPEDA — a principles-based privacy framework that actually works for AI development.

Here's the practical difference. HIPAA is entity-specific. It only covers "covered entities" — healthcare providers, insurers, and clearinghouses. Your AI startup processing voice calls for a dental clinic? You might not be a covered entity, but you're still handling PHI, and the legal exposure is enormous and unclear. PIPEDA covers all commercial activity involving personal information. There's no ambiguity about whether you're in scope. You are. And because PIPEDA's 10 Fair Information Principles are consent-based rather than entity-based, you can actually build a compliance architecture that makes sense for an AI product.

Ontario's PHIPA adds a healthcare-specific layer on top. Section 29 requires Canadian data residency. That sounds like a restriction, but it's actually a competitive moat. If your data stays in Canada, you're compliant by default with the data sovereignty requirements that are now hitting US companies as a surprise. The EU's adequacy decisions, cross-border transfer restrictions, and provincial approval requirements all become simpler problems when your infrastructure is already Canadian.

The Talent Math

Toronto is now the third-largest tech talent pool in North America — over 285,000 technology workers in software, systems, and engineering roles. Only the Bay Area and New York Metro are bigger. Toronto's tech talent grew 44% over five years. The Vector Institute, University of Toronto, and the broader Waterloo-Toronto corridor produce more ML engineers per capita than anywhere except maybe London.

But here's the number that actually matters: 30-40% cost savings compared to equivalent US hires. A senior ML engineer in San Francisco costs $250-350K fully loaded. In Toronto, that same engineer — often trained at the same institutions, publishing in the same conferences — costs $160-220K CAD, which is roughly $115-160K USD.

And Canada's Global Talent Stream visa processes international hires in two weeks. Not two months. Two weeks. We've used this at Autor to bring in specialized talent from India and Eastern Europe without the H-1B lottery or the 8-month USCIS processing times that US startups just accept as normal.

The Healthcare AI Market Nobody's Watching

The dental AI market alone is projected to grow from $516M (2025) to $3.9B by 2035 — a 22.5% CAGR. The Canadian Dental Association made AI its central theme at CDA Presents 2026 in April. This isn't fringe adoption. The professional governing bodies are actively pushing clinics to modernize.

We see this firsthand with Loquent. When we started building voice AI for dental clinics, the conventional wisdom was that Canadian healthcare was too conservative, too slow-moving, too resistant to automation. That turned out to be completely wrong. What Canadian clinics are is compliance-conscious. They don't want to be first, but they absolutely want to adopt technology that's already proven AND compliant. Once we showed that Loquent handled PHIPA-compliant call handling with Canadian data residency, the objection wasn't "we don't want AI" — it was "how fast can you deploy."

The competitive landscape is still early. DentalAssist.ai out of Burlington is doing interesting work. A few US-based companies are trying to enter the Canadian market but stumbling on compliance. The window for building a dominant Canadian healthcare AI company is open right now, and it won't stay open forever.

The SR&ED Advantage Nobody Talks About

Canada's Scientific Research and Experimental Development (SR&ED) tax credit covers up to 35% of eligible R&D spend for Canadian-controlled private corporations. If you're building an AI product, most of your engineering work qualifies. We've used SR&ED at Autor every year, and the refund effectively subsidizes our entire research pipeline.

The US has R&D tax credits too, but they're far less generous and the 2022 amortization rules made them worse. For early-stage healthcare AI companies burning cash on model development, prompt engineering, and integration work, the SR&ED refund is often the difference between having 12 months of runway and having 16 months.

Combine SR&ED with lower salaries, Canadian data residency compliance, and the fact that $1 USD buys you roughly $1.38 CAD of engineering output, and the unit economics of building in Canada are hard to argue against.

The Contrarian Bet

I know what the counterarguments are. The US healthcare market is 10x larger. US VCs have deeper pockets. The FDA approval pathway, despite its flaws, is a known quantity.

All true. And all beside the point if you're building voice AI, conversational agents, patient-facing automation, or ambient clinical intelligence — the categories that are actually growing fastest. For these products, the regulatory clarity, talent economics, and compliance infrastructure in Canada aren't just "comparable" to the US. They're better.

The US is heading toward a patchwork of state-level AI regulations. California, Colorado, and Illinois already have divergent frameworks. HIPAA wasn't designed for AI and hasn't been meaningfully updated. The FDA is doing innovative work with agentic AI reviews, but that's for medical devices — not for the voice agent that answers your clinic's phones.

Canada has a single federal privacy framework, provincial health information acts that are consistent in their principles, a regulatory gap that gives startups room to build without premature compliance burden, and a talent pool that keeps getting deeper.

We're not the only ones who've noticed. The healthtech founder I mentioned at the top? He told me his Toronto team shipped their MVP three months faster than his US team had projected, at 40% of the budget. That's not a fluke. That's the structural advantage of building where the fundamentals align.

Key Takeaways

PIPEDA's principles-based approach works better for AI than HIPAA's entity-based model. If you're building any healthcare AI product that isn't a traditional medical device, Canada's regulatory framework gives you clearer guardrails with less ambiguity.
The talent economics are unbeatable. Toronto's 285,000+ tech workers, 30-40% cost savings, and two-week visa processing make it the most capital-efficient place in North America to build an AI team.
Canadian data residency is a moat, not a limitation. As cross-border data transfer requirements tighten globally, being Canadian-first means you're already compliant where others are scrambling.
SR&ED extends your runway by 20-30%. No other G7 country offers R&D tax credits this generous for early-stage AI companies.
The dental and healthcare AI market is moving now. The CDA made AI its 2026 theme. Clinics are buying. The competitive window is open but closing.

If you're building something similar, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.

We're Open Sourcing Our Voice AI Latency Benchmarking Tool

Autor Technologies Inc. — Wed, 03 Jun 2026 21:56:41 +0000

Last month, a 340ms spike in our TTS pipeline caused 12% of Loquent callers to talk over the AI mid-response. We didn't catch it for six hours because we were measuring the wrong thing — average latency instead of tail latency at each pipeline stage. That incident is why we built vox-bench, and why we're releasing it today.

Why we needed this

When you're building a voice AI agent that handles thousands of live phone calls per month — dental appointment bookings, patient intake, after-hours triage — latency isn't a nice-to-have metric. It's the difference between a conversation that feels human and one that feels like talking to a broken IVR.

Our Loquent pipeline has five stages: Twilio media stream ingestion, speech-to-text via Deepgram, LLM inference via Anthropic Claude (with OpenAI as fallback), text-to-speech via ElevenLabs, and audio streaming back through Twilio. Each stage adds time. The total round-trip — from the moment a caller stops speaking to the moment they hear the AI respond — needs to stay under 800ms to feel natural. Go above 1.2 seconds and callers start repeating themselves. Go above 1.8 seconds and they hang up.

We know these numbers because we tracked them across 10,000+ calls over six months of running Loquent in production. But for the first four months, we were tracking them wrong.

What we were doing wrong

Our original monitoring was simple: we logged a timestamp when audio came in from Twilio and another when we sent audio back. Total round-trip time. One number. And for a while, it looked great — averaging around 650ms.

The problem was that average told us almost nothing. When our ElevenLabs latency spiked from 120ms p50 to 340ms p95 during a provider-side deployment, our total average barely moved — from 650ms to 710ms. Still "fine" by our alerting thresholds. But 12% of calls were hitting 1.4+ second response times, and those callers were already talking again before the AI responded. The result was conversational chaos — interrupted responses, repeated questions, callers saying "hello? are you there?"

We needed per-stage, per-percentile latency tracking. Nothing we found did exactly what we needed.

What exists today (and why it wasn't enough)

We evaluated several options before building our own:

Generic APM tools (Datadog, New Relic) — great for HTTP request latency, but they don't understand voice AI pipeline stages. You can instrument custom spans, but you're building the domain model yourself. We tried this with Datadog for two months. The dashboard became a wall of custom metrics that nobody on the team could parse quickly.

Provider-specific dashboards — Deepgram and ElevenLabs both have latency metrics in their dashboards, but they only show their own stage. You can't correlate a Deepgram STT spike with downstream effects on total response time. And they measure from their side — not from your server's perspective, which includes network transit.

Load testing tools (k6, Locust) — designed for HTTP endpoints, not real-time WebSocket audio streams. You can hack them into shape, but simulating realistic voice conversation patterns (variable utterance lengths, interruptions, silence gaps) is a project in itself.

We needed something purpose-built for voice AI pipelines. So we built it.

How vox-bench works

vox-bench is a TypeScript CLI tool that benchmarks each stage of a voice AI pipeline independently and in combination. Here's what it does:

Per-stage benchmarking. Point it at your STT provider, your LLM, and your TTS provider. It sends realistic audio samples (we include a corpus of 200 healthcare-domain utterances of varying lengths) and measures latency at each stage independently. You get p50, p95, p99, and max for each provider.

Pipeline simulation. Chain your stages together and vox-bench simulates full conversational round-trips. It measures total time-to-first-byte (TTFB) and time-to-complete, broken down by stage. This is where you catch the compounding effects — a 50ms STT increase plus a 80ms LLM increase that pushes your total over the threshold.

Provider comparison. Run the same benchmark against multiple providers simultaneously. We built this because we needed to evaluate whether switching from Deepgram Nova-2 to Nova-3 would actually reduce our p95 STT latency in practice (it did — by 35ms on average for our healthcare utterances, but increased p99 by 12ms on longer sentences). You configure providers in a YAML file and vox-bench runs them head-to-head.

Regression detection. Run vox-bench on a schedule (we use a GitHub Action that runs every 6 hours) and it compares results against your baseline. If any stage's p95 moves more than your configured threshold, it fires an alert. This is what would have caught the ElevenLabs spike that burned us.

Conversation pattern simulation. Real calls aren't "send audio, get response, repeat." Callers interrupt. They pause mid-sentence. They say "um" for three seconds. vox-bench includes conversation profiles — healthcare-intake, appointment-booking, general-inquiry — that model realistic interaction patterns we extracted from our Loquent call data.

What our benchmarks actually show

We've been running vox-bench internally for two months. Here's what the data looks like across our current production stack:

Deepgram Nova-3 STT: p50 = 180ms, p95 = 245ms, p99 = 310ms. The variance is almost entirely driven by utterance length. Anything under 3 seconds of audio processes fast. Once you cross 6-7 seconds (a full sentence describing symptoms, for example), latency jumps. Our takeaway: design your prompts to encourage shorter caller responses when possible.

Anthropic Claude (Haiku) LLM: p50 = 210ms TTFB, p95 = 340ms, p99 = 480ms. This is streaming — we start sending to TTS as soon as the first tokens arrive. We tested Claude Sonnet too: p50 = 380ms TTFB, p95 = 620ms. For voice, Haiku wins. The quality difference between Haiku and Sonnet for our use cases (appointment scheduling, FAQ answers, intake questions) is negligible, but the latency difference is enormous.

ElevenLabs TTS: p50 = 130ms, p95 = 220ms, p99 = 350ms. The most variable stage in our pipeline. We've seen p99 hit 600ms during what we assume are provider-side capacity issues, always between 2-4pm ET. vox-bench caught this pattern within a week of deployment.

Total pipeline (end-to-end): p50 = 620ms, p95 = 890ms, p99 = 1,150ms. Our p99 is above the 800ms "feels natural" threshold, but below the 1.2 second "callers repeat themselves" line. We're okay with that tradeoff — optimizing p99 below 800ms would require either pre-generating responses (quality hit) or switching to a faster but lower-quality TTS (quality hit). For now, 5-6% of responses feeling slightly delayed is acceptable.

The architecture

vox-bench is built with TypeScript (Node.js 20+). We chose TypeScript because our entire Loquent backend is TypeScript/NestJS, and we wanted the team to be able to extend the tool without context-switching languages.

Key components: a provider adapter layer (currently supports Deepgram, OpenAI Whisper, Anthropic Claude, OpenAI GPT, ElevenLabs, and Google Cloud TTS), a pipeline orchestrator that chains stages with proper streaming, a statistics engine that computes percentiles using the t-digest algorithm (accurate percentiles without storing every measurement), and a reporter that outputs results as JSON, Markdown tables, or sends them to your monitoring system via webhooks.

The whole thing is about 3,200 lines of TypeScript. No magic.

Key findings

TTS is your most variable stage. STT and LLM latency are relatively predictable. TTS providers show the most variance, and the variance is time-of-day dependent. Benchmark at different times or you'll get misleading numbers.
Average latency is a useless metric for voice AI. Your p95 and p99 determine caller experience. A 650ms average can hide a 1.4 second p99 that makes 5% of your conversations feel broken.
Streaming changes everything. Without streaming (waiting for complete LLM response before sending to TTS), our p50 total would be 1,100ms+. With streaming, it's 620ms. If your voice AI pipeline isn't streaming at every stage, fix that before optimizing anything else.
Provider latency varies by content domain. Our healthcare utterances benchmark 15-20% slower on STT than general conversation because of medical terminology. Always benchmark with domain-representative audio, not generic test phrases.
Schedule your benchmarks. Provider performance isn't static. Run benchmarks on a cadence and track trends. The regression detection in vox-bench has caught three provider-side degradations that our application monitoring missed.

Where to find it

The repo is at github.com/Autor-Technologies/vox-bench. MIT licensed. The README has quickstart instructions — you can be running benchmarks against your own providers in under five minutes if you have API keys ready.

We included our healthcare conversation profiles and audio corpus. If you're building voice AI for a different domain, you can create your own profiles — the format is documented and there's a generator script that builds profiles from your own call recordings.

We're actively using this internally. If you find bugs or want to add a provider adapter, PRs are welcome. If you're building voice AI and want to talk latency optimization, we've probably hit the same walls you're hitting.

If you're building something similar, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.

The Exact Prompt Engineering That Makes Our Voice AI Sound Human (Full Prompts Included)

Autor Technologies Inc. — Mon, 11 May 2026 14:37:59 +0000

Last month, a patient called one of our dental clinic clients at 11pm on a Saturday and had a full conversation about rescheduling their root canal — and didn't realize they were talking to an AI until the receptionist mentioned it at their next visit. That wasn't an accident. It was the result of 4 months of prompt iteration, 10,000+ call recordings analyzed, and about 140 prompt versions before we landed on something that actually works.

We build Loquent, a production voice AI platform that handles thousands of automated calls per month for healthcare and dental clinics across Canada. The system runs on Anthropic's Claude for conversation logic, Deepgram for speech-to-text, ElevenLabs for text-to-speech, and Twilio for telephony. When we started, our AI sounded like a chatbot reading a script. Now it sounds like a receptionist who's been working at the clinic for three years. The difference was almost entirely in the prompts.

I'm going to share the actual prompt architecture we use, the specific techniques that moved the needle, and the failures that taught us the most. If you're building voice AI for any domain, most of this transfers directly.

Why Voice Prompts Are a Completely Different Problem

The first mistake we made was treating voice AI prompts like chatbot prompts. We took our best-performing text prompts and plugged them into the voice pipeline. The result was technically correct and completely unusable.

Here's why: in a text chat, a user reads a 3-sentence response in about 4 seconds. In a voice call, that same response takes 12-15 seconds to speak aloud. By sentence two, the caller has already mentally checked out or tried to interrupt. We learned this the hard way — our first production deployment had a 34% hang-up rate within the first 30 seconds.

Voice has three constraints that text doesn't: latency sensitivity (callers expect sub-second responses), interruption handling (people talk over AI constantly), and conversational pacing (long responses feel robotic regardless of how natural the voice sounds).

The Prompt Architecture That Actually Works

After 140+ iterations, we settled on a three-layer prompt architecture. Here's the actual structure:

Layer 1: The System Identity Prompt

This is the foundation. We keep it under 400 tokens because longer system prompts measurably increase response latency with Claude. Here's a representative version (clinic details changed):

You are Sarah, a receptionist at Bright Dental Care in Toronto.
You answer phone calls. You are friendly, efficient, and 
knowledgeable about the clinic.

CRITICAL RULES:
- Respond in 1-2 short sentences maximum. Never more.
- Use natural filler words occasionally: "sure", "of course", 
  "absolutely", "let me check on that"
- If you don't know something, say "Let me check with the 
  team and get back to you" — never guess
- Always confirm spelled-out details back to the caller
- You cannot provide medical advice. Ever. Redirect to 
  the dentist.

CLINIC HOURS: Mon-Fri 8am-6pm, Sat 9am-2pm, Closed Sunday
EMERGENCY LINE: 416-555-0199

Notice what's NOT in there: no verbose personality descriptions, no "you are a helpful assistant," no lengthy backstory. Every token in the system prompt costs you latency, and in voice, latency kills the experience.

Layer 2: The Conversation State Manager

This is where most voice AI projects fail. They treat each turn independently. We inject a dynamic context block that updates every turn:

CURRENT CALL STATE:
- Caller intent: {appointment_reschedule}
- Caller name: {collected: "Michael"}
- Caller verified: {yes — DOB matched}
- Current appointment: {May 15, 2pm, Dr. Patel, cleaning}
- Turn count: {4}
- Sentiment: {neutral, slightly impatient}

NEXT LIKELY ACTIONS: confirm_new_time, check_availability

This state block is assembled programmatically from our NestJS backend. The sentiment field comes from Deepgram's tone analysis on the caller's voice. The "turn count" matters because we found that after turn 6-7, callers get noticeably more impatient, so we prompt Claude to be more concise and direct.

Layer 3: The Response Shaping Instructions

This is the layer we iterated on the most. Here's the version that cut our hang-up rate from 34% to 11%:

RESPONSE FORMAT RULES:
- Maximum 25 words per response unless reading back 
  specific information
- Lead with the answer, then context. Never context first.
- End with a clear next step or question
- Use contractions always (it's, we've, that's)
- No lists. No bullet points. No "firstly/secondly"
- If the caller seems confused, ask ONE clarifying question. 
  Not two.

PACING:
- After giving appointment details, pause with "Does that 
  work for you?" before continuing
- Never stack multiple pieces of information in one response
- If you need to relay 3+ data points, break across turns

The "lead with the answer" rule alone improved our caller satisfaction scores by 22%. When someone asks "Do you have anything available Thursday?" — the old prompt would say "Let me check our availability for Thursday. We have several options..." The new prompt produces: "Thursday works. We have 10am or 2:30pm with Dr. Patel. Which do you prefer?"

The Three Techniques That Made the Biggest Difference

1. The "Overheard Conversation" Training Method

We stopped writing prompts from scratch and started transcribing our best human receptionists. We recorded 40 hours of real receptionist calls (with consent), transcribed them, and identified the specific phrases and patterns that made callers respond positively. Then we encoded those exact patterns into the prompt.

For example, we noticed that the best receptionists always said "perfect" or "great" after a caller confirmed information, before moving on. Small thing. But when we added After caller confirms any information, acknowledge with a brief affirmation ("perfect", "great", "got it") before your next question to the prompt, our post-call satisfaction ratings went up 8%.

2. The 25-Word Ceiling

We tested response lengths systematically across 2,000 calls. The data was clear:

Under 15 words: callers felt the AI was too curt, asked "are you still there?"
15-25 words: optimal range, lowest hang-up rate, highest task completion
25-40 words: hang-up rate increased 18%
Over 40 words: hang-up rate increased 41%, callers started interrupting mid-response

We hard-coded the 25-word ceiling into the prompt and added a programmatic check that flags any Claude response over 30 words for review. In production, Claude stays under 25 words about 89% of the time with this prompt instruction alone.

3. Sentiment-Adaptive Prompting

We inject real-time sentiment into the conversation state (from Deepgram's audio analysis) and include conditional instructions:

IF sentiment = frustrated or impatient:
- Be extra concise. Under 15 words if possible.
- Skip pleasantries. Get to the point.
- Offer to transfer to a human: "Would you like me to 
  connect you with someone from our team?"

IF sentiment = confused:
- Slow down. One piece of information at a time.
- Repeat back what you understood.
- Ask a yes/no question to re-anchor.

IF sentiment = positive/chatty:
- Match energy briefly but stay on task.
- One friendly comment maximum, then redirect.

This single addition reduced our human transfer rate from 23% to 18%. The frustrated callers who previously would have demanded a human were getting handled faster, which resolved their frustration before it escalated.

The Failures Worth Mentioning

The persona trap. We spent two weeks crafting elaborate backstories for our AI personas — hobbies, favorite coffee orders, years of "experience." None of it mattered. Callers don't ask receptionists about their hobbies. Every token spent on backstory was latency we couldn't afford. We stripped it all out.

The politeness overcorrection. After getting feedback that the AI sounded "too robotic," we over-indexed on politeness. The AI started saying things like "I'd be absolutely delighted to help you with that!" on every turn. Three callers in one day asked if they were talking to a bot. Ironically, being too polite was the tell. Real receptionists are friendly but efficient, not performatively enthusiastic.

The temperature disaster. We ran Claude at temperature 0.9 for two days thinking it would sound more "natural." It did — until it started confidently inventing appointment slots that didn't exist and telling one caller that Dr. Patel "usually runs about 10 minutes behind on Tuesdays." Temperature 0.3 is where we live now. Boring is better than wrong.

Key Takeaways

Voice prompts must be ruthlessly short. Every word costs latency and attention. The 25-word ceiling isn't arbitrary — it's data-driven from 10,000+ calls. If your voice AI responses regularly exceed 30 words, you have a prompt problem.
Lead with the answer, always. Context-first responses are a text pattern that fails completely in voice. Callers want the answer in the first 3 seconds, then they'll listen to details.
Inject real-time state into every turn. Treating each turn independently produces conversations that feel like talking to someone with amnesia. The state manager layer is the difference between a demo and a product.
Copy real humans, not chatbots. Transcribe your best human operators. The specific words and micro-patterns they use (affirmations, pacing, question framing) are worth more than any prompt engineering framework.
Measure everything, trust nothing. We thought longer, more detailed prompts would perform better. The data said the opposite. We thought higher temperature would sound more natural. It created hallucinations. Test with real callers, not vibes.

We're planning to open-source our prompt benchmarking tool in the next few weeks (that's the Week 9 article). If you're building voice AI — healthcare or otherwise — and want to compare notes on prompt architecture, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.

We Built a Voice AI Receptionist in 8 Weeks — Every Decision We Made and Why

Autor Technologies Inc. — Mon, 04 May 2026 13:14:16 +0000

Eight weeks. That's how long it took our team at Autor to go from "we should build a voice AI receptionist for healthcare clinics" to handling live patient calls in production. Not a demo. Not a prototype collecting dust on a staging server. A real system answering real phones at real dental and healthcare clinics across Canada.

The product is called Loquent. It now handles thousands of automated calls per month, 24/7, for healthcare and dental clients. But the interesting part isn't what it does today — it's the 47 decisions we made in those 8 weeks that determined whether it would work at all.

Here's every major technical and product decision we made, why we made it, and what we'd change if we did it again.

Week 1–2: Picking the Stack

The first decision was the voice pipeline. We needed three things: a way to receive phone calls, a way to convert speech to text, and a way to convert text back to speech. Simple enough on paper.

For telephony, we went with Twilio. Not because it's the cheapest — it's not — but because we'd shipped 50+ products and knew Twilio's edge cases. When you're building something that needs to be in production in 8 weeks, you don't gamble on infrastructure you haven't battle-tested. Twilio's media streams gave us real-time audio over WebSocket, which was critical for keeping latency low.

For speech-to-text, we chose Deepgram. We tested Google Speech-to-Text, AWS Transcribe, and Deepgram head-to-head with 200 sample audio clips from actual clinic phone calls (with permission). Deepgram won on two axes: accuracy on medical terminology and latency. Their streaming API returned partial transcripts in under 300ms consistently. Google was close on accuracy but added 150–200ms more latency. In voice AI, that 200ms is the difference between a conversation that feels natural and one that feels like talking to a bad VoIP connection.

For the LLM brain — the part that actually understands what the caller wants and decides what to say — we went with Anthropic Claude. We'd used GPT-4 extensively on other projects, but Claude gave us two things we needed: more predictable instruction-following for complex system prompts, and better handling of the conversational nuance healthcare calls require. When a patient says "I think I need to come in but I'm not sure," Claude was measurably better at handling that ambiguity with the right mix of helpfulness and appropriate medical caution.

Text-to-speech was ElevenLabs. We tested 6 providers. ElevenLabs had the most natural-sounding voices and critically, their streaming API let us start playing audio before the full response was generated. This shaved another 400ms off perceived latency.

The backend is NestJS with TypeScript, running on AWS with Docker. Our API layer handles the orchestration between all these services. We use PostgreSQL with Prisma for call logs, appointment data, and conversation history. The frontend dashboard for clinic staff is Next.js on Vercel.

Total time on stack decisions: 4 days. We spent 3 of those days on benchmarking speech providers because that's where we had the least prior experience.

Week 3–4: The Latency Problem

Here's what nobody tells you about building voice AI: the technical challenge isn't making it smart. It's making it fast.

A normal human conversation has about 200ms of silence between turns. Our first end-to-end prototype had 2.4 seconds of latency from the moment the caller stopped speaking to when they heard the AI respond. That's brutal. Callers were hanging up or talking over the AI.

We broke the latency down:

Speech-to-text finalization: ~400ms
LLM inference (Claude): ~800ms
Text-to-speech generation: ~600ms
Network overhead between services: ~600ms

Every one of those had to come down. Here's what we did.

Speech-to-text: We switched from waiting for final transcripts to acting on interim transcripts with a confidence threshold above 0.85. This let us start LLM inference 300ms earlier on average, at the cost of occasionally sending a slightly wrong transcript. We added a correction mechanism that would interrupt and re-route if the final transcript meaningfully differed from the interim one. In practice, this happened on less than 3% of utterances.

LLM inference: We couldn't make Claude faster, but we could make it produce less. We restructured our prompts to front-load the critical response content. Instead of "think step by step and then respond," we used a format where Claude would output the spoken response first, then its reasoning. We also aggressively cached common conversation patterns — things like greeting responses, hold requests, and appointment confirmations. About 40% of conversational turns hit the cache.

Text-to-speech: Streaming. Instead of generating the full audio clip and then playing it, we streamed audio chunks as they were generated. The caller hears the first word within 200ms of generation starting.

Network: We co-located all services in the same AWS region (ca-central-1, because Canadian healthcare data stays in Canada — more on that later). We also moved from HTTP request/response to persistent WebSocket connections between our services.

Final latency after optimization: 800ms average. Not perfect, but well within the range where conversations feel natural. Callers stopped hanging up.

Week 5–6: Making It Actually Useful

A fast AI that says the wrong thing is worse than a slow AI that says the right thing. Week 5 was about prompt engineering and conversation design.

We spent two full days sitting in a dental clinic's front office, listening to actual receptionist calls and documenting every type of conversation. We categorized 14 distinct call types, from appointment booking to insurance verification to emergency triage. Each one needed different handling logic.

The critical insight: we didn't try to make one mega-prompt handle everything. Instead, we built a routing layer. The first few seconds of each call go through a lightweight classifier that determines the call type, then routes to a specialized prompt and conversation flow for that type. This meant each individual prompt could be simpler and more reliable.

For appointment booking — about 60% of all calls — we integrated directly with the clinic's scheduling software through their API. The AI doesn't just take a message; it actually checks availability and books the appointment in real time. This was the feature that made clinic owners go from "interesting demo" to "shut up and take my money."

We also built the HubSpot and Salesforce integrations during this phase. Every call gets logged with a full transcript, caller sentiment, call type, and outcome. Clinic managers can see exactly what's happening with their phone lines without listening to recordings.

Week 7: The 18% Problem

By week 7, we had something that worked. But 18% of calls were being transferred to human staff because the AI couldn't handle them. We wrote a whole separate article about what those 18% had in common (that's next week's post), but the short version: edge cases around insurance questions, multi-party calls, and callers who were genuinely distressed.

We made a deliberate decision: we would not try to get that 18% down to zero. Some calls should go to humans. A patient who just got a scary diagnosis and is calling to schedule a follow-up doesn't want to talk to an AI, no matter how good it is. We built robust handoff logic that transfers calls smoothly with full context, so the human receptionist knows exactly what's already been discussed.

This is one of the decisions I'm most proud of. The temptation in AI product development is to automate everything. But knowing where to draw the line is what makes the product trustworthy.

Week 8: Going Live

Production deployment was its own adventure. We did a phased rollout: the AI handled calls only during off-hours for the first clinic, then gradually expanded to business hours over 5 days.

The things that broke in production that didn't break in testing:

Background noise. Our test calls were recorded in quiet offices. Real calls come from cars, restaurants, playgrounds. We added a noise gate and retuned our Deepgram configuration with their noise cancellation features.

Accents and languages. Toronto is one of the most multicultural cities in the world. Callers speak English with every accent imaginable, and some prefer to start in another language entirely. We added language detection in the first 3 seconds and route non-English calls to human staff (multilingual AI is on our roadmap).

Caller expectations. Some callers figured out they were talking to AI and started testing it — asking trick questions, trying to confuse it, or just saying "give me a human." We added explicit handling for these cases. If someone asks for a human, they get one immediately. No persuasion, no "but I can help you with that."

What We'd Do Differently

If we were starting Loquent today, three things would change.

First, we'd invest in end-to-end latency monitoring from day one. We built our monitoring piecemeal and it cost us debugging time when production latency spiked at 3am (we wrote about that too — see our Week 3 article).

Second, we'd use a multi-model approach from the start. Not every conversational turn needs Claude's full reasoning capability. Simple acknowledgments ("Got it, let me check that for you") could come from a smaller, faster model. We're implementing this now, and it's cutting our average latency by another 150ms.

Third, we'd build the analytics dashboard before the AI itself. We spent the first two weeks of production flying blind on call quality because our dashboard wasn't ready. The data was being logged but we couldn't see patterns until we built the visualization layer.

The Numbers After 6 Months

Loquent now handles thousands of calls per month across multiple clinics. The 82% automation rate has held steady. Patient satisfaction scores for AI-handled calls are within 5% of human-handled calls. Clinics using Loquent report that their human receptionists spend 60% less time on routine calls and can focus on patients who actually need personal attention.

We built Loquent with a team of senior engineers, no offshore work, no handoffs between teams. The same people who designed the architecture wrote the code and debugged the production issues. That's how we shipped in 8 weeks.

Key Takeaways

Latency is the make-or-break metric for voice AI. Your AI can be the smartest system ever built, but if it takes 2 seconds to respond, callers will hang up. Optimize for speed before you optimize for intelligence.
Don't pick infrastructure you haven't used before when you're on a tight timeline. We chose Twilio over newer, cheaper alternatives because we knew its failure modes. That decision alone probably saved us a week of debugging.
Build specialized conversation flows, not one giant prompt. A routing layer with focused prompts beats a single do-everything prompt on reliability, latency, and maintainability.
Know where to draw the automation line. The 18% of calls we route to humans aren't a failure — they're a feature. Trustworthy AI knows its limits.
Co-locate everything and measure latency end-to-end. Every network hop between services adds latency. In voice AI, those milliseconds are the product experience.

Autor is a Toronto-based AI development studio that builds production AI systems. Loquent, our voice AI platform, handles thousands of automated calls monthly for healthcare clients across Canada.

If you're building something similar, we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.