DEV Community: Autor Technologies Inc.

AI Agent Examples for Small and Mid-Size Businesses (and Which of Ours Are Really Agents)

Autor Technologies Inc. — Fri, 13 Nov 2026 14:52:13 +0000

"What are some examples of AI agents?" is one of the fastest-growing questions we see in search data this autumn, together with "what's the best AI agent for a small business?" Most of the answers online are lists of products. We think the question underneath is a different one: what would an agent actually do in a business like mine? This post answers that with examples sorted by job. Then it does something most lists don't. It goes through the AI products we've built at Autor (they're all on our work page) and says plainly which ones are agents and which ones aren't.

First, a working definition

The most useful line we know comes from Anthropic's engineering guide, Building effective agents. It separates two things that both get called "agents." Workflows are systems where a language model and tools are orchestrated through predefined code paths. Agents are systems where the model directs its own process and tool use, deciding how to get the task done.

We use a two-part test that follows from that:

Does it decide its own next step? A fixed script that calls a model at step three is a workflow. That's often the better build, and nothing to be ashamed of.
Does it act through tools? If it only produces text for a person to copy somewhere, it's an assistant. An agent books the slot, updates the record or sends the message.

Most real business systems are a mix. That's fine. The label matters less than knowing which parts make decisions, because those parts need guardrails.

Is ChatGPT an AI agent? Is Claude?

The plain chat window is an assistant. You ask, it answers, and you do the work. Both companies now ship agent modes on top of it. OpenAI's ChatGPT agent can carry out multi-step tasks using tools. Anthropic publishes the same building blocks for developers in the Claude Agent SDK. So the honest answer is "the chat isn't, but the product can be." For a business, the more useful question is whether a general-purpose agent can reach your systems with the permissions and approval steps you need. That's usually where a general tool stops and a specific one starts.

AI agent examples by the job they do

These are the patterns we see most in small and mid-size businesses. Each one is narrow on purpose. In our experience, narrow agents are the ones that reach production. Our guide to building an AI agent explains why.

Job	What the agent decides and does	Systems it acts in	Where a person stays in the loop
Answering customers	Works out what the caller or chatter wants, answers from your own information, takes details	Phone, website chat, messaging, calendar	Anything outside what it's been told it can answer
Lead follow-up	Decides who is waiting, what to say next and on which channel	CRM or lead list, email, text	Approves outbound messages before they send
Booking and rescheduling	Finds a slot that fits the rules, books it, confirms	Calendar, booking system	Exceptions and double-bookings
Re-engaging past customers	Picks who is due, drafts the reminder, books whoever replies	Customer list, messaging, calendar	Approves the list and the wording
Document intake	Reads an incoming form, invoice or application, pulls out the fields, files it, flags gaps	Email inbox, storage, accounting or CRM	Reviews anything it flags as uncertain
Internal questions	Finds the answer in your policies, past tickets or docs and cites where it came from	Knowledge base, drive, ticketing	Owners keep the source documents current
Scheduling staff	Builds a roster that satisfies rules and availability, then proposes changes when someone drops out	Scheduling system, notifications	Manager signs off the roster

Notice what isn't on the list: "an AI that runs the business." Every example is one job with one measurable number attached, such as response time, the share of leads followed up within the hour, or overdue customers re-booked.

Which of our builds are actually agents

We've put every product below on our work page. Here's how each one scores on the two-part test, including the ones that fail it.

Build	What it is	Agent?
Loquent (our own product)	An AI workforce for small businesses: owners hire AI employees by role, and the same employee works across phone, website chat, WhatsApp and text	Yes. Each employee decides what a conversation needs and acts through tools. It asks the owner before it acts
Avatraxx	A fitness platform with LLM-driven training plans that adapt to each user's progress and engagement	Partly. The plan adapts in a loop, but within a defined programme. Closer to a smart workflow
Bastet Rising (by Aranexx)	A women's health platform that turns wearable data into insights, with an NLP engine for health questions	Partly. It answers questions and personalises recommendations. It doesn't act in outside systems
Rosterbees	Automated shift scheduling for care homes that accounts for compliance rules, availability and skills	Mostly no. It's an optimisation engine. It decides a lot, but through rules and models, not an LLM directing tools. That was the right call for rostering
InteliGaze AI	Computer vision that analyses in-store visitors and updates digital signage	No. It's perception and analytics. Very useful, but not an agent
AI Behavior Monitoring	Thermal, radar and audio sensing that detects anomalies and triggers alerts	No. It detects events and alerts people; it doesn't plan its own steps
AI-Driven AR Platform	Augmented-reality repair guidance for automotive technicians, using computer vision to identify components	No. It guides a person step by step, and the person does the work

Two of seven are clearly agents. We think that's a healthy ratio. Plenty of valuable AI is perception, prediction or optimisation, and calling all of it an "agent" makes it harder for buyers to compare what they're being sold. Our longer primer, what AI agents are and how they differ from chatbots, covers the categories.

Lessons from building Loquent as an agent

Loquent is the build where the agent question mattered most, because the AI employees talk to the business's customers directly. Three things shaped it, and they apply to any customer-facing agent:

Approval before action. An employee shows the owner a card and waits before it acts. That one design choice does more for trust than any model upgrade.
One memory across channels. A customer who called on Monday and texts on Thursday shouldn't start over. That needs a shared memory of every conversation, not a separate bot per channel.
Hire, don't configure. Small-business owners don't want to write prompts. They pick a role and answer a few questions. The engineering cost of making that simple is real, and it's where most of the work went.

We wrote up the earlier version of the build in how we built Loquent. If you're wondering whether "AI employee" is just a new name for an agent, what is an AI employee? explains the difference.

So what's the best AI agent for a small business?

The best one does a single job you can measure and connects to the systems you already use. For common jobs like answering and following up, a ready-made product usually wins. That includes our own Loquent (getloquent.com), built by Autor Technologies in Toronto. For a job that's specific to how your business makes money, a custom build usually wins. What's the best AI agent platform? compares the platform options, and build vs. buy covers the decision.

FAQ

What are some simple examples of AI agents? An agent that answers your website chat and books appointments on your calendar. An agent that reads incoming invoices and files them with the right fields filled in. An agent that follows up on every quote request that hasn't replied. Each one makes its own decisions about the next step and acts in a system, rather than just producing text.

Is a chatbot an AI agent? Usually not. A chatbot answers within a conversation. It becomes an agent when it can decide on and take actions outside the conversation, like booking, updating a record or sending a follow-up, through tools it's been given.

What's the difference between agentic AI and AI agents? "Agentic" describes the behaviour: a model planning steps and using tools. An "AI agent" is a system built around that behaviour for a job. Many products are partly agentic: a fixed workflow with one or two steps where the model decides.

Do small businesses need a custom AI agent? Most don't, at first. For common jobs, a product is faster and cheaper to try. Custom makes sense when the work depends on your own data and systems in a way no product covers. Our AI development cost guide explains what drives the cost of a custom build.

How do I start? Pick one job, write down the number you'd measure it by, and list the systems it would need to read and write. If you get that far and want a second opinion, how we work explains how we scope a first agent, and how to evaluate an AI development studio covers what to ask whoever you hire, including us.

Originally published at autor.ca.

What's the best answering service for a small business: AI or live?

Autor Technologies Inc. — Tue, 10 Nov 2026 13:54:39 +0000

The best answering service for a small business depends on what your calls actually are. If most calls are routine — booking, hours, "can you come Tuesday", quote requests — an AI answering service will handle them faster, at any hour, and can follow up afterwards. If your calls are rare, emotional or high-stakes — a flooded basement, a legal emergency, an upset patient — a live answering service with trained people is still the safer choice, and plenty of businesses end up using both.

We build AI systems at Autor, a studio in Toronto. Since 2021 we have shipped 50+ products used by 5M+ people in 10+ countries, and we build our own product in this space, Loquent (getloquent.com). So we are not neutral, and this guide says where AI is the wrong call as clearly as where it fits.

What each one actually does

A live answering service is a team of people, usually shared across many client businesses, who pick up when you can't. They work from a script you agree with them, take a message or book into your calendar, and escalate urgent calls to you. The quality depends on the agent who happens to answer and on how well your script covers the call.

An AI answering service is software that picks up the call, understands what the caller wants, answers from what it knows about your business, and takes an action — books the visit, sends you the details, texts the caller a confirmation. It doesn't get tired at 2 a.m. and it never puts anyone on hold. It also doesn't have a human's judgment, and it will sometimes misunderstand a caller.

The newer version of the AI option doesn't stop at the phone. The same assistant answers website chat and text messages, remembers the caller from last time, and chases the lead the next day. That's the idea behind what we call an AI employee: you hire a role, not a phone menu.

Five questions that decide it

1. How many of your calls are the same five questions? Pull up your last 50 calls or voicemails. If most are "are you open", "how much for", "can I book", "did you get my message" — that is exactly what AI handles well. If every call is different and needs judgment, a person is better.

2. What happens to the call after it ends? This is the question most owners skip. A live service usually ends with a message in your inbox. If the real work is the follow-up — calling the lead back, sending the booking link, reminding them on Thursday — an AI that does the follow-up too is worth more than one that only answers.

3. How bad is a wrong answer? If a mistake means a slightly awkward booking, AI is fine. If a mistake means someone with a medical, legal or safety emergency doesn't get to a human fast enough, you need a person in the loop, or a hard rule that sends those calls straight to you. Any AI answering service you consider should let you define "always transfer these" in plain words.

4. When do your calls come in? Live services staff for business hours and charge more for after-hours coverage. If a big share of your calls land at night and on weekends — common in home services — that's where AI earns its keep, because the cost doesn't change at 11 p.m.

5. Who is going to check its work? Every answering setup needs an owner for the first few weeks. With a live service that means reviewing messages and correcting the script. With AI it means reading transcripts and fixing what it got wrong. If nobody will do either, neither option will be good.

Where a live answering service is the better choice

Low call volume, high stakes. A small law practice that gets a few calls a day, each one a potential client in a stressful moment, is usually better served by a calm human voice.
Callers who will hang up on a machine. Some customer bases — older callers, people in distress — have little patience for software, however good it is. You know your callers better than any vendor does.
Calls that need empathy more than information. Complaints, cancellations and bad news go better with a person.
You need a message taken, nothing more. If you just want a polite human to write down the name and number, a live service is simple and mature.

Where an AI answering service is the better choice

High volume of routine calls. Booking, rescheduling, opening hours, service areas, "did you get my request" — repetitive, and fast to answer from your own information.
After-hours and overflow. Calls that come in while you're on a job, under a sink or with a patient.
Anything that needs a follow-up. An AI can text the booking confirmation, send the details to your calendar and nudge the lead the next day. A message slip can't.
More than one channel. If customers also reach you by website chat or text, one assistant that knows what was said on each is better than three separate tools.

The trade-offs nobody puts on the pricing page

AI misunderstands people. Accents, background noise, callers who change their mind mid-sentence. The good systems recover by asking again or handing off. Test it with real calls — including your worst ones — before you trust it.

Live services vary by agent. The person who answers tonight may not be the one who learned your business last month. Ask how they train agents on a new client and how they handle calls the script doesn't cover.

Outbound follow-up has rules. Answering a call someone made to you is one thing; calling or texting them back with an automated system is another. In the US, the FCC confirmed in 2024 that AI-generated voices count as "artificial" voices under the TCPA, so the consent rules for robocalls apply (summary from Cooley). In Canada, the CRTC's Unsolicited Telecommunications Rules cover automated calling. Whatever you choose, make sure follow-ups go only to people who contacted you, and ask the vendor how they handle consent. This isn't legal advice; if you're unsure, ask a lawyer.

Neither one fixes a missing process. If you don't know what should happen after a quote request, an answering service — human or AI — will faithfully do nothing useful with it. Write down the next step for your five most common calls before you buy anything.

Using both

A lot of small businesses end up with a hybrid: AI answers every call first, handles the routine ones end to end, and transfers or flags anything urgent or emotional to a person — you, a staff member or a live service. That gives you 24/7 coverage without putting a machine between you and the calls that matter most. If you're evaluating vendors, ask each one how a hand-off works and test it.

Where Loquent fits

Loquent (getloquent.com) is our own take on the AI side, built by Autor in Toronto. It's not a phone menu you configure; you hire AI employees by role — an AI Customer Care Coordinator that answers phone, website chat, WhatsApp and texts, an AI Sales Coordinator that follows up every lead. It remembers returning customers, and nothing goes out without your yes: it shows you what it's about to do before it acts. It's for businesses in Canada and the US, hosted in Canada, and it's now taking pilot businesses. If your calls are mostly emotional or high-stakes, though, start with a live service — that's the honest answer.

If you run a clinic, our comparison of AI receptionists for Canadian clinics goes into what vendors publish about PHIPA, PIPEDA and data residency.

FAQ

Is an AI answering service better than a live one for a small business? For routine, frequent calls and after-hours coverage, usually yes. For rare, emotional or high-stakes calls, a live service is still safer. Many businesses combine them.

Will customers know they're talking to AI? Often, yes, and it's better to be upfront about it. Most callers care more about getting an answer and a booking than about who picked up. Callers who want a person should be able to reach one.

Can an AI answering service book appointments into my calendar? Many can, if they connect to the calendar you already use. Check which calendars a vendor actually supports today rather than what's on the roadmap.

What's the difference between an answering service and an AI receptionist? An answering service, live or AI, picks up when you can't. "AI receptionist" usually means the AI version. Newer products go further and also follow up leads and handle other channels, which is closer to an AI employee than a receptionist.

Should a very small business with a few calls a day bother? If each missed call is a lost job, yes — even a few a week add up. If you rarely miss calls, voicemail and a quick callback may be all you need.

Can I try an AI answering service before committing? Most offer a trial. Use it on your real number for a week, read every transcript, and only then decide.

Originally published at autor.ca.

How to Build an AI Agent for Your Business in 2026: A Practical Guide

Autor Technologies Inc. — Thu, 05 Nov 2026 00:14:33 +0000

"How do I build an AI agent?" is the question we hear most often right now, usually from a founder or operator who has watched a demo, believes the technology is real, and wants to know what it actually takes to put one to work inside their own company. This guide is our answer. We build AI agents and products for a living — it is the first thing we do at Autor, a senior engineering studio in Toronto — and what follows is the process we use, stripped of the hype.

A quick definition so we are talking about the same thing: an AI agent is software that can take a goal, decide the steps to reach it, use tools and data on its own, and act — not just answer a question. If you want the longer version, we wrote a separate primer on what AI agents are and how they differ from chatbots. Here we assume you are past the "what" and on to the "how."

Step 1: Pick one job and one number

The single biggest predictor of whether an agent project succeeds is how narrow it starts. Teams that try to build "an AI assistant for the whole business" tend to ship nothing. Teams that pick one job — qualify inbound leads, answer tier-one support, reconcile invoices, follow up on no-shows — tend to ship something real in weeks.

Choose a job that is repetitive, rules-heavy, and currently done by a person who is stretched thin. Then attach one number to it that you can measure before and after: response time, percentage of tickets resolved without a human, leads followed up within an hour. If you cannot name the number, you are not ready to build yet — you are still scoping.

Step 2: Map the data and the systems it will touch

An agent is only as useful as what it can see and do. Before any model is chosen, write down two lists. First, what the agent needs to know: your CRM records, your knowledge base, past conversations, product data, pricing rules. Second, what it needs to do: create a ticket, book a calendar slot, update a record, send a reply, flag a human.

This is where most of the real engineering lives. A convincing demo reads from a single document; a working agent reads and writes across the systems you already run. If those systems have clean APIs, this is manageable. If your data is trapped in formats no one has looked at in years, plan for that work now — it is usually the long pole in the project.

Step 3: Choose the model and the tool layer

The model (Claude, GPT, Gemini, or an open-weight model you host) is the brain, but the part that makes an agent do things is the tool layer — the connections between the model and your systems. In 2026 the emerging standard for those connections is the Model Context Protocol (MCP), which gives a model a consistent way to call external tools and data sources. We build custom MCP servers for exactly this reason, and we wrote a guide to MCP if you want the detail.

Pick the model for the job, not the headline: a cheaper, faster model is often right for high-volume, low-stakes steps, with a stronger model reserved for the hard calls. The architecture that lets you mix them — and swap one out when a better one ships — matters more than today's leaderboard.

Step 4: Put a human gate on anything that acts

An agent that can send, charge, delete, or commit on its own is a liability until it has earned trust. The pattern we use, and build into every agent, is simple: the agent proposes, a person approves, and the approval threshold loosens as the track record proves out. Start with the agent drafting and a human sending; graduate the safe, high-frequency actions to automatic once the error rate is where you want it.

This is not a limitation to apologize for — it is the feature that lets you deploy an agent in a real business without betting the company on it being right every time.

Step 5: Pilot on real traffic, measure, then expand

A test set tells you the agent handles the cases you thought of. Only live traffic, scoped small, tells you about the ones you didn't. Route a slice of real work to it, keep the human in the loop, and watch the number you chose in Step 1. You will find edge cases no one imagined — that is the point of the pilot, not a sign of failure. Fix them, add them to your test set, widen the slice, and only then talk about the next job.

Build, buy, or co-build?

Not every business should build an agent from scratch, and we will tell you when you shouldn't.

Buy an off-the-shelf tool when the job is generic and a mature product already does it well — email triage, meeting notes, standard support macros. You will be live in days and you should not pay engineers to rebuild a solved problem.

Build custom when the agent needs your proprietary data, your specific workflow, or an integration no vendor offers — or when the capability is close enough to your core business that owning it matters. We go deep on this trade-off in Build vs. Buy: When Your Business Needs Custom AI.

Co-build when you want to own the result but do not have a senior AI team in-house. This is how we work with most clients: we build alongside your people so the knowledge stays with you after we leave. Loquent, our own AI product, is proof the model works — we wrote up how we built it.

What to budget — in time, not just money

The fastest way to de-risk the decision is a short prototype. We run 2–4 week prototyping sprints that produce a working agent against your real data, so you can judge feasibility before committing to a full build. A narrow first agent is a matter of weeks; a broad, multi-system deployment is a matter of months. For a fuller picture of what drives the number, see our 2026 guide to the true cost of AI development.

The mistakes that sink most agent projects

We have seen the same four failures repeatedly. Scoping too broad, so nothing ships. Skipping the data work, so the demo never survives contact with reality. Giving the agent authority to act before it has earned trust, so one bad action poisons the whole effort. And never instrumenting it, so no one can say whether it worked. Avoid those four and you are ahead of most teams attempting this in 2026.

How we build agents at Autor

We are a Toronto studio with a senior-only team — no offshore handoffs, no junior work shipped under a senior's name. We have delivered 50+ AI products used by more than 5 million people across 10+ countries. We build the agent, wire it into the systems you already run through custom MCP servers, keep a human in control of anything that acts, and leave your team able to run and extend it.

If you have a job in mind and a number you want to move, start a project with us — or start with a prototype sprint and decide once you have seen it work.

Frequently asked questions

How long does it take to build an AI agent?
A narrow agent scoped to a single job can be prototyped in 2–4 weeks and in limited production shortly after. A broad deployment across several systems takes months, mostly because of the data and integration work rather than the model itself.

Do I need to train my own model?
Almost never. Most business agents use a strong existing model (Claude, GPT, Gemini, or a hosted open-weight model) connected to your data and tools. The value is in the connections, the workflow, and the guardrails — not in training a model from scratch.

What is the difference between an AI agent and a chatbot?
A chatbot answers. An agent acts — it decides steps, uses tools, reads and writes to your systems, and completes a task. We explain the distinction in detail in What Are AI Agents.

Should I build or buy?
Buy when the job is generic and a mature product exists. Build or co-build when the agent needs your proprietary data, your specific workflow, or an integration no vendor offers. Our build vs. buy guide walks through the decision.

How do I keep an AI agent from making costly mistakes?
Put a human approval gate on any action that sends, charges, or changes data, and loosen it only as the agent's measured error rate proves out. Pilot on a small slice of real traffic before expanding.

Originally published at autor.ca.

What Is an AI Employee? The 2026 Guide for Small Businesses

Autor Technologies Inc. — Thu, 05 Nov 2026 00:14:26 +0000

An "AI employee" is an AI you hire by role — the way you would hire a sales coordinator or a customer-care rep — instead of a bot you have to configure. It is a newer way of packaging the same technology behind AI agents, aimed squarely at small businesses that do not have time to build or wire anything. We build in this space ourselves: our product Loquent (getloquent.com), built by Autor Technologies in Toronto, is an AI workforce that lets a small business hire AI employees by role. (If you have searched the name, note there are unrelated companies using "Loquent" elsewhere — the one we make is at getloquent.com.)

This guide explains what the category is, how it differs from the "AI agent" you may have read about, and what to look for if you are considering one.

AI employee vs. AI agent: the same engine, a different package

Under the hood, an AI employee runs on the same core technology as an AI agent: a model that can take a goal, use tools, and act. The difference is in how it is delivered.

An AI agent is usually something you — or a developer — design, connect, and configure. An AI employee is pre-shaped around a job. You pick a role, answer a few questions about your business, and it starts. There are no prompts to write and no flow builders to learn. For a small business owner who wants the outcome and not the project, that packaging is the whole point. (If you do want to build a custom agent, we cover that path in How to Build an AI Agent for Your Business.)

What an AI employee actually does

A good AI employee is defined by five things. This is how we think about Loquent, and a reasonable checklist for the category generally.

You hire it, you don't configure it. Pick a role, answer a few questions, and the employee starts working. No prompt engineering, no builder.

One team on every channel. The same employee answers the phone, website chat, WhatsApp, and texts — and knows what was said on each, so a customer never has to repeat themselves.

It remembers every customer. A returning caller is greeted with what they asked about last time. In Loquent we call this memory the Business Brain.

Nothing goes out without your yes. Before it acts, it shows you a card and waits for approval. In Loquent, you run your employees through a chat called Ask, and the things that need you land in a list called Needs you. It asks before it acts.

Your data stays put. For a Canadian business that matters — Loquent is hosted in Canada and is Google-verified (CASA) to read Gmail, Calendar, and Drive.

The roles you can hire

The point of the category is that you hire a specific job rather than a generic bot. The ready-made roles in Loquent today are the AI Sales Coordinator, AI Outreach Coordinator, AI Customer Care Coordinator, AI Content Strategist, AI Creative Designer, AI Social Media Manager, and AI Newsletter Manager — and you can define a custom employee by answering three questions about the job you need done.

To be concrete about scope, because this is where a lot of AI products overpromise: an AI employee like Loquent's can answer your phone, chat, WhatsApp, and texts; get you a local number in your area code; text your customers (Canada now, the US as registration completes); take the details and book the visit; and plan and design your social posts. We are deliberate about what it does not claim to do yet — it plans and designs posts rather than publishing them for you, and it connects to the tools we have proven, Google (Gmail, Calendar, Drive, Sheets) and Zoho (Mail, Calendar, CRM), rather than "everything."

Who an AI employee is for

The fit is a small business that loses work because nobody picks up, nobody follows up, or the admin never gets done — home and field services, clinics, professional services, local consumer businesses, and independent sales reps. If you have more inbound than hands to handle it, a role-based AI employee is a faster path to coverage than hiring or than building something custom.

How to try the category without betting on it

The honest way to evaluate any AI employee is to put it on a slice of real work and watch one number — missed calls recovered, leads followed up within the hour, hours of admin returned to you. Loquent is now taking pilot businesses, and you can start free at getloquent.com to see it answer on your own line before you commit to anything.

If you are a founder who would rather build and own a custom agent than hire a ready-made one, that is our day job too — Loquent is proof we can ship this kind of product, and we wrote up how we built it.

Frequently asked questions

What is an AI employee?
An AI you hire by role — a sales coordinator, a customer-care coordinator, a social media manager — that works across your channels and does the job, instead of a bot you have to configure. You pick a role, answer a few questions, and it starts.

How is an AI employee different from an AI agent?
They share the same underlying technology. An AI agent is typically designed and configured by a developer; an AI employee is pre-shaped around a job so a business owner can hire it without building anything. See What Are AI Agents for the technical side.

Does an AI employee replace my staff?
It is built to cover the work that currently falls through the cracks — the calls no one answers, the follow-ups no one gets to, the admin that piles up — and to ask before it acts. It extends a small team's reach rather than removing the people.

Is my data safe with an AI employee?
With Loquent, your data is hosted in Canada and the product is Google-verified (CASA) to connect to Gmail, Calendar, and Drive. Ask any vendor where data is hosted and which integrations are actually live before you commit.

How do I try one?
Loquent is taking pilot businesses now. You can start free at getloquent.com and have an AI employee answering on your own line to judge it on real work.

Originally published at autor.ca.

What's the best AI agent platform?

Autor Technologies Inc. — Thu, 05 Nov 2026 00:13:58 +0000

There is no single best AI agent platform, because four quite different kinds of product are sold under that name: no-code builders, workflow automation tools, agent frameworks, and model-provider SDKs. The honest answer is that the right choice is decided by who maintains the agent six months after it launches, not by a feature table. If nobody on your team writes code, a no-code builder or an automation tool is the correct answer and a framework is the wrong one — even though the framework is more capable.

We build AI systems for a living at Autor, a studio in Toronto. We have shipped 50+ products since 2021, reaching 5M+ users across 10+ countries, and we build our own product, Loquent (getloquent.com), on the same stack we recommend to clients. So the view below is a build-side view: what breaks later, not what demos well.

The four things called an "AI agent platform"

No-code agent builders. You describe a job in a web UI, connect a few accounts, and the agent runs. Fastest path from idea to something working. The ceiling arrives when you need branching logic that the UI doesn't express, or when you want to test a change without shipping it to every user.

Workflow automation tools with AI steps. Tools like n8n and Zapier started as integration plumbing and added model calls. If your "agent" is really a chain — trigger, fetch, call a model, write somewhere — this category is usually the cheapest correct answer, and a lot of what gets called an agent is actually this.

Agent frameworks. LangGraph, CrewAI, Pydantic AI and similar libraries give you state machines, tool calling, retries and multi-agent coordination in your own codebase. They assume you have engineers and CI. In exchange you get to version, test and debug an agent like normal software.

Model-provider SDKs. OpenAI's Agents SDK, Anthropic's SDK and Google's ADK sit one level below frameworks: tool use, structured output and loops, without opinions about orchestration. Thinnest layer, least lock-in, most code you write yourself.

Comparing a no-code builder against LangGraph is comparing a kit car to a machine shop. Both make a car.

The five questions that actually decide it

1. Who edits this in month six? The single highest-value question. If the answer is an operations manager, pick something with a UI. If it's an engineer, pick a framework and get real tests. Teams get this wrong in both directions: a studio hands a client a beautiful codebase nobody can change, or an ops team hits a logic wall in a builder and has to start over.

2. How wrong can one run be? An agent that drafts internal summaries can be wrong often and cheaply. An agent that sends a quote, moves money or writes to a medical record cannot. The second case needs an approval step and an audit trail, and that requirement eliminates most no-code tools immediately — not because they are bad, but because confirm-before-acting is architecture, not a setting. We built Loquent so nothing goes out without the owner's yes, and that one decision shaped more of the system than any model choice.

3. What does it have to touch? Count the integrations you genuinely need, then check they exist and are maintained, not merely listed. A single missing connector can outweigh every other consideration, and "has an API" is not the same as "has a tested integration."

4. Can you tell whether it's working? Most agent projects die here. You need to see what the agent did, replay a bad run, and know whether yesterday's prompt change made things better or worse. Ask of any platform: can I export every run, and can I score a change against a fixed set of cases before shipping it? If not, you are flying blind and you will find out in production.

5. What does leaving cost? Prompts and tool definitions port easily. Proprietary orchestration state, vendor-specific memory and UI-defined logic do not. The exit cost is roughly the amount of your logic that lives inside the vendor's abstractions rather than in your own code.

When you shouldn't use a platform at all

Three cases where a platform is the wrong purchase:

It's a chain, not an agent. If the steps are fixed and known, you want a script or a workflow tool. An agent loop adds cost, latency and nondeterminism to buy flexibility you aren't using. A great many "agent" projects are a cron job with a model call in the middle, and they are better, cheaper and more reliable built that way.

A product already does it. Support triage, meeting notes, invoice extraction, scheduling — these are products now. Buying one takes an afternoon; building the equivalent takes a quarter, and you are then a vendor to yourself forever. Build when the workflow is the thing that makes your business different. Buy when it isn't.

You can't tell whether it worked. If you cannot write down twenty cases and the right answer for each, don't start. Not because the agent won't work, but because you won't be able to tell, and you'll ship on vibes and roll back on complaints.

What we actually use

For client work we usually reach for a framework plus a model SDK, in the client's own repo, with an eval suite from day one — because we are handing over software that a team has to own for years, and we want a change to be reviewable. For a small internal task we will cheerfully use a workflow tool and move on; writing a framework agent to rename files would be bad engineering with extra steps.

The trade-off is real and worth naming: the framework route costs more up front. More setup, more code, more tests. You buy maintainability with it. If the agent is an experiment you may delete in a month, that's a bad trade — use the fastest thing that works and throw it away without regret.

FAQ

What's the best free AI agent platform? The open-source frameworks above are free as software; the model calls are not. Costs track tokens and run frequency, so a cheap-looking agent that runs on every page view can cost more than a paid platform running nightly. Estimate volume before you compare licence prices.

What's the best platform to build an agent with no code? A no-code builder or a workflow automation tool, and that's a legitimate answer, not a lesser one. Check first that the approval and audit requirements from question two above are satisfiable — that's where no-code tools usually stop, and discovering it late is expensive.

What's the best AI agent for a small business? Usually a bought product rather than a built agent. If nobody picks up the phone or nobody follows up on leads, that's a staffing-shaped problem with off-the-shelf answers — our own Loquent (getloquent.com) is one, and it's now taking pilot businesses. Build custom when the workflow is your competitive advantage.

How much does it cost, and how long does it take? Honest ranges are wide because scope varies enormously, so treat any single figure you read as marketing. The durable advice: the build is a fraction of the lifetime cost. Evaluation, monitoring and the slow drift of prompts and models dominate, and most published cost estimates ignore all three.

How hard is it to build one from scratch? A working single-tool agent is a day for a competent engineer. A reliable one is months, and the gap is almost entirely error handling, evaluation and observability rather than agent logic. That gap is why platforms exist and also why they don't remove the work.

If you're weighing a custom build against a platform, how we work sets out how we scope these, and how to evaluate an AI development studio covers what to ask whoever you hire — including us.

Originally published at autor.ca.

Building PHIPA-Compliant AI Agents for Canadian Clinics

Autor Technologies Inc. — Wed, 04 Nov 2026 17:19:03 +0000

The guidance you are reading is probably American

Search for how to build compliant healthcare AI and almost everything you find is written for HIPAA. We know, because we published a version of that article ourselves and left it up for six months. It described Business Associate Agreements, a 60-day breach clock, and a six-year log retention rule — none of which is Canadian law.

If you run a clinic in Ontario, HIPAA does not apply to you. PHIPA does. It is structured differently in ways that change the architecture, not just the paperwork.

This is what we learned building Loquent, our AI voice platform, for Canadian dental and medical clinics. It is not legal advice — we build software, we are not a law firm, and you should have a privacy lawyer review anything that touches patient data before it goes live.

What actually applies in Canada

There is no single national health privacy law. What applies depends on where the clinic is and what kind of data is involved.

Law	Where	What it governs
PHIPA	Ontario	Personal health information held by health information custodians
PIPEDA	Federal	Commercial handling of personal information, where no substantially similar provincial law applies
Law 25	Quebec	Personal information, with its own consent and transfer-assessment rules
PIPA	BC, Alberta	Personal information in the private sector
HIA	Alberta	Health information specifically
PHIA	Manitoba, Nova Scotia, NL, NB	Provincial health information statutes

For a Toronto clinic, the working answer is PHIPA plus PIPEDA. For a clinic in Montreal, add Law 25 and its rules on transfers outside Quebec. A vendor who only says "HIPAA compliant" has not thought about any of this.

Three differences that change how you build

1. There is no BAA. There is a written ESP agreement, and its contents are specified.

The HIPAA world runs on Business Associate Agreements. Canada does not have those. Under PHIPA's regulation, a custodian using an electronic service provider to handle personal health information needs a written agreement with that provider — and the regulation sets out what it has to cover: the permitted uses of the information, the provider's security obligations, breach notification procedures, what happens to the data when the contract ends, and the custodian's right to audit.

That last one is the item most AI vendors are not ready for. If a clinic has a contractual right to audit your handling of their patient data, your system needs to be able to answer an audit. That is an architecture requirement, not a legal one, and it has to exist before you sign.

The accountability point matters too: the custodian stays accountable for the information even when a service provider is handling it. You are not taking liability off their hands by being good at security. You are helping them discharge a duty that remains theirs.

2. There is no 60-day breach clock. There is "first reasonable opportunity" — and an annual report.

HIPAA gives you 60 days to notify. PHIPA does not set a day count at all. The standard is notification to the affected individual at the first reasonable opportunity, and Ontario's Information and Privacy Commissioner has made clear through its decisions that delays measured in months are not acceptable. Vaguer, and in practice tighter.

Custodians must also notify the IPC directly in defined circumstances. And there is a requirement with no HIPAA equivalent at all: health information custodians must file annual breach statistics with the IPC by March 1 covering the previous calendar year.

For an AI system, that has a concrete consequence. Your logging has to support a count — how many incidents, of what type, affecting how many individuals — produced on a fixed annual deadline, not reconstructed by hand in February. If your audit trail cannot answer that question quickly, you have built a system your customer cannot report from.

3. PHIPA does not mandate Canadian data residency. Everyone acts like it does.

This is the one most often stated wrongly, in both directions. PHIPA contains no explicit prohibition on storing personal health information outside Canada. Vendors claiming residency is legally required are overstating it.

But the accountability obligation does not travel. The custodian remains responsible wherever the data sits, which means cross-border storage adds a due-diligence burden, a lawful-access exposure, and paperwork that Canadian storage simply removes. Quebec's Law 25 goes further and requires an assessment before transferring personal information outside the province.

So: not a legal mandate, a very strong practical default. We keep Loquent's data in Canada because the alternative means explaining foreign lawful-access regimes to every clinic that asks, and they all ask.

The LLM provider question, asked correctly

In the HIPAA framing the question is "does this provider sign a BAA?" That question does not map cleanly onto Canadian law. The questions that actually matter:

Where does inference physically run? Not where the company is headquartered — where the request is processed. Canadian or Canada-available regions exist on the major clouds; the default region usually is not one.
Is there a written data processing agreement covering the items PHIPA's regulation requires, including deletion at contract end and a right to audit?
Is there a contractual commitment not to train on your data, and does it cover the specific tier and endpoint you are using rather than the enterprise plan you are not on?
What is the retention period on the provider's side, including abuse-monitoring copies that are often retained separately from your account data?
Is audio treated differently from text? For a voice agent this is the one people miss. Transcription frequently happens on a different service, in a different region, under a different retention policy than the language model. Two of the vendors we surveyed for our AI receptionist comparison publish a residency claim that covers storage but says nothing about where processing occurs.

Architecture that holds up

Most of the technical practice is the same as it would be under any regime. It is the emphasis that shifts.

Map the data flow before writing code. Every place personal health information travels, is processed, and comes to rest. For a voice agent:

Patient call
    ↓
[Telephony]        — encrypted, written agreement, Canadian region
    ↓
[Speech-to-text]   — check the region separately, it is often not the same
    ↓
[Agent logic]      — minimal PHI in prompts, no training on patient data
    ↓
[Action layer]     — writes to the PMS or EMR over an authenticated API
    ↓
[Audit trail]      — every access, queryable, retained to the custodian's schedule

Doing this exercise honestly surfaces most compliance gaps before they cost anything.

Send the model as little as possible. "Patient #12345 wants to reschedule Thursday" carries the same instruction as a full name and date of birth, and far less risk. Use identifiers, resolve them in your own database, and let function calling do the work against records the model never sees.

Encrypt in transit and at rest. TLS 1.2 or better, AES-256 at rest. Unremarkable, and still worth verifying rather than assuming.

Scope access properly. Role-based access, service accounts holding the minimum permission that works, credential rotation, MFA on any human-facing dashboard.

Build the audit trail as a product feature, not a log file. Who accessed what, when, what action followed, retained on the custodian's schedule rather than yours — retention periods come from provincial law and professional college requirements, and they vary, so the system has to be configurable rather than hardcoded to a number you read in an American article. Keep personal health information out of general application logs entirely.

Tell patients they are talking to an AI. Disclosure has never cost us a deployment. Patients care that the phone gets answered.

Canadian EMR and PMS integration

An AI agent that cannot write into the system the clinic actually runs is a demo. The systems that come up in Canadian practice:

Oscar Pro, Juno, Accuro, TELUS PS Suite, Med Access — medical
Curve Dental, Dentrix, ClearDent, AbelDent, Tracker, Open Dental — dental
Jane App — allied health, and increasingly dental

Requirements are the boring ones: authenticated APIs with rotating credentials, validation at every boundary, sensible behaviour when the upstream system is down, and a defined answer for what happens when a record changes while the agent is mid-conversation.

Ask any vendor whether their integration writes appointments or only reads availability. The gap between those two is most of the value, and marketing language rarely distinguishes them.

Before it goes live

Written agreement with every service provider touching personal health information, covering permitted use, security, breach notification, end-of-contract deletion, and audit rights
Data residency decided deliberately, and documented — including where audio is processed, not just stored
Personal health information encrypted at rest and in transit
Role-based access, minimum-permission service accounts, MFA on dashboards
Audit trail that can produce an incident count for the March 1 IPC filing
Personal health information minimised in model prompts, and a no-training commitment in writing
Retention and disposal configurable to the custodian's schedule
Breach response plan written down, with "first reasonable opportunity" as the standard
Patient-facing AI disclosure
Escalation path to a human, and a measured rate for how often it fires

What we got wrong

We shipped Loquent to production in under eight weeks and it now handles thousands of clinic calls a month. The compliance work was not the hard part. Getting the framing right was.

The article this one replaces was written to HIPAA because that is what the available material described, and it sat on our site describing American law to Canadian clinics for six months. Meanwhile every Canadian competitor that started outranking us on healthcare queries led with PHIPA and PIPEDA by name. That was not a coincidence and it was not sophisticated — they simply named the statute their customers are actually subject to.

If you are building healthcare AI in Canada, the useful version of the lesson is narrower than "compliance is an architecture decision," true as that is. It is: the jurisdiction you write for is itself an architecture decision. Choose it before you choose a cloud region, and definitely before you write the marketing.

We publish what thirteen Canadian voice AI vendors say about PHIPA, PIPEDA and data residency, including where we come off worse than they do, in our AI receptionist comparison for Canadian clinics.

Building something similar? Tell us what you are working on.

Originally published at autor.ca.

4 Months of vox-bench in Production — What 14,000 Benchmark Runs Taught Us About Voice AI Latency

Autor Technologies Inc. — Thu, 24 Sep 2026 22:32:52 +0000

In June, we open-sourced vox-bench, the latency benchmarking tool we built after a TTS spike caused 12% of Loquent callers to talk over our AI mid-response. Four months and 14,000 automated benchmark runs later, we have data on voice AI provider latency that nobody else is publishing — and some of our original assumptions were wrong.

Quick context if you missed the original release

Loquent is our production voice AI platform. It handles thousands of automated phone calls per month for healthcare and dental clients across Canada — appointment booking, patient intake, after-hours triage. The pipeline is Twilio (media stream) → Deepgram (STT) → Anthropic Claude (LLM) → ElevenLabs (TTS) → Twilio (audio back).

We built vox-bench because we needed per-stage, per-percentile latency tracking with regression detection. It runs as a TypeScript CLI, benchmarks each pipeline stage independently and in combination, and fires alerts when p95 latency at any stage crosses your configured threshold. We've been running it via GitHub Actions every 6 hours since May.

The tool is at github.com/Autor-Technologies/vox-bench. This article is about what the data told us.

Assumption #1 we got wrong: TTS is NOT the most variable stage anymore

When we released vox-bench in June, our data clearly showed TTS as the most unpredictable pipeline stage. ElevenLabs had a p99/p50 ratio of 2.69x — meaning the worst 1% of requests took nearly three times longer than the median. We built our alerting thresholds around that assumption.

Four months later, the picture has shifted. Here's the p99/p50 variability ratio across our current stack, aggregated from 14,000 runs:

Deepgram Nova-3 STT: 1.72x (was 1.72x in June — rock solid, no change)
Anthropic Claude Haiku LLM: 2.85x (was 2.29x in June — got MORE variable)
ElevenLabs Turbo v2.5 TTS: 1.92x (was 2.69x — significantly improved)

The LLM layer is now our most variable stage. Not because Claude got worse — the median actually dropped from 210ms to 185ms TTFB over the same period. But the tail got fatter. Our p99 went from 480ms to 525ms. We think this correlates with model updates that improved average performance but introduced more variance under load.

ElevenLabs, meanwhile, quietly got much more consistent. Their Turbo v2.5 release in July cut our p99 from 350ms to 255ms and the time-of-day pattern we reported in June (2-4pm ET spikes) mostly disappeared. Credit where it's due — their infrastructure team clearly addressed capacity issues.

The takeaway: don't set your alerting thresholds once and forget them. Provider performance characteristics change faster than you think. We now re-baseline our vox-bench thresholds monthly.

The 680ms wall

After 14,000 runs and correlating benchmark data with actual Loquent call logs, we've identified what we internally call "the 680ms wall." Here's what it is.

When total pipeline round-trip (caller stops speaking → AI audio starts playing) stays below 680ms, our call completion rate is 94%. The caller doesn't notice the delay. Conversations flow. When we cross 680ms, completion drops to 87%. Cross 1,100ms and it falls to 71%.

These aren't theoretical benchmarks. This is from 8 months of production call data across 40,000+ calls, correlated with the per-call latency measurements vox-bench introduced.

What surprised us: the drop isn't linear. There's a genuine cliff between 680ms and 700ms. Below the wall, callers behave normally. Above it, they start exhibiting what we call "confirmation seeking" — saying "hello?" or repeating their last sentence. Once a caller enters that mode, the rest of the call degrades even if subsequent responses are fast. The caller has lost trust in the AI's responsiveness.

We published our original article saying the threshold was 800ms. We were wrong. It's lower, and the penalty for crossing it is harsher than we expected.

Provider changes we made based on the data

vox-bench includes a provider comparison mode — run the same benchmark workload against multiple providers simultaneously. We've been using it continuously to evaluate alternatives. Three changes we made:

STT: Stayed with Deepgram Nova-3. We evaluated OpenAI Whisper (API) and Google Cloud Speech-to-Text v2 as alternatives. Whisper's accuracy on medical terminology was 3-4% better than Deepgram, but its p50 latency was 340ms versus Deepgram's 175ms. That 165ms difference eats almost our entire latency budget at the STT stage. Google was competitive on latency (195ms p50) but struggled with Canadian English accents — our word error rate was 18% higher on calls from patients in Quebec and Atlantic Canada.

LLM: Added a fast-path for simple responses. vox-bench data showed that 62% of our LLM calls were for straightforward responses — confirming appointment times, reading back addresses, answering "what are your hours?" These don't need Claude's full reasoning. We added a response cache and a classifier that routes simple queries to cached templates, hitting the LLM only for complex or contextual responses. Result: those 62% of responses now have 0ms LLM latency. Our blended p50 total pipeline time dropped from 620ms to 410ms.

TTS: Tested but didn't switch from ElevenLabs. We benchmarked Google Cloud TTS, Amazon Polly, and OpenAI TTS. Google had the lowest latency (90ms p50 vs ElevenLabs' 125ms), but every provider we tested had an uncanny quality gap compared to ElevenLabs on healthcare vocabulary. Pronouncing medication names, clinic addresses, and doctor names correctly matters when your caller is a patient. ElevenLabs' custom pronunciation dictionary handles this better than any alternative we tested.

