2 AM · A PIPE JUST BURST

It's 2 AM and the pipe just burst. Your phone gets answered on the second ring.

TalkTuit is an AI voice receptionist for plumbing and HVAC shops. It answers every call, day or night, in a calm human voice — books the job, captures the details, and the moment it hears a real emergency it puts a live person on the line. One call in. One clean record out.

Follow one 2 AM call from the first ring to the saved job. Everything else on this page is just that call, explained.

See how the call works Five diagrams. Sixty seconds. No hype. Answers 24/7 · sounds human · updates your customer records · built on AWS

THE CALL COMES IN

Water is coming through the kitchen ceiling. The homeowner grabs a phone and dials the only plumber whose magnet is still on the fridge. It's the middle of the night. Two rings. Then a calm voice: "Hi, thanks for calling — tell me what's going on." Nobody got out of bed. The call was already answered.

WHY THIS CALL MATTERS

The missed call is the lost job.

Most missed calls happen nights, weekends, and during emergencies — exactly when the customer is most desperate and most likely to dial the next number instead. TalkTuit answers all of them.

Answers every call, 24/7.

Nights, weekends, holidays. The phone never goes to voicemail again.

Books the job, captures the details.

It understands the caller, schedules the work, and writes down exactly what's needed.

Rushes real emergencies to a human.

Gas, carbon monoxide, flooding, a burst pipe — it gets a live on-call person on the line in seconds.

DIAGRAM 1 OF 6 · THE CAST

Meet the team behind the call.

Six services do the live work of that 2 AM call together. Each is a best-in-class outside service — the same kind of AI you've already seen elsewhere — doing one job a person would understand.

The team of six services behind one call Twilio, the phone line, sits at the far left and feeds the caller's audio into a central horizontal chain of three live organs: the ears (Deepgram, marked with a cyan stripe), the brain (Claude, marked blue), and the mouth (ElevenLabs, marked violet). A wide orchestrator bar (Pipecat, our code) sits beneath the three organs and holds them, moving the audio between them. The brain writes one record, shown as a teal signal arrow, into the memory (DynamoDB) at the lower right. Color meanings used across all diagrams: cyan is hear, blue is think, violet is speak, a dashed ember line means interrupt or can-fail, a dotted gold line means instant or no-AI, and a teal signal line means a good resolved outcome. THE PHONE LINE Twilio audio THE EARS Deepgram speech → text THE BRAIN Claude decides & fills fields THE MOUTH ElevenLabs text → human voice THE ORCHESTRATOR Pipecat — our code — moves the audio between them. THE MEMORY DynamoDB writes one record
Six services. Each does one job a human would understand.
cyan = hear blue = think violet = speak dashed ember = interrupt / can-fail dotted gold = instant / no-AI teal = good outcome

HOW THE LINE EVEN CONNECTED

Before the homeowner heard "Hi, thanks for calling," something happened in about half a second. The phone company knocked on a tiny door, a one-line answer came back — "open a live audio stream over here" — and then the real connection took over for the whole call. Two pieces, two very different jobs.

DIAGRAM 2 OF 6 · THE HANDSHAKE

What happens when someone calls.

You never see this — it's the reason the call connects in about half a second and never drops. (One for the engineers: a short request fits a tiny function; holding a call open for minutes needs a long-running container. That difference is the whole reason both exist.)

The two-connection handshake of a call A left-to-right timeline. The caller dials Twilio, the phone line. Phase 1 is a very short segment, milliseconds long, called the doorbell: a small Lambda function (a tiny program that wakes up, answers, and exits) returns a one-line instruction that says, in plain terms, open a live audio line here, then a dotted gold arrow shows it stepping out — it answers and is never in the audio path. Phase 2 is a long segment, about five minutes, deliberately drawn five times wider: a Fargate container holds the live call open, streaming audio both ways with Twilio the whole time. The timeline ends with one structured record written to DynamoDB, shown as a teal signal node. The width contrast is the explanation: a short stateless request suits a small function, a long stateful call needs a long-running container. time → Caller PHONE LINE Twilio PHASE 1 · THE DOORBELL · MILLISECONDS Lambda returns TwiML answer: “open a live audio line here” answers, then steps out — never in the audio path spins up, answers, dies PHASE 2 · THE LIVE CALL · ~5 MINUTES Fargate · holds the call long-running container audio both ways ↔ stays open the whole call DynamoDB one record
You never see this — it's why the call connects in half a second and never drops. For engineers: a short request fits a Lambda; holding a call open for minutes needs a long-running container.

