This is the second post in a series about the Aquant Conversational AI platform. The first one was about the journey. This one is about the capability I get asked about most: interaction flows.
Imagine the call.
A machine on a production floor has stopped. A technician is standing in front of it with a fault code on the display, and calls your service line. Or a homeowner's appliance has failed and they want someone out this week.
Now imagine you are trying to automate that with an AI agent, and the only thing you have is a very long instruction telling it what to do. It has to ask the right questions, in the right order. Recognize when the caller has changed the subject. Look up the right model and the right service history. Know when to hand off. Do the same thing on Tuesday that it did on Monday.
Some calls, it gets right. Some it does not. And when it goes wrong, you cannot point to the step where it went wrong, because there are no steps. There is only a wall of instructions.
That is the problem interaction flows solve. (See it in action)
An interaction flow is an atomic task an Aquant conversational agent can perform. Intake is a task. Booking a service appointment is a task. Troubleshooting a fault code is a task. You build each one once, and then you assign the ones you want a given agent to handle.
The useful way to think about it is hiring. A new service rep starts with one or two things they can do well. Over time they pick up more skills, and the range of problems they can resolve grows. Aquant's conversational agent works the same way. You add flows, and the agent gets more capable, without rebuilding it from scratch.
But the caller never sees the seams.
This is the part that matters. Flow boundaries are an authoring concept. They exist for the person building the agent, not for the person on the phone.
At runtime, the agent moves between flows the way a person would. Someone calls to book a service appointment, and halfway through asks when the machine was last serviced. The agent branches into that path, answers it, and returns to the booking exactly where it left off, with the context intact. To the caller, it is one conversation that happens to go where they take it.
Why flows, and not prompts or code
We looked hard at the alternatives.
You can do it with prompting. But prompts are LLM code - you have to be good at it, prompt boundaries are genuinely hard to get right, and you end up with no visual representation of your own business process. That last part is the killer. There is nothing to review, nothing to version cleanly, and no straightforward way to reason about consistency or predictability.
You can do it with code. But then only engineers can touch it, and the people who actually understand how service works at your company are locked out of the thing that encodes it.
We wanted to hand real control to customers in a self-serve way, and still let them build sophisticated flows rather than rudimentary ones. So the complexity goes into the framework, and what is left is a modeling environment.
Sophistication that scales with you
Anyone who understands the business problem should be able to build a flow. You start by modeling it - describing the steps. From there you can add logic and handle conditions, still inside the modeling environment. And when you need real integration, someone technical can stand up an MCP server, or build an agent in Salesforce Agentforce, and connect it back into the flow.
Same flow. Different depths of involvement, depending on what the step needs.
What that looks like in practice
Take booking a service appointment. The agent asks the caller what is wrong with the equipment. Validates their ZIP code. Calls out to a system to find the nearest service location with coverage for that asset. Confirms it with the caller. If the caller wants a different date or location, it loops back and reconfirms. Once confirmed, it creates the case in the system of record, gets a case number back, and sends the caller an SMS with the confirmation.
That is real process automation with several system touches, a confirmation loop, and a channel switch - inside one phone call. Building that yourself, in prompts or in code, is a project. Here it is a flow.
Skills that change with context
Call a service center during business hours and you reach one group of people with one set of services. Call after hours and it is a different group with different services - usually triage and emergency dispatch, not scheduling.
A twenty-four-seven AI agent has to switch gears the same way. So you can scope when a task is available: this one during business hours, this one only after hours, this one always. And it is not only time - you can vary availability along other dimensions too, like geography or caller tags, so a technician in the field and an end customer calling the same number get different capabilities. The agent's skill set adapts to who is calling and when.
Accuracy is the whole point
Everything above - the visual model, the versioning, the bounded steps, the scoping - adds up to one thing. The agent should do what it is supposed to do, the way it is supposed to be done, every time.
That matters more here than in most places AI is being applied. A wrong answer about a fault code sends a technician down the wrong repair path. A wrong part number means a second truck roll. These calls have physical consequences and real costs attached to them.
So accuracy is not a side effect we hope for. It is designed in, and we measure it. Accuracy is assessed inside the system itself, not left to anecdote - which means when it moves, you know, and you know where.
Then you get to see it run
Modeling and deploying is half of it. The other half is visibility.
There is live call monitoring, so you can listen in while a call is happening. There is a control center for what is happening across your calls. And for any individual call, there is a Gong-style view of the conversation that shows which flow ran, which step executed, what went in, and what came out.
Flow execution is fully open. When something needs to change, you can see exactly where.
The point
These are real calls with real outcomes for real customers, on equipment that has to get back up and running. That demands predictability and dependability,. and it demands that the people who own the service process can maintain and manage it themselves.
The technology underneath is complex. Using it does not have to be. We took the complexity into the framework so what you work with is a simplified view of a genuinely sophisticated system.
Try it yourself - the free trial is open here. Questions, feedback, or just want to compare notes? Reach me at indresh.ms@aquant.ai
