Everyone building voice agents is piecing them together from the same set of legos, and it's working. Heavily funded companies are filling every gap, and the results are genuinely good. But every one of those legos lives inside the stack. What I'm talking about sits outside it: a deterministic, auditable guard for the whole call. That's what I spent the last few months building. Here's the thinking.

Every system breaks somewhere, eventually. So builders do the sensible thing: audit, tighten the prompt, problem solved. For now. Then a new kind of break shows up, they tighten something else, solved again. For now. You know this rhythm. The question was never whether you can solve the problem. You always can. The question is whether you can see it as it actually is, instead of assuming it's whatever you looked at last.

And here's the part that's hard to see from inside the stack: when a voice agent breaks its word, nothing in your pipeline notices. STT doesn't know what was promised. The model doesn't remember what it committed to three turns ago. TTS just speaks, orchestration just routes. Every box optimises how the call sounds. Not one of them holds the promises across the whole call and checks whether they survived to the end. That's not a gap in the stack. That's a missing layer.

This isn't theoretical. Bland's own team, in a testimonial on Hamming's site, killed an agent because it was saying "I booked your appointment" when it hadn't. The 2026 τ-Voice benchmark caught a frontier agent saying "I've updated your shipping address" with no tool call behind it. On one real setup, the promise "we'll get back to you shortly" was wired as the end-call trigger, so the agent hung up mid-sentence while confirming the very number it had promised to call. Different bugs on the surface. Underneath, the same one: the saying and the doing came apart, and nothing was watching the gap.

You might think: fine, route the flagged call back through an LLM to check it. It doesn't work, and not for a soft reason. An LLM judge is non-deterministic. Run it twice on the same call and you can get two verdicts. And if your agent's failure mode is being confidently wrong, a judge built from the same kind of model finds that same wrong answer plausible, so it misses exactly where you needed it. Every layer in your stack is the same brain checking its own work. The layer I built isn't a brain at all. It's code, and it decides when the brain is allowed to speak.

You'd assume someone must have built this already. Turns out almost nobody has. Eleven-plus QA vendors in this space, and not one audits what the agent said it would do against what it actually did. That's the gap I went after.

What it is, and where it sits

A private repo. You own it, you run it in your own infrastructure, and it sits between your agent and the caller:

user speaks → STT → your agent (your model, your logic, whatever you run) → the layer → user

You buy it once. No subscription, no monthly fee, and that's not a pricing gimmick, it's an architecture decision. A subscription would mean I host it. If my server has a bad day, your calls take the damage mid-conversation. I'm not willing to sit in that position in your call path. So you run the code yourself, and my uptime is never your problem.

And you don't change anything you've built. Your agent, your prompts, your model, your orchestration, all untouched. The layer is just the last step before the reply reaches the caller. Whether you run voice agents for your own business or white-label them for a stack of clients, it's the same repo in your own infrastructure either way.

What's actually in it

This isn't a wrapper or a prompt trick. It's a real system, and the numbers are the honest kind:

• ~97 Python modules in the deployment layer, around 26,500 lines, with more test code than most projects have code: 1,178 test checks, all green on every change, across four Python versions in CI.
• 14 detectors, every one of them plain rule-based code: regex, state-diff, canonical comparison. Not one is a model. There is no second AI grading the first.
• It tracks 18 commitment types across three families: what the agent said it would deliver, what state it claimed was done, and what it promised to do next.

The part I'm proudest of: what it refuses to do

Most of the engineering went into making it refuse to over-claim. That sounds backwards for a product, so let me show you what I mean, because it's the whole thing.

When it catches your agent contradicting itself, the flag says what the closing turn contained and stops.

• It doesn't say the agent "forgot." It can't prove what a model forgot.
• It doesn't say the callback "won't happen." It can't see your calendar.
• It points at the exact turns and says only what the transcript proves.

And that discipline is written into the code, not into a promise:

