How to build an AI support agent

1. Storage, with tenancy from the first migration

Start with the schema, and put the tenant identifier on every row that will ever hold customer content — even if you are building for a single customer today. Retrofitting multi-tenancy into a system where the isolation boundary was assumed is one of the least pleasant refactors available.

If you are on Postgres, pgvector keeps embeddings alongside the relational data, which means tenant filters and citation joins happen in one query. Store the embedding model name on every chunk: changing models invalidates every vector, and you want that detectable rather than mysterious.

create extension if not exists vector;

create table chunks (
  id              uuid primary key default gen_random_uuid(),
  workspace_id    uuid not null references workspaces(id) on delete cascade,
  source_id       uuid not null references knowledge_sources(id) on delete cascade,
  content         text not null,
  embedding       vector(1536),
  embedding_model text not null,
  metadata        jsonb not null default '{}',
  created_at      timestamptz not null default now()
);

create index chunks_workspace_idx on chunks(workspace_id);
create index chunks_embedding_idx on chunks
  using hnsw (embedding vector_cosine_ops);

2. Ingestion as a background job

Parsing a large PDF, chunking it, and embedding every chunk will exceed a serverless request timeout on any corpus worth having. Make indexing a background job with visible progress from the start.

Chunk on document structure rather than a fixed character count wherever the structure exists, and carry the heading into the chunk body so the embedding reflects the topic. Batch the embedding calls; providers cap batch size, and a hundred at a time is a safe unit.

Track each run as a row — status, total chunks, embedded chunks, error — so the interface can show progress and a failure is diagnosable after the fact rather than a spinner that stopped.

3. Retrieval that cannot cross tenants

Put the search in a database function that takes the tenant ID as a required argument. This is a small thing that eliminates an entire category of catastrophic bug: there is no code path that can search without scoping, because the function will not run without it.

Return the similarity score alongside the content. You need it for the answer gate, and you need it in the trace when someone asks why a particular answer came out.

4. The answer gate — the part that matters

This is where a prototype becomes a product. Before generating, decide whether you should. If the best match is weak and nothing else could help, return a fallback without paying for a model call.

When you do generate, constrain the prompt to the retrieved context, delimit that context explicitly, and require structured output that includes the model's own assessment of how well the context covered the question. Blend that with the retrieval score to decide whether the answer is good enough to send.

Record the outcome on every answer: answered or not, the confidence, the chunk IDs and their scores, the model, the token counts. You will want all of it the first time someone reports a bad answer, and it is nearly impossible to reconstruct later.

5. Handle the messages that are not questions

"Hi", "thanks", "are you a bot" — these are a meaningful share of real traffic and they should not touch retrieval. Running the pipeline on a greeting produces "I couldn't find information about that", which is wrong, and in our case also triggered an offer to connect the customer to a human, which then hijacked the next real question into a handover flow.

A short classifier before the pipeline fixes it. This is a small feature that noticeably changes how the assistant feels.

6. Tools, once the content path is solid

Content questions are only half the inbox. "Where is my order?" needs a live lookup, and that means function calling plus a way to know who is asking. Build it after the retrieval path works, not alongside it.

The identity requirement is not optional. A tool that reads customer data must only be offered to a visitor whose identity your customer's server has cryptographically vouched for. Withhold the tool entirely from unverified visitors rather than checking permissions after the model has decided to call it.

7. The operational pieces

These are not features anyone asks for in a demo, and every one of them will be needed in the first month of real traffic.

• —Rate limits per visitor and per tenant, failing closed in production
• —An origin allowlist, so a public widget key cannot be used from anywhere
• —Input caps on message length and conversation history
• —A queue of unanswered questions, which is your content roadmap
• —Encrypted storage for any credentials a tool needs
• —A replay view showing the trace behind any past answer

Build or buy

All of the above is a few weeks for someone who has done it before, and considerably more for someone who has not — most of the time going to the answer gate, the tenancy boundary, and the operational list rather than the interesting parts.

Worth building if the assistant is your product, your data model is unusual, or you have requirements no tool fits. Worth buying if support is a cost centre you want smaller, in which case the differentiated work is your content, not your retrieval pipeline. AskBrew is our answer to the second case, and it has a free plan.