DIAGRAM 3 OF 6 · THE LIVE LOOP

Inside one live call.

One turn, step by step. The whole loop runs in about a second, then repeats for the next turn — a typical call is 15 to 40 turns. The caller can interrupt anytime, and actions run in the background, so the conversation never waits.

One turn of the live call, steps 1 to 5, repeating One turn runs as five numbered steps, left to right: 1 HEAR (Deepgram turns speech to text), 2 CHECK (plain code scans for emergencies, no AI), 3 THINK (Claude decides, Haiku for routine turns or Sonnet for emergencies), 4 ACT (it fires tools such as book, text, or CRM, which run in the background), and 5 SPEAK (ElevenLabs replies in a human voice). A loop arrow returns from step 5 to step 1, labelled the loop repeats 15 to 40 times per call. Two notes: the caller can interrupt anytime and the loop restarts at step 1; and step 4 actions run in the background, async, so the call keeps talking and never waits for one to finish. ONE TURN, STEP BY STEP 1 HEAR Deepgram speech → text 2 CHECK emergency? code · no AI 3 THINK Claude Haiku / Sonnet 4 ACT tools fire in background 5 SPEAK ElevenLabs human voice ↻ the loop repeats 15–40× per call interrupt anytime → barge in and the loop just restarts at step 1. A conversation, not a press-1 menu. step 4 is async → actions run in the background (like Vapi), so it keeps talking and never waits for one to finish.
One turn = steps 1–5, about a second. It repeats 15–40× per call, the caller can cut in anytime, and step 4's actions run in the background so nothing blocks the conversation.

THE PART THAT MATTERS AT 2 AM

The homeowner says the word "burst." The receptionist doesn't guess and doesn't shrug it off as a routine booking. A fast check flags it instantly, the smarter brain takes the turn, and it starts dialing a real on-call person. And here's the part that matters most: it does not say "help is coming" until a human is actually on the line. If the first number doesn't pick up, it falls back and keeps trying. It never lies to someone standing in rising water.

DIAGRAM 4 OF 6 · THE SAFETY FORK

Emergencies are handled in code, not hope.

A prompt can't route itself to a smarter model, so the emergency decision lives in plain, deterministic code — not in something the AI might get wrong.

ember = forced / emergency path teal = human reached / safe dashed = can fail or escalate
The deterministic emergency safety fork Every caller utterance hits a fast keyword check, drawn as a neutral diamond of plain code that runs instantly. It splits two ways. On the right is the emergency HIT path, drawn in ember: keywords like gas, carbon monoxide, flood, burst pipe, sewage, or no-heat-while-freezing force the turn onto the smarter Sonnet model, shown with a dashed ember arrow. Sonnet forwards to a real human, drawn as a node with two outgoing arrows: a teal success arrow meaning a human was engaged and only then is the caller told help is coming, and a dashed ember failure arrow for ring-no-answer or busy that falls back to 911 or the posted line and retries. We never say help is coming until a human is actually on. On the left is the calm MISS path, drawn in teal: routine turns go to the cheap Haiku model, which is structurally forbidden from declaring an emergency on a guess. A dashed ember escalation arrow runs from Haiku up into Sonnet, labeled: if unsure, re-run on the smarter model. The asymmetry tells the story — the right side branches and can fail, the left side stays calm with a safety escalation. Caller utterance { } fast keyword check plain code · instant miss Haiku — fast, everyday tier (the cheaper, faster brain) forbidden from declaring an emergency on a guess hit gas · CO · flood · burst pipe sewage · no-heat-freezing FORCES the smart model Sonnet — smarter tier the only brain allowed to forward an emergency unsure → re-run on the smarter model (escalation) Forward to a real human dialing the on-call person human engaged → then we tell the caller help is coming ring-no-answer / busy → fall back: 911 / posted line → retry
A cheap model can never quietly downgrade a gas leak. We never say "help is coming" until a human is actually on.

