After watching hundreds of Voice AI teams onboard onto Tuner, a pattern became hard to ignore.

The stack choice isn't just a technical preference, it determines what data you even have access to, and how hard it is to get it somewhere useful.

Three kinds of Voice AI builders

1. Platform-first builders

They move fast. They reach for Vapi, Retell, or another orchestration platform and accept the tradeoff, a bit more cost, a bit less control, because time to market matters more. The plumbing is handled. They ship fast.

2. Open-source engineers

They want control without starting from zero. LiveKit, Pipecat or Dograh, these give them a working foundation they can actually own. They pick their own STT, swap their TTS, and more often they self-host. Full flexibility, still some scaffolding.

3. Custom stack teams

These are the veterans. No off-the-shelf orchestration. They wire every piece themselves. LLM, STT, TTS, memory, routing, sometimes running their own fine-tuned ASR or TTS models. They're usually platform builders serving end customers who need reliability and cost efficiency at scale. They built all of it. They know all of it.

Three valid approaches. Wildly different engineering lift.

At Tuner, we serve all three and our customer base splits roughly equally across them. But something has shifted recently: custom stack teams are our fastest-growing segment.

They're also the hardest to onboard.

Not because Tuner is complex,w but because custom stacks don't have a standard shape. Every team captures call data differently, structures their traces differently, names things differently. They use different orchestration frameworks, different memory layers, different routing logic. And they have to capture all of it manually, construct the traces, format the data, then send it to Tuner. That instrumentation work shouldn't fall on the builder.

Every voice call has two layers

• Voice layer: STT hears the user, TTS speaks the reply. This is your transport. Most teams already track it.

• Brain layer: LangGraph decides which step runs next. LangChain runs the LLM and tools inside each step. This layer is invisible unless you instrument it.

Platform-first builders get this visibility by default, it's baked into the orchestration platform. Custom stack teams don't. They either hand-wrap every node and tool call themselves, or they fly blind.

That's the gap we close today.

Introducing tuner: LangChain/LangGraph library

Instead of hand-wrapping every node and tool call, you attach one callback handler to graph.invoke(). It records node transitions, timing, and tool calls automatically. At hang-up, you format those events and include them in your Create Call payload.
One attachment. Full brain layer visibility in Tuner alongside your voice layer.

How it works

Three pieces do the work:

Handler          = ears       (listens while the graph runs)
Accumulator      = notebook   (stores what happened)
Segment builder  = formatter  (turns the notebook into Tuner transcript rows)

Handler          = ears       (listens while the graph runs)
Accumulator      = notebook   (stores what happened)
Segment builder  = formatter  (turns the notebook into Tuner transcript rows)

Handler          = ears       (listens while the graph runs)
Accumulator      = notebook   (stores what happened)
Segment builder  = formatter  (turns the notebook into Tuner transcript rows)

Handler (TunerLangGraphHandler or TunerLangChainHandler) a LangChain callback. Pass it to invoke() and it does the rest. You never call its methods directly.

Accumulator (TunerAccumulator) one per call. Stores every event the brain layer produced. Read it back with get_invocations().

Segment builder (segments_from_invocation()) converts one turn's events into Tuner transcript rows, with timestamps as milliseconds since call start.

Full documentation: tuner-langchain docs

What's next

This is the first library in a series. Custom stack teams shouldn't have to choose between full control over their architecture and full visibility into how it behaves.

More soon.