The data pattern nobody warned us about

Here's something we didn't expect to find in four months of continuous benchmarking: provider latency is seasonal. Not in the weather sense — in the tech industry calendar sense.

We have 14,000 data points across May through September. The trend is clear:

Late June through July: All three providers (Deepgram, Claude, ElevenLabs) showed 10-15% lower latency than their April-May baselines. Our theory: lighter API traffic during summer.
Early September: Latency climbed 20% above baseline across the board. Every provider, simultaneously. This coincided with the post-Labor Day tech industry return-to-work surge.
Tuesday through Thursday consistently runs 8-12% slower than weekends across all providers.

If you're benchmarking voice AI providers and running your evaluation on a Saturday afternoon, you're getting a misleadingly optimistic picture. Benchmark during peak hours (Tuesday-Thursday, 10am-3pm ET) or your production experience will be worse than your evaluation predicted.

We've added time-of-week bucketing to vox-bench's reporting to surface this automatically.

What 47 GitHub issues taught us about other people's voice AI stacks

Since open-sourcing vox-bench, we've had contributions from teams building voice AI across different domains — customer service, real estate, legal intake, restaurant ordering. Their benchmark data (shared voluntarily via issues and PRs) revealed patterns we wouldn't have seen from healthcare alone:

Restaurant and retail voice AI runs 25-30% faster end-to-end than healthcare. The vocabulary is simpler, utterances are shorter ("I'd like to order a large pepperoni pizza" vs. "I need to reschedule my appointment with Dr. Krishnamurthy for my follow-up on the blood work from last Tuesday"), and there's less ambiguity for the LLM to resolve. If you're reading voice AI latency benchmarks from a non-healthcare context, discount them for medical applications.

