RAG vs an Agent vs a Plain Query: A Decision Guide

Use a plain query when the answer is already a field in your database. Use RAG when the answer must come from documents you can retrieve and cite. Use an agent when the job is a sequence of steps, tools, and decisions, including a step a person has to approve.

RAG vs an AI agent is the comparison most teams search for. A plain query is the option that demo decks leave out, and it is often the path that keeps a production answer tied to a row you can test. This guide applies the choice to work Prograsec has already shipped: retrieval on Cause Systems, a 12-step procedure on a confidential workplace platform, and a vision model on a key-recognition system whose accuracy moved from 40% to about 80%.

Two neighboring decisions sit on other pages. Build vs buy an AI chatbot asks whether to configure a platform or own the application. LangChain vs LangGraph asks how much of an agent workflow you write as an explicit graph. Settle where the answer lives before you pick a library.

What is the difference between RAG, an agent, and a plain query?

A plain query reads or writes a record with code you can test: SQL, an API call, or a rule. The same input returns the same row.

RAG, retrieval-augmented generation, searches documents you control, passes the retrieved passages to a model, and asks the model to answer from those passages. Cause Systems does this for company documents, including CSV files, and keeps a fallback for when retrieval comes up empty.

An agent keeps state across more than one step. It can call tools, branch, and stop for a person. The workplace-procedures platform runs a 12-step investigation and a 6-step offboarding workflow in LangGraph, with human approval on consequential steps, plus a retrieval layer over the client's policy documents.

One product can use more than one of these. On that workplace platform, retrieval answers what the policy says. The procedure answers which step the case is on, and who has to approve it.

RAG vs an agent vs a plain query

Pick the row that matches the job. If two rows match, split the feature along that line. One prompt that tries to be a ledger, a policy search, and a procedure at once is hard to test when it fails.

When is a plain database query enough?

Use a query when a correct system already stores the fact. Order status, remaining leave, whether a SKU is in stock, and which plan a customer is on are rows. A model that paraphrases the row can disagree with a value the database already got right.

Write the check before you write a prompt. If a unit test can assert the output from fixtures, keep that path in code. A later model can explain the row in the customer's words. The number still comes from the query.

• The fact has an owner table and a freshness rule. You know which write updates it.
• Showing the raw field is safer than a paraphrase of the field.
• The action is one call you already expose: create, update, or fetch. The next step does not depend on what a model inferred.
• You can log the query and replay it. You do not need a transcript to explain the result.

Chat demos pull teams toward RAG for this kind of fact, because a sentence looks more finished than a column. The failure is a confident balance that does not match the ledger. Show the field. If the user still needs a conversation, the conversation may quote the field.

When should you use RAG?

Use RAG when the answer is a passage, a clause, or a cell inside a file, and the user needs that source named. Policy PDFs, contracts, help-center articles, and spreadsheets of internal figures fit. A customer table does not, unless the question is about a document attached to the customer.

Cause Systems has Internet, Company, and Combination modes. Company mode queries vectorized knowledge bases, including CSV files. Fallbacks keep the answer grounded when retrieval returns nothing. Chat memory, math rendering, and voice input sit around that retrieval. We still develop and maintain the platform. The public product site is cause.systems.

Design the empty-retrieval case before the happy path. If search returns nothing, the product should say so and stop, or hand the question to a person. A model that fills the gap from general training will sound like your knowledge base. The Cause Systems fallbacks exist for that empty result.

• You can point at the document the answer came from.
• Removing a file removes it from the index. On the key-recognition project, a vector-database deletion did not stay in sync until it was fixed. A document index has the same failure mode: a withdrawn file can keep matching.
• You have questions with accepted answers, so a retrieval change can be scored. The prototype-to-production checklist covers that evaluation before launch.
• Permissions match the documents. A user who cannot open the file should not receive a passage from it.

When should you use an AI agent?

Use an agent when the job is a procedure: several steps, tools that change something, and at least one decision beyond which paragraph is relevant. Investigations, offboarding, and contract workflows are procedures. A single question about a policy is a retrieval problem.

For a confidential Australian client, the engagement started as one investigation workflow and expanded into a platform. The LangGraph backend walks a 12-step workplace investigation and a 6-step offboarding workflow. A person approves consequential steps. The workspace generates documents from an evidence matrix, streams chat, and retrieves the client's own policy documents. CHROs, consultants, and business owners have separate dashboards behind MFA. The platform is in final development, and the client stays unnamed. The write-up is the workplace-procedures case study.

Human approval on its own does not pick the library. The current LangChain create_agent interface runs on LangGraph and can pause for review, which the LangChain overview describes. Direct graph orchestration fits when the transitions are the product, as they are in a numbered procedure. Write the steps, the tools, and the failure path first. The LangChain vs LangGraph guide covers the library choice.

• List every step, including the ones that must stop for a named role.
• Name the tool each step may call, and what a failed call should do: retry, stop, or return to a person.
• Keep the policy answer in retrieval. Keep the case state in the procedure. The workplace platform does both.
• Count reviewer minutes as a running cost. The AI feature cost worksheet has a line for that time.

When does the job need a different model?

Some inputs are neither documents nor rows. A photo of a key is one. A property-tech client's recognition feature identified a scanned key 40% of the time. We replaced the feature extractor with configurable ResNet50 and EfficientNet-B3 models, added rotation augmentation at 0, 90, 180, and 270 degrees, normalized real-world photos, fixed a vector-database deletion-sync bug, and set the match threshold to 90%. Accuracy moved to about 80%, and false positives were virtually eliminated. The client is unnamed. The key-recognition case study has the detail.

A chat window in front of that module would still have needed the vision model. The accuracy problem was in the extractor, the rotations, and the threshold. If your labeled examples are images, audio, or sensor readings, measure a model built for that signal before you scope a conversation around it.

How do you choose in one sitting?

Block an hour with the person who owns the workflow. Leave with one row from the table, or with the feature split across two rows.

• Write the user action in one sentence, and the record it must read or change.
• Mark each fact as a row, a document, or another signal such as an image.
• Mark each step that may call a tool, and each step a named person must approve.
• If every fact is a row and no step branches on model output, ship the query.
• If the answer is a passage, ship retrieval, including the empty-result path Cause Systems uses.
• If the work is a numbered procedure with tools and approvals, scope the agent, then choose the orchestration library.
• If the input is an image or another non-text signal, test that model class against labeled examples. The key-recognition rebuild is the pattern: measure accuracy, then set a threshold.

Bring that page to a fit review. Bounded work can take a fixed quote. A question you cannot answer from the data you have is a separately scoped evaluation, with its own stopping point. Request a project scope and attach the page.

What does the choice change about cost?

A plain query costs a database read and the engineering to keep the field correct. RAG adds indexing, retrieval, and a generation call, then adds them again on retries. An agent multiplies generation and tool calls by the number of steps, and adds reviewer minutes on every approval. Price the row you actually chose. The running-cost worksheet is the place to put those numbers once the architecture is settled.

What should you hand an engineering team?

A useful estimate starts from a short brief:

• The job, in the user's words, plus the check that says it succeeded.
• One redacted example of the input, and the answer or action you would accept.
• Where each fact lives today: table, file, or image set.
• Which steps a person must approve, and which actions the system must refuse.
• What should happen when retrieval is empty, a tool fails, or the match score sits under the threshold.

That packet is enough for a fit review. The review is free. Scope and price are agreed before paid work starts. Ongoing monitoring and model changes are quoted separately from the build, which is how the AI development services page separates them.