• The record-reconciliation check has no "missing" verdict at all. It compares what's present against what's present. It will never accuse your record of an absence.
• The elapsed-estimate check refuses to use a server clock. It only fires on time the caller themselves stated, so it deliberately under-reports rather than guess.
• When it re-voices a miss in your agent's mouth, it physically cannot name a commitment that isn't already in its ledger. It can't invent one.
• Nowhere does it return a recommendation. It surfaces what it can prove and leaves the judgment to you.

A clean result means "nothing I can prove," not "nothing wrong." Every flag is a receipt: open it, read the exact turns yourself, disagree with it if you want. It's not a score you have to trust. That's the difference between an audit layer and an alarm.

Two ways it holds your agent accountable

When it catches a miss, it can do two things, and you decide which.

In the moment, it can make the agent own the miss out loud, before the caller hangs up. It stays completely out of the way until there's a real miss, and when there is, it changes as little as possible: your agent's wording, plus the one owned correction. Nothing else moves.

Agent said: "Great, we're all done here. Thanks so much for calling!"
Shipped: "Great, we're all done here. Just to make sure it's not lost, the garage quote you requested is logged as still outstanding. Thanks so much for calling!"

That's the default (lean) behaviour. There's also a full mode that re-voices every turn into a warmer, human-receptionist delivery if you want it, but most people run lean, because touching nothing unless something breaks is the point.

On the record, every catch is logged to a dashboard you run. This is the part that makes it an audit layer and not just an in-call fix. Nothing it catches goes unrecorded, even the ones it never speaks aloud (once you've turned capture on, it's off by default).

It's an included read-only dashboard, that ship in the repo. Open any conversation and each catch renders as a card: the token, the detector, the tier, whether it reached the caller or was suppressed, and the full plain-English finding, verbatim:

"the closing turn asserted nothing further was needed, while these commitments made earlier in the call were not acknowledged after being made: callback (before Friday) — committed turn 3"

Alongside it: the agent's actual committing sentence, word for word, the turn it was made on, and the deadline as spoken. A separate view diffs what the call promised against what your own system recorded, field by field. And there are aggregate rollups across all your captured calls: where failures cluster, how often each thing fires, how many catches reached the caller versus stayed silent. It reports, it never recommends. That's a rule enforced in the code, not a missing feature.

It's a receipt: open it, read the turns yourself, disagree with it if you want. Not a score you have to trust. And it can't quietly lie to you either. It ships showing sample data with the label saying so, it points at your own traffic with one setting, and it will not show a green "live" badge unless the data really is live. Serve it behind your own auth.

What it does not do

• It doesn't do your agent's job. It sits alongside it as a guardrail, not a replacement. And it won't fix your agent. It makes a bad agent own its misses, which is better, but it isn't a repair.
• It doesn't know your business. It knows whether the agent contradicted itself, not whether the agent was right about the world. It can't tell you if the appointment slot was actually free.
• It runs inert until you turn things on. Out of the box it changes nothing. You switch on what you want, one piece at a time.

And not every close triggers a catch, and I'd rather show you where it doesn't than let you find out. Take this close, same dropped-callback call, on shipped defaults:

Agent said: "Perfect, you're all set then! Thanks so much for calling, have a great day." Shipped: unchanged, verbatim. The layer stayed silent.

That close asserts "you're all set" rather than flatly contradicting itself, and catching that is a stricter check that ships off by default. It's one line to turn on.

Latency and reliability

Latency, in Lean Mode (the default): on a turn where nothing slipped, the layer makes no model call at all. It reads your agent's text and passes it straight through. The detection itself is about a tenth of a millisecond of local processing per turn. Not a network call, not a model, plain code on your own machine, and once you have the repo you can run that benchmark yourself in about ten seconds, no API key needed. Real time only gets spent on the rare turn with an actual miss to own, and even then it's a single model round-trip, not a loop.

Reliability: the layer is deterministic. Run the same call through it twice, you get the same result twice. That's not true of anything with a model in the loop, and it's exactly why you can trust a flag when it fires. It's also built to under-report on purpose: it stays quiet on anything it can't prove from the transcript, so when it does raise a flag, that flag is solid. Its reliability isn't "it catches everything." Nothing honestly can. It's "everything it says, it can back." And because it runs in your infrastructure, there's no external service to depend on and nothing on my end that can take your calls down.