The STT bottleneck shifts by language. Two contributors benchmarking Spanish-language voice AI found that Deepgram's Spanish model runs 40% slower than English Nova-3 on equivalent utterance lengths. One switched to a self-hosted Whisper model and got better latency AND accuracy for Spanish. We added multi-language benchmark profiles to vox-bench based on their work.

WebSocket connection reuse matters more than we realized. A contributor profiling their pipeline found that 180ms of their "STT latency" was actually WebSocket connection establishment — they were opening a new connection per utterance instead of keeping a persistent stream. vox-bench now measures connection overhead separately from processing time.

Updated numbers: September 2026 production stack

For anyone comparing their own pipeline, here are our current production numbers from vox-bench, benchmarked Tuesday-Thursday 10am-3pm ET (worst-case real-world conditions):

Stage	p50	p95	p99
Deepgram Nova-3 STT	175ms	240ms	300ms
Claude Haiku LLM (complex)	185ms	355ms	525ms
Response cache (simple)	<1ms	<1ms	<1ms
ElevenLabs Turbo v2.5 TTS	125ms	195ms	255ms
Total (complex path)	580ms	870ms	1,090ms
Total (cached path)	365ms	510ms	630ms
Blended (62% cached)	410ms	645ms	800ms

Our blended p50 is now comfortably below the 680ms wall. The complex path p95 still crosses it, which means roughly 5% of complex-response calls have a noticeable delay. We're okay with that — pushing it lower would require sacrificing response quality, and our completion rate data shows 5% above the wall is an acceptable tradeoff.

