Chatbots driven by generative models: from scripted FAQ to agents that act

Note revised on 25 May 2026. Article originally published in March 2026 — full rewrite.

The term chatbot has become a portmanteau that covers structurally different systems. A 2015-era scripted decision-tree system, a RAG system anchored in a business knowledge base, and an agent capable of executing actions in existing systems have practically nothing in common operationally, although they share an apparent conversational interface. This confusion produces costly trade-offs for organisations that stick to an undifferentiated reading.

This note sets out the distinction between these successive generations, qualifies what each category actually allows, and identifies the constraints specific to the Swiss framework that structure a durable deployment.

Three generations with nothing in common

The public conversation on chatbots regularly mixes three families of systems that deserve to be explicitly distinguished.

Scripted chatbots first, which constitute the previous generation and remain widely deployed. Their functioning rests on predefined decision trees: the user clicks a button or chooses from a list, the system follows the programmed path, and proposes pre-formulated answers. As soon as the question leaves the planned scope, the answer is invariably "I did not understand, can you rephrase?". This generation correctly covers frequent and stable questions — opening hours, public rates, order tracking — but fails in the face of nuanced or contextual requests. Its main quality lies in operational predictability; its main limitation lies in its inability to handle what has not been planned.

RAG-anchored chatbots next, which constitute the current dominant generation for serious enterprise projects. These systems combine a language model with a semantic-search mechanism in a knowledge base specific to the organisation. They understand the intent behind a question formulated in natural language, they retain the context of the conversation in progress, and they produce responses anchored in the company's own documents. The operational difference with the previous generation is substantial: the system does not follow a script, it reasons on the basis of verified information.

Agents capable of acting complete the list, and constitute the most recent generation. An agent does not merely answer a question; it combines a language model with tools — access to an existing management system, scheduling an appointment, creating a support ticket, triggering an approval workflow — to execute a concrete task that exceeds the simple conversation. This capacity for action transforms the nature of the system, which becomes an operational intermediary and not only an information channel.

Understanding in which category a given project sits is the most structuring decision of initial framing. Each category corresponds to a different implementation effort, a different operating cost, and a different risk profile.

The mechanics of RAG: what it allows and what it does not eliminate

The RAG pattern deserves to be understood in its mechanics, because its strengths and limitations are structural rather than anecdotal.

Its mechanics rest on four successive steps. The company's documents — manuals, product sheets, procedures, knowledge base — are first split into segments and transformed into vector representations capturing their semantic meaning. When a user asks a question, the system in turn transforms it into a vector representation and searches for the segments closest semantically. The relevant segments are injected into the prompt sent to the language model, with the initial question. The model then produces a response anchored in those segments, with the ability to cite its sources.

This mechanics responds to the central challenge of language models used alone: hallucinations. By anchoring each response in verified documents, the system remains factual on questions covered by the knowledge base. And when the base does not contain the answer to a question, the system can say so explicitly rather than invent a plausible but incorrect answer.

The mechanics does not, however, completely eliminate hallucinations. The model can still extrapolate beyond the supplied content, particularly when the segments returned by the search are partially relevant but incomplete. This residual limit calls for response monitoring and a user-feedback system that detects drift.

More structurally, the quality of a RAG system depends directly on the quality of the indexed data. Obsolete documents produce obsolete responses; contradictory documents produce inconsistent responses; poorly structured documents produce imprecise searches. The feeding and maintenance of the document base constitute a continuous effort that does not reduce to initial indexing.

Agents: when AI moves to action

Agents driven by models represent the most recent, and probably the most structuring, evolution of the category. Their operational interest lies in their capacity to execute a sequence of actions to accomplish a complex task, rather than simply answer a question.

A few use cases illustrate what this capacity opens. An agent can check the status of an order in a company's management system and provide a contextualised answer to the client. It can schedule an appointment in a salesperson's calendar after qualifying the prospect's need. It can create a support ticket in a business system after collecting the necessary information. It can generate a personalised quote based on the parameters extracted from the conversation. It can trigger an internal approval workflow with the appropriate documentation.

This level of capacity demands a more sophisticated technical framework than previous generations. The tools accessible to the agent must be explicitly defined, their permissions framed, the security rules set. The agent decides which tool to use according to the request, but this decision remains within a perimeter controlled by the system's design.

The operating cost of an agent is substantially higher than that of a simple RAG chatbot. An agent can make several dozen model calls to handle a complex task, against one or two calls for a classical RAG response. This characteristic reserves the use of agents for high-value use cases where the complexity of the task justifies the cost.

Four use cases that structure the Swiss market

The observation of operational deployments in the Swiss market brings out four use cases that constitute the majority of serious projects.

Continuous multilingual customer support first. The structural multilingual character of the Swiss market — French, German, Italian, English — makes particularly relevant a system that natively masters several languages without additional configuration. For a service company or an e-commerce actor, this capacity releases a first-level support channel available continuously, with a linguistic quality that classical outsourcing struggles to reach in all four languages simultaneously.

