agents vs pipecat: a participant inside LiveKit's media server against a pipeline you compose

A participant in a media server against a pipeline you compose

Both projects build realtime voice agents in Python, but they start from opposite ends of the stack.

LiveKit's agents starts from the media server. The README calls it a framework for realtime, programmable participants that run on servers, and its core concepts reflect that. An Agent is an LLM-based application with defined instructions. An AgentSession is a container that manages interactions with end users. An entrypoint is the starting point for an interactive session, described as similar to a request handler in a web server. An AgentServer is the main process that coordinates job scheduling and launches agents for user sessions. Underneath sits LiveKit's WebRTC media server, and the framework is designed to be used with it. Turn handling uses a transformer model for semantic turn detection, so the agent can tell when a user has finished speaking rather than waiting on a fixed silence threshold. Job scheduling and dispatch APIs connect end users to agents, and the telephony stack lets an agent place or receive calls from ordinary phones.

pipecat starts from the pipeline. The README describes each pipeline as an agent, so composition happens between pipelines: specialists hand off to each other, fan out in parallel, or run as sidecars over a shared bus, locally or distributed across processes and machines. On top of that sits Pipecat Flows, for conversations with predefined or dynamic paths and state management. The framework also stays out of the transport decision, working over WebSockets or WebRTC depending on what you wire in.

The practical difference is ownership. With agents you adopt LiveKit's infrastructure as well as its framework. With pipecat you adopt the composition model and assemble the rest.

Transports, clients and who reaches the user

LiveKit's agents comes with a single answer to the client question, and it is a good one. The README points at LiveKit's open-source SDK ecosystem as supporting all major platforms, and adds RPCs and other data APIs so an agent can exchange structured data with a running client rather than only speaking audio. Telephony is part of the same stack, so the same agent can meet a user on the web and pick up a phone call. The cost is on the operations side: our analysis of agents says to skip it if you cannot run a LiveKit server and its dependencies, and to check that your deployment can absorb the WebRTC and job dispatch overhead before committing.

pipecat offers more client choices and a different kind of tooling. The official SDKs cover JavaScript, React, React Native, Swift, Kotlin, C++ and ESP32, and our analysis makes verifying your transport against that client list the first check. For the front end there is Pipecat UI, a shadcn registry of components for voice applications. For the back end there is Whisker, a real-time debugger for pipelines and processors, and Tail, a terminal dashboard for a running system. The Pipecat CLI ships with the package and can be installed with uv tool install "pipecat-ai[cli]", then scaffold, monitor and deploy.

So the choice here is depth against breadth. One stack, deeply integrated, with one client ecosystem and one media server to operate, against a wider set of clients, a UI kit and debugging tools, with the media layer left to you.

Getting agents and pipecat running

LiveKit's agents starts with credentials. You install the library with the provider extras you need, pip install "livekit-agents[openai,deepgram,cartesia]", then set three environment variables: LIVEKIT_URL, LIVEKIT_API_KEY and LIVEKIT_API_SECRET. The code itself is short. You instantiate an AgentServer, decorate a function with the server's rtc_session decorator, and inside it create an AgentSession with a voice activity detector and the model providers you want. Tools are ordinary Python functions marked with a decorator, which keeps the tool surface familiar to anyone who has written a normal API.

pipecat gets you to a running bot faster and with less setup. The quickstart command scaffolds a project, and the README describes the CLI setting things up so that an AI coding assistant such as Claude Code or Codex can build it, scaffolding a runnable bot in under a minute, after which the same CLI monitors and deploys it. There is a quickstart guide for people who would rather read than prompt. The requirement that catches people is Python: the analysis puts requires-python at 3.11 and newer, with audioop-lts pulled only from 3.13 upward, so a 3.10 environment is out.

The difference in first-run friction is mostly about what you have to bring. agents needs a LiveKit deployment to point at before anything runs. pipecat runs locally with nothing external, and the account and infrastructure decisions come later.

Composition, delegation and how you check it works

