The issue is not that they are "not intelligent enough." The real problem is that their engineering paradigms make it difficult to satisfy several core requirements of enterprise-grade customer service at the same time: non-linear conversations, smooth interaction, fast response times, strict rule enforcement, traceability across long conversations, and debuggability for complex business logic.
Let's start with ReAct Agents.
A typical ReAct Agent allows the large language model to autonomously decide, through multi-step reasoning, what to do next, which tools to call, and how to move the task forward. This looks flexible, but in enterprise customer service scenarios, it quickly exposes several problems:
- It behaves more like a black box, making its actions difficult to fully predict;
- Every step depends on LLM reasoning, which leads to slower responses and higher costs;
- It is prone to hallucinations around complex business rules, permission checks, and API boundaries;
- It is hard to debug, replay, and trace precisely in the same way as traditional engineering code. But in enterprise customer service, many processes cannot be handled on a "good enough" basis. Scenarios such as ticket changes and cancellations, insurance claims, after-sales support, account opening, approvals, and work orders often require explicit rule evaluation, permission control, state transitions, and external system calls. Allowing the LLM to freely improvise introduces too much risk.
Now let's look at Workflow Agents.
Workflow Agents take a different approach: they define the process upfront and control the conversation through nodes and edges. This solves part of the controllability problem, but at the cost of making the interaction rigid and unnatural.
Real users do not follow a predefined flow step by step. They may provide information out of order, correct themselves midway, add new details, jump to another topic, or even insert a different request within an ongoing process. Traditional workflow systems struggle to handle these non-linear conversation patterns naturally. The result is often a bot that repeatedly asks users to start over or respond in a fixed format.
What enterprise customer service truly needs is neither a completely free-form LLM nor a rigid flowchart. It needs a more white-box, engineering-oriented conversational Agent architecture:
- Let the LLM handle what it is good at: intent recognition, information extraction, and natural language generation;
- Let code handle what must be handled by code: business decisions, permission checks, API calls, and state management. This is exactly why we built TeliChat.
TeliChat is a code-first, white-box conversational Agent designed for enterprise customer service and complex business processes. It is neither a ReAct Agent that lets the LLM run freely, nor a rigid Workflow Agent. Instead, it manages multi-turn conversation state through "ChatTree + InfoItem + Python code."
In TeliChat, the LLM is not responsible for deciding all business logic. Real business decisions, permission checks, and API calls are handled by code, with support for Python breakpoint debugging. This preserves the natural language interaction capabilities brought by LLMs while meeting enterprise requirements for controllability, traceability, and debuggability.
As a result, TeliChat can support much more complex real-world conversation scenarios. Users can provide information out of order, correct or supplement previous information, switch topics, or insert new topics into an existing flow, and the system can handle these situations naturally. At the same time, it supports long conversations, traceability, debuggability, smooth interaction, and fast response times required in enterprise environments.
If you are building business processes with strong rule constraints, such as ticket changes and cancellations, insurance claims, after-sales support, account opening, approvals, or work orders, you may have already found that relying purely on ReAct Agents makes the system too black-box, too slow, too expensive, and too prone to hallucination. Relying purely on Workflow Agents, on the other hand, makes the experience too rigid to handle how users actually express themselves.
If you are tired of Rasa CALM's YAML, frustrated by Dify's rigid responses, or dissatisfied with the black-box nature of Claude Code / OpenClaw, feel free to try TeliChat:
https://telichat.io
At the moment, TeliChat's core product is not open source. What we have made available on GitHub is example code for building Agents with TeliChat:
https://github.com/hanswang73/telichat
We have also shared more of our thinking on the blog:
https://telichat.io/blog/telichat
Feedback, criticism, and discussion are all welcome.
Top comments (0)