A user asked our AI support agent a simple question: "Why can't I export more than 30 days?"
The agent knew the answer. The knowledge was all there. But this is what it said:
Starts with "you can't", then immediately explains how you can. Answers a different question than was asked. Volunteers limitations nobody asked about.
The user asked why. The agent answered how — and then contradicted itself by explaining exactly what the user could actually do. Three paragraphs to say almost nothing useful.
This is a very common failure mode in AI agents, and it's not really an AI problem. It's a prompt problem. The agent had no guidance on how to interpret a "why" question, so it defaulted to throwing everything it knew at the wall.
The Fix
I added four sentences of guidance to the agent's instructions:
- Answer the question that was asked. If the user asks "why", explain the reason.
- Don't pivot to explaining the mechanics of the feature unless that's directly relevant to the why.
- Don't say "you can't X" and then immediately describe how to do X. If you're going to mention what's available, frame it positively from the start.
- Don't volunteer limitations that weren't asked about. Adding those unprompted creates confusion and makes the response feel like it's hedging.
Same question. Same knowledge base. Here's what the agent said after:
Answers the actual question. Leads with what the user can do. Gives the reason clearly. No contradictions, no unprompted caveats.
The Takeaway
AI agents drift toward completeness. When they don't have explicit instructions about how to interpret a question, they try to cover everything they know. That's not helpful — it's noise.
The intervention isn't more training data or a better model. It's clearer rules about what kind of answer each kind of question deserves. "Why" questions get reasons. "How" questions get steps. You don't mix them unless one genuinely requires the other.
Four sentences. The response went from confusing to correct.
How I Actually Train Arbi
Arbi is our AI support agent at RB2B. I didn't build it once and walk away. I treat it more like a new hire I'm actively coaching — the difference being that when Arbi gets something wrong, I can fix it immediately and the fix applies to every conversation from that point forward.
My process is simple: I read real conversations, spot patterns in where the responses break down, and write guidance in plain language that addresses exactly what went wrong. Not abstract rules. Specific ones, derived from actual failures.
The example in this post is a good illustration of how that works. I didn't go looking for a response about CSV exports. I found it while reviewing conversations, recognized the pattern immediately, and had the fix written and deployed in about ten minutes. The next user who asked the same question got a completely different answer.
Most of Arbi's improvements have come from exactly this kind of iteration. The agent doesn't get better because the underlying model gets better — it gets better because the instructions get more precise. That's the work. Reading conversations, finding the drift, writing the correction.
It compounds quickly. Each rule added on the back of a real failure makes the agent sharper, and the failures get rarer. The job shifts from fixing obvious mistakes to catching subtler ones. That's a good sign.