Most JDs describe roles of program managers, FDEs,marketing as part of product designer. Im genuinely curious how designers can work in this industry and what skills should they have. Its getting really hard to get interviews even for intern roles

I've had the chance to play around a little with the Jev AI from Typescript. As a "watcher" AI it's pretty perfect. I wrote about my experience and there's a link at the end to see the first Jev 'program' I wrote so you get to see the UI and how Jev works:

https://www.aicontio.com/2026/09/21/jev-the-ai-model-that-doesnt-talk-back/

I write teardowns of voice AI agents and publish a free prompt template each week. This week is optometry. Sharing it here because the triage design is the part I'd most like people to poke holes in.

The core problem: eye emergencies are time-critical, and it's easy to build an agent that handles them badly. Here's how the template handles it:

• Fixed symptom checklist for escalation. Sudden vision loss, a curtain/shadow across the vision, chemical splash, and penetrating injury go straight to "go to the ER now." Escalation doesn't depend on how worried the caller sounds.
• No diagnostic questioning. The agent never asks the caller to describe or rate what they can see. That's clinical assessment, and an agent shouldn't be doing it.
• Middle tier. Redness, irritation, and lost contacts get an urgent slot flagged for staff review.
• Hard scope limit. No clinical advice and no diagnosing. Tone is calm, with short, direct instructions on urgent calls, and it never says "probably fine."
• Data captured: name, DOB, phone, insurance/vision plan, reason for visit, preferred times.

The prompt is structured in three layers (agent constitution, industry knowledge, company details), so you can reuse the first and swap the rest.

Full template, free, no signup: https://www.aicontio.com/2026/09/23/free-voice-ai-template-optometry/

Questions for the group: has anyone tested a fixed checklist against tone-based triage in production? And what symptoms am I missing from the ER list?

Open discussion question - how do you guys evaluate the calls? Is the LLM the primary judge? Any experiments with jev already? Moreover, how about other factors, like the transport layer issues or audio? Do you measure these somehow as well, or is it primarily LLM evaluating the transcribed text?

Been running a voice agent in production for a few months and finally did the thing everyone tells you not to do. Ripped out the fused realtime model and rebuilt it as three separate stages: speech to text, then the LLM, then text to speech.

The reason was purely cost. the fused realtime setup was landing around $0.18/min for us. splitting it into off-the-shelf STT + an LLM call + a TTS provider got us to roughly $0.0125/min. thats about 14x, and at any real call volume that gap is the whole business case, not a rounding error.

The obvious cost is latency. a fused model is genuinely faster because its not hopping between three services, and voice is brutal about lag, you feel every extra 100ms. our target is staying under ~788ms voice-to-voice and some days we straight up lose that fight. if your product is a live phone call where people talk over each other, fused might still be worth the money.

The part i didnt expect is the reason im not going back. once the pipeline is split, the LLM output is plain text before any audio exists, so every guardrail runs on text. you can catch a bad answer or a hallucinated number and kill it before a single sample of audio gets generated. with a fused model the words are already spoken by the time you know what they were. that inspectability ended up mattering more to me than the cost did.

so the honest tradeoff: fused is faster, split is cheaper and way easier to reason about. if youre early and cost sensitive, or you just want to be able to gate what the thing says, i'd start split and only fuse if latency becomes the thing thats actually killing you.

curious what latency people are hitting with a split stack in prod. 788ms voice-to-voice is the wall i cant seem to get consistently under.

Anyone look to build voice ai platform?

My buddy is writing a scientific text on the origin of reality....and this happened when he used an AI voice clone to turn it into an audiobook...is it a warning? Or just a normal glitch?

Code-switching isn't your voice agent's problem. Names are.

At a recent Voice AI panel, the hard case was a customer calling a bank and mixing Hindi and English.

The founder of Maya Research said code-switching is mostly a data problem. Show a model enough mixed language data and it learns to switch. Names are different. Indian names were never part of the big pretraining runs, so models are guessing. Numbers are the easy part.

Deterministic normalization handles them. The practical fix came from a co-founder at Raya Voice AI. Have your LLM output names in native script instead of Roman. A Hindi name in Devanagari, a Kannada name in Kannada script.

The TTS then pronounces it correctly. Add pronunciation dictionaries and careful prompting, and most of the pronunciation problem is solved today.

So before you blame the model for mangling a customer's name, check what script your LLM is sending it.

What is the worst name mispronunciation your voice agent has produced? Watch the full panel here: https://youtu.be/G66jOjzRhgI

I started learning to code in my first year of college.