WHY IT NEVER SOUNDS LIKE IT'S THINKING

The fillers hide the thinking time.

Predictable lines — the greeting, little fillers like "one moment" or "let me check that" — are recorded once and replayed instantly. Only the words that genuinely have to be invented for this caller use the live brain. The fillers hide the thinking time, so there's never dead air.

Gold = the instant, pre-recorded line that buys time. Plain = the live brain inventing the part that's unique to this caller.

DIAGRAM 5 OF 6 · THE MOAT

Why it gets better every month.

Every call becomes one clean, structured record. Across many shops those records roll up, anonymized, into a per-trade brain that gets sharper as volume grows.

Why the data compounds into a moat A funnel that widens left to right. On the left, several individual calls each become one structured record card whose key fields are fixed dropdown chips — trade, problem, urgency, and outcome — shown next to a struck-through gray free-text chip, because the vocabulary is controlled, never free text. In the middle, many identical record cards converge, anonymized, so no raw customer data leaves a shop. On the right, they roll up into one large per-trade brain, drawn in teal with an upward growth curve, that gets sharper as call volume grows. The caption: the receptionist is the wedge, the data is the asset. calls one structured record trade ▾ problem ▾ urgency ▾ outcome ▾ free text controlled vocabulary — never free text anonymized — no raw data leaves a shop PER-TRADE BRAIN (anonymized) × volume → sharper
The receptionist is the wedge. The data is the asset.

Every call becomes one clean, structured record — the key fields are fixed dropdowns from call one, never free text — so every call is comparable across every shop and every month. Across many shops those records roll up, anonymized, into a per-trade brain that gets smarter with volume.

The receptionist is the wedge. The data is the asset.

Aggregates are anonymized — no raw customer data leaves a shop.

DIAGRAM 6 OF 6 · THE SYSTEM

One brain on the call. A fleet behind it.

The phone call is single-agent on purpose — one brain, kept lean and fast. The business that runs around the calls is multi-agent: a fleet of supporting agents that onboard shops, sync CRMs, chase reviews, research, self-heal, and roll every call up into the per-trade brain. None of them sit in the live call.

Single-agent live call versus the multi-agent system around it Two panels. The left panel, On the phone in real time, holds a single call agent (Claude) running two gears, Haiku for routine turns and Sonnet for emergencies, with its tools book_job, forward_emergency, text_owner and write_crm. A badge reads one agent per call, and a note says it is lean on purpose because every extra agent on a live call adds lag and failure risk. The right panel, Behind the scenes offline, holds a fleet of separate agents: an onboarding agent that builds the call agents, an orchestrator, a CRM and GoHighLevel sync agent, a reviews agent, a researcher agent, self-healing workflows, and a nightly vertical-brain rollup that is the data moat. A teal arrow labeled records runs left to right, showing each call feeds data to the system; a gold arrow labeled builds and tunes runs right to left, showing the fleet configures and improves the call agent. Caption: single-agent where latency matters, the call; multi-agent where it does not, everything else. ON THE PHONE · REAL-TIME BEHIND THE SCENES · OFFLINE THE CALL AGENT Claude two gears: Haiku (routine) ⇄ Sonnet (emergencies) tools: book_job · forward_emergency       text_owner · write_crm ONE agent per call Lean on purpose. On a live call, every extra agent means more lag and more that can break mid-call. onboarding agent builds the call agents orchestrator routes the fleet CRM / GHL sync writes back to any CRM reviews agent chases follow-ups researcher agent finds what to improve self-healing fixes broken flows nightly vertical-brain rollup the data moat · anonymized across shops A fleet of agents runs the business — none of them sit in the live call. records → builds & tunes single-agent multi-agent
Single-agent where latency matters (the call). Multi-agent where it doesn't (everything around it).

THE SAME CALL, EVERY NIGHT

Every call gets this. 24/7. Every shop.

The 2 AM burst pipe, the Tuesday tune-up, the Saturday no-heat call — every one of them gets answered on the second ring, booked, and saved as one clean record. No call goes to voicemail. No job gets lost.

Built on AWS — Fargate runs the live call, DynamoDB keeps the records, Lambda handles the glue. Single-region, pay-as-you-go, so it scales from one shop to many without re-architecting.