> ## Documentation Index
> Fetch the complete documentation index at: https://docs.unpod.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Why Unpod
> The communication backend for agentic apps.
**Unpod is the communication backend for agentic apps.** One SDK to build
agents that call, message, email, remember context, run durable workflows,
and react to every customer interaction in real time.
Supabase made database, auth, storage and realtime feel like one backend —
Unpod does the same for software that talks to people.
## One backend problem
The moment an agent's job is a human conversation, it inherits questions no
model answers and no channel API solves: who is this person across channels?
What happened before? Which channel right now? What happens when they reply
tomorrow? Did it produce the outcome? Teams answer them by stitching together
a channel API, a workflow engine, an agent framework, a database, a CRM, a
vector store, and an observability stack. Those are not seven integration
problems — they are one backend problem.
## Four layers, one substrate
Unpod answers it with four layers over a single substrate of communication
state. The Calling Engine is the trusted anchor, but it is one Transport
channel — an app can live on WhatsApp and email without placing a call.
| Layer | Unpod primitives | Role |
| ------------------- | ------------------------------------------------ | -------------------------------------- |
| Communication state | Entities, Conversations, Context Graph, Outcomes | The durable system of record |
| Execution | Flows, Journeys, Agent Workforce | Decides and performs what happens next |
| Transport | Calling Engine, WhatsApp, Email, other Channels | Reaches the human |
| Control | Teams, Policies, Events, Observability | Governs, secures and exposes execution |
**Status:** the Calling Engine (\~5 lakh calls a month on owned voice rails),
Agent Workforce, Outcomes, and Teams carry production traffic today;
Conversations, Flows & Journeys, and the unified event stream are in build.
The [Core Engine overview](/core-engine/overview) walks the full map, with
an honest status per component.
## Why Execution and Transport are the hard layers
Speech is solved. Telephony is solved. The layers that run the conversation
are where projects stall.
Every top model drops \~39% from single-turn to multi-turn - mostly
unreliability, not capability. Take a wrong turn and the conversation
never recovers. Prompt-tuning plateaus around 85%: nothing in a
100-page prompt is addressable, so nothing is testable.
Humans swap turns in \~200ms; past \~700ms a caller hears a machine. The
LLM is \~70% of that budget, and frontier models spend 1.1-1.4s before
their first token - the whole budget, on one hop.
## What Unpod runs
This is why Unpod owns the runtime instead of wrapping a model:
Conversations as checkpoints and outcomes, not prose. Every step is
addressable - so it can be simulated, fixed, and regression-tested.
Each turn gets only the context it needs - so the agent stays fast on a
third-party model, or - in early access - faster on a fine-tuned \~1B SLM
trained on your workflows ([Intelligence](/core-engine/intelligence)).
Swap either way without touching the conversation.
Pass a session id and the agent keeps its state - across turns, and
across calls.
## Quickstarts
The fastest path is the [Quickstart](/get-started/quickstart) - a real call
placed and read back in six SDK calls. Or use a trained agent like a model:
| Surface | I/O | Live in |
| --------------------------------- | ------------------- | ----------- |
| [Chat](/get-started/chat) | text in, text out | 1 URL swap |
| [Realtime](/get-started/realtime) | audio in, audio out | 1 WebSocket |
| [Phone](/get-started/phone) | a phone number | 1 click |
Same trained agent, three ways in. Your orchestration, speech, and transport
stay where they are.