Assistants handle policy questions well and account questions poorly. The gap is not about language ability but about what has to happen before the model can answer at all.
The answer is not in the model
A question about a return window can be answered from documentation. A question about one order's status requires a live lookup in a system the model has no access to by default.
That lookup has to be arranged deliberately: identify the customer, locate the record, retrieve the relevant fields and place them in front of the model.
Each step is ordinary software integration, and the quality of the answer depends almost entirely on it rather than on the model's capabilities.
Identity verification comes first and breaks the flow
Before an account question can be answered, the system must establish who is asking, to a standard the company's security policy accepts.
In a chat interface this interrupts the conversation with a verification sequence, which is precisely where many customers abandon and call instead.
Companies that relaxed verification to keep the flow smooth created a disclosure risk, so the friction is generally deliberate rather than an oversight.
Stale data produces confident wrong answers
Account systems update on their own schedules. A shipping status, a payment posting or a claim state may be minutes or hours behind what the customer already knows.
The assistant reports what it retrieved without any sense that the value is out of date, and states it in the same assured tone as everything else.
Customers reading a contradiction between the assistant and their own inbox conclude the system is broken, which is a fair description even though the model did nothing wrong.
Permissions determine which fields can be spoken
Not everything in a customer record may be repeated back, and the rules differ by field, by role and sometimes by state law.
Handling this correctly means filtering the retrieved record before it reaches the model, rather than instructing the model to avoid mentioning certain things.
Instruction-level restrictions leak under pressure from a persistent customer, while data that was never supplied cannot be disclosed at all.
Multi-record questions are where it collapses
Questions spanning several records, such as comparing charges across months or reconciling a partial refund, require assembling and reasoning over structured data.
This is the point at which most deployments hand off, because assembling the right set of records is a query problem nobody specified in advance.
The assistants that handle these well are the ones given a small number of purpose-built lookups rather than general access to the underlying systems.