A bot that stays on script, without a training pipeline
Define dialogue flows and intents in plain configuration files. An LLM handles intent recognition and detail extraction, so there is no labelled-data collection or model-training step. Connect any channel, and let a human operator take over a live chat when needed.
Discuss a pilot →Quick facts
- Business size
- Any team running task-oriented bots with repeat dialogue patterns
- Timeline
- 2-4 weeks test, 1-3 months pilot, 3-6 months production
- Budget range
- Pilot from EUR 20k. Ongoing operator workspace and LLM API cost.
- Hardware
- Cloud-only by default. Open-source operator workspace (Chatwoot) supported out of the box. Self-hosted LLM available for data-residency needs.
- Data needed
- Dialogue scenarios and intents (we define them with you in YAML). Optional FAQ or knowledge base as a separate source. No labelled training utterances required.
- Evolution
-
- Genesis
- Custom-built
- Product
- Commodity
No product gives you this. We assemble and train it around you.
What this scale means
Further right means more proven and cheaper. Further left means newer and riskier. Here is the test for each step.
- Commodity
- You could get the result yourself from a ready service, with almost no work. We rarely take these on.
- Product
- A vendor already sells this result turnkey, like shelf recognition from Trax or document reading from ABBYY. If one of them fits you, use it. You come to us when it does not: when it has to run on your own servers, cost less, or fit systems the product cannot reach.
- Custom-built
- Vendors sell only the parts. A tool like Tableau hands you charts, but the dashboards and metrics for your business still have to be built. That build is the work, and that is us.
- Genesis
- The approach exists but does not work reliably yet. You are betting on it maturing, so it costs more and carries more risk.
Expected outcomes
The Problem
Teams that run task-oriented dialogue bots face a recurring tax. The classic machine-learning approach to natural-language understanding asks you to collect labelled example utterances, run a training job, and manage model versions every time intent coverage changes. A small wording change in a scenario can mean another round of data collection and retraining. Frameworks like Rasa made this disciplined and reproducible, but the training loop stays in the way of fast iteration.
At the same time, the fully open-ended LLM chatbot has the opposite problem. It answers anything, which is exactly what you do not want when the bot has to follow a defined process, such as opening a support request, qualifying a lead, or walking a customer through a fixed flow. For those jobs you need the dialogue to stay on script and stay predictable.
What has changed in the last two years is that an LLM can read intent and extract details from a message reliably enough to replace the trained classifier, without the training pipeline. That makes a middle path practical: keep the scenarios deterministic, and let the LLM do the language understanding.
What the Solution Does
A production bot that follows the flows you define, with the language understanding handled by an LLM.
- Scenarios and intents live in configuration. You describe the dialogue flows and the intents in YAML files. There is no labelled-utterance collection and no training job.
- The LLM does the language understanding. Each incoming message goes through LLM-based intent recognition and entity extraction. The model provider is pluggable, so you are not locked to one vendor.
- Any channel on the front. Connectors plug into the channel you use. Chatwoot integration is supported out of the box.
- Human handoff at any point. A live operator can take over a dialogue mid-conversation, which is the difference between a useful bot and a frustrating one.
- Optional knowledge source. An FAQ or knowledge base can attach as a separate source when the bot needs to answer open questions alongside the scripted flows.
Where It Fits
This makes sense if you…
- Run task-oriented bots that must follow defined flows and stay off free-form chat
- Iterate on scenarios often and feel the cost of a retraining loop each time
- Want a single bot to serve more than one language
- Need a human to be able to step into a live dialogue
- Prefer to stay vendor-neutral on the LLM provider
This is probably not the right time if you…
- Need a pure open-ended assistant with no defined process (a knowledge-base assistant fits better)
- Have very low dialogue volume where a person handles everything comfortably
- Cannot send dialogue text to a cloud LLM and have no appetite for a self-hosted model
Business Value
No training pipeline. Scenarios and intents are configuration files. There is no trained model. Teams write and update flows without collecting labelled utterances, running training jobs, or managing model versions.
Faster iteration. Changing a flow is a file edit. There is no data-and-training cycle to run. That shortens the loop between noticing a problem and shipping a fix.
Multilingual by default. Language coverage comes from the underlying LLM, so it needs no per-language training data.
Predictable behaviour. Because the flows are deterministic, the bot does what the scenario says. The LLM is scoped to understanding the message. It does not improvise the process.
Graceful handoff. A human can take over a live chat, so the hard cases reach a person with the conversation already in context.
How It Works
The processing chain runs in a fixed order, and the LLM is used only where language understanding is needed.
1. Scenarios in YAML
Dialogue flows and intents are defined in YAML files. An optional FAQ or knowledge base attaches as a separate source. This is the part your team owns and edits over time.
2. Message intake and intent recognition
An incoming message first goes through LLM-based intent recognition. The LLM decides which intent the message matches, against the intents you defined.
3. Entity extraction
If the intent needs details (a date, an order number, a product), the LLM extracts them from the message.
4. History lookup and story resolution
The bot looks up the conversation history and resolves where the dialogue should go next. This is the most involved step: one story can branch into another story, and an action call can trigger a new intent, which creates recursive dialogue paths. Getting this resolution right is what keeps multi-step conversations coherent.
5. Action dispatch
If the flow calls for it, the bot dispatches an action, such as a lookup against a business system, before composing the reply.
6. Response and optional handoff
The bot replies. At any point a human operator can take the dialogue over through the operator workspace.
Stack
LLM access through PydanticAI (provider-agnostic), scenarios in YAML, conversation history in PostgreSQL through JIMS (e8’s data framework, with the storage layer kept loosely coupled), and Chatwoot as the optional operator workspace and channel. This is the architecture of Stell, e8’s own conversational-bot framework.
What You Need to Make This Work
Scenarios. The dialogue flows and intents you want the bot to handle. We define them with you in YAML. Optional: an FAQ or knowledge base for open questions.
Integrations. The channel you want the bot to live in, plus read access to any business system the bot should look up during a flow. Operator workspace: Chatwoot by default.
Hardware. Cloud-only by default. Self-hosted LLM available for data-residency requirements.
Team. An owner for the scenarios who can write and update flows. A pilot group of operators to handle handoffs and give feedback during tuning.
Implementation Roadmap
1. Test (2-4 weeks)
Set up the bot on a slice of your dialogue traffic, with a first set of scenarios and intents wired in. Connect a channel and the operator workspace. Output: a working bot on a real flow, with handoff in place.
2. Pilot (1-3 months)
Production deployment on a meaningful share of dialogues. Expand scenario coverage, tune intent recognition, and refine the handoff rules with operators. Output: a working production bot with documented behaviour.
3. Production (3-6 months)
Full rollout. Your team owns the scenarios and edits them as coverage grows. We stay on for accuracy reviews and integration extensions.
Keep in Mind
The limits, stated plainly:
- The LLM still needs checking. LLM-based intent recognition is good, though not infallible. We measure it against your real dialogues during the test phase and do not assume it works.
- Deterministic flows are a design job. The value comes from well-designed scenarios. Poorly structured flows produce a poorly behaved bot, training pipeline or not.
- Story resolution is the hard part. Recursive paths, where stories branch and actions trigger intents, are where multi-step dialogues break if the resolution logic is wrong. This is where the engineering goes.
- Managed platforms exist. Off-the-shelf platforms such as Rasa, Dialogflow, and Voiceflow are a sensible first look if you want a managed product. Our approach fits when you want deterministic scenarios without a training loop, a pluggable LLM, and an open-source operator workspace.
- Cloud LLM by default. Self-hosted models are supported for data-residency needs, with additional setup.
FAQ
Do I have to train a model?
No. Intents and scenarios are defined in YAML, and the LLM does the language understanding. There is no labelled-utterance collection and no training job.
Can I use my own LLM provider?
Yes. LLM access goes through PydanticAI, which keeps the integration provider-agnostic. You can switch models, including a self-hosted one.
Does it support multiple languages?
Yes. Language coverage comes from the underlying LLM, so multilingual support does not require per-language training data.
Can a human take over a conversation?
Yes. Chatwoot integration is supported out of the box, so an operator can step into a live dialogue at any point.
How is this different from an open-ended LLM chatbot?
An open-ended chatbot answers anything, which is wrong for task-oriented flows. Here the flows stay deterministic and the LLM is scoped to understanding the message, so the bot follows the process you defined.
Ready to Discuss?
If you run task-oriented bots and the training loop or the rigidity is slowing you down, this is a measurable pilot. We will walk through your scenarios, your channels, and your handoff needs, and tell you what to expect.
Case studies
Stell Stell dialogue framework AI Assistants