Key findings after 4 months

Re-baseline your latency thresholds monthly. Provider performance characteristics change with model updates, infrastructure changes, and traffic patterns. The thresholds you set in month one will be wrong by month three.
The conversational latency wall is 680ms, not 800ms. Our original estimate was too generous. Below 680ms, callers don't notice. Above it, call quality degrades non-linearly.
Cache simple responses aggressively. 62% of our voice AI calls don't need LLM inference at all. A response cache with a lightweight classifier cut our blended latency by 34%.
Benchmark during peak hours or your data is lying. Tuesday-Thursday, 10am-3pm gives you realistic production numbers. Weekend benchmarks are 15-20% more optimistic than what your users will experience.
Provider variability shifts over time. TTS was our most variable stage in June. Four months later, it's the LLM. Continuous benchmarking catches these shifts before your callers do.

What's next for vox-bench

We're working on two additions for the next release. First, a Grafana dashboard template that visualizes vox-bench data over time — right now you have to build your own or use the JSON/Markdown output. Second, a "latency budget calculator" that takes your target total round-trip time and suggests per-stage allocations based on current provider performance data.

vox-bench is at github.com/Autor-Technologies/vox-bench. If you're running it against your own stack, we'd genuinely like to see your numbers — open an issue or PR with anonymized benchmark data and we'll incorporate it into the cross-domain analysis.

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

