If your assistant answers customer questions about orders, bookings, refunds or accounts, the failure that costs you is not downtime. It is a fluent, confident, completely invented answer.

I know this one first-hand. The first version of my own demo told a customer we had agreed a refund - from a conversation it had never retrieved. I published that bug and the two fixes rather than quietly patching it.

WHAT I DO

1. Reproduce it. I find the cases where your assistant asserts something it did not retrieve. If I cannot make it fail, I tell you that instead of selling you a fix.

2. Ground it. Scored retrieval with a weak-match cutoff, so a poor match returns nothing rather than the closest-looking thing. Every factual clause has to trace back to retrieved content or it does not get said.

3. Teach it to refuse. "I don't know" becomes a correct, tested answer - not a failure state.

4. Prove it. You write the acceptance test: real questions from your real data, including the ones where it must refuse rather than guess. All pass, or the work is not done.

WORKS WITH n8n, Make, Zapier, or direct API assistants. OpenAI or Anthropic. Retrieval over email, order systems, CRM, Notion or your own database.

TURNAROUND: 5 business days from access.

NOT INCLUDED: model or API costs, and building a new assistant from scratch - this repairs and hardens one you already have.

Straight answer before you ask: no reviews on this profile yet. That is exactly why the acceptance test is yours to write and why the scope is fixed.