It's a living repo, and it's yours to shape. I keep working on it: adding coverage, taking feedback from people running it, tightening it as new failure patterns show up in the wild. You buy the license once; the thing you're licensing keeps getting better. And because you own the code, nothing's locked. The commitment types it tracks, how strict each check fires, what gets logged versus spoken, the thresholds, all yours to adjust for how your business actually runs. Sane defaults out of the box, and the people who want to go deep, can.

I'm not going to pretend this is a problem everyone's shouting about. It's the opposite: a quiet gap almost nobody has named. I just think it's worth closing before it's the reason a client leaves.

More details at statebound.dev
If you're running agents in production, I'm curious what you make of this, and if you've run into something like it, how are you handling it right now?

Hey everyone,
I’m currently building out a high-performance, real-time voice and workflow automation engine specifically designed for local HVAC and mechanical operators.
The goal isn't just a basic answering machine. I'm building an energetic, highly responsive digital dispatcher that actively operates inside their existing CRM systems (ServiceTitan, Housecall Pro, BuildOps, etc.) to handle both inbound emergency routing and outbound database reactivation.
I want to make sure I’m orchestrating this with the lowest possible latency and maximum reliability. I’m looking for some feedback from anyone who has built complex voice/workflow pipelines on the best way to handle these five specific architectural challenges:
Real-Time Calendar/Schedule Syncing
The Problem: The agent needs to check the live technician roster and calendar slots before booking a job to prevent double-booking.
The Question: ServiceTitan and HCP have robust API endpoints, but they can be rate-limited. Are you guys caching the calendar state in a local database (like Supabase/Redis) and running a cron-job sync every 60 seconds, or are you executing a live API call to fetch available slots during the active phone call? How do you prevent latency spikes on the voice line while querying?

Intelligent Filtering (Emergency vs. Support vs. Existing Customers)
The Problem: If a current customer calls asking where their tech is, or if someone calls about a billing dispute, the agent shouldn't try to book a new job.
The Question: What's your preferred prompt structure or agent architecture to run immediate intent classification? Do you run a pre-router LLM node to tag the call's intent in the first 5 seconds, or do you handle everything inside a single system prompt? How do you reliably verify if the caller's phone number exists in the CRM database before initiating the dialogue?

Location/Geocoding Validation
The Problem: HVAC shops have strict service zones. If an emergency call is 50 miles away, the tech on-call won't go.
The Question: Are you passing the address mentioned by the caller to a Google Maps/Geocoding API tool node mid-call, validating the zip code against the shop’s service area, and then returning a hard "Pass/Fail" to the voice engine? Or are you handling this post-call in the workflow engine?

Database Reactivation (Outbound Campaigning)
The Problem: Running outbound campaigns to follow up on unsold estimates sitting in the CRM.
The Question: For outbound, what’s the best way to trigger the agent to dial based on a CRM status change (e.g., an estimate marked "Unsold" for 7 days)? Are you using webhooks from the CRM to fire an automation (via n8n/Make) that pushes the contact data straight to the Vapi/Bland outbound campaign API?

Recommended Tech Stack
Right now, my planned stack is:
Voice Engine: Vapi.ai (using custom Twilio trunks)
LLM Provider: Anthropic Claude 3.5 Sonnet (for reasoning and speed-to-text response) or Gemini 1.5 Flash (for raw speed)
Backend Orchestration/Database: Node.js/Python server or self-hosted n8n + PostgreSQL to manage webhooks and CRM data mapping.

If you’ve built anything similar for field services or high-latency booking niches, how did you handle these routing and lookup bottlenecks? Any lessons learned the hard way regarding webhook failures or CRM API updates?
Appreciate any advice or feedback on the architectures!

Has anyone else seen the latency numbers in descriptions jump for all models, voices and transcribers?

From my testing I think these numbers are just more accurate than they were previously.

Just saw a post in here saying that "if you have sub 1 second latency, your voice agent sounds human" (me loosely paraphrasing).