The AI receptionist market is solving the wrong problem

Autor Technologies Inc. — Tue, 08 Sep 2026 03:13:58 +0000

Every AI voice startup in healthcare is demoing the same thing: "Listen to how natural it sounds!" Meanwhile, the clinic office manager who actually has to use the product is asking a completely different question — and nobody's answering it.

We've been running Loquent, our production voice AI platform, across dental and healthcare clinics for over a year now. Thousands of automated calls every month, 24/7, handling everything from appointment scheduling to insurance verification. And the single biggest lesson we've learned has nothing to do with how the AI sounds.

The Demo That Wins Deals vs. The Product That Keeps Them

Here's a pattern we see constantly in the healthcare AI voice space: a startup builds an impressive demo. The AI sounds warm, conversational, almost indistinguishable from a real person. The founder posts a clip on LinkedIn, it goes viral, inbound explodes.

Then the product lands in an actual dental practice.

Within the first week, the office manager discovers that the AI can't check whether a patient's insurance is active in their practice management system. It can book an appointment, sure — but it creates a separate record that someone has to manually reconcile with Curve Dental or Dentrix or Open Dental at the end of the day. The AI sounds great on the phone, but it's creating more work, not less.

We know this because we built the wrong version of Loquent first. Our initial prototype had impressive voice quality. We spent weeks fine-tuning prosody, adding natural pauses, getting the pacing right. Our first pilot clinic was genuinely impressed — for about three days. Then the office manager called and said, "This thing is booking patients into slots that are already taken in our system."