Multi-agent structure is where the two frameworks differ most in shape. LiveKit's agents models delegation as agents handing off to each other. You subclass Agent, give it instructions, and use on_enter to decide what the agent says when it takes over, which is enough for a specialist that collects a few facts and passes the conversation on. The framework also supports MCP with one line of code, so tools from an MCP server are available to an agent without extra plumbing.

pipecat treats a pipeline as a first-class agent, so the composition vocabulary is wider: handoff, parallel fan-out, sidecar workers over a shared bus, and deployments distributed across processes and machines. Pipecat Flows adds structured conversation paths with state management on top of that.

Testing is where agents has the clearer story. The framework includes a test integration aimed at exactly the problem that voice agents are hard to test: a pytest example drives a session, asserts that the next event is a function call with a given name, and the README describes judges for checking that an agent behaved as expected. pipecat's equivalent debugging story lives outside the framework in Whisker, a real-time pipeline debugger, which is a different tool for a different job: watching a live pipeline rather than asserting on recorded events.

If your agent makes decisions you need to regress against, agents gives you a way to write that down. If your agent is one node in a fleet of cooperating pipelines, pipecat gives you the shapes to express that.

Where each one falls short

LiveKit's agents is the wrong tool in two clear situations. The first is a product that is a chatbot with a voice input bolted on, because the framework's value is realtime media, and that infrastructure has to be there for the value to appear. The second is an organisation that cannot run a LiveKit server and its dependencies, since the framework is designed to sit on top of that infrastructure rather than replace it. Even then it is a specific stack: clients built on LiveKit's SDKs, telephony through LiveKit's SIP integration, and scheduling through its job dispatch.

pipecat has a different weakness, and it arrives early. The analysis of pipecat notes that the base dependency set pulls in the OpenAI client, onnxruntime and numba before you have chosen any provider, which means a project that wants a small install does not get one. That is a real cost in cold-start time, in image size and in the number of transitive packages you inherit on every upgrade. The release cadence is the second one: the analysis records 1.11.0 and 1.10.0 inside the same month and 1.12.0 on 2026-09-26, with the package marked Production/Stable, which reads as a project that ships often and expects you to pin the version you develop against. Third, pipecat does not ship a media server, so the audio and transport layer is yours to build, secure and operate.

Both frameworks also assume a realtime deployment. Neither is a good fit for a request and response API with no audio path.

Licence, maintenance and the choice by scenario

The licences are both permissive and both let you ship closed source. LiveKit's agents is Apache-2.0, which carries an express patent grant. pipecat is BSD-2-Clause, a two-clause licence with a warranty disclaimer and no patent grant. Neither imposes a disclosure obligation on a hosted service built on top of it, and both allow modification of the framework itself.

Activity is similar. LiveKit's agents pushed on 2026-10-04, with recent releases at [email protected] on 2026-08-27 and 1.7.0 and 1.6.10 on 2026-08-20. pipecat pushed on 2026-10-21, with tags v1.10.0 on 2026-09-12, v1.9.0 on 2026-09-11 and v1.8.1 on 2026-08-27. Both are moving, and pipecat's cadence is the faster of the two, which is the practical argument for pinning it.

Choose by what you want to own. If the conversation happens in a browser, on a phone, or in a call centre queue, and you would rather have one vendor-shaped stack with job dispatch, client SDKs and telephony already agreeing with each other, take agents and run LiveKit alongside it. If your agent is one stage in a wider system, where work fans out to parallel specialists, where a stage runs as a sidecar over a shared bus, or where stages sit on different machines and different transports, take pipecat and build the media layer yourself. If neither of those describes you, the honest answer is that neither framework earns its dependency.

Bottom line

Take agents when you will commit to LiveKit's WebRTC stack and want its client, dispatch and telephony story whole; take pipecat when the composition model matters more than the media stack and you can live with the OpenAI client, onnxruntime and numba arriving before you choose a provider. Before committing to pipecat, pin the version you develop against and read the dependency list, and before committing to agents, measure whether your deployment can absorb the WebRTC and job dispatch overhead.

Sources

1. livekit/agents repository
2. livekit/agents README
3. pipecat-ai/pipecat repository
4. pipecat-ai/pipecat README