The fastest way to lose trust in an AI support tool is to let it touch production data. So when I owned the agentic support system for Avni, I started from a hard constraint: the AI can read prod, but it can never write it. Not "shouldn't" — can't. There is no write database connection anywhere in the workspace.
Inside that constraint, the agent still did the heavy lifting — and the numbers moved: −60% ticket resolution time and +40% team efficiency, measured on real production tickets.
Draft everything, execute nothing
- ▸
/triagecategorizes each ticket — settings issue, data problem, or bug — and drafts a jargon-free reply with no sensitive data in it. - ▸Read-only investigation. The agent queries production over read-only connections to understand what actually happened.
- ▸
/datafixgenerates a SQL file — it never runs it. A human reviews and executes every change. - ▸Human decision points everywhere. The AI drafts; a person decides what sends and what runs.
The safest automation is the one that structurally cannot do damage. Guardrails you can point to beat guardrails you hope for.
Why the ceiling is the point
It would have been easier to give the agent write access and let it "just fix" things. It also would have been the kind of decision you regret exactly once, expensively. By making unsafe actions impossible rather than merely discouraged, the system got faster and more trustworthy at the same time — which is usually a trade-off, and here wasn't.
That's the through-line in how I build AI: give the model room to be fast and creative, and put the irreversible actions behind a human and a gate.