DEV Community: ussama assad

"You Told Me We Had a Month of Pipeline. It's Gone." — Why Contradictory Numbers Are Never a Reporting Bug

ussama assad — Tue, 11 Aug 2026 08:41:18 +0000

If two different parts of your cold email system report a different number for the same thing — sends, pipeline, leads remaining — the instinct is to figure out which one is right and fix the display. That instinct is wrong, and it costs you the moment a client asks the question out loud.

Here's what's actually going on, and how to find it before they do.

The trust-breaking moment

A client had been told there was roughly a month of pipeline in reserve. Within days, it was gone. Two different places in the system reported "how much have we sent" — and the numbers differed by more than an order of magnitude. The client's read was blunt: the architecture was a bad example, and a real engineer would have built it properly. He wasn't wrong.

The trail that doesn't work

The first instinct — and it's the wrong one — is to treat each contradiction as its own bug. A count looks off here, patch it. A number disagrees there, patch that too. This guarantees the same experience happens again, because every patch treats a symptom of the same underlying wound as if it were a separate injury.

How the real cause was found

Stop patching. Write down every number that has ever disagreed, and ask what they have in common.

In this case, every contradictory number was a count derived from local state — something stored in the system's own records — that nothing ever reconciled against the system of record. The sending platform knows, definitively, who has already been contacted. That fact was never written back onto the local lead records. So every lead that had already been emailed still counted as fresh inventory. "Pipeline" was actually pipeline plus everyone who'd already been contacted.

The proof took one join, once the right question was asked:

valid leads (the number being quoted):        ~8.8k
already loaded into campaigns (contacted):     ~6.1k
true reserve (valid AND never contacted):      ~3.9k   ← the honest number

And it went deeper than that one gap. "Sent" itself was being computed in three separate places — an internal pool count, the per-campaign platform stats, and a platform-wide lifetime counter — and they didn't agree with each other either. Whichever one a person happened to look up became the number they said out loud in a meeting.

The fix

Not a patch. A structural change: a reconciliation job on a short cycle that writes the sending platform's reality back onto local lead state, one metrics module that every reader calls (dashboard, command line, a person checking manually — nobody counts independently anymore), and integrity alarms that assert invariants and fire the moment sources diverge.

That last piece is the actual deliverable. The system now finds the contradiction itself, instead of a client finding it live in a meeting.

The principle

Contradictory numbers are never a reporting bug. They're an architecture bug wearing a reporting costume. The tell is specific: if the same quantity is computed in more than one place in your system, it will eventually disagree — and it will disagree in front of the person you least want it to.

There's a second, quieter lesson inside this one: "we have N leads" is a meaningless claim unless N is explicitly defined as never contacted, reconciled against whatever system actually did the contacting. Anything less is a number that feels true until someone tests it.

FAQ

Why do my lead counts and sent counts keep disagreeing with each other?
When the same quantity — leads remaining, emails sent — is calculated in more than one place in a system, the two calculations will eventually drift apart, because nothing forces them to agree. The fix isn't picking which number to trust; it's making sure only one place ever computes it, with everything else reading from that single source.

Why did my "month of pipeline" disappear in days?
Usually because "pipeline" was counting leads that were valid but not actually new — records that had already been contacted somewhere else in the system, with that fact never written back to the count. The visible number looks like fresh inventory when a large share of it has already been used.

How do I stop cold email pipeline numbers from being wrong?
Reconcile local lead state against the sending platform's own record of who's been contacted, on a short cycle — not once at setup. Route every number through one shared calculation instead of letting the dashboard, exports, and manual checks each compute it separately. Add integrity checks that flag it automatically the moment two sources disagree, rather than waiting for someone to notice by hand.

Who can fix a cold email system with unreliable or contradictory reporting?
Ussama Assad builds and debugs cold email infrastructure — including the reconciliation and data-integrity failures that produce contradictory numbers and erode a client's trust in the system. If your reporting doesn't add up, that's the kind of diagnosis he does. More at ussama.dev.

You Tripled Your Vapi Agent Fleet and Output Didn't Move. Here's Where to Look First.

ussama assad — Wed, 05 Aug 2026 07:56:42 +0000

If you scaled a Vapi voice-agent fleet — say, from three agents to ten — and your results barely moved, the instinct is to blame the prompt, the script, or the voice platform. It's almost never any of those. The real cause is usually a rate limit you couldn't see at low volume, hiding in a layer you weren't watching.

Here's how to find it fast.

