Forem: Autor Technologies Inc.

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

Autor Technologies Inc. — Mon, 27 Apr 2026 14:16:58 +0000

Eight weeks. That's how long it took our team at Autor to go from "we should build a voice AI receptionist for healthcare clinics" to handling live patient calls 24/7. Not a demo. Not a proof of concept. A production system that now processes thousands of automated calls per month for dental and healthcare clients across Canada. Here's every technical and business decision we made along the way, and the reasoning behind each one.

The Starting Point

A dental clinic in Ontario came to us with a problem we'd heard a dozen times: they were losing patients because nobody answered the phone after hours. Their staff spent 3+ hours per day on calls that followed the same script — confirming appointments, answering insurance questions, routing urgent calls. They wanted automation, but every off-the-shelf solution they'd tried sounded robotic and confused patients.

We'd already built 40+ AI products at that point. We knew the gap between a voice AI demo and a voice AI that handles real calls from real patients who are sometimes anxious, sometimes angry, and sometimes just confused. We scoped 8 weeks and got to work.

Week 1–2: Choosing the Voice Stack

The first decision was the hardest: which speech-to-text and text-to-speech providers to use. We benchmarked four STT options and three TTS options over two weeks.

Speech-to-text: Deepgram won. We tested Deepgram, Google Cloud Speech, AWS Transcribe, and Whisper (self-hosted). Deepgram gave us the best combination of latency and accuracy for Canadian English with diverse accents. Our benchmarks showed Deepgram averaged 180ms first-byte latency versus 320ms for Google Cloud Speech. For a phone conversation, that 140ms difference is the gap between natural and awkward. Whisper was the most accurate but unusable for real-time — even on a GPU instance, streaming latency was 400ms+.

Text-to-speech: ElevenLabs. We needed a voice that didn't trigger the "I'm talking to a robot" response. ElevenLabs' Turbo v2 model gave us near-human quality at 150ms latency. We tested with 30 real patients in a blind study — 22 of them didn't realize they were talking to AI until we told them.

Telephony: Twilio. This wasn't a hard choice. Twilio's Media Streams API gave us bidirectional audio streaming over WebSocket. We'd used it before, understood the edge cases, and knew the Canadian number provisioning was solid. We briefly considered Vonage but their WebSocket implementation had reliability issues in our testing.

Week 3–4: The Brain — Why We Chose Anthropic Claude Over GPT-4

This is where it gets interesting. We needed a language model that could handle the core conversation logic — understanding patient intent, managing appointment scheduling, handling insurance questions, and knowing when to transfer to a human.

We ran both GPT-4 and Anthropic Claude through 200 simulated patient conversations. The results surprised us.

Claude was better at saying "I don't know." In healthcare, making something up is worse than admitting uncertainty. When we threw edge cases at both models — rare insurance scenarios, questions about specific procedures the clinic didn't offer — GPT-4 was more likely to confabulate a plausible-sounding answer. Claude was more likely to say it wasn't sure and offer to connect the patient with staff. For a healthcare application, that behavior is worth its weight in gold.

Claude's instruction-following was more consistent. We needed the model to stay strictly within its role as a receptionist. No medical advice, ever. No promises about pricing without checking the database. After prompt engineering both models for a week, Claude held its boundaries more reliably across 1,000+ test conversations.

We built the conversation engine on Claude with structured tool use. The model calls functions to check appointment availability, look up patient records, and route calls — all through a clean tool-use interface rather than string parsing.

Week 5: The Integration Layer

Week 5 was all plumbing. We built the integration layer that connects the voice AI to the clinic's actual systems.

Architecture: NestJS backend on AWS ECS. We chose NestJS because our team thinks in TypeScript and NestJS gives us dependency injection and module structure without the bloat. The service runs on ECS Fargate — we didn't want to manage servers, and Fargate's auto-scaling handles call volume spikes at 9am when every patient calls at once.

Database: PostgreSQL with Prisma ORM. Every call gets logged — full transcript, intent classification, actions taken, duration, and outcome. This data is what makes the system get better over time. We chose Prisma because the type safety between our TypeScript code and the database eliminated an entire class of bugs we'd dealt with in past projects using raw SQL.

