Most chatbot projects fail at a decision made in the first week, before anyone writes a prompt: which questions get a hand-drawn flow, and which get answered from the knowledge base. Teams tend to pick one mechanism and force everything through it. The bot that is all retrieval invents order statuses. The bot that is all flows becomes a branch tree nobody dares edit by month four.
The choice is not a matter of taste, and it is not about how advanced your AI is. It follows from a single property of the question being asked.
The rule: does the correct answer depend on a record?
A deterministic flow is correct when the answer depends on state: a row in your database that differs per customer and changes over time. Retrieval is correct when the answer is the same for every customer who asks and lives in prose you have already written.
“When does my order arrive?” depends on order 4417. “How long does delivery usually take?” does not. Those two questions look similar in a transcript and are structurally opposite: the first is a read of a record, the second is a read of a document. Route them to the same mechanism and one of them is going to be wrong.
The test is mechanical enough to apply in a spreadsheet. For each of your top intents, ask: could two customers ask this in the same minute and need different answers? If yes, it is stateful and needs a flow with a lookup. If no, it is explanatory and belongs to the knowledge base.
A second test catches the rest: does answering require changing something? Cancelling an order, moving an appointment, starting a return: those are actions, and actions are always flows, because retrieval has no verbs. A document cannot cancel anything.
The decision table
| Intent | Stateful? | Action? | Mechanism | Why |
|---|---|---|---|---|
| Where is my order? | Yes | No | Flow with an order lookup | The answer is a field on one order row |
| How long does shipping take? | No | No | Knowledge base retrieval | One answer, same for everyone |
| Cancel my order | Yes | Yes | Flow, with identity proof first | Changes a record; wrong customer means real damage |
| What does the warranty cover? | No | No | Knowledge base retrieval | Policy prose, updated by editing an article |
| Is this in stock in medium? | Yes | No | Flow with a stock lookup | Changes hour to hour |
| Book an appointment | Yes | Yes | Flow | Writes to a calendar, needs slot validation |
| Why was my card declined? | Partly | No | Retrieval, escalating to a human | Causes are documentable; the specific decline is not yours to read |
| How do I change my password? | No | No | Knowledge base retrieval | Instructions, not state |
The “partly” row is the honest one. Some intents split: the general explanation is an article, the customer-specific part is either a lookup you have or a handoff you need. Design those as an article that ends in an offer to fetch the specific case, rather than pretending either half answers the whole question.
What getting it backwards costs, in both directions
Retrieval used on a stateful intent produces confident wrong answers. This is the expensive direction. A customer asks where their order is; retrieval finds the shipping-times article; the model writes a fluent paragraph saying orders typically arrive in three to five business days. Every word of that is true as policy and false as an answer, because this particular order has been sitting unfulfilled for nine days. Nothing in the pipeline is broken. Retrieval retrieved, the model generated, the passage supported the sentence. The bot was simply asked a question its mechanism cannot answer, and a grounded bot is only grounded relative to the documents it has: it cannot be grounded in a record it never read. Our guide to grounding a chatbot in your knowledge base covers making retrieval accurate; no amount of retrieval quality fixes this, because the right passage was retrieved.
Flows used on an explanatory intent produce a maintenance bill. This direction is slower and less visible. Someone builds a warranty flow: fourteen branches covering product category, purchase age, proof of purchase, damage type. It works. Then the warranty changes and nobody remembers which three branches encode the old terms, because the policy now lives in a diagram instead of in a document with a revision history. The same policy as an article is one paragraph, edited in thirty seconds, and it retrieves for phrasings nobody predicted. Articles also have a second reader: the same knowledge base is searched from the ticket screen in the Oneop help desk, so an explanatory answer written once serves both the bot and the agent.
The asymmetry matters when you are deciding under uncertainty: the retrieval mistake harms customers immediately, the flow mistake harms you slowly. When an intent is genuinely borderline, prefer the article and watch what customers actually ask.
Runtime routing: what decides which mechanism a message hits
Classification at design time is only half of it. At runtime, something has to route an arbitrary sentence to a flow or to retrieval, and the honest design is to put the flow first.
Flows should claim messages by explicit trigger (a button, a menu selection, a keyword you chose) and retrieval should take everything unclaimed. That ordering is deliberate: a flow that fires by accident is a worse outcome than a retrieval answer, so flows get narrow, explicit triggers rather than fuzzy intent matching. It also has a cost consequence, since a flow made of questions, branches and lookups does not call a model at all, while every retrieval answer does.
Then design the third case properly. A message that matches no flow and retrieves nothing relevant is not an error to swallow. It should reach a person, carry the reason it got there, and be counted. Teams that track unmatched intents by volume end up with an evidence-backed build queue instead of an argument about what to automate next; teams that do not track them end up rebuilding the same bot on intuition every six months. The related question of which work should stay human is covered in when not to automate.
How Oneop separates the two mechanisms
In the Oneop chatbot builder, the two mechanisms are different blocks with different guarantees, and the product says so rather than blurring them.
Flow blocks read and change records. The palette is 51 blocks in ten groups, classified in the product as Read, Prepare and Act: reads return catalogue, stock, order, tracking and invoice data; Prepare blocks create something a person picks up, such as a lead, a ticket or a return; Act blocks change the business immediately, such as cancelling an order or moving an appointment. Act blocks require either signed-in staff or a visitor who has proved ownership of that exact record with a mailed six-digit code, and they are capped at five record changes per conversation in any ten minutes.
Retrieval is one block with a stated contract. The knowledge-answer block retrieves from your workspace’s own content, requires the model to declare whether the retrieved context actually supported its answer, overrides that declaration to false when nothing was retrieved, and discards the model’s text entirely on the ungrounded path in favour of the fallback you wrote. The other AI blocks are ordinary generation with knowledge attached as context, which is a weaker promise, so anything a customer might act on should go through the knowledge-answer block, with its fallback branch routed to a person.
That split is the whole point of this article expressed as software. Determinism where the answer is a record, retrieval where the answer is a document, and an explicit branch for neither. If you want to see the difference on your own content, the chatbot builder, knowledge base articles and the web chat widget are on the free plan, and the fastest first exercise is to take your top twenty tickets and sort them into the two columns above before you draw anything.