Tel-Agent: a self-hosted SIP-to-LLM gateway for teams that want to own the call recording
AI phone assistant | open-source
At a glance
- What is it?
- Tel-Agent routes inbound SIP calls to an AI agent, a human, or a block list, and runs on your own hardware with your own model keys. It is alpha software, AGPL-3.0 licensed, and the README is explicit about what it is not.
- Who is it for?
- Adopt Tel-Agent if you already run a SIP PBX such as 3CX, Asterisk or FreePBX, you want the recordings and transcripts to stay on your own hardware, and you are comfortable running alpha software with a v0.1.x release history. Do not adopt it if you need analog line support, if you expect it to replace the PBX itself, or if you need a stable API surface for a customer-facing deployment.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Tel-Agent claims: an open AI receptionist you host yourself
The README states the problem directly: well-funded closed products already sell an AI receptionist for business, and what does not exist is a good open, self-hosted equivalent where you own the recordings, choose the models, and decide which callers ever reach the AI. That last clause is the interesting one. Most hosted AI phone products route every call to the model by default. Tel-Agent inverts it: a call arrives over SIP, the gateway checks the caller against your routing rules, and only then does it pass the call to a human, block it, or hand it to an agent. The audience is therefore narrow and specific. It is an organisation that already runs a PBX, has opinions about where call audio and transcripts are stored, and does not want a vendor holding the model API keys. The README's own framing of what the project is not is unusually candid for a repository at v0.1.1: not a PBX replacement, not a workflow automation platform, not a CRM, and not analog-capable. Those four negatives do most of the work of defining the product.
Call flow: SIP in, routing decision, then agent or human
The mechanism described in the README is a gateway, not a switchboard. A call arrives over SIP, Tel-Agent evaluates the caller against routing rules, and branches three ways: pass through to a human, block, or hand to an AI agent. When the agent takes the call it speaks with the caller in real time and can invoke tools. The README names four examples: transfer the call, take a message, check a calendar, call any HTTP endpoint. Every call is recorded, transcribed and searchable. Tool invocation is exposed over MCP, which is the architectural decision worth noting. Rather than a bespoke plugin API, the project presents itself as an MCP endpoint, and the README's one-line pitch is "Connect them over MCP, and get full control." That choice matters for adoption: an MCP server is reachable by any MCP-capable client, so the tool surface is not locked to this project's own agent loop. The README does not document the routing rule syntax, the SIP registration details, or the transcription pipeline in the excerpt available, so the exact configuration format for caller matching is something to read in the repository before committing.
Twenty-four channels, one agent, and a distinction the README insists on
The channel list in the README is long: phone, web chat, SMS, email, WhatsApp, Telegram, Messenger, Instagram, Discord, Slack, Microsoft Teams, Signal, Viber, Google Chat, Mattermost, Matrix, IRC, LINE, WeChat, WeCom, QQ, DingTalk, Feishu/Lark and iMessage. The README states the official scope covers 24 channels including the phone, with more built on an extension contract, and that the wave-2 channels are tracked in issues labelled "channel". Two claims here deserve scrutiny. First, a README badge row is not a working integration, and the project is at v0.1.1; the README itself separates channels that ship today from those being added now, which suggests the list is a roadmap as much as a feature set. Second, the README draws a line between a channel and an integration: a channel is where the conversation happens, an integration is a system the agent acts on, and integrations are reached through webhooks and the HTTP tool rather than owned by the project. That is a defensible boundary. It keeps n8n and Home Assistant out of scope, and it means the project does not have to maintain a connector for every SaaS product. It also means any business system you want the agent to touch needs an HTTP endpoint or a webhook you build yourself. The README is explicit that credentials for each channel are yours, never a shared application of the project's.
Install paths and the configuration you actually have to supply
The README states that native installers and container images are available today, and points to a download page and the releases page. The named artefacts are a Windows installer and macOS packages for Apple Silicon and Intel, with the README text truncating at the Linux entry. The releases list shows v0.1.0 and v0.1.1, both dated 2026-09-05. Beyond that, the excerpt does not give concrete commands, environment variable names, or config keys, and I will not invent them. What can be said from the README is the shape of the setup: you bring your own API keys for the model provider, you connect each channel with your own credentials from that platform, and the gateway attaches to an existing PBX as an extension rather than replacing it. The README names 3CX, Asterisk and FreePBX as the PBX types it connects to. Anyone evaluating this should treat the repository's installation documentation, not this article, as the source for the exact steps, because the README excerpt available here stops mid-sentence in the platform list.
Alpha status, SIP-only, and the cases where this is the wrong tool
The repository carries an alpha badge and the README repeats the status in its own section. The release history supports that: two releases, both on the same day, at v0.1.0 and v0.1.1. The last push to the default branch was on 2026-09-14. The most concrete limitation is stated plainly: Tel-Agent is not analog-capable and only speaks SIP. If your line is analog, you bridge it with an ATA and Tel-Agent never sees the difference. The second limitation is architectural. Because it is not a PBX replacement, it cannot be your only telephony component; you need something for it to register against. The third is the one that will bite teams that skim the README: the channel count reads like a mature product, but the README itself splits channels into those that ship today and those being added, and the release number says v0.1.x. Treat the wave-2 channels as unproven until you have tested the specific one you need. A team that needs a stable, SLA-backed voice product with analog support and no infrastructure of its own is not the audience for this.
How it differs from a hosted AI receptionist and from building on a voice API
The nearest comparison the README makes is against closed AI receptionist products, and the difference is not the feature list, it is who holds the data and the keys. A hosted receptionist terminates the call on the vendor's infrastructure; Tel-Agent terminates it on your LAN, with your model API keys and your platform credentials for each channel. That has a real operational cost: you run the machine, you patch it, you handle the SIP trunk. The other alternative is to build directly on a voice API from a model provider or a telephony API vendor. That route gives you a programmable call leg and no opinion about routing or recording, which means you write the routing rules, the recording store, the transcript search and the tool dispatch yourself. Tel-Agent's contribution is that it packages those four things behind one MCP tool surface and a routing layer, at the price of adopting its architecture and its alpha release cadence. Neither route is strictly better. The hosted product wins on time to first call; the raw API wins on control; Tel-Agent sits between them and asks you to accept a young codebase in exchange for owning the audio.
Licence and the maintenance arithmetic
Tel-Agent is licensed under AGPL-3.0, and the README also carries DSGVO/GDPR and EU AI Act compliance badges. The licence is the detail most likely to surprise a commercial adopter. AGPL-3.0's network clause means that if you modify Tel-Agent and let users interact with it over a network, you are generally obliged to offer those users the corresponding source. Running it unmodified as an internal receptionist is a different situation from shipping a modified version as part of a product. That is a question for your own legal review, not something this article can settle. On maintenance, the observable facts are these: the repository is not archived, the last push was on 2026-09-14, and the only releases are v0.1.0 and v0.1.1 from 2026-09-05. The README states the project is maintained by Dpro GmbH in Vienna and lists a homepage at tel-agent.com. A single-vendor project at v0.1.x means upgrade cost is currently low in absolute terms, because there is almost no version history to migrate across, but it also means the API surface can move under you between releases. Pin a release tag rather than tracking main if you deploy this anywhere real.
Editorial conclusion
Adopt Tel-Agent if you already run a SIP PBX such as 3CX, Asterisk or FreePBX, you want the recordings and transcripts to stay on your own hardware, and you are comfortable running alpha software with a v0.1.x release history. Do not adopt it if you need analog line support, if you expect it to replace the PBX itself, or if you need a stable API surface for a customer-facing deployment. Before installing, verify two things in the repository: which SIP extension configuration your PBX requires, and whether the AGPL-3.0 network-copyleft clause conflicts with how you intend to expose the gateway to users outside your organisation.
Community notes