Most of what reaches a support team is the same handful of questions repeated: billing status, line details, fault records. Letting a language model answer those freely introduces two risks at once — the model inventing an answer, and customer data leaking into logs uncontrolled. On an enterprise support channel neither is acceptable.

I built the bot on a rule engine rather than free generation. Conversation flows live in YAML files as a state machine: 16 separate flows, each with its own steps, validations and exits. Changing a flow means editing YAML, not changing code — the support team can update their own scenarios without writing any.

When the bot cannot resolve something it does not simply drop the conversation: it opens a ticket in Zammad/Zendesk and hands off to a live agent together with the full conversation history, so the customer never has to explain twice.

A three-layer read-only guarantee on the production database. The bot reads live MySQL, but the possibility of a write had to be closed entirely. Instead of trusting a single safeguard, I stacked three:

1. Table whitelist — the bot can only see explicitly permitted tables
2. SQL guard — every generated query is inspected for write statements before it executes
3. READ ONLY transaction — the query runs inside a transaction the database itself refuses writes on

Even if the first two are bypassed, the third is enforced by the database engine. Not leaving safety to the good intentions of the application layer was the single best decision in this project.

End-to-end PII masking. Sensitive fields — national ID numbers, phone numbers, email addresses and card numbers — are caught by regex patterns plus Luhn validation for card numbers, then masked. Masking runs before anything is written to logs or the database, so sensitive data never hits disk in raw form.

107 tests as a regression net. I wrote tests for every step of all 16 flows. Because changing one YAML flow can silently break another, updating the system safely would not have been possible without them.

Flask + Gunicorn. A deliberately plain stack: a single service that fits the synchronous request/response model and can be packaged and scaled horizontally. State lives in YAML and the database; the application server itself is stateless.

A significant share of repeat requests now close without ever reaching an agent, and the ones that do arrive with the ticket and history already attached. Answers are correct because they come from production data, safe because queries are read-only, and changeable because the flows live in YAML.