CRM integration: HubSpot and Salesforce. Most clinics use one or the other. We built adapters for both so the AI receptionist can pull patient history and push call summaries. The HubSpot integration took 3 days. Salesforce took 8. If you've worked with the Salesforce API, you know why.

Week 6: Latency Optimization — The Make-or-Break Week

Week 6 nearly broke us. Our end-to-end latency — from when the patient stops speaking to when the AI starts responding — was averaging 2.1 seconds. That's unacceptable for a phone conversation. Anything over 1.2 seconds and callers start saying "hello?" again.

Here's what we did to get it under 800ms:

Streaming everything. We switched from waiting for complete STT transcription to streaming partial results. As soon as Deepgram gives us a stable partial transcript, we start sending it to Claude. Claude streams its response back, and we start TTS on the first sentence while Claude is still generating the rest. This pipelining cut 600ms off the round trip.

Prompt caching. Claude's prompt caching feature was a massive win. Our system prompt is about 2,000 tokens — clinic-specific information, conversation rules, available tools. With prompt caching, that system prompt gets processed once and reused across turns. This alone saved 200-300ms per turn.

Connection pooling and keep-alive. We keep persistent WebSocket connections to Twilio, persistent HTTP/2 connections to Claude's API, and persistent connections to Deepgram. Cold-starting any of these adds 100-200ms.

After a week of optimization, we hit a median response time of 740ms. The 95th percentile was 1.1 seconds. Patients stopped noticing the delay.

Week 7: Edge Cases and Failure Modes

We spent all of week 7 on what happens when things go wrong. This is the week that separates a demo from a product.

What if the patient speaks a language the AI doesn't handle? We built language detection into the first 3 seconds of the call. If we detect French, Mandarin, or Cantonese (the three most common non-English languages for our Ontario clinics), we route immediately to a human or play a pre-recorded message in that language.

What if the AI gets confused? We built a confidence scoring system. If Claude's response confidence drops below our threshold for two consecutive turns, the system says "Let me connect you with our team" and transfers the call. No patient should ever be stuck in a loop with a confused AI.

What if Deepgram or Claude goes down? Circuit breakers on every external dependency. If STT fails, we fall back to a DTMF menu ("press 1 for appointments"). If the LLM fails, we route to voicemail with a text notification to staff. We tested every failure mode by literally killing services in production during low-traffic hours.

What about PIPEDA compliance? This is Canada — we have to handle patient data under PIPEDA, not HIPAA. All call recordings are encrypted at rest and in transit. Transcripts are stored in Canadian data centers. We built a data retention policy that auto-deletes recordings after the clinic's specified retention period. We worked with a privacy consultant to ensure our consent flow at the start of each call met PIPEDA requirements.

Week 8: Launch and the First 1,000 Calls

We launched on a Thursday at 5pm — right when the clinic closed. The AI receptionist would handle all after-hours calls for the weekend as a soft launch.

The first weekend: 127 calls. 89 handled completely by AI. 24 transferred to the on-call number (correctly — these were urgent or complex). 14 hung up before the AI could help. That's a 70% full-automation rate on day one.

Within the first month, the automation rate climbed to 82% as we tuned prompts based on real call data. The clinic saved an estimated 45 staff-hours per month. More importantly, they stopped losing after-hours patients to competitors who answered their phones.

What We'd Do Differently

Start with latency budgets, not features. We should have set our 800ms latency target on day one and built every component to that budget. Instead, we built features first and then scrambled in week 6 to optimize. The architecture would have been cleaner if latency was a first-class constraint from the start.

Build the monitoring dashboard earlier. We didn't have real-time call monitoring until week 7. That meant weeks 5 and 6 were partially blind. Now, every Loquent deployment gets a monitoring dashboard on day one.

Test with real patients sooner. Our simulated conversations, no matter how good, didn't capture the way real patients talk on the phone. They pause mid-sentence. They talk to someone else in the room. They put the phone down and come back. We caught these patterns in week 8 when we should have been finding them in week 4.

Key Takeaways

