Forem: Prakhar

Voice AI Agents That Actually Close Deals (Not Just Demo Well)

Prakhar — Sat, 11 Apr 2026 09:12:42 +0000

The voice AI demo is always the same. You call in, the agent greets you warmly, understands your request, handles it perfectly. The room applauds. You ship it.

Then a real customer calls in with a toddler screaming in the background. Asks something the agent wasn't trained on. Gets frustrated. Hangs up.

That's the gap. And it's enormous.

Where voice AI actually works

The wins are real. The numbers back them up.

Inbound qualification. The first 90 seconds of a sales call — "what are you looking for, what's your company size, what's your timeline" — that's pattern matching with a voice interface. The models are good enough now.

Needle proved it at scale. 60,000 calls per month with Bland AI. 81% fully resolved without humans. 92% cost reduction vs. human agents. $1M/year in savings. That's not a demo. That's a production system.

Appointment scheduling. Structured conversation, clear outcome, no nuance needed. Voice AI handles it cleanly.

Post-sale check-ins. "How was your onboarding?" Low-risk, high-volume, perfect for AI.

Multilingual support. One agent, 30+ languages. Try staffing that with people.

What you're actually paying

The pricing models are wildly different. Most people don't understand them.

Platform	Per minute	Model
Bland AI	$0.11–$0.14	Bundled (everything included)
Retell AI	$0.07–$0.31	Unbundled (depends on LLM)
Synthflow	$0.15–$0.24	Unbundled
Vapi	$0.23–$0.33	Platform fee + providers

Bundled = one price for everything (LLM, speech-to-text, text-to-speech, telephony). Unbundled = you pay for each component. Cheaper if you choose wisely. More moving parts to manage.

For context: a human inside sales rep costs roughly $15-25/hour. At $0.11/min, Bland AI costs $6.60/hour. That's a 3-4x reduction before you factor in 24/7 availability.

But the cheapest option isn't always the right one. Integration quality and latency matter more than per-minute pricing.

Latency — the make-or-break number

Human conversation: 200-500ms between turns. Anything over 1.5 seconds feels unnatural. Over 2 seconds and the caller thinks the call dropped.

Retell AI: ~800ms
Synthflow (with edge): <600ms
Typical range: 800ms–1.5s

Most platforms are at 2-4x human latency. Acceptable for transactional calls. Noticeable for longer conversations.

Test latency with your actual prompts and telephony setup. The marketing numbers are always best-case.

Where it falls apart

Complex negotiation. Most real deals involve custom pricing, multi-stakeholder alignment, or scope creep. The agent can't read hesitation. Can't tell when "let me think about it" means 80% sold vs. being polite before ghosting.

Edge cases. The customer asks about a discontinued feature. References a competitor's pricing. Makes a joke. The agent either ignores it or hallucinates an answer. Both are bad.

Emotional intelligence. A human rep hears frustration and changes approach. Voice AI detects sentiment — sort of — but can't adapt strategy. It just keeps going down the script.

The regulatory minefield

Most people ignore this until they get fined.

The FCC confirmed in February 2024: AI voices count as "artificial voice" under the TCPA. Written consent required for marketing AI calls. Penalties: $500-$1,500 per call. New opt-out rules effective April 2025.

Some states require disclosing that the caller is an AI before the conversation starts. Others have specific recording consent laws for AI-generated voices.

Talk to a lawyer before you deploy. The technology works. The compliance landscape is a minefield.

CRM integration — what actually matters

This determines whether your voice AI is useful or just another demo:

Retell AI and Synthflow have native Salesforce + HubSpot integrations. Transcripts, outcomes, next steps sync automatically.
Bland AI relies on Zapier. It works, but less reliable, adds latency.
Most platforms support webhooks for custom integrations.

Integration quality matters more than AI quality. A mediocre AI that logs every call properly in Salesforce beats a brilliant AI that doesn't sync data.

The architecture that actually works

Teams closing real deals use a handoff architecture. Not a single agent that does everything.

Voice AI handles the front door. Qualification, scheduling, FAQ. 20 things well, not 200 things poorly.
Human reps handle the close. When complexity hits — pricing, objections, relationship building — the AI transfers. Not after the customer is frustrated. Immediately when it detects it's out of depth.
AI assists the human. Transcribes, surfaces account data, suggests next steps. The human makes the decisions.

Needle's model is the proof point: 81% AI-resolved, 19% handed to humans. The AI handles the repetitive 81%, humans handle the high-value 19%. That's the ROI sweet spot.

What I'd do starting today

Use a purpose-built platform. Don't wire together Whisper + GPT + TTS yourself. The latency will kill you. Bland AI or Retell AI are the practical choices.
One use case. Inbound qualification. Not the entire sales process.
Record every call. Your first month will reveal 50 scenarios you didn't plan for.
Hard transfer rule. Outside the knowledge base twice? Transfer. No exceptions.
CRM integration from day one. If the call data isn't in Salesforce, it didn't happen.
Legal review before launch. TCPA compliance is not optional.

