AI Support Agent v6.0.1

Release Date: August 11, 2026 Tags: PERFORMANCE, RETRIEVAL, KNOWLEDGE, COVERAGE, DEFLECTION, WALKTHROUGHS, TOOLS, LATENCY, ADMIN

Overview

A performance release. The answers a customer receives in a conversation, and the coverage percentage on Gaps, are decided by the same rules as before: two lookups that ran after the reranker now run underneath it, a report that replayed two hundred questions one at a time now replays them four at a time, and a search whose result was discarded on every turn but the first no longer runs on those turns. Same answers, less work — with one exception. A persona limited to a chosen set of tools was being offered none of them, so on those installs the assistant can now use the tools you chose.

One change is not purely internal. The answer offered while a customer is still typing their subject line no longer waits on the store-hosted documentation, and the shortlist it judges that suggestion against is longer as a result. The passage it leads with is unaffected, but a suggestion can now be withheld as ambiguous where it was not before, so the number of tickets this surface deflects can fall — it cannot rise. That is described in Upgrade Notes. Read it before you update.

Requires Core v6.6.3.

Update Instructions

pnpm updator

Nothing to configure. No setting changes and no data repair.

Upgrade Notes

The suggestion offered while a customer types no longer reads the store-hosted documentation

When a customer types a subject line, the agent searches for an answer that already exists and offers it before they file anything. That search was also making a signed request to the store for its hosted documentation — on every debounced keystroke, with a 2.5-second ceiling on each one. That is affordable once per question and not once per character.

Those pages were never offered as a suggestion, and still are not: only an article or FAQ you wrote can be shown here. What their presence did was change the shortlist a suggestion is judged against, and that shortlist is what decides whether a suggestion is unambiguous enough to show at all.

• Changed this surface to read your own index alone. Merging the store's pages in also trimmed the shortlist back to the retrieval limit, which quietly dropped any passage your own index had added beyond it. Those come back, so the shortlist here is now longer than it was — never shorter.
• The passage the suggestion is taken from does not change. Everything from your own index outranks everything the store returns for ten places, so the leading passage was always one of yours; on the default limit of six the store's pages were not reaching the shortlist at all, and only above ten were they taking slots from your articles outright. Raise aiSupportTopK past that and the effect below is correspondingly larger.
• What does change is one-directional. A longer shortlist means more chances for a second, similar article of yours to make the suggestion look ambiguous, and an ambiguous one is withheld — so your deflection count can fall. It cannot rise. Compare the figure against last week's a few days after you update.
• The confidence bar a suggestion must clear is unchanged; it is measured against your own index before anything is merged in. So is the rule that refuses a fee or limit question with nothing of yours behind it. There is no setting for this one surface.
• aiSupportRemoteDocsEnabled still governs the store-hosted documentation inside a conversation, where the round trip happens once per question rather than once per keystroke. Nothing about that path changed.

Changed

Answering a customer

• Changed the two lookups that do not depend on the reranker — the store-hosted documentation, and your own configured fees, limits and review times — to start before the reranker runs rather than after it. The reranker is the slowest step in the whole path, measured at 35 seconds warm on the installation this was profiled on, and both lookups were being paid for strictly on top of that. They now run underneath it and are usually settled by the time anything reads them. What is retrieved is unchanged.
• Changed the direct-answer check so it no longer searches on turns where it could never produce a hit. A verbatim article is only ever served on the opening question — a follow-up like "and what if I lose my phone?" retrieves the two-factor article at high confidence while answering something nobody just asked — so on every turn but the first, that search ran and its result was discarded. The condition is now tested before the search instead of after it.

The coverage panel on Gaps

• Changed the report behind What your documentation can answer to replay its sample of recent ticket subjects four at a time rather than strictly one after another. Each replay carries a database aggregate, and two hundred of them in single file was a wait an operator sat through with the screen open. The sample, the two gates applied to it and the order the misses come out in are all unchanged, so it is the same percentage and the same list.
• Changed those replays to read your own index only. With no reranking involved — the panel never makes a model call, by design — that signed request was, on an install with aiSupportRemoteDocsEnabled left on, the largest part of each wait, two hundred times over. The percentage does not move: the gate that decides "no documentation" is measured against your local index, and an article you wrote is promoted into the judged passages whether or not the store answered.

The walkthroughs the assistant can offer

• Changed the check that decides which walkthroughs a particular customer is eligible for from one at a time to six at a time, and the settings and extension lists every one of those checks reads are now loaded once up front rather than inside whichever check happened to run first. Six rather than all at once is deliberate: a walkthrough gated on identity verification reads that customer's applications from the database, and one chat turn should not take the connection pool your wallet transactions share. The walkthroughs offered, and the order they are offered in, are identical.

Fixed

A persona limited to certain tools was left with none of them

A persona can carry a list of the tools the assistant is allowed to use — the account and activity lookups, the walkthrough offer, the request to bring in a person. That list is stored as JSON, and the two databases this product runs on disagree about what a JSON column is: MySQL hands the list back as a list, MariaDB hands the same column back as text. Read as text it matched no tool name, so the filter it feeds withheld every tool. On those installs a persona with a list set answered from your documentation alone — it could not read the customer's own balances or recent transactions, could not offer a walkthrough, and could not ask for a person even though its own instructions tell it to. Nothing errored, and the list looked correct in the database the whole time.

• Fixed the stored list so it is read as a list on either database. A persona naming three tools is now offered those three, so far as the switches that already governed each one allow — an offered action, for instance, stays withheld until you enable those separately — and a persona naming none is unrestricted, as it always was.
• Applies only where such a list was set, which is done through the API rather than the persona screen — an install that never set one was never affected. The automatic hand-overs are unaffected either way: a refusal, an ungrounded answer, or a question your documentation cannot cover has always escalated on its own, without a tool.