That was the moment we realized we were solving the wrong problem.

What Clinics Actually Buy

After running Loquent across multiple practices and analyzing the patterns in thousands of calls, here's what we've found: clinics don't buy voice quality. They buy workflow integration.

The actual purchase decision comes down to three questions, and none of them are about how human the AI sounds:

"Does it talk to my PMS?" Every dental practice runs on a practice management system — Curve Dental, Dentrix, Open Dental, Eaglesoft, and a dozen others. If the AI can't read real-time availability from that system and write bookings back into it, the product is a toy. Not a "good start." Not an "MVP." A toy. Because someone still has to sit there and manually enter every appointment the AI books.

We spent more engineering time building PMS integrations than we spent on any other part of Loquent. Curve Dental alone took us three weeks of back-and-forth on API access, data mapping, and edge cases like provider schedules that change mid-week. It's unglamorous work. Nobody posts a video of "look at our Dentrix integration" on LinkedIn. But it's the thing that makes the product actually usable.

"Does it handle our compliance requirements?" In Canada, healthcare data falls under PHIPA — the Personal Health Information Protection Act. This isn't just "use encryption and you're fine." It governs where data is stored, who can access it, how consent is obtained, and what happens when a patient asks for their records. Most AI voice startups we see are building with US infrastructure, US-hosted models, and US-centric compliance (HIPAA). Then they try to sell into Canadian clinics and discover that PHIPA has requirements HIPAA doesn't — like the requirement that personal health information stays within Canada unless the patient explicitly consents to cross-border transfer.