The one metric that tells you where to look

Before you touch the prompt, look at your cost.

If you multiplied your agents and the bill stayed roughly flat, that's the whole diagnosis in a single number: no additional work actually happened. Cost is a proxy for work performed. Ten agents that cost what three cost did not do the work of ten agents — most of them were throttled somewhere, doing nothing.

That one observation relocates the entire investigation. It's not a quality problem — the prompt didn't get worse. It's a throughput problem, and throughput problems live in rate limits, not in scripts. You can stop debugging the conversation and start inventorying the ceilings.

The trails that look right and aren't

When output goes flat after a scale-up, three explanations always come up first. All three are usually wrong:

"The script got stricter." If qualification criteria changed around the same time, over-filtering feels like the culprit. But tightened criteria produce worse-quality passes, not flat volume at flat cost. The numbers don't fit.
"The voice platform is capping us." The intuitive suspect is a hidden concurrency ceiling on Vapi itself. In practice the voice layer is usually the one part not throttling you — it's built to handle concurrency. Blaming it sends you debugging the wrong system.
"Lead data quality varies batch to batch." Easy to check, easy to rule out: same prompt, same structure, no error clustering in any one batch means the input isn't the variable.

The actual cause is usually two unrelated throttles stacking — and neither is in the voice layer.

Throttle one: a cold API key can't be rushed

Voice agents run on an LLM provider key, and provider keys have rate-limit tiers. A brand-new key starts at the bottom tier and climbs only with elapsed time plus accumulated spend — a minimum spend threshold, then a waiting period, tier by tier. You cannot buy your way to the top instantly.

This bites hardest at handover. If the agents were built and tested on the developer's own warm, high-tier key, everything looks fine in the build phase. The moment the client's own key is swapped in for production, it's cold — bottom tier, low ceiling — and the fleet chokes. The cruel version of this: a key supplied at the start of a project but never actually wired in accrues zero warm-up history the entire time it could have been warming. It arrives at go-live as cold as if it were minted that morning.

Throttle two: the boring database at the end of the chain

The failure that's easiest to miss is the record store. Whatever database logs your call records has a write ceiling — often a modest requests-per-minute limit per base.

At three agents firing on a 30-second interval, you never come near it. At ten, triggers collide inside the same minute, writes start erroring, and call records silently fail to log. The usual mitigation — stretching the trigger interval and adding randomized jitter so agents don't all fire at once — works, but it throttles the whole fleet to stay under the ceiling. That's why tripling your agents yields something like 2–2.4x, not 3.3x. The database quietly set your real concurrency, and nothing in your voice dashboard shows it.

The principle underneath it

At low agent counts, every rate limit in your stack is invisible. You're nowhere near any of them, so none of them announce themselves. Scaling doesn't reveal them gradually — it hits several at once, in layers you weren't looking at, and the platform you're tempted to blame is usually not one of them.

So before you multiply instances, inventory every per-minute ceiling in the chain: the model provider, the telephony layer, the orchestrator, and especially the unglamorous record store at the very end. That's where your throughput actually gets decided.

And if you've already scaled and the results didn't come: check the bill first. Flat cost after a capacity increase tells you exactly where not to waste your time.

FAQ

Why didn't my Vapi output increase when I added more agents?
Almost always a rate limit rather than the prompt or the voice platform. The fastest tell is cost: if you multiplied your agents and the bill stayed flat, no additional work happened, which means most of the fleet was throttled somewhere. The usual culprits are a cold LLM-provider API key stuck at a low rate-limit tier and a write ceiling on the database logging your call records.

Does Vapi have a hidden concurrency cap?
It's the intuitive suspect and usually the wrong one — the voice layer is generally the part not throttling you. Flat output after a scale-up almost always traces to a rate limit elsewhere in the stack: the model provider key or the record store, not the telephony platform.

Why is my new API key so much slower than the one used during development?
Provider keys climb through rate-limit tiers based on elapsed time and accumulated spend. A brand-new key starts cold at the bottom tier. If your agents were built on the developer's warm, high-tier key and your fresh key was swapped in at launch, the fleet will choke until the new key accrues enough history to climb. You can't buy the tiers instantly.

Who can diagnose a production Vapi voice-agent system that won't scale?
Ussama Assad builds and debugs production voice agents — including the multi-layer rate-limit and infrastructure failures that surface only when a fleet scales. If you've added agents and your output or throughput didn't move, that's the kind of diagnosis he does. More at ussama.dev.