Latency is the product. In voice AI, response time determines whether your system feels like a helpful receptionist or an annoying robot. Budget for it from day one.
Pick models for their failure modes, not their best cases. Claude won over GPT-4 not because it was smarter, but because it failed more gracefully — admitting uncertainty instead of making things up.
Healthcare voice AI in Canada is viable right now. PIPEDA compliance is manageable, Canadian data residency options exist for all major cloud providers, and patients are more accepting of AI receptionists than most people assume.
The 80/20 rule applies hard. Getting to 80% automation was 3 weeks of work. Getting from 80% to 82% was another 4 weeks of prompt tuning and edge case handling. Plan your timeline accordingly.
Build the transfer path first. The AI knowing when to hand off to a human is more important than handling every scenario. A graceful transfer builds trust; a confused AI destroys it.

This is the system we turned into Loquent, our production voice AI platform. It now serves multiple healthcare and dental clients across Canada, handling thousands of calls per month.

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

We Analyzed 10,000 Automated Healthcare Voice Calls — Here's What We Found

Autor Technologies Inc. — Tue, 31 Mar 2026 16:24:13 +0000

Last October, we hit a milestone at Autor that I didn't see coming: Loquent, our production voice AI platform, processed its 10,000th automated healthcare call. Instead of celebrating, we did what any team of engineers would do — we pulled the data, locked ourselves in a room for a week, and tore apart every single pattern we could find.

What we discovered changed how we build voice AI. Some of it confirmed our assumptions. Most of it didn't.

The Setup

For context, Loquent handles automated calls for healthcare and dental clinics across Canada. We're talking appointment scheduling, confirmations, cancellations, insurance verification questions, and general intake routing. The system runs 24/7 on a stack built with Twilio for telephony, Anthropic Claude for conversation intelligence, Deepgram for speech-to-text, and ElevenLabs for text-to-speech. We built the first version in under 8 weeks and have been iterating on it for the past six months.

The 10,000 calls in this dataset span 14 clinic clients — a mix of dental offices, family practices, and specialist clinics in Ontario and British Columbia. Call durations ranged from 12 seconds (hang-ups) to 14 minutes (complex scheduling with insurance questions). The median call was 2 minutes and 38 seconds.

Here's what the data told us.

Finding 1: 73% of Calls Follow Just 4 Patterns

We categorized every call by intent. Out of the dozens of potential reasons someone calls a clinic, four patterns dominated:

Appointment booking: 31%
Appointment confirmation/change: 24%
Cancellation: 11%
"Am I covered for this?" (insurance/billing questions): 7%

That's 73% of all inbound call volume handled by four well-defined flows. The remaining 27% was a grab bag — prescription refill requests, referral follow-ups, directions to the clinic, and a surprising number of people just wanting to talk to "a real person" about nothing specific.

This matters because it means you don't need a general-purpose conversational AI to handle the majority of healthcare front-desk calls. You need four really good, tightly scoped flows with clean handoff logic for everything else. We spent months trying to make Loquent handle every possible conversation gracefully. The data told us to stop doing that and instead make those four flows bulletproof.

Finding 2: Latency Tolerance is Exactly 1.8 Seconds

We measured caller drop-off rates against our system's response latency — the time between when a caller finishes speaking and when the AI begins its response. The data was clear: at 1.2 seconds or less, drop-off rates were near zero. Between 1.2 and 1.8 seconds, drop-off crept up slightly. Above 1.8 seconds, we saw a cliff. Callers either hung up or started talking over the AI, derailing the conversation.

1.8 seconds. That's your budget for the entire pipeline: speech-to-text transcription, LLM inference, text-to-speech generation, and audio delivery back through Twilio. In practice, this means we run Deepgram's streaming transcription (adds ~300ms), Claude Haiku for most routine responses (adds ~400-600ms), and ElevenLabs with their Turbo v2 model (adds ~350ms). That leaves roughly 200ms of network overhead before we're in the danger zone.

For complex queries where we need Claude Sonnet's reasoning — like disambiguating between similar appointment types or handling multi-step insurance questions — we've built a "thinking buffer" that plays a natural filler phrase ("Let me check that for you...") to buy an extra 2-3 seconds. This single trick reduced our complex-query drop-off rate by 41%.

Finding 3: Morning Callers Are 2.3x More Patient Than Afternoon Callers

This one surprised us. We segmented call behavior by time of day and found a pattern so consistent it changed our system design.

Callers between 8am and 11am had an average interaction length of 3 minutes 12 seconds and tolerated longer AI response times before dropping off. Callers between 2pm and 5pm averaged 1 minute 54 seconds and were significantly more likely to request a human transfer.