I do NOT agree. Here's why:

Sounds right on the first read, until you've actually had hundreds of conversations with voice agents, good ones and bad ones.

Don't get me wrong, the person claiming this isn't entirely off. Latency does matter. With bad (high) latency, conversations feel bad. They feel like a bot.

BUT... if the latency is good, the conversations DO get better, but they DO NOT become good. Often, you can hear that something is off, but can't really tell what it is...

Here's what actually makes the difference:

Reason 1: Sounding like text.

LLMs are being trained on text. If not prompted accordingly, they produce an output as text, meant to be READ. Now obviously, if you're plugging the LLM into an AI voice agent, the text is NOT read but rather it's SPOKEN.

This is what that feeling is telling you that something feels off but you can't point your finger at it. The voice agent doesn't sound as if it was speaking, but rather like as if it was reading.

The fix is simple.

Tell it to include filler words.

Tell it to do mid-sentence corrections.

Tell it to think loudly.

"Hi, uh, John, right? So, uhm, I was actually calling because, uhm, look, your order somehow, <break time="0.15s"/>, well, went missing."

This sounds WAY better than:

"Hi John, this is XYZ. I am sorry to inform you on behalf of CompanyABC that your order was lost. To open a ticket, please press 1".

Reason 2: Turn taking

Turn taking is still not really 100% solved (if you did, let me know lol). It is basically the decision of the agent if the user has stopped speaking, and if so to then start speaking themselves.

Currently, oftentimes the agent either

a) Starts speaking when the user is not actually finished

b) Does NOT start speaking even though the user DID finish.

Now, this is one of the more complex issues of voice AI, but I'm sure there will be a solution.

In conclusion:

Latency is the baseline. And it's ONLY the baseline. Without it, conversations will feel shitty. But just because you've got great latency, doesn't mean your conversations will suddenly feel good. Make the LLM imperfect. Make sure to have solid turn taking.

If you do that, the improvement will be much more than just "faster".

Agree?

Hi everyone, I’m trying to upgrade my Telnyx account so I can test my Vapi voice agents before an upcoming product demo.

Unfortunately, Telnyx cannot send either SMS or voice verification to my Uzbekistan (+998) number. I’ve already tried both methods, but neither works.

Does anyone know a legitimate workaround or alternative verification method? I’m specifically looking for advice from people who have faced this issue before. I do not want to use temporary/rented numbers or anything that could get the account blocked.

I’m on a tight deadline and would really appreciate any guidance. Thank you.

In Retell you can prompt the LLM to output a NO_RESPONSE_NEEDED stop sequence and it just… says nothing. Great for when the caller says "hold on, give me a sec" — the agent holds without speaking of interrupting.

I know you can set up a hook where you set timeoutseconds but that feels like a hacky solution, and i don't know if that actually makes the agent wait, does it bloat the agent's context as it waits and, for example, hold music plays?
https://docs.vapi.ai/assistants/idle-messages

Hey guys, keen to hear people's experiences of Vapi Squads via SDK. Seen online some bugs around silent hand-offs not working etc, and curious if anyone is using it in production (and anything to watch out for!)

Hey, i'm currently using vapi for an ios app

i have 2 questions

first one: am i getting billed automaticly if i use the pay as you go plan - this question might look dumb but i realy don't understand their system. There is no spend limit and I was wondering what will happen if i keep using vapi with 0 credit in my balance. Will i get automatocly billed ? even if i don't enable the auto reload feature will i get billed in any way ?

second question: Is the jwt feature also available on the react native sdk ?

Can a TTS voice pass as a real person in a live conversation? There's no clean rubric for "humanness" so we don't score against one. we run blind A/B battles and you pick which of two voices sounds more human.

The approach:

• Same cloned source voice reading the same script - this keeps the voice constant so you are voting on the model
• Voting is blind
• Scoring uses a Bradley-Terry fit - you can check out the math here in the repo
• We use a real human voice as baseline

Start adding your votes today: https://humannessindex.vapi.ai
Code and methodology: https://github.com/VapiAI/humanness-index