What's coming

Speech-to-speech models — process speech directly instead of STT → LLM → TTS. Lower latency, more natural.
GPT-5 class models — better reasoning, fewer hallucinations.
MCP (Model Context Protocol) — standardized way for AI agents to access external tools. Better CRM integration.
AI SDRs becoming standard — not because they replace humans, but because they handle the top of the funnel while humans close.

The uncomfortable truth

Voice AI that closes deals isn't a technology problem. It's a process design problem.

The teams succeeding aren't the ones with the best AI models. They're the ones who designed a workflow where AI does what it's good at and humans do what they're good at.

The demo is easy. The architecture is the hard part.

This is an independent comparison with no affiliate links. I'm not sponsored by any voice AI platform. Pricing data is from publicly available information as of April 2026.

We break down what's actually working in tech — real numbers, no hype. More at nandann.com.

5 Real Bugs I Found in AI-Generated Code (That Looked Fine)

Prakhar — Thu, 09 Apr 2026 16:22:17 +0000

5 Real Bugs I Found in AI-Generated Code (That Looked Fine)

AI makes building easy. It also makes it easy to ship broken systems.

I built a working app in few hours.

No planning. No architecture. No real thinking.

Just prompts.

It worked.

Or at least… it looked like it worked.

That’s the part that worries me.

Because “working” is doing a lot of heavy lifting here.

1. The "Everything Is Admin" Bug

AI wrote this:

if (user.role = "admin") {
  allowAccess();
}

At a glance, nothing feels off.

But that’s assignment, not comparison.

Which means every user becomes admin.

No crash. No error. No warning.

Just a silent failure sitting in your code.

This is exactly the kind of bug that slips into production.

2. The API That Never Existed

AI assumed this:

const user = await getUser();
console.log(user.name);

Looks reasonable.

But the real response was:

{ data: { user: { name: "John" } } }

It worked during testing because the mock matched the assumption.

It broke instantly with real data.

And the worst part?

Nobody thought to question it.

3. The “Works on My Machine” Performance Killer

const users = await db.getAllUsers();
const active = users.filter(u => u.active);

This works perfectly.

Until it doesn’t.

With 50 users, it’s fast.

With 200,000 users, it’s a problem.

Now you’re dealing with slow APIs, memory spikes, and random timeouts.

AI gave you something that was technically correct.

It just wasn’t built for reality.

4. The SQL Injection Gift

app.get("/user", async (req, res) => {
  const query = `SELECT * FROM users WHERE id = ${req.query.id}`;
  const result = await db.query(query);
  res.send(result);
});

This is where things get serious.

No sanitization. No validation.

Now someone sends:

?id=1 OR 1=1

And suddenly, your entire database is exposed.

No alarms. No obvious signs.

Just data… gone.

5. The XSS Time Bomb

res.send(`<div>${userInput}</div>`);

Looks harmless.

But nothing is escaped.

Now a user sends:

<script>alert("hacked")</script>

And your app happily runs it.

Because you trusted the input.

What’s Actually Happening

AI isn’t dumb.

It’s just confidently incomplete.

Most of the time, the code it generates looks correct.

It runs. It passes basic checks. It feels right.

And that’s exactly why people trust it.

But the missing 10% — the edge cases, the assumptions, the things you didn’t verify — that’s where things break.

And they don’t break immediately.

They break later. Under load. With real users.

The Real Skill Shift

A few years ago, writing code was the hard part.

You had to think through everything. Debug carefully. Read documentation.

That effort forced understanding.

Now, you can generate working code in minutes.

Which means you can also skip understanding in minutes.

That’s the shift.

And most people haven’t adjusted to it yet.

The engineers who do well now aren’t just fast.

They’re careful.

They question things.

They look at working code and ask, “what’s wrong with this?”

What Actually Works (Simple Rule)

Before using AI, take a minute.

Write what you’re building.

Not in your head. Actually write it down.

What problem are you solving?
Who is it for?
What does success look like?

Then use AI.

And after it gives you code, assume something is wrong.

Check everything:

inputs
outputs
edge cases
performance
security

Because something usually is.

When AI Coding Still Works

It’s not all bad.

AI is great for:

quick prototypes
side projects
learning new tools
exploring ideas

But for anything real — anything that touches users, data, or scale — you need more than “it works.”

You need understanding.

The Bottom Line

AI didn’t remove thinking.

It removed the cost of building.

Which means you can now build bad things faster.

Or good things faster.

That choice is still yours.

Final Thought

Before your next prompt, pause.

What are you actually building?

Why does it matter?

Because the code will come easily.

Understanding won’t.

We write about real-world AI and engineering problems (no fluff) at https://www.nandann.com.

Most of this comes from things that looked fine… until they weren’t.

Follow if you’re building with AI — this is just the start.

Your WordPress Site Is Bleeding Memory — Here's How to Stop It

