Why Unpod - Unpod AI

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 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.

Prompts lose the plot

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.

Big models miss the beat

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:

Playbooks

Conversations as checkpoints and outcomes, not prose. Every step is addressable - so it can be simulated, fixed, and regression-tested.

Context layer

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). Swap either way without touching the conversation.

Sessions

Pass a session id and the agent keeps its state - across turns, and across calls.

Quickstarts

The fastest path is the 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	text in, text out	1 URL swap
Realtime	audio in, audio out	1 WebSocket
Phone	a phone number	1 click

Same trained agent, three ways in. Your orchestration, speech, and transport stay where they are.

Where Unpod sits

Layer 3

Agent platformsVapi / Retell / Bland

used by

Layer 2

UnpodCommunication infra

builds on

Layer 1

Raw telephonyTwilio / Plivo / Bandwidth

Start building

Getting Started

Choose your path - and the right credential for it.

Try itPlaygroundBuild and hear an agent in the browser. No account needed.

GitHub

Open source, MIT. Self-host the full stack.

​One backend problem

​Four layers, one substrate

​Why Execution and Transport are the hard layers