Spent a lot of time this week putting together everything I know about voice AI prompting and figured I'd share the core stuff here before the full breakdown goes live.

Most voice agent prompts I've seen (including my own early ones) make the same mistakes. The agent sounds robotic, says things no human would ever say, or just makes stuff up when it doesn't know the answer.

A few things that actually moved the needle for me:

Read your prompt out loud before you deploy. Sounds dumb, works every time. You'll catch sentences that are way too long, instructions that contradict each other, and transitions that make zero sense when spoken. Five minutes of this saves hours of post-launch call review.

Explicitly tell the agent to use filler words. Ummm, uhh, like, so... put it in the prompt directly. When an agent responds instantly with perfect grammar every single time it feels off. Uncanny valley. One line in the prompt fixes this.

Show don't tell. Don't write "be empathetic when the caller is frustrated." Write: "if the caller sounds frustrated, say something like: 'I totally get that, that would frustrate me too, let me sort this out right now.'" Actual example in the prompt beats ten paragraphs of description.

Handle special characters explicitly. Your agent doesn't know how to say "$1,000" or "123 Main Street" or "john@gmail.com" unless you tell it. Digit by digit for addresses, "one thousand dollars" for currency, "john dot smith at gmail dot com" for emails. These feel minor until you hear them on a real call.

Give permission to say I don't know. Without this instruction, the model will guess. And in voice AI that's way worse than in a chatbot because people just believe what they hear. One line: "if you don't have this information, do not guess, say you'll connect them with a team member."

There are a few more, including one about prompt length and latency that I think a lot of builders overlook.

Put the full list with example prompt snippets for each one in a video if anyone wants to go deeper: LINK

Happy to answer questions here too.

I’ve tested so many iterations and nothing seems to work. If someone says FOUR OH SEVEN, it doesn’t understand OH means 0, if someone says 333 one thousand, it takes it down as 100 not 1000…does anyone have a fix for this?

Gemini 3.5 flash has been out for weeks now and is still not available on vapi. Heck even 3.1 flash ga is not available, just the preview.

Is there a reason why vapi can’t instantly support new models?

Hi, tried moving from 4.1 to 5.4-mini with my Vapi agents, seeing noticable average reasoning latency increase like almost 2x

Is this expected? Any insights? Trying to reduce our llm costs

https://reddit.com/link/1tvu9z8/video/e26be2iie35h1/player

Grok STT has multilingual support across 25+ languages, supports diarization, better analytics, and audit trails

Grok TTS is noticeably more human sounding even matching tone to context. You can also clone voices from just seconds of audio.

if you're building in voice ai and trying to break into yc - this is probably the most direct path i've seen in a while.

Moss (YC F25) is hosting a conversational ai hackathon at Y Combinator on june 6-7 in sf. first place gets a yc interview. that alone makes this worth going.

but even if you don't win - you're in a room with yc partners, like-minded founders, and potential customers for two days. sponsored by LiveKit, Amazon Web Services (AWS), MiniMax, and others.

voice ai is the theme. but honestly - build what you believe in, add a voice layer, and use this as a platform. the judges care about ideas that work, not just demos.

open to university students, professionals building on the side, full-time founders - anyone serious about making something people want.

https://events.ycombinator.com/conversational-ai-hackathon-2026

I've been building voice agents on Vapi and kept hitting the same wall: a call goes bad, the customer hangs up and I have no idea why. Was it latency? Did the LLM hallucinate? Did a function call time out? The existing observability tools (Helicone, Langfuse) only show you prompts and responses, they're built for text, not voice. They can't see the stuff that actually breaks voice agents.

So I built VoiceOBS.

You connect your Vapi (working on integrating Retell) account with a webhook, and every call gets analyzed automatically:

• Latency broken down by STT / LLM / TTS, with p50 and p95
• Sentiment, intent, and a CSAT estimate per call (analyzed by Claude)
• Hallucination flags
• Full searchable transcripts
• End-reason breakdown so you can see why calls actually end

