Editor's Note: In Production is a series of dispatches from Wonderful's forward-deployed engineers and deployment strategists - the people living inside customer environments, doing the work. Most AI stories are told from the outside. In Production is a captain's log told from inside the room.

Most voice agents can survive a little ambiguity. Troubleshooting agents cannot.

When a caller is standing next to a hardware device, every answer changes the next safe step. If the agent skips a confirmation or treats two similar faults as interchangeable, the failure doesn’t look like a bad response, but it can mean a damaged device, an unnecessary technician visit, or a caller who no longer trusts the system.

That was the problem we walked into midway through a deployment for a large consumer appliance brand. The agent had already been in development for months. It could understand callers. It could answer. But it could not yet do the thing production required: stay reliably on the path.

The use case was simple until it reached production

Callers varied widely in age, technical comfort, and vocabulary. Most were not technicians and described the issues however they could: an error on the screen, a sound the device was making, or something they saw but did not know how to name.

The agent had to guide them through a fix step by step, without losing its place, skipping a required check, or leading them down the wrong path.

The scale made that difficult. There were eight device types, with 80 to 100 fault types each. Every fault had its own resolution path. Some paths overlapped, some required the same question for different reasons, and some needed the caller to go backwards before moving forward. The procedures were also not limited to questions and answers. Certain steps triggered API calls whose responses had to be interpreted in real time and incorporated into the next decision. All of these behaviors had to operate as a single coordinated mechanism: reliable, persistent, and perfectly synchronized across every interaction.

The architecture had to change

We treated the architecture itself as an open question. The issue was whether the agent could stay oriented through a long operation with a caller who might interrupt, answer indirectly, go backwards, or change the topic halfway through.

We quickly realized that conversational success and procedural success were not the same thing. An interaction could sound perfectly natural while still violating the troubleshooting process. A skipped confirmation, an overlooked prerequisite, or a branch taken too early could put the caller on the wrong resolution path. The challenge was not getting the next response right but maintaining procedural integrity across a long, unpredictable conversation.

From scripts to maps

At the beginning, the troubleshooting tree lived inside the prompt, split across two skills, one per fault. It looked simple: if the agent had the procedure in its instructions, it should be able to follow it. But in practice, long troubleshooting flows do not behave like short scripted tasks. The agent could carry the next step for a while, then lose the sequence when the caller interrupted, answered indirectly, or moved backwards.

The response to that drift was to pull the tree out of the prompt and put it behind a tool. The tool held the full JSON and returned one step at a time, so the agent no longer had to carry the whole flow in context. It was more controlled, but the pendulum had swung too far. Every step became another tool call, latency increased, and the conversation started to feel like it was advancing by command rather than by understanding.

The second pivot point was chunked context. The agent should not be responsible for remembering an entire script, but it also should not be reduced to a rigid step runner. It needed local context: enough of the operational path to move naturally, while the system still held the route.

The principle was simple: the agent should see the part of the troubleshooting map it needed now, not the entire map at once. Instead of feeding the agent one step at a time, the system exposed a chunk of the tree around the current point. The agent could navigate inside that local area without calling the tool every turn.

The breakthrough was a Guided Resolution Engine

Under the hood, every fault became a graph: diagnostic questions, caller actions, checks, transitions, conditions, and escalation rules. A chunk included the current step, nearby branches, allowed transitions, and the conditions that determined whether the agent should continue, clarify, go backwards, or escalate.

When the caller followed the expected path, the agent could keep moving through the chunk. When the caller disagreed, went backwards, answered ambiguously, or changed the topic, the system could re-anchor the conversation to the right node and continue from there.

What we had built was a Guided Resolution Engine: a chunked operational map that let the agent navigate locally while the process stayed controlled.

Being in the building

We were at our partner's offices throughout the engagement, which meant that their team could watch a flow in real time, point to the exact moment something felt off, and tell us why. We could translate that feedback directly into architecture and flow changes, and they could see those changes land the same day.

That visibility changed the relationship. Our partner wasn’t outside the build, waiting to see it: they were a part of it. They wanted to understand the system, and that meant being able to inspect it, challenge it, and improve it with us.

This means there was no need for a handoff, and by the time the deployment went live across the group, our partner had clear owners on their side who knew the system inside-out because they helped shape it.