A custom AI assistant for business answers from your files, with the source attached

Take the marketing away and there are four parts:

• A language model, bought through an API or run on your own server. It writes the answer. It doesn't know your office.
• Your sources: the specifications, standards, reports and records it's allowed to search.
• Retrieval: the step that finds the passages relevant to each question and hands them to the model.
• Rules: who may ask what, which folders each person can reach, and what the assistant does when the sources hold no answer.

A chatbot answers from a script. A general assistant like ChatGPT answers from what its model learned in training. A custom assistant answers from your documents. An agent goes one step further and acts: it sends the email, files the request, edits the record.

Most offices should start with the third and stay there for a while. An assistant that reads is a different risk from one that writes.

Microsoft 365 Copilot, ChatGPT Enterprise and similar products already search company files. If your documents sit in a system those products connect to, your staff ask in English, and everyone may see every file, a licence is probably the right answer. You don't need us, or anyone like us, for that.

A custom build earns its cost when one of these is true:

• The knowledge sits where the products don't reach: Revit models, drawing sets, a project database, a document control system built in-house.
• Permissions differ by project, and the assistant has to respect them file by file.
• The questions and documents are in Persian, and answer quality has to be tested in Persian.
• Every answer must cite a specific clause or sheet, in a form the office can check.
• The assistant has to live inside a tool people already use, such as the office's own management dashboard.

If none of those apply, buy. If two or more do, the licence will do most of the job and fall short on the part that matters.

The assistant that answers anything about the company is the one that never ships. Pick a single job for a single team, where the right answer exists in writing and someone can recognise it.

In an architecture or engineering office, the jobs that usually qualify are these:

• Specification lookup: which product, rating or tolerance the spec calls for, with the clause number.
• Office standards: the drafting manual, naming rules, template choices, the BIM execution plan.
• Past-project search: which earlier projects used a similar system, client or detail.
• RFI and correspondence history: what was asked, what was answered, and when.
• Onboarding: the questions every new hire asks in their first month.

Collect real questions for that job from the people who ask them, and write the correct answer beside each one. That list becomes the test later on, and it has to exist before anything is built.

The technique behind almost every custom assistant is called retrieval-augmented generation, from a 2020 paper by Patrick Lewis and colleagues. The paper's starting point still describes the problem: a language model's ability to access and precisely manipulate knowledge is limited, and showing where its answers came from was an open problem.

In practice it runs in four steps:

1. Documents are split into passages: a clause, a paragraph, a table row.
2. Each passage is indexed so it can be found by meaning as well as by exact words.
3. For each question, the passages most likely to answer it are retrieved.
4. The model writes the answer from those passages only, and cites them.

The model is the step people talk about. Retrieval is the step that decides the answer. If the right clause isn't retrieved, the best model available writes a fluent answer from the wrong one.

That makes the documents the real project. A specification scanned as images, three drafts of the same report in one folder, a standard replaced last year: all of it goes straight into answers. Preparing company data for AI covers that work in full. An assistant is where skipping it shows first.

NIST's Generative AI Profile names the core failure confabulation: the production of confidently stated but erroneous or false content. You can't train it fully out of a model. You can design around it.

Ask a general chatbot about your office's door schedule and you'll still get an answer. Tidy, fluent, and about some other office.

Three rules keep a custom assistant honest:

• Cite every answer: file name, revision, and the clause, page or sheet, linked so the reader can open it.
• Say when the sources don't answer: "not found in the documents you can access" is a correct response, and the assistant should be tested for it.
• Stay inside the job: questions outside its sources get pointed elsewhere, not improvised.

Citations change how people use it. An answer with a source gets checked by opening one file. An answer without one gets either trusted blindly or ignored, and neither is what you paid for.

Most guides assume English. An office working in Persian runs into problems none of them mention.

The same word can be stored several ways: Arabic and Persian forms of ye and kaf, a zero-width non-joiner in one file and a space in the next, Persian digits beside Latin ones, Jalali dates beside Gregorian. A person reads them as one thing. A search index can treat them as different words, and the passage that answers the question is never retrieved.

Scanned Persian documents are harder. Text recognition has to get joined letters, dots and mixed-direction lines right, and it can return text that looks complete and isn't. Check a sample by eye before anything is indexed.

NIST's profile lists performance disparities between languages as a generative AI risk. The practical consequence is plain: normalise Persian text before indexing, and test the assistant with Persian questions written by the people who will ask them. A model that shines in an English demo tells you little about how it handles a Persian specification.

An assistant that can read every file will, sooner or later, quote a fee proposal to someone who shouldn't see it. Permissions have to be enforced at retrieval, not left to the model's judgment: a person asking a question should only ever get passages from documents they could already open.

Two more decisions belong here:

• Where the data goes. A model called through an API sends passages to the provider with each question. A model run on your own server doesn't, and costs more to host. Read the provider's data terms before the first document is indexed, not after.
• What it may do. Start read-only. OWASP ranks prompt injection as the first risk for LLM applications, including the indirect kind, where instructions hidden in a file or web page change how the model behaves. An assistant that can only read and cite has far less to lose to that than one that can send, edit or delete.

Log questions, answers and the passages used from the first day. That's how a wrong answer gets traced to the file that caused it.

Before anyone relies on it, run the question list from the first step. Mark each answer correct, wrong, or correctly declined, and check that each citation actually supports its answer. A wrong citation is a separate failure from a wrong answer.

Keep testing after launch. Documents change, standards get replaced, and every new project adds folders nobody has indexed yet. Re-run the list whenever the sources change, and add every real question the assistant got wrong. Over time the list becomes the most accurate description of what the assistant can be trusted with.

The build follows the same order as this article:

1. Scope: one job, one team, and the question list with a correct answer for each.
2. Source inventory: which files answer those questions, who owns them, which version is current.
3. Prototype on a slice: one project's documents, enough to see whether retrieval finds the right passages.
4. Test: the question list, including the questions that should be declined.
5. Pilot: one team, real questions, everything logged.
6. Widen: more sources or a second team, only once the first team trusts it.

Cost follows the same drivers as any custom software: how many source systems there are, how messy the documents are, how fine-grained the permissions need to be, and whether it runs on a provider's API or your own hardware. A prototype on one slice is the cheapest way to find out which of those will be expensive before the full build is priced. It's the same staged approach our research and development work uses.