Our theory: morning callers are often calling during a planned moment — they're at their desk, coffee in hand, checking things off a list. Afternoon callers are squeezing in a call between meetings or during a break. They want speed.

We now dynamically adjust Loquent's behavior based on time of day. Afternoon calls get shorter confirmations, faster routing, and more aggressive escalation to human staff. Morning calls get slightly more conversational, exploratory flows. This alone improved our afternoon completion rate by 18%.

Finding 4: The "Second Sentence" Problem

Here's a pattern we almost missed. In 34% of calls where the AI's first response was correct and helpful, the caller still asked to speak to a human. We dug into the transcripts and found the issue wasn't accuracy — it was the AI's second sentence.

The AI would correctly answer the question, then add a follow-up that felt robotic or presumptuous. Things like: "Is there anything else I can help you with today?" delivered in the exact same cadence as a phone tree. Or worse, immediately pivoting to: "I can also help you with appointment scheduling, prescription inquiries, or billing questions."

Real receptionists don't do this. They pause. They let the caller process. They read the room.

We rewrote our prompt engineering to include explicit "breath" instructions — moments where the AI generates a brief pause and waits for the caller to lead. We also cut the generic menu-style follow-ups entirely. The result: human transfer requests after successful first responses dropped from 34% to 12%.

Finding 5: 6% of Callers Will Try to Break Your AI (And That's Fine)

We identified a consistent 6% of callers across all clinics who deliberately tested the AI. They'd ask trick questions, try to confuse it, speak in fragments, or demand things the AI clearly couldn't do. We affectionately call these "stress-test callers" internally.

Early on, we tried to make the system handle these gracefully — clever redirects, patient re-prompts, escalation paths. We burned weeks on it. The data showed us something freeing: these callers almost always called back within 24 hours and had a normal, productive interaction the second time. They were curious, not hostile.

We now let these calls fail gracefully with a simple "I want to make sure you get the help you need — let me connect you with the team" after two confused exchanges. No heroics. Our engineering time is better spent on the 94%.

What This Changed For Us

After this analysis, we made three architectural decisions that shaped Loquent's next iteration:

1. Flow specialization over generalization. We rebuilt our four core flows from scratch, each with its own optimized prompt chain, latency budget, and escalation logic. The "general conversation" handler became a thin routing layer, not a Swiss Army knife.

2. Time-aware behavior. Loquent now adapts its conversational style, response length, and escalation thresholds based on time of day. The morning version and the afternoon version are meaningfully different systems.

3. Silence as a feature. We invested heavily in teaching the AI when not to talk. Strategic pauses, shorter confirmations, and eliminating the "anything else?" reflex made the system feel less like a phone tree and more like a receptionist who respects your time.

The Numbers After the Rebuild

Six weeks after implementing these changes across all 14 clinics:

Overall call completion rate: 74% → 82%
Average call duration: 2:38 → 2:11
Human transfer requests: 22% → 14%
Client satisfaction (post-call survey): 3.4/5 → 4.1/5
Peak hour handling capacity: up 23% (same infrastructure cost)

None of these improvements came from a better model or a fancier tech stack. They came from reading our own data honestly and being willing to simplify.

Key Takeaways

Most healthcare voice AI problems are scope problems, not intelligence problems. You don't need AGI to book a dental cleaning. You need four flows that work perfectly and clean handoffs for everything else.
Latency isn't a "nice to have" metric — it's the metric. Every millisecond above 1.8 seconds costs you callers. Architect your entire pipeline around this constraint from day one.
Time of day changes caller behavior more than you'd expect. Build your system to adapt, or you're leaving completion rate on the table.
The AI's second sentence matters more than the first. Getting the answer right is table stakes. How the AI handles the moment after the answer determines whether the caller stays or bounces.
Not every edge case deserves engineering time. The 6% who stress-test your system will come back. Focus your effort on the 94% who just want their appointment booked.

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

How We Built a Production Voice AI Agent in Under 8 Weeks (With Twilio + Anthropic Claude)

Autor Technologies Inc. — Tue, 24 Mar 2026 23:36:05 +0000

Earlier this year, we shipped Loquent — a production conversational AI platform that handles real phone calls, books appointments, processes patient follow-ups, and verifies insurance — completely autonomously, 24/7.

We built it in under 8 weeks.

This isn't a tutorial about building a toy chatbot. This is a breakdown of what it actually takes to get voice AI into production — the architecture decisions, the hard lessons, and the specific stack we used.

The Problem We Were Solving

Healthcare and dental clinics miss a massive percentage of inbound calls. Front desks get overwhelmed during peak hours. Patients call after hours and get voicemail. Appointments slip through.

The ask: build an AI system that could handle inbound and outbound calls — booking appointments, confirming details, following up with patients, verifying insurance — without a human in the loop.

Not a demo. Not a prototype. Production. Real patients. Real clinics. Real calls.

The Stack

Before diving into architecture, here's what we ended up with:

Layer	Technology
Voice / Telephony	Twilio Voice + Media Streams
Speech-to-Text	Deepgram Streaming
LLM	Anthropic Claude (claude-sonnet)
Text-to-Speech	ElevenLabs
Backend	NestJS + Python
Frontend Dashboard	Next.js + React
Database	PostgreSQL + Prisma
Queue	Redis + BullMQ
Cloud	AWS (ECS, RDS, ElastiCache)
Integrations	HubSpot, Salesforce, Zendesk

We evaluated OpenAI's Realtime API, but at the time latency and reliability on production call volumes wasn't where we needed it. We went with the Deepgram → Claude → ElevenLabs pipeline, which gave us full control over each layer.

Architecture Overview

Caller dials in
     ↓
Twilio receives call → webhook fires to our backend
     ↓
Twilio Media Stream opens WebSocket to our server
     ↓
Audio chunks stream in real-time → Deepgram STT
     ↓
Transcript fed to Claude with conversation context + clinic data
     ↓
Claude response → ElevenLabs TTS → audio streamed back via Twilio
     ↓
Actions extracted (book appointment, send confirmation, update CRM)

The whole loop needs to complete in under 1.5 seconds to feel natural. That's the hard constraint everything else is built around.

The Latency Problem

This was the hardest engineering challenge. Users tolerate maybe 1–2 seconds of silence before it feels broken. We were dealing with:

Deepgram STT: ~200–400ms
Claude inference: ~400–800ms
ElevenLabs TTS first-chunk: ~300–500ms
Twilio playback: ~100ms

That's already pushing 2 seconds before any network overhead.

What we did:

1. Stream everything. We don't wait for a complete Claude response before starting TTS. The moment Claude starts outputting tokens, we pipe them to ElevenLabs sentence by sentence. The first audio chunk starts playing while Claude is still generating.

2. End-of-utterance detection. We use Deepgram's endpointing, but also built our own silence detection layer. Aggressive endpointing cuts off users mid-sentence. Too conservative and the response feels laggy. We tuned this per use case — a patient confirming an appointment has different speech patterns than one describing symptoms.

3. Claude prompt engineering for speed. Verbose responses kill latency. We prompt Claude to be concise, speak like a receptionist, and never use filler phrases that add tokens without value. We also give it explicit response format guidance — short sentences, direct answers.

4. Pre-warm everything. ElevenLabs has cold start latency. We keep connections warm with keepalive pings. Same with our database pool.

With all of this in place, we got average response latency down to ~900ms. Occasionally spikes to 1.4s. Feels natural.

Designing the Claude Prompt

This took more iteration than the infrastructure. The system prompt has to do a lot:

You are [Clinic Name]'s AI receptionist. Your name is [Agent Name].

You are speaking with a patient over the phone. Be warm, professional, 
and concise. Speak in short sentences. Never say "Certainly!" or 
"Absolutely!" or similar filler phrases.

CLINIC CONTEXT:
- Name: [Clinic Name]
- Hours: [Hours]
- Providers: [Provider list with availability]
- Services: [Service list]

CURRENT PATIENT CONTEXT:
[Injected dynamically: patient name, upcoming appointments, 
last visit, insurance status]

AVAILABLE ACTIONS:
[JSON schema of actions Claude can trigger: book_appointment, 
cancel_appointment, send_confirmation, transfer_to_human, etc.]

RULES:
- If you cannot handle the request, transfer to a human. Never guess.
- Confirm all bookings by repeating back date, time, and provider.
- Never discuss billing details — transfer to billing team.
- If the patient seems distressed, offer to transfer immediately.

The key insight: Claude needs to know what it can and cannot do. An AI that tries to handle everything and fails is worse than one that gracefully transfers when out of scope.

We use Claude's tool use (function calling) for actions — booking, cancelling, sending confirmations. This gives us clean structured outputs instead of trying to parse intent from natural language.

Multi-Tenant Architecture

Loquent serves multiple clinics, each with their own:

Phone number(s)
Providers and availability
Booking rules and constraints
Brand voice and agent name
CRM integration

The system prompt is dynamically assembled per-call using the clinic's configuration. We built a dashboard where clinic admins can update their agent's name, working hours, provider list, and escalation rules without touching code.

Each clinic gets isolated data — separate database schemas, separate API credentials, separate call logs.

The Integrations Layer

The hard part isn't the AI — it's making the AI useful by connecting it to real data.

Appointment booking: We built adapters for common dental/healthcare practice management systems. The adapter pattern let us add new integrations without touching the core engine.

CRM sync: After every call, we write a structured summary back to HubSpot or Salesforce — caller ID, intent, outcome, booking details, and a Claude-generated call summary. This is actually one of the features clinics love most.

Confirmation messages: Post-call, we trigger SMS/email confirmations via Twilio Messaging and SendGrid. Patients get a confirmation within 30 seconds of booking.

What Broke in Production (And How We Fixed It)

Problem 1: Callers interrupting the AI mid-sentence

Users naturally interrupt. The AI was finishing its sentence before responding to the interruption, which felt robotic.

Fix: Barge-in detection. When Deepgram detects speech while TTS is playing, we immediately stop audio playback, flush the TTS buffer, and re-run inference with the new input. Feels much more natural.

Problem 2: Claude hallucinating availability

Early builds had Claude generating appointment times that didn't exist. Patients were being told "Tuesday at 2pm" when the provider wasn't available.

Fix: Availability is never in the prompt. Instead it's a tool call. Claude calls get_availability(provider, date_range) and we return actual real-time slots. Claude can only offer what the function returns.

Problem 3: Long calls running up costs

Some patients would keep the AI on the phone indefinitely — confused, or just chatty. Unbounded calls = unbounded cost.

Fix: Configurable max duration per clinic. At 10 minutes, the AI politely offers to transfer to a human or calls back. Average call length is now 2.5 minutes.

Problem 4: Noisy environments destroying STT accuracy

Callers in cars, waiting rooms, restaurants. Background noise crushed Deepgram accuracy.

Fix: Deepgram's noise suppression model + a fallback that asks the caller to repeat if confidence drops below threshold. "I'm sorry, I didn't quite catch that — could you repeat that for me?"

Numbers After Launch

Calls handled: Thousands of automated calls per month
Average handle time: 2.5 minutes
Transfer rate: ~18% (calls that go to a human)
Booking completion rate: ~74% of calls that started with booking intent
Uptime: 99.7%
Average response latency: ~900ms

The clinics running Loquent have effectively eliminated missed after-hours calls. One client told us their front desk spends the first hour of every morning re-booking patients who couldn't get through the day before. Loquent eliminated that entirely.

What We'd Do Differently

Start with tool use from day one. We initially tried to have Claude make decisions through natural language reasoning. Switching to structured tool calls for all actions made the system dramatically more reliable.

Invest in evals earlier. We didn't set up proper evaluation pipelines until week 5. Building a test call suite in week 1 would have caught several issues earlier.

Separate the conversation engine from the telephony layer sooner. The abstraction between "what the AI is doing" and "how the call works" should be clean from the start. We refactored this at week 6 and it made everything better.

What's Next

We're now extending Loquent to handle outbound campaigns — appointment reminders, recall messaging, post-visit follow-ups. The same architecture works, you just flip the direction of the call.

We're also exploring multi-agent setups where a triage agent hands off to specialist agents (billing, clinical questions, booking) with full context preservation.

If you're building something similar or want to talk through the architecture, we're at getloquent.com and autor.ca.

Happy to answer questions in the comments.

Autor is a Toronto-based AI development studio. We build custom AI agents, voice assistants, and full-stack AI products for businesses. autor.ca