[ AI & Automation  /  AI RAG Chatbot ]

A chatbot that answers from your data, not its imagination.

Retrieval-augmented generation means the assistant looks things up in your content before answering, and shows you where each answer came from. Done properly it is genuinely useful. Done badly it invents policies you never wrote.

Evaluated before launch · Citations on every answer · Fixed scope

Citedanswers, always
Evaluatedagainst a real test set
Your datastays yours
Fixedscope and price

[ Why most fail ]

Why the demo worked and production didn't.

The gap between a convincing demo and something staff will actually rely on is almost entirely in these six areas.

Confident wrong answers

No grounding, so the model fills gaps with fluent invention and users cannot tell the difference.

Retrieval finds the wrong thing

Documents chunked badly, so the passage that actually answers the question is never retrieved.

Stale content

Indexed once at launch and never refreshed, so answers slowly drift out of date.

No access control

Internal documents surfaced to anyone who asks the right question.

Costs nobody modeled

Token spend scaling with usage in a way nobody projected before launch.

No way to measure quality

No test set, so nobody can tell whether a prompt change made the assistant better or worse.

[ How it works ]

Ground it, evaluate it, then ship.

01  —  Week 1

Scope & test set

Which questions it must answer, from which sources, for which users. We write a real test set of questions and correct answers first — that is what makes evaluation possible later.

02  —  Week 2-4

Build

Ingestion, chunking, embedding and retrieval tuned against your content, with citations and refusal behavior built in from the start.

03  —  Launch

Evaluate & deploy

Scored against the test set, tuned, then deployed with logging so you can see what people actually ask and where it falls short.

[ What actually changes ]

What gets built.

The retrieval layer matters more than the model. Most quality problems are retrieval problems wearing a costume.

Retrieval

  • Document ingestion — from your site, help center, PDFs, wiki or database, on a refresh schedule.
  • Chunking strategy — tuned to your content, because the default rarely suits real documents.
  • Vector search — usually combined with keyword search, since pure semantic search misses exact terms.
  • Reranking — so the most relevant passage reaches the model, not merely a related one.
  • Freshness — automatic reindexing when source content changes.

Answer quality & control

  • Citations — every answer links to the source passage, so users can verify it themselves.
  • Refusal behavior — says it does not know instead of guessing when retrieval comes back empty.
  • Access control — answers scoped to what that specific user is permitted to see.
  • Evaluation harness — a scored test set so prompt and model changes are measured, not felt.
  • Cost controls and logging — per-conversation budgets, plus a record of what gets asked.

[ Example engagement ]

Support assistant that deflected real tickets.

A help center assistant grounded in existing documentation, with citations and a strict refusal rule. Evaluated against 200 real historical support questions before launch.

Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.

200questions in the test set
91%correctly answered or refused
31%of tickets deflected
100%answers with citations

[ Free · no obligation ]

Is your content ready for this?

Tell me what you want the assistant to answer and where that knowledge lives today. You get an honest assessment of feasibility, cost and what it would take.

Ask me

[ Pricing ]

Pricing that fits your budget.

Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.

Fixed project price

Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.

Monthly retainer

For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.

Hourly for small jobs

For a single bug or a short task where writing a full scope would cost more than simply doing the work.

Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.

[ Questions ]

Common questions.

Which model do you use?

Whichever fits your accuracy, latency, privacy and budget requirements — and the architecture is built so the model can be swapped later without a rewrite, because this field moves quickly.

Does our data get used to train a model?

No. Retrieval-augmented generation looks your content up at query time; nothing is trained on it. Where data residency matters, providers offer options that keep processing within a given region, and I will configure that explicitly.

What does it cost to run?

Ongoing cost is mostly per-query token spend, which is modeled from your expected volume before you commit. Per-conversation limits and caching keep it predictable.

What if our documentation is bad?

Then the assistant will be bad, and I will tell you that before taking the project. Retrieval cannot invent information that was never written down. Sometimes the honest first step is fixing the documentation.

Can it do things, not just answer?

Yes — booking, lookups, ticket creation and similar actions. Anything that changes data gets confirmation steps and permission checks, because a wrong answer is annoying and a wrong action is expensive.

How do we know it is working?

The evaluation test set gives you a score before launch, and query logging shows what people actually ask afterwards. Both matter, and the second one usually produces the improvement backlog.

[ Let's talk ]

Tell me what you're building.

Describe it in a few lines and you'll get a straight answer on scope, cost and timeline — same working day, from the person who'd actually build it.