Core Concepts

What is Reecall?

Reecall is a platform for building AI voice assistants that handle real phone calls and browser conversations. You configure an Assistant with AI models, connect it to a Channel (phone or web), and it handles conversations autonomously.

How resources are organised

Before you create anything, understand the two-level scope that wraps all Reecall resources:

• Organization - your top-level workspace, tied to your account and billing.
• Project - a logical container inside your Organization. Each Project holds its own Assistants, Channels, Hooks, and Knowledge Bases. Use one Project per client, product, or environment. All API requests are scoped to a Project, either automatically (project-scoped API key) or explicitly (org-scoped key + projectId in the body).

See Organizations & Projects for how to list and create Projects and retrieve your projectId.

The building blocks

Every Reecall application is made of four concepts:

• Assistant - Your AI agent. It has a personality (instructions), a brain (LLM or STS model), a Voice (TTS), and ears (STT). You can also use a single STS model that handles speech in and speech out directly.
• Channel - How the Assistant connects to the outside world. Two types: SIP for phone calls via your PBX, and WebRTC for browser or app conversations via LiveKit.
• Exchange - A single conversation. Created when someone calls or connects. It contains the transcript, extracted data, duration, and cost.
• Tools - Capabilities you give your Assistant: call APIs (HTTP requests), look up data (Knowledge Bases, MCP servers), transfer calls, or end the conversation.

graph TD
    ORG[Organization] --> PRJ[Project]
    PRJ --> A[Assistant]
    A -->|connects via| C[Channel]
    C -->|SIP| P[Phone / PBX]
    C -->|WebRTC| W[Browser / App]
    A -->|uses| T[Tools]
    T --> KB[Knowledge Bases]
    T --> API[HTTP Requests]
    T --> TR[Call Transfer]
    A -->|produces| E[Exchange]
    E -->|contains| D[Transcript + Data]

How a conversation works

When a caller reaches your Assistant, audio flows through a processing pipeline and back:

sequenceDiagram
    participant Caller
    participant Channel
    participant Assistant
    participant Models as STT → LLM → TTS

    Caller->>Channel: Incoming audio
    Channel->>Assistant: Route to Assistant
    Assistant->>Models: Process speech
    Models-->>Assistant: Generated response
    Assistant-->>Channel: Response audio
    Channel-->>Caller: Plays audio back

If you use an STS model, the three model steps collapse into one. The flow stays the same.

Two model approaches

You pick one of two architectures when you configure an Assistant:

STS (Speech-to-Speech) - A single model receives audio and produces audio directly. This is simpler to configure, gives lower latency, but costs more per minute.

LLM + TTS + STT - Three separate models each handle one job: transcribe speech, generate a text response, then synthesise audio. You get more control over each step and lower cost, but there is more configuration involved.

You can switch between approaches at any time without changing your Channel or Tools.

After the conversation

When a call ends, the Exchange stores everything: full transcript, extracted data, duration, and cost.

Hooks let you trigger workflows automatically: send an email summary, call an external API, or push a notification. See Automating post-call actions for a full walkthrough. Metrics track usage and cost across all your Assistants.