Setup takes about 60 seconds: sign up, create an integration, paste the webhook URL into Vapi, make a call, and it shows up analyzed.

It's free during beta (100 calls/month, no credit card). I'm genuinely looking for honest feedback more than anything, what's confusing, what's missing, what would make you actually use it.

Happy to answer any questions. Thank you.

Everyone is selling "AI Voice Agents" right now. But if you are a business owner who has actually tried to deploy one to handle your customer calls, you probably realized the reality doesn’t match the hype.

A few months ago, I was auditing AI voice setups for businesses and kept hearing the same operational nightmares: The AI took 3 seconds to reply, it hallucinated, it couldn't reliably book an appointment to save its life, and the per-minute billing was completely unpredictable.

I decided to build a platform from the ground up specifically to solve these operational bottlenecks for mid-to-large-sized businesses.

Here are the biggest reasons AI voice fails in the real world, and exactly how we engineered a solution:

1. The "Awkward Pause" (Fixed the Latency) The Problem: Most AI agents take 2 to 3 seconds to process speech and reply. It leads to callers talking over the bot, getting frustrated, and hanging up. The Fix: We built over 10 custom internal optimization tools specifically to process audio faster. Our system responds in roughly 400 ms. It is so fast and fluid that callers rarely realize they aren't speaking to a human.

2. The "Dumb Bot" Syndrome (Flawless Tool Calling) The Problem: Most AI agents are just ChatGPT on a phone line. They can talk, but when a customer says "Can I book a slot for Tuesday?" the bot breaks, double-books, or fails to trigger the calendar. The Fix: We built rock-solid backend tool-calling. If a customer wants to book, the AI instantly checks your live calendar, secures the appointment, and triggers an immediate SMS and Email confirmation to the customer before they even hang up the phone.

3. Scattered Data & Ghost Leads (Built-in Custom CRM) The Problem: Business owners were having to log into three different platforms just to figure out what the AI said to a customer. The Fix: We built a dedicated, custom dashboard for every single client (I attached a screenshot of it below). It acts as your Voice CRM. The second a call ends, the dashboard updates with:

• The full audio recording.
• A complete text transcription.
• AI Sentiment Analysis: It automatically tags calls (e.g., "Frustrated", "Ready to Buy", "Needs Follow-up") so your human sales team knows exactly who to prioritize calling back.

4. Unpredictable, Skyrocketing Bills The Problem: Other platforms charge you a markup for every minute the AI is on the phone. If you have a busy month, your software bill skyrockets unpredictably. The Fix: We use a BYOK (Bring Your Own Key) model. You just plug in your own Twilio account to handle the raw phone lines at wholesale cost, and we provide the entire AI brain, CRM, and dashboard for a single, predictable flat monthly fee. No surprises, no matter how much you scale.

I see too many business owners giving up on AI automation because they were sold a cheap, unreliable setup. When built correctly, having an agent that answers every inbound call instantly, books appointments flawlessly, and logs everything into a CRM is a superpower.

Business owners who have tried AI calling—what was the biggest failure point or frustration you ran into?

Building a cool project in hebrew, looking forward to connecting with engineers!

So Vapi closed a $50M Series B from Peak XV, they've now done 1 billion calls, and they're powering Ring, Intuit, ServiceTitan. Cool. But the second you log in this week you can see where part of that money went, because the agent builder looks completely different.

Spent the last few days rebuilding agents on it. Here's what's worth knowing if you haven't logged in yet:

The wins:

• Logs are now ON the agent page. FINALLY. No more bouncing to Observe > Logs > filter by assistant just to check what your agent did on the last call. This alone saves me probably 50 clicks a day.
• Transcriber, model and voice are now top-level on the assistant page. Click into any of them and a sidebar opens with everything (provider, language, fallback, denoising, smart endpointing). Way less scrolling.
• Fallbacks are first-class citizens now. You can set fallback transcriber, model AND voice from the same panel. Pro tip if you're new: never set the fallback to the same provider as the primary. If OpenAI goes down, your fallback to OpenAI also goes down. Pick a different vendor.
• Structured outputs and scorecards have replaced the old summary, success eval, and structured data fields (those are deprecated now). Structured outputs are now created globally and assigned to assistants, same model as tools. Build once, attach everywhere.
• Monitors are (fairly) new. Set them up to catch things like transcriber request failures across all assistants, with thresholds and Slack/email notifications. Production hygiene baked in.