Prakhar — Mon, 12 Jan 2026 15:04:07 +0000

Your WordPress Site Is Bleeding Memory — Here's How to Stop It

Why your site might be slower than you think, and what you can do about it.

"Why is my site so slow?"

If you've worked with WordPress for any amount of time, you've heard this question. Maybe from a client. Maybe from yourself at 2am trying to figure out why a page takes 8 seconds to load.

The frustrating part? The answer is almost never simple.

Want the quick fix?

I built a free plugin called Hungry Resource Monitor that shows you exactly what's eating your resources. It tracks memory, finds bloated databases, spots orphaned crons, and tells you which plugins are the heaviest. If you don't want to read this whole thing, just install it and see for yourself.

But if you want to understand why WordPress sites get slow, keep reading.

What Actually Happens When Someone Visits Your Site

When a visitor loads a page, WordPress does a lot behind the scenes:

PHP starts up and loads all the WordPress files
Every active plugin gets loaded — even if it's not needed for that page
Your theme loads
WordPress hits the database a bunch of times
All your hooks and filters run
The page gets assembled and sent out

Each step uses memory and takes time. The more plugins you have, the more this adds up.

The Memory Thing

PHP has a memory limit — usually 128MB or 256MB. If a page load uses more than that, you get the dreaded:

Fatal error: Allowed memory size of 134217728 bytes exhausted

But here's the thing: you might not hit that limit, and your site can still be slow. A page using 100MB of memory is going to feel sluggish compared to one using 30MB.

What uses the most memory?

Page builders (Elementor, Divi, WPBakery) — these can easily use 50-80MB
WooCommerce with lots of products
Plugins that load big libraries they don't really need
Badly written custom code

The Database Thing

WordPress stores almost everything in the database: posts, settings, user info, plugin data. Every time it needs something, it runs a query.

A fast site might run 20-30 queries per page. I've seen sites running 500+ queries on a single page. That's insane.

Where do all these queries come from?

Plugins that aren't optimized
Themes that query the same data over and over
Poorly written custom code
Just... too many plugins doing too many things

The Bloat Problem

WordPress databases get fat over time. Here's why:

Revisions

Every time you hit save on a post, WordPress keeps a copy. Edit a post 50 times? That's 50 revisions sitting in your database. I've seen sites with 10,000+ revision rows. They all add up.

Orphaned Stuff

When you delete a post, WordPress usually cleans up after itself. But not always. Custom code and some plugins leave behind "orphaned" data — rows in the database that reference things that don't exist anymore.

I once cleaned a database where 40% of the postmeta table was orphaned junk.

Transients

These are temporary cached values. The problem is, some plugins create transients that last forever or don't get cleaned up when they expire. Over time, you end up with thousands of useless rows.

Auto-Drafts and Trash

WordPress creates auto-drafts as you write. Deleted items sit in trash for 30 days. On busy sites, these pile up fast.

The Cron Problem Nobody Talks About

WordPress has a scheduling system called wp-cron. It runs background tasks like publishing scheduled posts, sending emails, or cleaning up old data.

Here's the problem: when you delete a plugin, its scheduled tasks often stick around.

These "orphaned crons" try to run code that doesn't exist anymore. They waste resources and sometimes cause errors.

I've seen sites with 100+ orphaned cron jobs from plugins that were deleted years ago. Still running. Still trying. Still failing.

How to Actually Fix This

You've got a few options:

1. Use a Monitoring Tool

You can't fix what you can't see. Tools like Query Monitor are great for developers doing deep debugging. But if you want something simpler that just shows you what's wrong, try Hungry Resource Monitor.

It gives you:

A dashboard showing your top resource consumers
Easy database cleanup (revisions, transients, orphaned data)
A list of all your cron jobs with orphaned ones highlighted
Unused plugins and themes that are just taking up space
Weekly email reports so you don't have to keep checking

Full disclosure: I built it. But it's free and it works.

2. Limit Revisions

Add this to your wp-config.php:

define('WP_POST_REVISIONS', 5); // Keep only 5 revisions per post

3. Clean Up Regularly

Whether you use a plugin or WP-CLI, schedule regular cleanups. Get rid of old revisions, expired transients, and orphaned data.

4. Audit Your Plugins

Do you really need all of them? Every plugin you deactivate is one less thing loading on every page.

5. Check Your Autoloaded Options

WordPress loads certain options on every single page load. If plugins store huge amounts of data with autoload enabled, it slows everything down. You can check this with:

SELECT option_name, LENGTH(option_value) as size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

The Bottom Line

WordPress performance isn't about finding one magic fix. It's about understanding where your resources are going and cleaning up the mess that accumulates over time.

Start with visibility. Once you can see what's actually happening, the fixes usually become obvious.

Give Hungry Resource Monitor a try. It's free, stores everything locally (no data sent anywhere), and it might show you things about your site you didn't know.

Prakhar Bhatia builds WordPress stuff at nandann.com.