How Agent Mode Works
In a flow-based bot the orchestrator is a router: once per user turn it picks one flow, and the flow you drew does everything else. In an Agent Mode bot the orchestrator is the bot: it works in a loop, calls tools, looks at each result and decides the next step itself. Nobody draws the path in advance.
This page provides the conceptual background for Agent Mode. It is written for anyone who already knows how flow-based bots behave and wants to understand what actually changed – not in the interface, but in how a conversation unfolds.
The difference at a glance
Flow-based: one decision picks one of your flows, then a fixed path. Agent Mode: the orchestrator calls tools, reads their results and decides again.
Both bots receive the same message. What differs is who decides what happens next, and how often that decision is made.
- Flow-based: the decision is made once, at the start of the turn. The orchestrator sees all of your flows - names and descriptions only - picks exactly one of them, and steps aside. The flow you designed then follows the path you drew.
- Agent Mode: the decision is made after every single step. The orchestrator calls a tool, reads the result that comes back, acts on it, and decides again - as often as the turn needs. There is no list of flows to choose between, because everything the bot can do is a tool it may call.
How a single turn runs
The clearest way to see the difference is to follow one request - "can I move appointment #4711 to Friday?" - through both kinds of bot.
In a flow-based bot
In a flow-based bot the path is drawn in advance - the orchestrator only decides which one to walk:
The same request, handled by a flow-based bot. The orchestrator appears once per turn, at the very beginning.
Written out, the mechanics are these:
- The user writes a message.
- The orchestrator receives the list of flows - name and description only - and must choose exactly one.
- The chosen flow runs node by node until it needs user input or reaches its end. Every message the user sees in this turn comes from the flow - or from another flow that it pulls in through a flow transition node.
- On the next user message the orchestrator runs again.
Three consequences are worth remembering, because they are exactly what Agent Mode removes:
- The orchestrator sees the conversation, not the machinery. On the next turn it reads the visible history - the messages the flow sent included - and it knows which flow it picked last. What it does not see is what happened inside: which nodes ran, what an action returned, or why the flow said what it said. It routes, it does not supervise.
- One turn, one flow. A user who asks two things at once gets one of them handled, and only the flow author can plan for the other.
- A paused flow only continues if the orchestrator picks it again. Nothing carries the flow over the turn boundary: on the next message the orchestrator decides from scratch, and you have to trust it to land on the same flow. If the answer sounds like a different topic, it may route elsewhere and the half-finished form stays where it was.
In Agent Mode
Here the orchestrator does not hand over and disappear. It works, sees results, and keeps working until the turn is genuinely finished:
The orchestrator works on its own until it needs the user. Asking a question ends the turn; the answer starts the next one.
Written out, that exchange reads like this:
- The user's message arrives at the orchestrator.
- The orchestrator writes text whenever it wants to say something.
- It calls a tool whenever it needs something: a lookup, an API call, a search in the knowledge base. The call goes out, the result comes back into the loop - visible only to the orchestrator, never to the user - and it acts on that result: answer, call the next tool, or ask the user for what is still missing.
- It repeats that as often as the turn needs. Three tools in one turn, or none at all, are both normal.
- When it needs something only the user can give it - a date, a confirmation - it asks, and the turn ends there. The user's answer opens the next turn, and the orchestrator continues with everything it already knows, including the tool results from before.
- The turn ends when the orchestrator is done - not when a graph runs out of nodes.
For the orchestrator, everything is a tool
The interface groups tools by type, but the orchestrator sees only functions it may call, each described by a name and a description. What actually differs is what happens after the call:
| The orchestrator may call | What it does | After the call |
|---|---|---|
| Script or HTTP tool | Runs a script, or calls an external system | Result comes back into the loop |
| Knowledge search tool | Searches the bot's knowledge base on demand | Result comes back into the loop |
| Web search | Looks something up on the internet | Result comes back into the loop |
| Forward call, hand over to live chat | Forwards the conversation to a phone target or the live chat | The turn ends there |
| Hang up | Ends the phone call after speaking a farewell | The call ends |
A flow is never in this list. No flow is visible or callable by the orchestrator in Agent Mode. Flows exist only as event-triggered subflows - the error flow, phone conversation start, phone call ended, chat conversation end - entered by the event and nothing else. See Flows.
What moves where
Nothing you know from flow building becomes worthless. The building blocks survive; only the wiring between them disappears.
The same building blocks, re-labelled. What disappears is the wiring - that is now the orchestrator’s job.
- Descriptions still matter. In a flow bot, the flow description told the orchestrator when to enter. In Agent Mode, a tool's name and description are the only reason it will ever be called. Write them for the AI, precisely: what it does, and when to use it.
- Extraction fields stay exactly what they were: the bridge between free conversation and structured data. Only now they belong to a tool instead of a form node, and the orchestrator gathers them by asking naturally, in its own words.
- Knowledge is asked for, not injected. An Agent Mode bot reaches its knowledge base through a Knowledge Search tool - an ordinary tool that the orchestrator calls when it judges the question needs it, and whose result it then works with like any other.
- Wording is described, not placed. A response node defined what the bot would say – at exactly the point where the node sat. In Agent Mode the orchestrator writes every reply itself, in its own words and at the point it judges right. The persona sets the tone it writes in, the orchestrator prompt sets what it may and may not say. You no longer decide where a sentence appears – only what the bot is like and what it is allowed to tell people.
When a flow is still the right answer
Agent Mode is the recommended default, but autonomy is not always what you want. Reach for a flow when the order itself is the requirement:
- legally or contractually fixed sequences, where a step may not be skipped or reordered
- wording that must be delivered verbatim, in a fixed position of the conversation
- hard, data-driven branching that must never be re-interpreted
When that describes the bot as a whole, build it flow-based - that is what the mode is there for.
Mixing the two is not available. An Agent Mode bot cannot call a flow as a tool: its flows are entered by events only. If a whole process must run on a guaranteed fixed path, that bot belongs in flow-based mode.
Related Documentation
- Agent Mode - configuring an Agent Mode bot, tools, AI Assistant and rollback history
- Flows - the flow editor and every node type
- Extraction Fields - the structured values behind tools and forms
- Development Chat - testing a bot while you build it