Support that learns from its own answers

Every morning, in thousands of companies that sell a product and provide support for it, an agent opens the ticket queue and recognizes the question from its first line: it is the same one they answered last week, and the month before, and probably yesterday. The answer exists, written down somewhere, perhaps in a manual, perhaps in an email from six months ago. But between the question and the answer there is always the agent, and their time costs more than any piece of software.

The naive idea, the one that has been circulating in boardrooms for a couple of years now, is that it is enough to "add a chatbot". Experience says the opposite: a language model left free to answer customers always answers, even when it does not know, and support that invents answers is worse than support that is slow. The interesting technical problem is not getting a machine to answer. It is deciding, request by request, whether the machine has enough elements to answer, and building the fallback path for when it does not. Forge QA, the technical support platform developed by AYXZA, is built entirely around this decision.

Answer when you can, hand over when you must

When a customer opens a request on Forge QA, the platform does not pass the question to a generic model and hope for the best. The request is first classified by a lightweight, inexpensive model, then matched against the knowledge base of the product it refers to: a dedicated corpus for each product in the catalog, queried by semantic similarity through vector embeddings on PostgreSQL with the pgvector extension.

The pivotal point is the confidence calculation. Every generated answer carries a score that combines retrieval quality (how closely the retrieved documents actually match the question) with the model's own assessment. Above a configured threshold, the answer is published as automatic and the customer receives it immediately. Below the threshold, the answer does not disappear: it becomes a low-confidence draft that lands in the human queue, where an agent reviews it, corrects it, or discards it. And if the knowledge base contains nothing relevant, the system says so: no context, no invented answer, request routed directly to a person.

It is an architectural choice before it is a product choice. The model is never the last word: it is the first filter in a chain where the human being remains the guarantor, with a cost per intervention that falls as the knowledge base grows.

Three tiers, one platform

Forge QA is multi-tenant across three tiers, because that is how software is actually sold in much of the market: there is the company that makes the software, there is the network of resellers or partners that distributes it, and there are the end-customer companies that open the requests. The platform models this hierarchy explicitly. The producer administers the product catalog and the knowledge bases; each reseller receives a ceiling of products it can activate and, within that ceiling, activates its own customers autonomously; each customer sees only the products it is entitled to.

The entitlement engine that governs all of this is granular: each customer's effective rights are the intersection of what the reseller can offer and what has been activated, and every request is routed to the knowledge base of the correct product. For anyone selling through a network, this means something concrete: a single installation serves the entire chain, with data isolation between tenants and permissions that reflect the actual contracts, not a theoretical org chart.

The loop that improves the system with every answer

Perhaps the most interesting part of the platform is not how it answers, but how it learns. Every resolved request, whether it was closed by an agent or ratified with one click from an automatic answer, generates a candidate entry for the knowledge base: the customer's question and the answer that resolved it, already paired. A supervisor reviews them in a dedicated console, edits the text where needed, excludes doubtful ones, and with one operation exports the consolidated document into the knowledge base, which is then reindexed.

The result is a measurable virtuous cycle: the questions a person answers today become the answers the system will give on its own tomorrow. There is no one-off "knowledge base population" project to run once and let age; there is a continuous flow in which the ordinary work of support produces, as a by-product, the material that reduces future work. And since every entry passes through human review before entering the corpus, the knowledge base grows without polluting itself.

The analytics dashboard closes the circle: requests are classified into disjoint categories (automatic answers, automatic answers ratified by an agent, human handling, pending), so that management can see at any moment how much of the support load the machine is actually absorbing, and with what confidence distribution.

Under the hood

A few details for those who weigh the technical substance. Forge QA is a server-rendered application in Python, on FastAPI with Jinja2 templates: no single-page application, no megabytes of JavaScript, pages that simply load. The data lives on PostgreSQL, with pgvector for semantic search and versioned migrations. The intelligence layer is separated from the application domain through an internal library that abstracts the providers: models are chosen and replaced through configuration, not by rewriting code.

This separation has a direct economic consequence. Request classification uses a lightweight model; answer generation uses a mid-tier model, selected after comparative testing on quality and adherence to the output format. The switch from the high-end model to the mid-tier one, measured internally on the platform's real calls, reduced the average cost per answer roughly fourfold, at equal or better quality. The cost of each interaction is tracked per token and visible: whoever administers the platform knows what they are spending, rather than discovering it at the end of the month from the provider's invoice.

Failures are designed for, too. If the model provider is temporarily unavailable, the customer's request is not lost: it stays persisted in its initial state and can be reprocessed as soon as the service returns. The platform runs behind an encrypted tunnel, with CSRF protection on every write operation and services managed at the operating-system level. These are details that do not show in a demo and show very clearly the day something goes wrong.

A note of caution

It should be said honestly, because chatbot vendors tend to omit it: automated support disappoints when it is promised as a full replacement for people. Industry experience converges on one point: language models, without documentary grounding and without thresholds, produce plausible answers even when they are wrong, and the reputational damage of an invented answer given to a paying customer far exceeds the savings of a few minutes of an agent's time.

Forge QA is built taking this criticism as true. That is why the system stays silent when it has no context, why the human queue exists, why every entry that reaches the knowledge base passes through a review. The promise is not "zero agents": it is that agents stop answering the same question a hundred times, and that each of their answers works for the next ones as well. Those looking for magic will find, elsewhere, vendors willing to promise it.

Who it is for, and how to try it

Forge QA is designed for any company that provides support for its own products or services: directly to end customers, or through a network of resellers and partners. It needs a starting documentation base, even a minimal one, because the learning loop does the rest; it needs the will to keep people inside the process, because the system is designed for them, not against them.

AYXZA, the Italian studio of AI software systems that designed and developed the platform, offers it in two forms: as a product for companies that want to structure their own support, and as a white-label solution for software houses and resellers that want to offer it under their own brand to their own network.

For a demonstration on your real data, or simply to find out whether the use case holds, you can write to ping@ayxza.com or start from ayxza.com. The first conversation is meant to assess, not to sell: if the problem is not a good fit, we say so.