
Korean-first voice AI stack — from real-time calls to care operations
Repository audit · 30+ voice processors we built
Voice AI, connected end to end.
It handles real-time Korean conversation, manages call flows and outcomes in the operator console, and connects family and care-team apps.
One stack, every surface. A real-time voice engine, an operator console, and consumer apps — designed to work on their own or together.
A Korean-first real-time voice engine

An operator console for care teams

A care operations backend

Web and mobile apps for families

Telephony wired and key-gated

An orchestration layer we own

The scale of what
is actually built
Every figure was counted in the repository — audit, August 2026.
Unshakeablereliability.On every call.
Vendor failover, silence watchdogs, and staged flag rollout hold the call instead of dropping it. The last step into production is always a person.
- Vendor failoverone provider stalls, the call continues
- Silence watchdogsa dead response recovers immediately
- Redundant transportsbrowser, mobile, telephony
- Feature flagsrisky changes open in stages
- A human opens productionsensitive actions need confirming
Wherever the call happens. At home, in care settings, and across the operations that connect them.
Deployment scenarios drawn from what exists
See the stackThese are not customer stories. They are deployment scenarios you can assemble from capabilities that are already built — each one grounded in what we shipped.

Live transcripts and call records
One screen calls, status, follow-up
Voice engine, operator console, care backend

Web + mobile on one shared stack
No install to start from the browser
Consumer apps, WebRTC, voice engine
The team that built it works alongside you
Implementation design. We shape the call flow and integration path around the environment you already run.
See the stackIntegration guidance. We decide together which paths open when — web, mobile, or telephony.
See the surfacesOperations support. Console workflows and follow-up handling get tuned to how the work is actually done.
See operationsWhere families and care teams meet the stack
See a callThe same stack surfaces differently in the browser, on mobile, and in the console.
Korean-first by design. The pipeline is tuned to the rhythm and register of Korean conversation, not retrofitted to it.
See the stackProduction stays human-opened. Sensitive actions and production rollout happen only after a person confirms them.
See operationsA day of calls
How one call moves through a day
From connect to observation, the same stack runs the same path from morning to night.

6AM — step 1 of 5
Connect
Transport
A call opens from the browser or the app, and the transport connects.
- In the browser, no install
- From the iOS and Android apps

12PM — step 2 of 5
Korean-first turn-taking
Turn-taking
Backchannels are told apart from real interruptions, so nobody gets cut off.
- A nod keeps the agent talking
- A real interruption yields the floor

3PM — step 3 of 5
Processors we wrote, on every pass
Pipeline
More than thirty processors run in order on a single pass through the pipeline.
- Counted in the August 2026 repository audit

6PM — step 4 of 5
Degrade over drop
Resilience
When a layer wobbles, capability steps down a notch instead of the call ending.
- Vendor failover
- Silence watchdogs

10PM — step 5 of 5
Per-call observability
Observation
When the call ends, its record and follow-up land in the console.
- Transcript and call record
- Reviewed on the operator surface
How one call is handled
See the scaleTransport, speech and language models, orchestration, Korean tuning, care handling, and a human confirmation — the real sequence, not a simplification.
Call session pipeline
The processing order from transport connect to Korean tuning.
- Transport connects and the call begins
- Conversation is transcribed live
- Record and follow-up hand off to the console
session.pipeline([transport, stt, korean_turn_tuning, llm, tts]);
Transcription accumulates while the call is still running
When the call ends, the record and its follow-up land in the console. Production actions run only after a person confirms them.
See the setup
What's happening at IntuneLabs
Current implementation state and what is actually open, stated plainly.

Where would you like to start?
Begin with how the stack is put together, or with what is actually running today.














