Bolna Voice AI Agent Platform
An end-to-end open-source voice agent framework: orchestrate ASR, LLM, and TTS through a single JSON config to build phone-capable conversational assistants fast.
Keys flow via .env and system AWS credentials; tests deliberately prevent pointing at live accounts. No malicious behaviour or excessive permissions observed. Deductions: external effects (initiating phone calls) lack built-in confirmation; data-flow transparency (audio/transcripts sent to many cloud providers) only described in README fragments; no rollback mechanism; unverified publisher and thin attribution.
Dependencies pinned or bounded; test infrastructure (conftest, smoke script) is carefully designed; failure paths in the smoke script have explicit events and messages. Deduction: error handling visible only for the provided files, not the whole orchestration platform's failure semantics.
README targets voice-assistant developers, with telephony and text-only paths, a telephony extension guide, and Python version requirements; boundaries (closed-source hosted components) stated. Deduction: trigger precision (language switch/LID) visible only in test fixtures, not documented for users.
Complete MIT license, disciplined pyproject (commitizen, ruff, pytest), install notes with quick-start and manual Docker steps, rich examples. Deductions: README admits maintainer shortfall ('actively looking for maintainers') and fluctuating maintenance; no CHANGELOG; known limitations only indirectly mentioned.
JSON-driven assistant orchestration, programmatic Python API and a Docker local stack are usable; output shape (async streaming dicts) documented; clear marginal value versus hand-building ASR+LLM+TTS pipelines. Deduction: cost/benefit depends on third-party API pricing, not quantified.
README links point to specific commits/paths; examples align with requirements. Deduction: limited cross-source corroboration (README plus a subset of code); 'production ready' claims unsupported by test evidence in scope; fact/inference separation otherwise clear.
- Initiating real phone calls is a high-risk external effect; add your own confirmation and rate-limiting before deployment.
- Audio and transcripts are sent to multiple cloud providers (Deepgram/OpenAI/ElevenLabs/Azure etc.); assess data residency and compliance yourself.
- The project publicly seeks maintainers; maintenance continuity is uncertain — evaluate update cadence before production use.
- Publisher identity is unverified; establish supply-chain trust independently (pin dependencies, review workflows).
What does this agent do, and when should you use it?
Bolna (bolna-ai/bolna, MIT license) is an end-to-end open-source, production-ready framework for building LLM-based, voice-driven conversational applications. The repository contains the full orchestration platform, which conducts voice conversations over websockets by combining different ASR + LLM + TTS providers and models. The local deployment consists of four Docker containers: a telephony web server (Twilio or Plivo), the Bolna server, an ngrok tunnel, and Redis persistence. Hosted APIs and a no-code playground built on this orchestration are also offered, but both are currently closed source. Developers can build pipelines programmatically via the Python Assistant class or make real phone calls through the Dockerized local setup. The project explicitly states it is actively looking for maintainers, and admits maintenance investment has fluctuated between the open-source and hosted offerings.
Bolna orchestrates the full voice conversation pipeline: initiating calls via Twilio or Plivo (Exotel and Vonage marked coming soon), transcribing audio with providers like Deepgram and Azure, handling conversation with LLMs such as OpenAI, DeepSeek, Llama, Cohere, and Mistral, then synthesizing responses back to the phone line via AWS Polly, ElevenLabs, Deepgram, OpenAI, Azure, Cartesia, Smallest, Maya, or Kalpa. LLM integrations use the LiteLLM package, with VLLM-hosted models also supported. In code, developers assemble tasks with bolna.assistant.Assistant, configuring a Transcriber (e.g., provider='deepgram', model='nova-2'), an LlmAgent/SimpleLlmAgent (e.g., provider='openai', model='gpt-4o-mini'), and a Synthesizer (e.g., provider='elevenlabs'), building a transcriber → LLM → synthesizer pipeline with add_task, and iterating asynchronously over assistant.execute() for streamed chunk results. examples/simple_assistant.py and examples/text_only_assistant.py demonstrate both flows; REST-based agent CRUD is documented in API.md at the repo root. The local deployment starts via local_setup/start.sh or docker compose build/up -d, with provider credentials supplied through a .env file (e.g., DEEPGRAM_AUTH_TOKEN, ELEVENLABS_API_KEY, TWILIO_ACCOUNT_SID).
- Development teams that need to quickly build voice assistants capable of placing and receiving calls for support or outbound calling in their product
- Engineers who want to self-host the voice pipeline with their own LLM keys (OpenAI, DeepSeek, VLLM-hosted models) rather than depending on a single SaaS
- Developers building bidirectional streaming voice apps on Twilio or Plivo who need a ready-made websocket orchestration layer
- Technology evaluators benchmarking multiple TTS options (ElevenLabs, Cartesia, AWS Polly) against multiple ASR options (Deepgram, Azure) in one pipeline
- Developers who prefer a pure Python programmatic interface and want to consume conversation results as async streams (runnable examples in examples/)
- Users who only need a text-only LLM conversation pipeline with no audio input/output (supported via the text-only mode)
What are this agent's strengths and limitations?
- Highly swappable providers: ASR (Deepgram, Azure), LLM (OpenAI, DeepSeek, Llama, Cohere, Mistral, and VLLM-hosted models via LiteLLM), TTS (ElevenLabs, Cartesia, AWS Polly, and more), and telephony (Twilio, Plivo) can all be mixed and matched, avoiding single-vendor lock-in
- Complete runnable local deployment path: the Dockerized four-container setup in local_setup/ (telephony server, Bolna server, ngrok, Redis) ships with a one-command start.sh script
- Dual access modes — a Python programmatic interface (Assistant class, async streaming execute) and a REST API (API.md) — plus a text-only pipeline example, giving flexible integration options
- The README documents a concrete extension path for adding new telephony providers like Vonage or Telnyx by subclassing telephony.py in input_handlers and output_handlers
- The hosted APIs and no-code playground (platform.bolna.ai) are closed source, so the full product experience depends on the vendor's hosted services
- Making local calls requires an ngrok tunnel plus paid Twilio/Plivo accounts, making the deployment chain long (four containers plus .env credential configuration)
- The project publicly states it is actively looking for maintainers and admits past fluctuation in maintenance investment between the open-source and hosted offerings, creating long-term uncertainty
- assistant.execute() yields dicts whose fields vary with provider and tool configuration — there is no fixed schema, so callers must handle streamed parsing themselves
- Some telephony providers (Exotel, Vonage) are still marked 'coming soon' and not yet implemented
How do you install or deploy this agent?
Prerequisite: Docker with Docker Compose V2 installed. Quick start:
cd local_setup
chmod +x start.sh
./start.shThe script checks Docker dependencies, builds all services with BuildKit, and starts them detached. Manual route: export DOCKER_BUILDKIT=1 and COMPOSE_DOCKER_CLI_BUILD=1, run docker compose build, then docker compose up -d. You can also start a subset: docker compose up -d bolna-app twilio-app (or plivo-app). Before first run, create .env from .env.sample and fill in provider keys; making calls via Twilio or Plivo requires accounts with those services, and ngrok requires an authtoken in ngrok-config.yml.
How do you use this agent?
Option 1 (Dockerized local setup): once the four containers are running, create agents and instruct them to initiate calls; agent and prompt data persist in Redis. Sample agents are available at examples.bolna.dev. Option 2 (programmatic Python): set OPENAI_API_KEY, DEEPGRAM_AUTH_TOKEN, and ELEVENLABS_API_KEY, then run python examples/simple_assistant.py. In code, create an Assistant(name=...), assemble a pipeline via add_task(task_type='conversation', llm_agent=..., transcriber=..., synthesizer=...), and iterate over assistant.execute() — an async generator yielding per-step dict chunks whose fields vary by configuration; process incrementally. Text-only mode: call add_task with enable_textual_input=True and no transcriber/synthesizer; only OPENAI_API_KEY is needed. REST-based agent CRUD is documented in API.md at the repo root.
How does this agent compare with similar options?
The README distinguishes Bolna's open-source repository from its own hosted APIs and the no-code playground at platform.bolna.ai: the open-source repo is the core orchestration platform where new features land first before reaching hosted APIs and the UI. No other specific competitor products are named in the source, so no reliable comparison can be made.