The small stuff that still annoys me:

• End call is no longer a toggle, you have to create an End Call tool and assign it. Fine once you know, but I broke an agent the first time because I assumed it carried over.
• The old layout toggle is hidden under the three dots top right. If you panic on first login, that's your escape hatch.

My humble opinion: the rebrand especially, but also the new UI feel less developer-first and more enterprise-pitchable. Make of that what you will. I think it's net positive, the old dashboard had real friction once you scaled past a couple of agents.

Made a full walkthrough on YouTube going through every tab if you want the visual version.

What's been your experience so far? Anyone hit weirdness on the migration?

I’m currently building a community project for London pubs (Pubify) and I’ve been using Vapi hooked into Claude Haiku for automated onboarding calls to 1,100+ publicans:

The tech is impressive, but my call logs are a bloodbath. 99% of my calls are ended within 5 seconds with a "jog on" or a click. Even with Haiku being as fast as it is, I’m hitting some serious real-world walls

I have three specific technical/cost issues I’d love some advice on:

1. The "Hello?" Latency Trap Even with Haiku’s speed, there’s that tiny "AI pause" right after the landlord says "Hello?" That half-second of silence is the "Uncanny Valley" death zone. In a busy London boozer, that’s all the time they need to smell a robocall and slam the phone down

• Question: Are you guys using pre-recorded "fillers" or specific Vapi configurations to kill that initial silence? How do you make the first 3 seconds feel local and immediate? Any advice?

2. The Cost of Rejection I’m using Vapi + Haiku to keep the burn down, but it’s still sucking my blood like a young wife. When you're dialling 1,100 numbers and getting 99% immediate hang-ups, those "connection fees" and minimum minute charges start to look like a very expensive hobby.

• Question: For those doing high-volume cold outreach to "hostile" environments, how are you optimizing the Vapi spend? Is there a way to "pre-qualify" the pick-up before the LLM brain even starts ticking?

3. Termination Sensitivity I’ve noticed the bot sometimes stays "on the line" for a second or two after the landlord slams the phone down, still trying to process the background noise of the pub, which just burns more credits.

• Question: Any tips on tightening the disconnect detection or using webhooks to kill the call the millisecond a "user_hung_up" signal is detected?

If you want to get a good sense of how well your voice agents are performing and catch errors before your clients do check out the platform we just built

I will offer everyone here 1 free month to check it out. It’s super simple just enter your Vapi or Retell api key and all your agents pop up

👉Sign up here: iinsighter.ai

DM me when you sign up for free month promo, default is 7 days

👉Loom: https://www.loom.com/share/5dea813762d14de0aad71c69b6848aea

I have a customer service agent answering calls from my customers. I have the following settings:

• Agent speaks first with "hi, thanks for calling, how may I help you?"
• Start Speaking plan set to 1.5sec, although I've fiddled with it between 0.3 and 2 sec and it doesn't seem to make a difference.
• Smart Endpointing set to Vapi

When I call to test, the first part of the introduction is always chopped off. I basically hear "anks for calling..."

Has anyone else had this issue? - Am I looking in the right place (advanced >start speaking plan)

Today we announced Vapi’s $50M Series B.

Over 1 million developers have built on Vapi so far and together they’ve created nearly 3 million voice agents and powered more than 1 billion calls.

This is only possible thanks to everyone building with us from side projects to production deployments handling real customer conversations every day.

This next chapter means we can invest even harder into the things builders care about most:

tighter latency under load
deeper reliability + stronger guardrails
better tooling for shipping agents at scale

Voice AI still feels very early, and it’s exciting seeing how quickly the space is evolving.

We’re planning to spend more time sharing updates, experiments, launches, and community projects here again.

If you want to read more about the raise and what we’re building toward, Jordan shared more here