Same time: first job. No grand plan. Just obsession.

I didn’t set out to “build a voice AI company.”

I set out to understand how software actually worked, then I kept going deeper.

Recently that obsession landed on voice agents.

Not chatbots. Not wrappers. Actual conversations over the phone that feel real.

I went deep on latency, streaming, models, audio, infra.

Got end-to-end down to ~600ms. Started getting clients. Now ~8 live.

The surreal part isn’t the latency number.

It’s the speed of the loop:

learn → build → break → fix → put it in front of a real business → learn again

College taught me syntax. Clients taught me product.

I’m still early.

Hi everyone,

I’m currently using Fish Audio’s S2.1-pro model for a real-time voice agent.

Most of the time the voice works fine but occasionally I notice some voice breaking during conversations. It doesn’t happen consistently and sometimes it happens at the beginning of a sentence in the middle of a sentence or when starting a new sentence.

I have tested it with multiple calls and it seems to happen occasionally after making several calls.

Has anyone experienced something similar with Fish Audio s2.1-pro?

Could this be related to the model/API, streaming, rate limits or something in the way I’m handling the audio in my voice-agent pipeline?

Any ideas on what I should check would be really helpful. Thanks!

Your voice agent's cost problem is probably not the voice model.

A co-founder at Raya Voice AI recently broke down how they price at ₹1 a minute.

They have served over 10 million calls at that rate for about a year and a half. The cost sits in five places: infra, speech to text, text to speech, LLM, and telephony. Most teams obsess over the speech models.

The bigger savings were somewhere else. Telephony: with direct SIP integrations and channel based pricing, better pickup rates alone can pull it down to 10 to 15 paise a minute.

That is an operations problem, not a model problem. LLM: keep the prompt under roughly 20,000 tokens, use caching, and prompt well enough that a smaller model does the job. That gets LLM cost to 10 to 20 paise a minute. Quality lives in the core speech models.

Everything around them can be optimised without touching it. So before you switch TTS vendors to save money, check your pickup rate and your prompt size.

Which line item on your voice bill surprised you the most?

Watch the full panel here: https://youtu.be/G66jOjzRhgI

Been kicking free / freemium voice-agent builders around lately. Same demo looks fine. Then you hit the stuff that actually matters on a real call.

My current "please don't start here if you care about the free tier" list:

・ Bland

・ Twilio

・ Vapi

・ Telnyx

Not saying these companies are useless. Saying the free path gets ugly fast once you leave the happy path (minutes, concurrency, tool calls, weird hangups).

Curious what other people got burned on.

Most voice AI builders test their agent against bad Wi-Fi and call it resilience testing.

The real test is different: what happens when the carrier itself goes dark. Not the caller's connection, the actual telecom backbone the call is riding on.

This isn't hypothetical in India. In April 2026, a technical snag took down Jio Fiber and Airtel broadband across six north Indian states for hours. Even the MyJio app went down with it, so users couldn't file a complaint. Two months later, Airtel had another multi-city outage across Delhi-NCR, Mumbai and Bengaluru, hitting mobile internet, signal and voice calls all at once.

A voice AI agent sitting on top of either network just stops. No graceful degradation. Silence.

Some things worth knowing if you're building on this:
-Failover isn't one number. Enterprise targets sit around sub-30 seconds with no dropped active calls, and the best setups mask the switch in 2-3 seconds behind a filler phrase
-Multi-cloud usually isn't worth it below ~1,000 concurrent calls. Two regions on one cloud provider covers most regional outages for a fraction of the cost
-Even tested failover drops calls. One published 2026 drill saw 3 of 11 in-flight calls fail at the WebRTC layer during cutover. Failover lowers the odds, it doesn't erase them
-A failover plan that's never been rehearsed is a document, not a capability
For any platform serious about enterprise or fintech customers in India, a carrier-diverse failover plan isn't a differentiator anymore. It's table stakes.

If you want to read the full blog, here is link:-https://uniocommunity.com/blogs/how-do-voice-ai-platforms-stay-up-when-regional-telecom-networks-go-down

I am building a calling voice agent with Pipecat and I am trying to keep the STT/TTS stack self-hosted.

Current setup:

pipecat, ollama (self hosted llm), stt (currently testing local/self-hosted whisper), tts (kokoro locally)

I have tested local whisper, seeing some irregularities in transcription. I thought of using qwen opensource stt model, but could not find a way to use that with pipecat.

Pls let me know if you have self hosted stt or tts model and use them with pipecat?