We built Loquent from day one for PHIPA compliance. Canadian-hosted infrastructure. Canadian data residency. Consent workflows built into the call flow, not bolted on after. This wasn't a feature. It was a prerequisite. And it's the single most common gap we see when Canadian clinics evaluate competitors.

"What happens when it can't handle a call?" This is the question that separates production voice AI from demos. Every AI receptionist will encounter calls it can't handle — a patient who's upset, a complex insurance question, a medical emergency. What matters is how gracefully it fails.

In our data, about 15-20% of calls need human escalation. That number hasn't budged much regardless of how sophisticated the AI gets. The important thing isn't reducing that number to zero — it's making sure those transfers happen seamlessly. The patient shouldn't have to repeat themselves. The human who picks up should have full context. The handoff should feel like one continuous conversation, not a cold transfer to a confused receptionist.

We built Loquent's escalation system before we built its conversational AI. That's not a typo. We designed the failure mode first, then built the happy path around it.

Why "Human-Sounding" Is a Distraction

I'm not saying voice quality doesn't matter at all. Obviously, a robotic monotone isn't going to work. But there's a threshold of "good enough" that modern TTS models crossed about two years ago. ElevenLabs, Deepgram, Play.ht — they all produce perfectly adequate voice quality for a professional phone interaction. Spending engineering cycles on making the voice 5% more natural is optimizing the wrong variable.

Here's what we've actually observed: patients don't care whether the AI sounds human. They care whether it solves their problem. A patient calling to reschedule an appointment at 9pm on a Sunday doesn't need the AI to crack a joke or use conversational fillers. They need it to find an open slot that works, confirm it, and send a reminder. If it does that in a slightly robotic voice, they're fine. If it sounds perfectly human but can't actually see the dentist's schedule, they're furious.

The startup landscape right now is full of companies raising millions on voice demos. Their pitch decks are full of "indistinguishable from human" claims and TTS benchmarks. Their integration page says "coming soon" next to every PMS system. They have beautiful landing pages and zero production deployments handling real patient data under real compliance requirements.

Meanwhile, the companies that will actually survive in this space are the ones doing the boring work: building PMS connectors, navigating provincial privacy regulations, designing escalation workflows, and handling the thousand edge cases that only show up in production.

The Market Is About to Correct

There are now dozens of AI receptionist startups targeting dental and healthcare in Canada alone. New ones pop up every month. Most of them will be gone within 18 months, and it won't be because their AI wasn't good enough. It'll be because they couldn't answer the three questions above.

The clinics that adopted early are already starting to churn from the "sounds great, integrates with nothing" products. They're moving to solutions that actually connect to their existing systems and handle their actual compliance requirements. This is the correction that's coming, and it's going to be brutal for startups that spent their runway on voice quality instead of plumbing.

Key Takeaways

