My role has been engineering owner of the TalkOps fork: deciding what to fix first
TalkOps Voice AI Agent Platform
Most teams that try to build a voice AI agent end up building five products at once. A telephony integration. A WebRTC layer for browser calls. An auth system. A place to store recordings. A background job queue so calls don't block the app. An admin panel to manage all of it. TalkOps exists so a team doesn't have to build all five from scratch. TalkOps is a commercial voice AI platform for building, deploying, and managing conversational AI agents, with both telephony and WebRTC support built in. It ships as a full-stack foundation: a Next.js frontend, a FastAPI backend, a PostgreSQL database, Redis-powered background tasks, dedicated audio storage, and a deployment structure that's ready for production rather than a demo.
Summary
Most teams that try to build a voice AI agent end up building five products at once. A telephony integration. A WebRTC layer for browser calls. An auth system. A place to store recordings. A background job queue so calls don't block the app. An admin panel to manage all of it. TalkOps exists so a team doesn't have to build all five from scratch. TalkOps is a commercial voice AI platform for building, deploying, and managing conversational AI agents, with both telephony and WebRTC support built in. It ships as a full-stack foundation: a Next.js frontend, a FastAPI backend, a PostgreSQL database, Redis-powered background tasks, dedicated audio storage, and a deployment structure that's ready for production rather than a demo.
Problem
Teams building voice agents typically need to wire together real-time conversation handling, telephony, WebRTC, authentication, audio storage, background jobs, organization management, and deployment infrastructure, usually as separate systems that were never designed to talk to each other. Without something unifying those pieces, the result is fragmented, hard to maintain, and harder to scale once it needs to work commercially rather than as a proof of concept.
My Contribution
TalkOps runs on a fork of Dograh, an open-source voice AI platform built on pipecat, not a from-scratch build. My work is the 18 commits since that fork. Two of them are real product fixes. One closed a password reset bug: a token_used flag was set on use but never checked, so reset tokens could be replayed. That fix shipped alongside Zod validation across all four auth forms (email normalization, password complexity, a 72-byte bcrypt cap) and moved the rate limiter onto Redis so limits hold across workers instead of resetting per process. The other adds per-agent metrics: average latency and cost per minute, computed server-side and surfaced in the workflow table. It's a monitoring layer, not a latency fix. Everything else in the fork is what turns Dograh into TalkOps: the rebrand, a license change from BSD-2-Clause to proprietary, swapping the support widget from Chatwoot to Tawk.to, and the CI/Docker setup for building and shipping images. The voice pipeline itself, WebRTC, STT/TTS, turn-taking, agent context, hasn't been touched yet.
Product Context
TalkOps started because none of the existing voice agent platforms hold up end to end. Vapi runs into latency. Retell's pricing doesn't scale. OmniDimension limits which STT, TTS, and LLM models you can use. Those are the three core failure points in voice AI infrastructure right now, and forking Dograh, an open, self-hostable base, was the way to fix them without inheriting any one vendor's ceiling. The build is happening in layers. The first layer, already shipped, is branding and access control: turning it into an invite-only platform under the TalkOps name instead of a public Dograh instance. The next layer goes straight at the two hardest problems, latency and agent context, alongside a model evaluation layer: testing STT, TTS, and LLM models against each other and publishing real pricing next to real performance numbers, so whoever's deploying an agent can pick the model that fits their use case instead of being stuck with whatever the platform defaults to. That directly answers the OmniDimension problem of a locked-down model list.
What I Worked On
TalkOps is a fork of Dograh, an open-source voice AI platform built on pipecat, with 18 commits of original work on top of it. Two of those are real product fixes: a password reset security bug and a per-agent latency and cost metrics view. The rest turns the open-source base into a branded, invite-only product: a license change, a swapped support flow, and a working CI/Docker deployment pipeline.
System Workflow
User signs in -> creates or manages an organization/workspace -> configures a conversational AI agent -> connects required communication channels such as telephony or WebRTC -> platform handles real-time conversation flow, backend API coordination, background jobs, and audio storage -> user manages agents, settings, and operational workflows from the dashboard.
Technical Implementation
The fork starts at commit c2b3328, the unmodified Dograh import. Everything after is original work across 18 commits. The auth fix (f609fe9, around 11 files) closed a password reset flow where a token_used flag was set when a token was used but never checked before allowing another reset, so a used token could be replayed. Zod validation was added across all four auth forms: email normalization, password complexity rules, and a 72-byte cap to match bcrypt's input limit. The rate limiter, previously slowapi running per-process, now stores state in Redis, so limits hold when the app runs across multiple uvicorn workers instead of resetting per worker. Per-agent metrics (4353ef1, 65f42d5) compute average latency and cost per minute per agent inside workflow_run_client.py, expose it through the workflow route, and surface it in the WorkflowTable component. It's covered by tests. It's a monitoring layer, it doesn't change latency itself. The remaining commits handle the rebrand (Dograh to TalkOps, a1442f2 swaps the BSD-2-Clause license for a proprietary one), the support widget (Chatwoot to Tawk.to, f9f7d20 and 6232990), and CI/Docker: GHCR image builds, pipecat pinned as a git submodule, healthcheck and entrypoint fixes, and an aiosmtplib version pin. Untouched so far: the voice pipeline itself, WebRTC, STT/TTS, turn-taking, and agent context passing.
Product & Engineering Decisions
The first decision was what to build on: fork an existing platform instead of building from zero or staying on a managed one. Vapi's latency, Retell's pricing, and OmniDimension's limited model choices ruled out staying put, and Dograh gave a working, self-hostable base instead of starting from an empty repo. The second decision was sequencing: fix security and turn the fork into something sellable, an invite-only platform under a proprietary license, before touching the harder problems of latency and agent context. Inside that first phase, the rate limiter moved from an in-process check to Redis-backed state, since the old version reset per worker and didn't hold limits once the app ran across multiple uvicorn processes.
Constraints & Tradeoffs
Building on a fork instead of a clean build means inheriting Dograh's existing architecture, including whatever limits it already has in the voice pipeline, until those parts get touched directly. None of that has happened yet: WebRTC, STT/TTS, turn-taking, and agent context passing are all still exactly as Dograh built them. The metrics view is a real tradeoff too, it shows latency and cost per agent, but showing the number and fixing the number are different projects, and only the first one is done. The choice so far has been to get the business fundamentals right first, security, licensing, access control, before spending time on the deeper platform work, which means the parts of TalkOps meant to be different from Vapi, Retell, and OmniDimension aren't built yet.
Impact
The password reset fix closed a real security hole: reset tokens that should have expired after one use could be replayed indefinitely. Auth forms now validate real constraints, email format, password complexity, bcrypt's length limit, instead of trusting whatever the client sends, and rate limits hold across every worker instead of resetting per process. The metrics view adds visibility that didn't exist before: real latency and real cost, per agent. And the rebrand and license change turned an open-source repo into something that can be sold and supported as a product.
What I Learned
Whitelabeling turned out to be more than a logo and a name change: licensing, naming, and support all had to move together for it to read as a different product instead of a reskinned one. Packaging it as an image and pushing it to GHCR meant setting up a real build and versioning process, not just running things locally. Deploying through Dokploy meant treating it like a production target from day one instead of a personal script. Working through what's wrong with Vapi, Retell, and OmniDimension, latency, pricing, model selection, made the gaps in current voice AI platforms concrete instead of abstract, and that's what's shaping what TalkOps builds next. And swapping in Tawk.to meant learning a live-chat integration end to end instead of just picking a vendor off a list.
Disclosure
TalkOps is a fork of Dograh, an open-source voice AI platform released under a BSD-2-Clause license. The fork itself moved to a proprietary license as part of turning it into a commercial product, which is why this codebase isn't public. Dograh's original source remains open under its own license.