BLACKBENCH

All work RagReply


AI systems · 2026

RagReply


An admin panel for AI agents that answer from the client's own knowledge base.

Upload the documents a business already keeps, and the agent answers by text, by voice or on a call — naming the file it took the answer from.

By the numbers

5
AI tasks: speech-to-text, translation, embeddings, generation, speech
3
ways to test an agent: text, voice, call
pgvector
semantic search in Postgres 16
EN
chunk language — documents are normalised before indexing

The problem

Most of what a business needs to say is already written down: the price list, the opening hours, the service descriptions, the booking rules. It sits in files, while a chatbot on a general model answers from somewhere else entirely and invents the prices. The client wanted a panel where an owner uploads those same documents and the agent answers from nothing else, showing which file every figure came from.

The other half is cost and trust. One model for everything is either expensive or bad — transcription, translation, vectorisation, answering and speech synthesis differ in what they cost and in how good they have to be. And before an agent meets a customer, somebody has to put it through what customers will: awkward questions by text, by voice, and over the phone.

The solution

Uploaded documents are normalised into English chunks before they go into pgvector, so one vector space covers a base written in several languages. Retrieval matches meaning rather than word overlap, and the agent answers in whatever language the question arrived in.

The five AI tasks are configured one by one, each with its own connection and its own model. A cheap model transcribes, a strong one answers, a local Whisper stands in for the hosted one — the bill for an agent is assembled task by task rather than paid as one flat rate.

A connection is an OpenAI-compatible endpoint: base URL, type, key. Changing provider, or moving to a model you host yourself, is a row in settings and not a change to the code.

Answers come back with their source files listed, so checking where a claim came from takes a second instead of a trip through the logs.

Knowledge bases are isolated per client — separate documents, separate indexing, separate testing, and the testing runs against the exact base that goes to production.

Screens

All data shown is synthetic, with no connection to any real client.

Clients, each with a knowledge base and a document count of its own. One panel runs several agents. The salon, the dental clinic and the garage were invented for this portfolio and seeded by seed_ragreply.py — they are not a client roster.
Inside a client's base: document language, chunk count, indexing status. Reindexing is a button, not a migration.
Testing the agent, with a prepared dialogue: the answer is quoted verbatim from the chunks seeded into this client’s knowledge base rather than returned by a live model, both source files named below it, and microphone and call sitting next to the input.
Connections. A provider amounts to a base URL, a type and a key — enough to attach any OpenAI-compatible endpoint, local ones included.
Sign-in. The panel is behind a password because client documents are behind the panel.

Stack

Next.js
PostgreSQL 16 with pgvector
OpenAI-compatible APIs, hosted and local
Agent testing by text, voice and call
Multi-client model: one knowledge base per client