Why a chatbot is not a system

The interface organizes access

An interface determines how a person expresses an intention and receives a response. It may use forms, buttons, conversation, or a combination. Its design affects effort, the information collected, and the clarity of what happens.

Natural language is particularly useful when inputs vary or someone needs to explore a question. It can also help a person navigate a service. That flexibility does not remove the need to turn a request into something the application can handle precisely.

“Resolve this” can start a useful conversation while remaining an insufficient specification for an operation. The interface must clarify scope, identify the affected object, and distinguish an inquiry from a proposal or an instruction to act.

The design must decide which ambiguity dialogue can resolve and which requires an explicit selection. Sometimes displaying three concrete options is clearer than asking the user to write another explanation. Conversation loses none of its value by working alongside other interface elements.

What the user sees should correspond to what the service can support. If the application only prepares a recommendation, the interaction should make that status recognizable. If it starts work that will finish later, it should explain how the outcome will become known. The conversation itself participates in setting expectations, including the distinction between an answer and a commitment to perform work.

Conversation history is not operational state

A conversation retains messages. Operational state expresses what currently holds within the service. The two can be related, but they are not interchangeable.

The history may contain an initial request, a correction, and a later approval. Continuing the work requires knowing which decision governs the current operation. Keeping every sentence does not establish that priority on its own.

Changes can also occur outside the conversation. Another person updates a case, an application changes availability, or an operation finishes while the user's window is closed. The service must incorporate those events without depending on someone narrating them in the chat.

This does not prescribe a separate database for every application or a particular technology. It requires distinguishing information about the exchange from information representing the work. That separation may be logical, but it must allow an operation to be recovered without informally rereading messages to reconstruct its truth.

Persistence alone does not solve the problem either. Saving an incorrect assertion merely keeps it available. Useful state needs update rules and a clear relationship to the systems that are authoritative for each fact.

Users encounter this difference when they return to the service. They should be able to identify what remains pending, what is complete, and what requires their attention. Continuity belongs to the work even when the session or the channel used to inspect it changes. A fresh conversation should not silently turn an unresolved operation into a new request.

Talking to the system does not grant access

A fluent conversation still needs identity and authorization controls. Knowing a customer's name, a case number, or a document title does not establish permission to access it.

The system must determine which information each user may consult and which actions they may perform. That check belongs where the resource is accessed or the action executed. It cannot be delegated to an instruction asking the model to be cautious.

OWASP recommends validating permissions on every request and applying controls to the specific object or function. The principle applies to conversational interfaces just as it does to other applications: the entry channel does not replace authorization.

This matters when a request combines several operations. A person may be allowed to inspect a record without changing it, or act on some records but not others. The conversation must reflect those limits rather than assume a general authorization covers the entire exchange.

The application's identity matters as well. A tool using a service account may have broader technical permissions than the user. The system must preserve that distinction when acting on the user's behalf. Otherwise, the interface can provide an access route that the ordinary process would not permit.

Every answer need not become a security explanation. Access decisions do need to be consistent, and denials need understandable treatment. A reliable service must be able to say that an action is unavailable without improvising another route that crosses the same boundary. That consistency is part of service behavior, not an optional conversational preference.

Execution has its own timeline

Conversation encourages thinking in turns: someone writes, then the system replies. Many business operations do not fit that rhythm. They may depend on another application, a review, or work that takes longer than the initial interaction.

In those situations, an immediate response may acknowledge receipt rather than completion. The application must preserve that distinction and provide a way to inspect progress. Using the same language for both states can lead someone to act on an outcome that does not yet exist.

Microsoft's asynchronous request-reply pattern documents this separation. A request can be accepted with an HTTP 202 response, while its outcome is inspected later through a status resource. This does not mandate a particular implementation. It illustrates that accepting work and completing it are separate events.

Conversation can represent that sequence clearly. It can state that a request is in progress, show the latest available information, and communicate the outcome once there is evidence. Those messages should come from the operation's state, not from the model's inference about what has probably happened.

Interruption also needs consideration. If the user closes the window, does the work continue, stop, or wait for a decision? None of these choices is universally correct. The service determines the answer, and its behavior should make that answer clear.

The interface need not expose every internal detail. It should let the person distinguish between waiting, supplying information, and trying an action again. This prevents reassuring conversations that leave the user unable to decide what to do next. It also keeps a delayed response from becoming an invitation to repeat work whose effects remain uncertain.

Conversation needs evidence

A response can confidently describe an outcome without adequate confirmation. In a system that acts, the explanation should be grounded in what has actually been observed about the operation.

For a documentary question, the evidence may be relevant, accessible sources. For a modification, it may be the confirmed state of the affected record. For a pending request, it may be an identifier and the status supplied by the responsible service.

The appropriate evidence depends on the promise being made. A writing suggestion and an action on company data do not require the same checks. In both cases, however, the style of the response should not imply a stronger guarantee than the available evidence supports.

This changes how the interface should be evaluated. A pleasant conversation can be unhelpful if it does not distinguish confirmed facts from assumptions. A more restrained response may be better when it makes clear what happened and what comes next.

Errors deserve the same care. “Something went wrong” describes an experience, but may not help someone continue. Where possible, the application should distinguish a rejected request, an operation still in progress, and an outcome it has been unable to confirm.

That distinction does not require exposing sensitive data or internal diagnostics. It requires turning service state into useful information. Conversational quality includes this fidelity as well as linguistic fluency. The interface should preserve uncertainty when the service is uncertain, rather than smoothing it away to keep the exchange sounding complete.

Design the service before fixing the channel

Conversation can be the main entry point, assistance within an application, or a secondary channel. Choosing its role requires understanding what the person needs to do and which parts of the work benefit from an exchange.

Dialogue may reduce friction when someone needs to express an open-ended need. Tables or forms may offer better visibility when comparing many items, reviewing changes, or confirming an exact selection. A good experience can combine them without forcing users to translate every action into messages.

Some work must continue through a different channel. One person starts a request conversationally; another reviews it in an operational queue. Both views must refer to the same work and its current decisions. Copying conversation history is not the same as designing that relationship.

The architecture needs an explicit relationship between the interface, coordination, and systems of record. The interface captures intent and communicates. Coordination applies the rules of the workflow. Systems of record supply or retain the information for which they are responsible. These are logical responsibilities that may coexist inside a single application.

Separating them supports evolution. Adding another entry point tomorrow should not require redefining what it means to approve, cancel, or complete the same operation. Shared rules need a recognizable home that does not depend on how each conversation is worded.

A chatbot may be enough for a bounded informational use, and there is no reason to add complexity that use does not require. When it promises to participate in company operations, the question becomes which system sustains that promise. The answer lies in the responsibilities and relationships behind the interface, and in whether those relationships remain dependable beyond a single exchange.

The choice of channel can then evolve without changing the commitment represented by the work. A request viewed in a chat and the same request viewed in a queue should not acquire different meanings merely because the interface changed. That consistency is one of the responsibilities the conversation alone cannot define.