We replaced our 223-node agent graph with a single open-source LLM

Skip to main content

Industries

Careers

CompanyCustomers<br>Resources

Book a demo

We replaced our 223-node agent graph with a single open-source LLM<br>Aug 20, 2026<br>Netic

Ajay Arora

When Netic initially began exploring new voice agent architectures six months ago, we tested a wide variety of complex harnesses, from graph approaches to planner sub-agents to swarms and codifying conversational flows. None of these solved the main problems with voice agents today: they take too long to respond, they loop, they deflect instead of answering, and they miss things a human would instantly catch.

With the release of flagship models like Kimi K2.6 and GLM 5.2, we’ve seen for the first time that open-source LLMs can handle 100s of operating procedures concurrently in context while adjusting on the fly to the nonlinear nature of human conversations.

Today, Netic’s agents book at over 15 points higher on containment and appointment booking than they did just three months ago. Time to first token has halved to under 500ms. This post explains the guiding principles behind our decision to switch to a single LLM architecture and how we orchestrate our voice agents to achieve over $500M in autonomous job bookings for our customers.

A brief history<br>Netic started encoding Standard Operating Procedures (SOPs) as a graph in 2024. Every step in a procedure became a node, with edges gated by conditions. Some were boolean checks over variables extracted from the caller's speech. Others were natural-language conditions evaluated turn by turn. Existing members, after-hours requests, or any other category got its own branch. In an era when LLMs frequently hallucinated instructions, writing procedures in code let us out-perform competing vendors on reliability.

As we grew, the complexity and volume of procedures we supported began to grow too. Single if-else conditions became if-elif-elif-elif-else chains, and edge conditions stopped fitting in one readable sentence. Under vague, real-world caller speech, the agent started choosing wrong branches, so we added dedicated classifiers: intent classifiers, ownership classifiers, trade classifiers, etc. These first lived on our backend behind tool calls, but as the product matured, we built them into the orchestration layer as classifier nodes to remove network hops.

The conditions kept misfiring on real speech anyway. This example of a caller trying to buy a full system replacement (a high revenue job) shows where it veered off-path.

Transcript

Customer

New furnace and new air conditioning.

Agent

Just so I understand, are you looking for an estimate to install a new furnace and air conditioner, or do you need service on your current systems?

Customer

I need financing for… oh.

mention of "financing" &rarr; escalation edge

Agent

Since it's after hours, I'll need to leave a message for a team member to call you back about financing and your new furnace and air conditioner.

Customer

We need this as soon as possible. I have five kids and a baby.

Agent

I understand, that sounds stressful with little ones at home. Since it's after hours, I do need to leave a message for our team…

The fix was a band-aid commit: “stop escalating when financing is mentioned on new-system calls." As models improved, we kept building primitives to facilitate these classifier patches and stitch new agentic capabilities onto a growing graph. But two years later, this became unsustainable, and failures would keep emerging from the graph architecture.<br>Guiding Principles<br>The system we run today is simple yet effective: one agent, with the full conversation history and a procedure library it loads from as the conversation develops. It runs on a single open-weight model which streams out dialogue and thus gives us control over our own inference.<br>Behind it are four principles:<br>1. Constrain outcomes, not paths. Determinism lives at the tool boundary, at the points of irreversible action. The conversation itself has no prescribed shape.<br>2. The model sees everything. Full conversation history and the relevant procedures in context. Most of our graph-era failures were context starvation in disguise.<br>3. Instructions over primitives. Ordering and policy are stated once as procedure text. Current models follow them reliably enough that structural enforcement is redundant.<br>4. One agent per conversation. Context never fragments across specialists, and there is no handoff to go wrong.

We derived these lessons from watching a graph architecture break down over two years in production.

Why graphs fail at conversation<br>The failures we saw compress into four mechanisms, and each one reflected one of the principles above.

‍1. Constrain models, not paths

‍ A graph forces a commitment to a classification at the moment you have the least information, when the caller first speaks. Real callers reveal what they need gradually, out of order, and often after...