Docs

GuidesSupport

IntuneLabs stack documentation

What order a call is processed in, which processors run over it along the way, and how capability is opened in stages. This is not a published, versioned API reference — it is an explanation of how the stack is put together.

See how it is assembledRead the guides

Browse by topic

Each entry describes something that exists in the repository today. Where a path is not open yet, it says so.

The call pipeline

  • Transport connect

    Browser WebRTC and mobile are the transports live today.

  • Speech to text

    A vendor speech model, orchestrated rather than owned.

  • Korean turn tuning

    Turn detection that does not read a backchannel as the end.

  • Language model

    A vendor language model called from inside the pipeline.

  • Speech synthesis

    Sticky failover between providers runs mid-call.

  • Per-call instrumentation

    Measured for operations; not published as benchmarks.

Custom processors

  • PII redaction

    Runs as a processor inside the pipeline.

  • Output guardrails

    The response is checked before it is synthesized.

  • Risk scoring

    Marks the points in a conversation that need a look.

  • Diarization

    Separates who is speaking within the stream.

  • Korean text normalization

    Shapes numbers and notation into how they are read.

  • Filler audio

    Covers the pause when a tool call runs long.

Feature flags and rollout

  • A flag is a level

    Not an on/off switch but how far down to step.

  • Default off

    A risky path comes up only once it is observable.

  • Degrade over crash

    The capability steps down instead of the call dropping.

  • Vendor failover

    One provider wavering does not end the call.

  • Fail closed

    Unverified state is never read optimistically.

  • Production stays human-opened

    A person is the gate to production.

The console's Features screen — speech recognition, language model, and synthesis picks that apply from the next call where the stack switch is on
A pick on the Features screen applies from the next call, with no redeploy — only where the stack switch is on.

The operator console

  • Call list

    Calls in progress and calls already handled, on one screen.

  • Transcript review

    Read back what accumulated while the call was running.

  • Call records

    Recordings and records are stored for later review.

  • Follow-up

    The work left after a call is closed out in the console.

  • Schedules

    Regular calls are wired into the operating rhythm.

  • Usage

    What a deployment actually consumed.

The console's Agents screen — published personas listed with their voice, language, and publish date
The console's Agents screen. Call lists and transcript review continue in the same console.

Transports and integration

  • Browser (WebRTC)

    Start a call in the browser with no install. Live.

  • Mobile

    iOS and Android apps reach the same engine. Live.

  • Telephony

    Built and key-gated. Integrated per deployment.

  • Console API

    The same data path the console itself reads.

  • Care and manager apps

    UI is complete; backend integration is in progress.

  • Web app

    Families reach the same stack from the browser.

Where to go next

The examples explain how the stack is assembled; they do not describe a versioned public API.