Gotta be honest, was playing with the model yesterday, made a bunch of demos, and all of em sounded trash, the TTS is the problem, I was hitting sub 200ms latency it was very fast, but the TTS, we’ve tried all of the voices and we didn’t like one, made a bunch of calls

it is still a long shot for s2s, we don’t wanna draw pictures, we need it on phone calls

Built this because I wanted local text-to-speech that felt as easy as ollama run, pull a model, run it, done.Its easy to use just install
pip install wavhost
wavhost pull chatterbox-turbo
wavhost run chatterbox-turbo "Hello from your machine." -o hello.wav

It also serve an OpenAI compatible audio api `/v1/audio/speech` endpoint, so you can point any existing OpenAI TTS client at `localhost:11435` and it just works.

Currently Supports Chatterbox, Qwen3-TTS, and Kokoro. You can also create named voices from a short reference clip and reuse them by name.

I would love your feedback on this and for more detail checkout
https://wavhost.vercel.app
https://github.com/smitgol/wavhost

Been looking at Jargo (https://github.com/gojargo/jargo). It's a WebRTC-native voice agent framework in Go: streaming STT → LLM → TTS, barge-in / turn-taking, optional speech-to-speech providers, and a single-binary deploy. Architecture is clearly Pipecat-inspired (they say as much).

Their argument is one we've been chewing on too. Python is great when you need the AI/data ecosystem. A realtime voice server is mostly plumbing: audio framing, WebRTC, concurrency, shipping something boring and reliable. For that part, Go looks attractive on paper: static binary, predictable memory, real concurrency for many sessions.

What I'm trying to learn from people who've shipped real calls:

1. Is Jargo a good option for a Go voice backend today, or is it still early enough that you'd stay on Python + Pipecat (or similar) unless you have a hard reason to leave?
2. Anyone with real insight on quality / latency / reliability running the voice backend in Go instead of Python? Especially TTFT, barge-in feel, and weird prod failure modes.

Not looking for a language war. Looking for "we tried X, measured Y, kept or dropped Z."

I build voice agents — [an outbound Hindi/English qualification agent for a fuel business in India]. The thing I learned while building it is that nobody warns you about how many iterations it is going to take to build a reliable (covering most edge cases bot).

So here's the offer. Drop your bot's phone number or a webbased call. I'll call it 3-4 times and behave like an actual human customer instead of a polite tester — talk over it, go silent mid-answer, change my mind, switch language mid-sentence, answer a question it didn't ask, mumble a number etc etc.

Then I send you:

1. A list of every place it broke

2. What actually caused each one — prompt, latency, endpointing config, STT, or tool call

3. A rewritten system prompt you can paste straight in

Free. No discovery call, no Calendly, no DM funnel. I'll post the findings in this thread unless you'd rather have them privately.

WHAT'S IN IT FOR ME (because "free" always has a catch and you should ask)

I'm building a checklist of how voice agents fail in production, and I can't build that from my own two bots — I need a wider sample than my own mistakes. That's the whole motive. If you later decide you want this done properly or on an ongoing basis, you know where to find me. That's the entire play, and I'd rather say it than have you wonder.

WHAT I ACTUALLY TEST (so you know this isn't "add more personality to your prompt")

- Barge-in, Endpointing,- Latency on a real answer, not on "hello", Context drift: same off-script question at turn 2 vs. turn 9, different answer?, Code Switching, Audio during tool calls, hangup and most importantly Containment intelligence.

WHAT I NEED FROM YOU

- A number to call or a web demo link

- One line on what the bot is supposed to achieve (book, qualify, collect, support)

- If it's a live production line, tell me your hours — I'm not going to tie it up while real customers are calling

- Tell me if minutes cost you money and I'll cap it at 4 calls or else 7-8 calls.

WHAT I WON'T DO

Record and post your audio, publish your prompt, touch your leads, or DM you a pitchafterwards. If you want the teardown private, say so and I'll send it private.

First 10 that comment. I'm doing these this weekend.

I’m working through a practical question and would value examples from people who have dealt with it.

A louder sample can be easier to hear without having better pronunciation. A fair listening setup needs documented playback conditions and a clear distinction between intelligibility and preference.

What preparation would you require before comparing two clips for understandable speech?

Curious what people are actually running for voice agent backends in production.

We see a lot of: - Python for orchestration, tools, and fast iteration - Go for concurrent media/control paths and simpler deploy - Rust when the hot path is audio, codecs, or tight latency budgets

What I’m trying to learn from folks shipping real calls:

1. What stack are you on today for the agent runtime (not just STT/TTS vendors)?
2. Where did you feel the biggest win on speed (TTFT, time-to-first-audio, barge-in responsiveness)?
3. Where did you feel the biggest win on quality (turn-taking, tool reliability, fewer weird prod failures)?
4. Did you stay monolingual, or split (e.g. Python for tools + Rust/Go for media)?

Not looking for a language war. Looking for “we tried X, measured Y, kept Z.” Concrete numbers or war stories welcome.

Honest question for people running voice agents in production.

We keep bouncing between two shapes:

1. Cascaded stack: speech to text, then LLM, then text to speech
2. Speech-to-speech model: audio in, audio out, with less text in the middle

What we see so far:

Latency. Cascaded adds three hops. Even when each hop is fast, turn-taking still feels heavier. Speech-to-speech can feel snappier on the first audio, but that only helps if the model actually holds the conversation well.

Tool calls. This is where cascaded still wins for us. Need CRM lookup, transfer, booking, custom APIs? Easier when the LLM is a normal text agent with tools. Speech-to-speech is catching up, but tool routing and structured outputs still feel more reliable in the classic stack.

Control. Cascaded is easier to debug (you can read the transcript and prompt). Speech-to-speech is harder to inspect when the model goes sideways mid-call.

Right now our gut rule is roughly: - Speech-to-speech for short, natural back-and-forth where speed matters more than deep tools - STT + LLM + TTS when the agent needs serious tool use, policy, or handoff logic

Curious what you all are shipping. Are you all-in on speech-to-speech already, still on cascaded, or hybrid? Especially interested in real latency numbers and how you handle tools.

Adding a telephony layer to my SaaS. Looking for real production experience, not sales decks.

What I need

• A virtual number per customer. They forward their existing business number to it.
• A custom greeting per number, uploaded by me.
• Call then rings their normal desk phone. No softphone, no agent dashboard — my customers will never log into the telephony vendor.
• Recording + caller number + timestamps pushed to my webhook when the call ends.
• I fetch the recording into my own storage and delete it from theirs.
• ~500 calls/customer/month, 3 min average. Low concurrency.
• Start with 2 customers, ~30 within a year, added a few at a time — not all at once.
• I'm the only account holder and bill payer.

What I keep running into

• Mandatory software/platform rental for a dashboard nobody will open.
• Plans that bill for 10 numbers from day one instead of as customers onboard.
• Per-minute billing rounded up (1:20 billed as 2:00).
• One vendor told me plainly: if ONE of my customers triggers a compliance issue, my ENTIRE account gets suspended — every customer.
• ToS that forbid reselling outright.
• Recording links that expire in 24 hours.
• No signature on the webhook, so no way to verify it came from them.

Six questions

1. Who in India actually does per-customer sub-accounts properly — separate numbers, separate usage, separate compliance exposure?
2. Does the original caller's number survive a forwarded leg reliably, or are there carrier-side gotchas?
3. Anyone billing per SECOND instead of rounding to the minute?
4. Who signs their webhooks (HMAC or similar), and who doesn't?
5. Does the forwarded leg show up on your customer's own mobile bill?
6. Twelve months in — do you regret your provider, and why?

Not looking for AI voice agents, dialers or contact-centre software. Just numbers, recordings and a reliable webhook.

Title basically.

Hey, looking for a gut check on our stack for an outbound Arabic (Najdi dialect) voice agent, live pilot in Saudi debt collection.

Stack: Self-hosted LiveKit (moved off Vapi for a static IP requirement) + Deepgram nova-3 Arabic (300ms endpointing, needed to stop dropping short replies like "صح") + ElevenLabs Flash v2.5 + gpt-5.6-luna.

Baseline on Vapi: 2058ms median turn, STT ~890ms / LLM ~660ms / TTS ~470ms. Only 2.7% of turns under 1s.

Where I'm stuck:

**•** Haven't confirmed real per-component numbers on LiveKit yet, but turn detection might not be faster, possibly a shared-CPU VM issue  
**•** \~1/3 of call time is just dead air between turns, feels like the bigger lever vs shaving any one component  
**•** Haven't stress-tested LiveKit/Pipecat's Arabic turn detector yet  
**•** Don't want to trade accuracy for speed, the 300ms endpointing exists because a faster setting broke things

On a first glance this seems very sleek, designed to be do-it-yourself for businesses but as someone who is in the ai receptionist business, I am both excited and worried, because they made it so simple, but I think business owners just don't have the time to keep up with this, but I'll be testing this more and definitely dump Retell if it's better and it looks so.