AI phone assistant

Connect any phone line to any AI model. Self-hosted, bring your own keys.

tel-agent.com · maintained by Dpro GmbH, Vienna

What it is

Tel-Agent is an open-source gateway that sits between a phone line and an AI agent.

A call arrives over SIP. Tel-Agent checks the caller against your routing rules and either passes it through to a human, blocks it, or hands it to an AI agent. The agent speaks with the caller in real time, can invoke tools — transfer the call, take a message, check a calendar, call any HTTP endpoint — and every call is recorded, transcribed, and searchable.

It runs on your own hardware, on your own LAN, with your own API keys.

The phone comes first and is the hardest case. After it works, the same agent answers on web chat, SMS, email, WhatsApp, Telegram, Messenger, Instagram, Discord and Slack — connected with your own credentials from each platform, never a shared application of ours. Ten channels, and the list is closed. A channel is a route a customer uses to reach you; a system you run your own business on is an integration, and those are reached through webhooks and the HTTP tool.

What it is not

• Not a PBX replacement. It connects to your existing PBX (3CX, Asterisk, FreePBX) as an extension.
• Not a workflow automation platform. Webhooks and a generic HTTP tool reach n8n and Home Assistant, which do that job better. A channel is where the conversation happens; an integration is a system the agent acts on. We own the first and reach the second through the HTTP tool.
• Not a CRM.
• Not analog-capable. Bridge an analog line with an ATA; Tel-Agent only speaks SIP.

Why it exists

Well-funded closed products already do "AI receptionist for business". What does not exist is a good open, self-hosted one — where you own the recordings, choose the models, and decide which callers ever reach the AI at all.

Project status

Pre-alpha. Not usable yet. There is no installable release.

The project is at Milestone 0: getting a single conversation answered end to end in a web chat — the reply streaming token by token, interruptible mid-sentence, with the message captured and the transcript printed. The messaging channels follow, and the phone comes last, at Milestone 11.

Most of the screens now have something behind them. Twenty-three are served by a real API — sign-in and the account flows, home, the conversation archive and one conversation in full, the notification tray, contacts, assistants, knowledge, the catalogue, apps, numbers, routing rules, backups, system health, settings and workspaces. Eight are still design with fixture data in them: the calendar, outbound campaigns, connectors, the consent log, the live call, usage, updates and the install wizard. Every one of those eight belongs to a milestone that has not been reached.

This is still not a product you can run. There is no installable release, no packaging, and the agent does not answer with a model until one is configured — the loop that carries the reply is built and the model is a key away.

The build order is deliberate, and it was reversed once, on 2026-08-22. It originally required an answered phone call before anything else was built; the phone loop was proven elsewhere, which retired the risk that ordering existed to cover. What was not proven is that anyone can reach the agent at all. The superseded rule and the cost of reversing it are recorded in internal/DECISIONS.md as D-017.

Milestone 0 of 12 — in progress. The full plan, and what each milestone means, is in docs/ROADMAP.md.

Watch or star the repository if you want to know when it becomes installable.

Planned architecture

Providers for v1: Deepgram (STT) · one cloud LLM · ElevenLabs (TTS). Local models (Ollama, Whisper, Piper) follow in v1.1 — they need a GPU to hold a natural conversation, so they are not the default.

Latency target: under 800 ms from the end of caller speech to the first audio out. Everything streams; the first sentence starts speaking while the rest is still being generated.

Quick start

git clone https://github.com/Dpro-at/Tel-Agent.git
cd Tel-Agent
cp .env.example .env
# set ENCRYPTION_KEY in .env - generate one with: openssl rand -hex 32
docker compose up -d --build

Then open http://localhost:3000. The first visit creates the administrator — there are no default credentials. The API and its documentation are on http://localhost:8000/docs, and conversations live on the tel-agent-data volume (SQLite by default; a postgres profile is in docker-compose.yml).

Both ports are published on loopback only. Reaching the installation from other machines is a decision made in .env — the TEL_AGENT_* block there lists the three values to change and why the dashboard image is rebuilt for it. On a server, put a reverse proxy terminating TLS in front instead.

Running it without Docker stays supported and documented — contributors need to run the code without rebuilding an image on every edit. See CONTRIBUTING.md for the manual run, docs/SPEC.md for the full design and CLAUDE.md for the development rules.

Requirements when it ships

• API keys for an STT, an LLM, and a TTS provider (or a GPU for local models)
• A machine on the same LAN as the PBX
• Network access to the PBX on 5060/UDP and an open RTP port range
• A SIP endpoint. Most lines already are one:

Tel-Agent only ever speaks SIP. That is deliberate: supporting telephony hardware directly is a project of its own, and an ATA solves it for about the price of a cable.

Security notes

• The port is not exposed by default. The server listens on 127.0.0.1, and python -m api warns if you change that. The supported ways to reach an installation from elsewhere — a private network, a VPN, or a reverse proxy terminating TLS — all talk to a server on loopback, so none of them requires widening it.
• A password is required on first run. There are no default credentials.
• API keys are encrypted at rest and are never returned in full to the c