When a vendor talks about "RAG", "agents" or "data pipelines", they're describing three very different families of tools with very different costs, risks and benefits. Confusing them means risking buying the wrong solution. Here's the translation.

RAG: your documents answering questions

The problem it solves: "The information exists somewhere in our files, but finding it takes hours."

A RAG system (retrieval-augmented generation) connects a language model to your documents: client files, contracts, procedures, past quotes. When you ask it a question, it first retrieves the relevant passages from your archives, then formulates an answer citing its sources so you can verify every claim.

It's the typical tool for a notary office searching for the right clause across twenty years of files, or a contractor who wants to lean on past quotes to price a bid.

Its limit: a RAG is only as good as your documents. If the information is outdated or contradictory, so are the answers. Preparing the documents is often half the work.

Agent: a system that carries out a sequence of actions

The problem it solves: "This series of repetitive tasks eats hours every day."

An agent doesn't just answer: it acts, according to defined rules. Triage incoming requests, propose a first appointment, send a reminder, collect a form then hand over to a human for anything outside the frame.

It's the clinic's "front desk that never sleeps": simple requests run their course automatically, and the team concentrates its time where its judgment matters.

Its limit: an agent needs clear rules and guardrails. Which decisions can it make alone? Which require human validation? An agent deployed without those answers is a risk, not a tool.

Data pipeline: order before intelligence

The problem it solves: "Our data exists, but it's scattered, poorly structured, full of entry errors."

A pipeline gathers data from multiple sources, structures it, detects anomalies and prepares outputs ready for review GST/QST reports, for example. It's the least spectacular family in a demo, and often the one that generates the most day-to-day value.

It's also, frequently, the prerequisite for the other two: you can't build a good RAG or a good agent on top of disorganized data.

The right tool depends on the problem never the other way around

You'll notice the pattern: each family of tools answers a specific category of problem. The right approach therefore starts from your pain point, not from the catalogue. Be wary of anyone who proposes a solution before understanding your problem, your data and what "success" means for you.

That's exactly what a diagnostic is for: naming the problem, examining the data, and only then choosing the tool RAG, agent, pipeline… or sometimes a simple, well-designed script.