A RAG AI agent that admits what it does not know
Queries the company knowledge, answers with sources, admits when it lacks enough information and hands off to a person.
A useful agent is not the one that answers everything: it is the one that knows what it may do, recognises when it lacks enough information, and passes the conversation to a person before inventing something.
A pilot without these answers ends as a nice demo that never reaches production.
A specific, measurable task, not "handle customers". If it cannot be described in one sentence, it cannot be evaluated either.
Which documents, which systems and who keeps them current. The agent is only as good as its sources.
Reading an order is different from changing it. Actions with side effects are limited in code, never only in the prompt.
What triggers escalation and with what context it arrives. Without this, the agent becomes a wall.
Scope
They answer from your documentation citing the source, and admit when they find insufficient support.
They check the state of an order, an invoice or a ticket in the real system, with least privilege.
See integrations : Agents connected to your systemsWeb, WhatsApp or the product itself. The channel is decided last, not first.
A set of real cases with expected answers, so you know whether yesterday’s change made things better or worse.
Explicit escalation rules and human approval on actions that carry consequences.
Conversation logs, errors and model usage, so the bill is not a surprise at month end.
The pilot exists to decide with data whether to continue, not to leave something half-finished in production.
The pilot is quoted by scope once the task and sources are defined. Build, hosting and model usage are presented as three separate lines so you can compare them.
Recurring third-party costs: Model usage per conversation, hosting and infrastructure, and channel licences (the WhatsApp API, for example).
Evidence
A valid query with sources, a query with insufficient information where the agent admits it, and a handoff to a person.
Queries the company knowledge, answers with sources, admits when it lacks enough information and hands off to a person.
Yes, and anyone claiming otherwise is not being honest. That is why the work concentrates on bounding what it may do, measuring with an evaluation set, and handing off when support is insufficient. We publish no accuracy percentages or savings: without a comparable baseline they mean nothing.
It depends on conversation volume and the model chosen. We estimate it before the pilot using your real volume and present it separately from development: build, hosting and usage are three distinct lines.
It helps a great deal, but it need not be perfect. Part of the pilot is finding out what is missing. What is essential is that it exists and that someone owns keeping it current: an agent over stale documentation repeats errors very confidently.
Yes, with limits defined in code rather than in the prompt. Actions with side effects are explicitly restricted, and consequential ones go through human approval.
Conversational assistants for support and sales: knowledge, tone, evaluation and escalation.
Synchronisation between systems with error handling, retries, duplicate control and monitoring.
Your own systems and platforms, when no off-the-shelf tool solves the process.
Tell us what the agent should resolve, with which information and what it should be able to do. We will say whether a pilot makes sense.