Documented technical support next. An industrial company can feed its system with its technical manuals, product sheets and troubleshooting guides. The system then becomes capable of guiding a client through the resolution of a complex problem by relying on the precise documentation of the product concerned, rather than proposing generic answers that oblige the client to look up the information themselves.

Lead qualification completes the list of external uses. A conversational system on a company's website can ask the right questions to qualify a visitor's intent, identify their need precisely, and direct them to the right internal contact. The interaction is immediate and adapted to the situation, which classical contact forms do not allow by construction.

The internal assistant for staff closes the list, and is often the simplest use case to deploy with the best return. A system fed with internal procedures, company policies and technical documentation lets staff find information quickly without soliciting internal support teams. This application reduces the load on saturated teams, and improves the quality of operational decisions by easing access to reference information.

Human escalation: design as important as technology

A model-driven chatbot, whatever its generation, must know how to recognise its limits. Emotional requests, complex complaints, atypical cases that exceed the scope of the indexed data, must be transferred to a human. The design of the escalation path is as important as the technology underlying the system.

Three characteristics distinguish a well-designed escalation from a poorly thought one.

Detection of escalation signals first. The system must identify — explicitly through rules, or implicitly through the characteristics of the conversation — situations exceeding its capacities. A visibly dissatisfied client, a question outside the scope of the knowledge base, a request touching a sensitive subject, must trigger a transfer rather than a forced answer.

Continuity of transmitted context next. When escalation triggers, the staff member taking over must receive the conversation history and the qualified context of the request, rather than having to re-ask the client. This continuity is constitutive of a respectful customer experience; its absence turns escalation into additional frustration.

Clear management of waiting completes the list. If the transfer to a human cannot be immediate, the system must say so honestly, indicate a realistic delay, propose a callback or another channel. This transparency preserves the trust that unrealistic promises erode.

This dimension is particularly structuring in the Swiss context, where the Federal Act on Data Protection^[1] imposes transparency on automated processes affecting users. Where the system produces or prepares an automated decision significantly affecting the user, the possibility of a human review must be treated explicitly from design onwards.

The Swiss data-protection framework

Three dimensions of compliance with the Federal Act on Data Protection deserve to be posed explicitly at the framing of a corporate chatbot project.

Transparency on the nature of the system first. The user must know that they are interacting with an automated system, and not with a human staff member. This transparency is not a formality; it conditions trust and the quality of the interaction. It is generally handled by an explicit mention at the opening of the conversation.

Treatment of personal data shared next. If a client shares personal information during a conversation — contact details, identifiers, health data, financial data — these data enter the scope of the Federal Act on Data Protection. Their processing must comply with the principles of lawfulness, proportionality and transparency. This dimension calls for explicit analysis at framing, rather than default treatment.

Localisation of processing completes the list. If the system is hosted on infrastructure under foreign jurisdiction, the transfer of personal data to that infrastructure may raise questions of applicable law and extraterritorial access. For sensitive sectors — finance, health, public administration — this question must be treated explicitly. Alternatives exist: hosting on European or Swiss infrastructure, deployment of open models on controlled infrastructure. Each option presents a different cost and complexity profile that deserves to be qualified at framing.

The discipline that distinguishes durable deployment

The deployment of a corporate chatbot driven by a model does not reduce to a technological choice. It calls for operational discipline, of which a few orientations distinguish projects that produce durable value.

Starting on a limited scope first. Rather than aiming for a system capable of handling everything from launch, identifying a precise and measurable use case — support FAQ, lead qualification, internal assistant on a documented subject — produces faster results and more useful learnings for subsequent extensions.

Investment in the knowledge base next. The quality of a RAG system depends directly on the quality of the indexed data. Structuring, cleaning and updating documents before indexing them represents, in the firm's observed practice on MCVA projects, a substantial share of the total effort — typically between one half and two thirds. This observation deserves to be owned rather than minimised at framing.

Explicit design of human escalation completes the list. Transfer criteria, takeover paths by a staff member, management of transmitted context, deserve to be thought through at project start, not discovered in operation.

Continuous measurement and iteration closes the sequence. Tracking the resolution rate, user satisfaction, questions that do not obtain a satisfactory answer, feeds a continuous improvement that distinguishes systems consolidating their quality over time from those drifting.

A well-designed model-driven chatbot absorbs a substantial share of repetitive requests, frees up time for higher-value interactions, and improves the customer experience through its immediate availability and response quality. A poorly designed chatbot produces customer frustration and accumulates technical debt. The difference is not played out in the model used. It is played out in the rigour of the initial framing and in the discipline of deployment.

Sources

[1] Federal Act on Data Protection (FADP), revision of 25 September 2020, in force since 1 September 2023. www.fedlex.admin.ch/eli/cc/2022/491/en [↩]

Jérôme Deshaie is CEO of MCVA Consulting SA, a Swiss firm specialising in strategic consulting on artificial intelligence, based in Valais.