Integration beats voice quality every time. The single highest-value engineering investment is PMS integration. If your AI can't read and write to the clinic's existing system, you don't have a product — you have a demo.
Compliance is a prerequisite, not a feature. In Canada, PHIPA compliance means Canadian data residency, explicit consent workflows, and provincial-level privacy controls. "We're HIPAA compliant" doesn't cut it north of the border.
Design the failure mode first. 15-20% of calls will need human escalation regardless of AI quality. Build seamless handoffs before you optimize the happy path.
"Good enough" voice quality already exists. Modern TTS crossed the usability threshold years ago. Stop optimizing the 95th percentile of naturalness and start optimizing the 0th percentile of integration coverage.
The market correction is coming. The startups that survive will be the ones that did the boring work — PMS connectors, compliance infrastructure, escalation design. The ones with the best demos will be the ones that shut down.

If you're building something similar — or evaluating AI voice solutions for your practice — we'd love to hear about it. Reach out at hello@autor.ca or visit autor.ca.

I Built 50+ AI Products in 4 Years — Here's What I Wish I Knew at the Start

Autor Technologies Inc. — Tue, 01 Sep 2026 03:30:16 +0000

Since 2021, our team at Autor has shipped over 50 AI products across healthcare, fintech, logistics, and SaaS. Some of them are running in production right now, handling thousands of automated calls per month. Others failed spectacularly — and those are the ones that taught us the most.

Where This Comes From

I started Autor in Toronto as a one-person AI development shop. The original thesis was simple: companies needed custom AI but couldn't hire fast enough to build it themselves. Four years and 50+ products later, we're a senior-only studio with a production voice AI platform (Loquent) serving healthcare and dental clients 24/7. Along the way, we've impacted over 5 million users, helped clients raise more than $10 million in funding, and shipped across 10+ countries.

This isn't a highlight reel. This is the unvarnished list of things I got wrong, figured out the hard way, or wish someone had told me before I wrote my first line of production AI code.

1. Your First AI Product Should Be Boring

Our first few products were ambitious. Multi-modal pipelines, complex reasoning chains, novel architectures. Most of them took twice as long as estimated and required constant babysitting in production.

The products that actually made money and kept clients happy? A straightforward document classifier. A simple intent router. A basic FAQ bot with good fallback logic.

I used to think "boring" meant "not innovative." Now I know boring means "reliable enough that I don't get paged at 3am." Our most successful product, Loquent, handles healthcare scheduling calls. It's not doing anything architecturally exotic. It picks up the phone, understands what the caller needs, books or reschedules an appointment, and hangs up. The magic isn't in the model — it's in the 200+ edge cases we've handled around it.

If you're building your first AI product, pick the most boring version of your idea and ship that. You can add complexity later. You cannot add reliability later.

2. Prompt Engineering Is Real Engineering

Early on, I treated prompts like configuration — something you'd tweak until it worked, then move on. That was a $40,000 mistake across three client projects.

Prompts in production need version control, testing, rollback plans, and monitoring. We learned this when a Claude model update changed how our voice AI interpreted scheduling instructions. Calls that used to resolve correctly started booking appointments on wrong days. The model hadn't broken — our prompts were too tightly coupled to specific model behaviors instead of being robust against model variations.

Today, every prompt at Autor goes through the same review process as application code. We maintain prompt test suites with 50+ test cases per critical path. When we onboard a new healthcare client, we run their specific terminology through our prompt regression suite before going live.

The companies that treat prompt engineering as "just writing" are the ones calling us at midnight asking why their AI started hallucinating appointment times.

3. The Model Is 20% of Your Production System

This is the hardest lesson for technical founders to internalize. When I started, I spent 80% of my time on model selection, fine-tuning, and evaluation. That ratio was exactly backwards.

In a production AI system, the model is a component. The other 80% is:

Monitoring and observability — knowing when something goes wrong before your users tell you. We log every Loquent call: latency per turn, confidence scores, fallback triggers, transfer reasons. That's how we discovered that 18% of calls were being transferred to humans and could systematically fix the common failure patterns.

Integration plumbing — connecting to Twilio for telephony, to clinic management systems for real-time appointment data, to HubSpot and Salesforce for CRM updates. Each integration has its own failure modes, retry logic, and authentication quirks.

Edge case handling — what happens when the caller speaks a language the system wasn't configured for? When the clinic's API is down? When someone calls to report a medical emergency? These aren't model problems. They're systems engineering problems.

Deployment infrastructure — zero-downtime deployments, canary releases, A/B testing different prompt versions. We use Docker on AWS, and the CI/CD pipeline for Loquent is more complex than the AI logic itself.

If you're spending more than 20% of your time on the model, you're probably not ready for production.

4. Ship Weekly or You'll Ship Never

At product number 15 or so, I noticed a pattern. Projects with two-week sprint cycles shipped. Projects with "we'll ship when it's ready" timelines didn't.

The reason is subtle. AI systems have a special failure mode where you can always make them "a little better." Run one more evaluation. Try one more prompt variant. Fine-tune on one more dataset. Each improvement is real but marginal, and the compound effect is that you never ship.

We now enforce a hard rule at Autor: something goes to a real user every week. Not a demo. Not a staging environment. A real user, using it for a real task. Loquent was built in 8 weeks, and it was talking to real callers by week 3. Those early calls were rough — the AI mispronounced the clinic name, got confused by call-waiting beeps, and once tried to book an appointment at 2am. But each of those failures generated specific, actionable fixes that no amount of internal testing would have caught.

The team that ships a mediocre v1 in week 3 will have a solid v4 by week 12. The team perfecting their v1 will still be in staging.

5. Charge What Production AI Actually Costs

Our first three clients got significant discounts because I was terrified of sticker shock. The result: we couldn't afford to invest in proper monitoring, the systems degraded, and two of those three clients churned anyway.

Production AI isn't a commodity. The model API costs are the smallest line item. The real costs are: senior engineers maintaining the system (we're a senior-only team for a reason), infrastructure running 24/7, ongoing prompt optimization as models update, and being available when something breaks at 3am on a Saturday.

We charge $150/hour and we're transparent about why. A junior team charging $60/hour will cost you more in the long run because they'll build something that works in the demo and breaks in production. We know because we've been hired to replace those systems more than once.

The clients who balk at $150/hour aren't our clients. The ones who've had a production AI fail on them understand exactly why it costs what it does.

6. Pick Your Stack and Commit

Over 50 products, we've tried almost everything. LangChain, LlamaIndex, raw API calls, various vector databases, different embedding models, multiple TTS and STT providers. Here's what we actually use in production today:

OpenAI and Anthropic Claude for language models — we run both because each has strengths for different use cases. Deepgram for speech-to-text because their latency is unmatched for real-time voice. ElevenLabs for text-to-speech. Twilio for telephony. Pinecone for vector search when we need it (which is less often than you'd think — RAG is genuinely overkill for most voice AI). PostgreSQL with Prisma, not some exotic vector-native database. Next.js and NestJS for the application layers. AWS and Docker for infrastructure.

We stopped experimenting with our production stack around product number 30. Every new tool has a learning curve, integration cost, and risk of undiscovered failure modes. The marginal improvement from switching to the latest vector database isn't worth the three weeks of integration work and six months of discovering its production quirks.

Pick tools that are boring, well-documented, and have active communities. Your future self will thank you.

Key Takeaways

Start boring, add complexity later. The most successful AI products solve mundane problems reliably. Pick the simplest version of your idea and ship it.
Treat prompts as production code. Version control, test suites, regression testing, and monitoring. Prompts are not configuration — they're the core logic of your system.
Spend 80% of your time on everything except the model. Monitoring, integrations, edge cases, and deployment infrastructure are where production AI lives or dies.
Enforce weekly shipping to real users. AI projects have a unique "just a little better" trap. The antidote is putting imperfect work in front of real users every week.
Charge what production AI costs, and be transparent about it. Underpricing leads to underinvestment, degradation, and churn. The clients who understand this are the ones worth keeping.

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

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.