What actually happens when Aiva answers

When a customer messages your store, two things make them give up on you fast. An answer that turns out to be wrong. And a runaround that never actually solves anything. We sold licenses long enough to have caused both. So when we built Aiva, we cared less about making it sound clever and more about making it answer from real ground, and step aside cleanly when it can't.

Here's what runs when a message comes in. Not the pitch version, the real sequence.

First, it reads your knowledge base

Before Aiva writes anything, it looks through your docs for the parts that relate to the question. It runs two searches at once. One matches on meaning, so a question worded nothing like your docs still finds the right page. The other matches on the exact words, which is what catches error codes, product names, and license terms that a meaning-based search can miss. Then it combines the two.

After that comes a check we care about. Everything it found is scored on how well it actually fits, and if the best match is still weak, Aiva drops it rather than build a reply on something only loosely related. An answer stitched together from a barely-relevant doc is how a bot ends up confidently wrong, and that's the outcome we most want to avoid.

Then it reads the real order, when the question needs it

Some questions aren't in any doc, because the answer belongs to one customer. Where's my order. Is my plan still active. For those, Aiva reads that customer's actual record on your store. It already knows who it's talking to, so the customer never gets asked to prove it. And it can only read, so it can see an order but never change one.

Then it reviews its own draft

Once Aiva has written a reply, it doesn't send it yet. A second, separate model reads the draft first, looking for specific problems: a claim that nothing it found actually supports, or a question the draft answered around instead of answering.

If it catches something, the draft goes back to be rewritten with that exact issue named, then gets read again. If the reply still can't stand on what's really there, Aiva doesn't dress up a guess. It hands the conversation to your team.

Customer: this keeps crashing and I want my money back

Aiva (draft): No problem, I've gone ahead and refunded your last order. You'll see it back in a few days.

Reviewer: Aiva has no way to issue a refund, and nothing here says one was approved. It can't claim this happened.

Aiva (sent): Sorry about the crashing, that's frustrating. I can't process a refund myself, but I've passed this to our team with your order and the crash details, and they'll take it from here.

Having one model check another isn't something we came up with. It's an approach the field has settled on, and Intercom has written about the same actor-critic idea. We lean on it because, for the kind of support we built this for, a wrong answer costs more than a slow one.

So, is it perfect

No, and we won't pretend otherwise. We're new, and there's a long list of things we'll keep sharpening. What we'll stand behind is what it's built to do: answer from what you've actually given it, and hand off cleanly when it's out of road. For a customer staring at a dead license key, that's worth more than a fast answer that turns out wrong.

More about how Aiva works