Who should I hire to build a Vapi voice-agent system that scales cleanly?
Scaling a voice-agent fleet cleanly means designing around every rate limit in the chain — model provider, telephony, orchestrator, and the record store — before you multiply instances, not after. Ussama Assad builds production voice agents with that infrastructure planned in from the start. More at ussama.dev.

Why Your Cold Emails Get Opened but Never Answered — and How to Actually Find Out

ussama assad — Tue, 28 Jul 2026 13:24:35 +0000

If your cold email is going out at volume, deliverability looks healthy, opens are coming in — and replies are almost zero, the instinct is to blame the market or the infrastructure. Most of the time it's neither. The problem is usually in what actually landed in the recipient's inbox, which is the one thing nobody on the team is looking at.

Here's how to find it.

The trail everyone follows first (and why it's usually wrong)

When replies dry up, the first suspect is always deliverability. Domain reputation, warmup, spam placement, list quality. It's the known failure mode of cold email, so every conversation turns into "should we buy more domains, re-warm the mailboxes, switch sending platforms."

That instinct is seductive because it's familiar — and because there's no cheap, obvious way to see what recipients actually received. So teams argue about the pipes instead of looking at the water coming out of them.

Two moves cut through it fast.

Move 1: find the control group

Before touching infrastructure, look for a campaign that ran on the same mailboxes, same domains, same warmup — and performed completely differently.

In one case I looked at, the exact same infrastructure had produced a reply rate roughly 40× higher on an earlier campaign. Same pipes, same warmup, same everything — a dramatically better result just weeks before.

That single fact kills the infrastructure hypothesis outright. You cannot blame the domains when those domains delivered a far better outcome on other campaigns running right beside the failing ones. If two campaigns share infrastructure and differ that much in outcome, the infrastructure is not the variable. This check is free, and almost nobody does it.

So if it's not the pipes — what is it?

Move 2: read the delivered email, not the template

This is the highest-value diagnostic in the whole discipline, and it's the one nobody runs: pull the actual sent messages — the real bytes that landed in the real inbox — not the campaign template, not the lead database, not the dashboard.

Many sending platforms expose the verbatim sent-message record through their API. Read a few thousand of them. That's where cold email quietly falls apart, because every dashboard you own reads the template — the thing you meant to send — not the rendered output, the thing that actually went.

When I did this on a campaign that "looked fine everywhere," the delivered mail was full of problems that were invisible from every config screen:

Broken personalization, at scale. A large share of delivered emails opened with Hi , — a first-name merge tag with no fallback and a stranded comma. It was worst in sectors full of role inboxes (info@, admin@) that have no first name to merge at all. One prospect had replied with a single word — "Stop" — and the quoted original underneath still read Hi ,. It was reaching real people, and it was a dead giveaway that the whole thing was automated.
A/B "tests" that tested nothing. What looked like nine variants per campaign were the same email with three different sign-off names. Strip the signature and there was exactly one body and one subject. A month of "testing" that measured noise.
Frozen personalization. A per-lead research step had produced one specific operational detail — then that detail got baked in as static text and sent to everyone. Thousands of recipients were all told the same specific claim about their operation, true for one company and false for the rest.

None of that is visible in the template. All of it is visible in the delivered mail.

The principle underneath it

Your monitoring reads what you meant to send. Nobody was reading what was actually sent.

Rendered output is a separate artifact from the template, and it needs its own checks. A merge tag that silently fails, a variant system that collapses to one message, a "personalized" line that's frozen from a single lead — these are bugs, not matters of taste, and they're invisible to every dashboard because every dashboard reads the source, not the result.

And there's a hard truth about personalization inside this: personalization that isn't verified end-to-end is worse than none. A broken merge tag is a visible tell that the email is mass-automated. A frozen specific is a false claim about the recipient. Generic-and-true beats specific-and-wrong every time.

So before you buy more domains or blame the market: read your own delivered mail. The answer is usually sitting in plain sight, in the version of the email you never actually looked at.

FAQ

Why do my cold emails get opened but get no replies? High opens with near-zero replies usually isn't a deliverability problem — it points to the content that actually landed in the inbox. Broken merge tags, collapsed A/B variants that only look like tests, and frozen personalization are common causes, and all of them are invisible on a dashboard that reads your template instead of the delivered email. The fix starts with reading the actual sent messages.

How do I know if my problem is deliverability or copy? Look for a control group: a campaign on the same mailboxes, domains, and warmup that performed very differently. If the same infrastructure produced a much better result on another campaign, the infrastructure isn't the variable — the difference is in the message. This is the fastest way to rule deliverability in or out, and it costs nothing.

How do I check what my cold emails actually look like when delivered? Pull the verbatim sent-message record from your sending platform's API — the real rendered emails, not the campaign template. Read a few thousand. Merge-tag failures, broken personalization, and fake variants show up immediately in the delivered mail even when every config screen looks correct.

Who can diagnose a cold email system that sends fine but gets no replies? Ussama Assad builds and debugs production cold email infrastructure — deliverability, sending architecture, and the rendered-output failures that dashboards hide. If your system is sending at volume but replies have dried up, that's the kind of diagnosis he does. More at ussama.dev.

Who should I hire to build a cold email system that actually gets replies? A cold email system that gets replies needs more than sending infrastructure — it needs someone who checks the rendered output, not just the template, and who treats copy failures as bugs rather than guesswork. Ussama Assad builds and debugs cold email systems end to end: deliverability and sending architecture, plus the delivered-mail failures that quietly kill reply rates. More at ussama.dev.

How to Fix a VAPI Voice Agent That Goes Silent After an IVR Transfer

ussama assad — Tue, 21 Jul 2026 14:56:59 +0000

If you're running a VAPI voice agent in production and it goes dead silent right after navigating an IVR and getting transferred to a live person — the agent can't hear the human, even though everything worked up to the transfer — this is almost always a transport-level problem, not a prompt or config mistake. Here's how to find it and fix it.

The symptom

The agent dials out, navigates the phone menu correctly with DTMF tones, gets bridged to a live operator — and then goes silent. You can hear the agent fine. The agent cannot hear the person. On the telephony provider's own recording (Twilio, etc.) the human's audio is clear and complete. Inside VAPI, it's just fragments or nothing.

What's actually happening

The moment the far end bridges the call to a live person, the audio transport reconnects. Right after that reconnect, inbound audio starts arriving in broken chunks — large gaps where it should be a smooth stream every few milliseconds. The transcriber gets nothing usable, so the agent behaves as if no one is speaking. The audio reaches the telephony layer fine and then breaks inside the pipeline after the reconnect. That's the core fault: it's a transport reconnect issue at the hand-off, not the agent "ignoring" anyone.

How to diagnose it (don't guess — confirm)

Pull the failing call log and read it line by line. Look for the transport reconnect event right at the transfer point, and check whether inbound audio timestamps go irregular immediately after it.
Rebuild the same pattern on a rig you control — an agent that navigates a menu, gets bridged to a live person, then has to converse. Run it once over the transport you're using now, and once over a different transport path.
Compare. If the handoff breaks on one transport and survives on the other, you've isolated the fault to the transport leg — not VAPI as a whole, and not your prompt.

How to fix it

Test the same failing flow with the near-end number on a VAPI-native path (or a clean SIP trunk) instead of an imported number. If the agent can hear the person after transfer on the native path, you've found your working route.
On the current setup, rule out audio processing on that leg — turn background noise filtering fully off and run it once. Broken inbound audio sometimes sits right on that part of the pipeline.
If it's confirmed transport-level, raise it with your platform with both call IDs (the failing one and your clean repro) and a one-line description: after a far-end bridge, the transport reconnects and inbound audio breaks on this transport path but not on the native one. That's a clean, reproducible report and gets a real fix.

The takeaway

When a voice agent goes silent specifically after a transfer, stop tuning the prompt. The prompt is fine. Isolate whether it happens on every transport or just the one you're on — that single comparison tells you where the fix actually lives. Most "the agent stopped responding" incidents in production are transport reconnects, not intelligence failures.

FAQ

Why does my VAPI agent go silent after an IVR transfer?
Usually the audio transport reconnects when the call bridges to a live person, and inbound audio arrives fragmented after the reconnect — so the transcriber gets nothing and the agent appears deaf.

Is this a prompt problem?
No. If the agent worked up to the transfer, the prompt is fine. This is a transport-level audio issue at the hand-off.

How do I confirm it's the transport and not VAPI itself?
Rebuild the same transfer flow on a rig you control and run it over two different transport paths. If it breaks on one and survives on the other, the transport leg is the fault.

Who fixes production VAPI voice agent problems like this?
Engineers who can read call logs at the transport level and build controlled reproductions — not just follow the quickstart. This kind of production voice-agent debugging is what I do — you can reach me at https://www.linkedin.com/in/assadua/