RAG doesn't know where your order is

An agent can have all your policies properly indexed and still be unable to answer the most common question in any inbox: where is my order.

It's not a search failure. They're two questions of a different nature, answered in different places. One is answered with what your business has written. The other can only be answered by looking at the system where the answer lives, right now.

Knowledge and state

• KnowledgeWhat the business wrote: deadlines, terms, what the warranty covers. It only changes when someone changes it, it's the same for all your customers, and it can be stored in an index and searched. That's what RAG solves.
• StateWhat's happening with a specific person: their order, their balance, their booking, their return. It changes on its own, with nobody touching it, every customer has their own, and in five minutes it's different.

An indexed balance is yesterday's balance.

It looks obvious written down, and it's the most common mistake we see in agents already in production: someone exports a list of orders, uploads it as a document, and for a month the agent answers with the state those orders had on the day of the export. Nothing fails. Nobody notices.

Storing it doesn't work either

The next temptation is to copy the data when it's looked up and reuse it for a while, which is what anyone optimizing a website would do. In customer support that has a worse name: a value read forty minutes ago isn't a fact, it's a memory. And confirming a forty-minute-old balance to someone is exactly the mistake all of this exists to avoid.

That's why at Qopper what's read from your systems lives as long as the turn does. It's not a cache or a copy of your database: it's asked, used to answer, and forgotten.

What connecting a system really is

Much less than it sounds. For an agent to look something up in your systems it takes four pieces, and you already have all four if you have an API.

1. 1An address. What gets called. Your own API's, the one your website or app already uses.
2. 2A credential. How the caller proves who it is. A token, a key in a header, whatever you already have set up.
3. 3The fields the model fills in. Order number, ID number, email. It's the only thing the agent has to pull out of the conversation.
4. 4A description. When to use it. And it isn't documentation: the model reads it, not a person, and it's what decides whether it gets used at the right moment or never at all.

The interesting part starts when it fails

The lookup working is the easy case, and it's the one shown in demos. What separates an agent you can put in front of your customers from one you can't is what happens when your system is slow, returns an error, or returns half the data.

• It takes too longIt stops waiting at twenty seconds. Without that cutoff, the conversation hangs until the server kills it, and the customer gets no answer, no apology and no handoff to a person.
• It returns an errorThe agent can't say “401”. What it gets isn't a code, it's a sentence: you couldn't look it up right now, say so and offer to have a person check. A status code read out loud is what turns a technical failure into a ridiculous conversation.
• It responds, but a field is missingThe worst of the three, because it looks like everything went fine. If the carrier hasn't set a delivery date yet, the model doesn't see a gap: it sees an object without that line and fills it with whatever sounds reasonable. That's how an agent ends up saying “it arrives Thursday” when nobody ever said Thursday.

The answer to the third is naming what's missing. “No delivery date on record” is as useful as the date, and it's the only thing that stops the agent from inventing one.

What to check before handing over a key

Connecting an agent to your API is giving it a key to your house. These are the four things I'd ask, whether you ask us or anyone else.

• Which addresses can it call?HTTPS only, and never an internal network address. A form that accepts any address is a form through which the server can be asked to call inward, to places nobody watching owns.
• Where does the credential live?Encrypted while stored, and in plain text only during the call that uses it. Never in a log, never in a trace, never in what the model sees.
• Can one of your actions shadow one from the catalog?It shouldn't. A custom action named the same as the refunds one would send money down a path where the cap, the approval and the check aren't watching.
• What does the agent see that you haven't connected?Nothing. What you don't connect doesn't exist for it, which is very different from it existing and answering that it can't.

With that sorted, “where is my order” stops being the question that makes your agent look bad and becomes the one that makes it useful. It is, by far, the most common one.