Loading today’s stories
Build1 distinct publisher3 min readUpdated
A dev.to post argues the "RAG or agents" question is malformed. The interesting part is the invoice: one axis out of five justifies the premium, and most buyers never use it.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A developer writing on dev.to reports getting the same client email at least once a month: should we use RAG or agents? The post's answer is that the question is malformed, because the two are not competing implementations of one capability [s1c1][s1c2]. The reason an operator should care is the invoice attached to the confusion: by that account, conflating them is how you end up with a $3,000-a-month "agent" doing work a $0.20 retrieval pipeline would have done, or a retrieval pipeline that hallucinated its way into taking an action nobody authorised [s1c3].
The distinction is short enough to keep. Retrieval governs what the model knows; agency governs what the model does, and cost, latency and failure modes all follow from that single difference [s1c4].
Retrieval is a straight line: question, embed, vector search, top-k chunks, prompt, answer [s1c5]. The post prices it at $0.01 to $0.05 per query, one round trip, one prompt to reason about, with every answer traceable to a chunk that actually exists [s1c6][s1c7]. Its weakness is stated without hedging: it cannot act. It can tell you the refund policy and cannot issue the refund; it can summarise a log and cannot rotate the credential it just found [s1c8].
An agent is a loop rather than a call: observe, reason, call a tool, use the result, repeat until the goal is met, a budget is hit, or it escalates [s1c9]. The defining property is multi-step action without a human authoring each step in advance [s1c10]. Its default knowledge is training data plus whatever a tool hands back, so an agent with no retriever attached will answer questions about your private policy from vibes, and then act on them [s1c11]. Which is why, the post says, most production agents quietly contain a retrieval pipeline inside [s1c12].
The scoring is where the budget argument lands. On answer quality over your own content both score 4, because the agent's grounding comes from the retriever it contains; without one it is a 1 and confidently wrong, making this a dependency rather than a contest [s1c13]. On action capability retrieval scores 1 and the agent 5 [s1c14]. On cost per task retrieval scores 5 and the agent 2, with a five-step task and two tool calls running roughly 5 to 10 times a single generation [s1c15]. On latency, 5 against 3: a second or two versus seconds to minutes, which a user watching a chat window feels immediately [s1c16]. On predictability and governance, 4 against 3 [s1c17]. Added up, that is 19 out of 25 for retrieval against 17 for the agent, and the entire agent advantage sits in one column [1].
Put the money next to it. At the post's own $0.01 to $0.05 per query, a $3,000 monthly agent budget buys between 60,000 and 300,000 retrieval queries [2]. The same multiplier implies something like $0.05 to $0.50 per agent task [3]. Neither number is an argument against agents; they are an argument against buying action capability for a system whose entire job is to answer questions, which the post frames as paying a heavy premium for a capability you never use [s1c15].
The governance asymmetry is the part that does not show up in a pilot. Retrieval's failure is a wrong sentence; an agent's failure is a wrong action, which is why actions need budgets, permission layers and human approval [s1c18].
Two things worth checking this week. First, whether anything you call an agent has a retriever attached, because if it does not, its confident answers about your own documents are unsourced [s1c11]. Second, whether the permission scope of any deployed pipeline was reviewed by someone who understood it could mutate state rather than merely describe it [s1c18].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
A developer writing on dev.to says a client emails the same question at least once a month: "Should we use RAG or agents?"
The post argues the phrasing is wrong because RAG and agents are not two versions of the same thing: RAG answers questions from your knowledge base, an agent takes actions toward a goal.
The post's one-sentence summary: RAG controls what the model knows; agents control what the model does, and everything else including cost, latency and failure modes follows from that single difference.
The RAG flow described is short and deterministic: user question, embed, vector search, top-k chunks, prompt, answer, with documents stored as embeddings in a vector database.
The post's stated weakness of RAG: it cannot act. It can tell you the refund policy but cannot issue the refund, and can summarize a log file but cannot rotate the compromised credential it just found.
The agent pattern described is a loop: while the goal is not met, observe, reason, call a tool, use the result, repeat, continuing until the goal is met, a budget is hit, or it escalates.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One self-published essay, no measurements
Every claim in the cluster traces to a single dev.to post by one practitioner. Architectural statements (retrieval cannot mutate state, an agent is a bounded tool-calling loop, an unretrieved agent is ungrounded) are internally coherent and unremarkable. But the quantitative spine — per-query pricing, the 5–10x task multiplier, latency ranges, the hallucination reduction claim and the five 1–5 axis scores — arrives with no rubric, token accounting, traces, billing data or evaluation set, and no second publisher corroborates any of it.
One unverified self-reported build
The only adoption signal in the supplied material is the author's own logistics-company system, described without client name, query volumes, cost outcomes or dates. The broader prevalence claim that most production agents contain a retrieval pipeline is asserted in a single sentence with no survey or citation. Nothing here measures adoption of the RAG-under-agent pattern beyond one anecdote.
Deflationary thesis, overstated numbers
The article's direction is hype-reducing: it argues against buying agents where retrieval suffices, and its headline point that only one of five axes justifies the premium is a check on agentic marketing rather than an amplification of it. The gap is local and arithmetic. Specific dollar figures, a 5–10x multiplier and numeric axis scores are presented with the texture of measurement while resting on recollection, and the illustrative figures do not reconcile with each other — an implied $0.05–$0.50 per agent task only reaches $3,000 a month at volumes the post never states.
Consultant demonstrating services expertise
The author writes explicitly as a vendor of the work being discussed: clients email him the question, he complains about how rivals lump both patterns into 'AI integration' on services landing pages, and the closing case study is a system he personally built. A post arguing that buyers overspend on agents and should hire someone who knows the difference functions as capability marketing, and dev.to is a self-publishing platform with no editorial fact-check. This is an ordinary practitioner-marketing incentive rather than an undisclosed financial stake.
Coherent reasoning, unverifiable specifics
Confidence is limited by structure, not incoherence. One publisher, one author, zero corroboration and zero measurements mean the architectural claims can be trusted about as far as any competent explainer, while every number should be treated as a placeholder until re-derived against real pricing and traces. The tradeoff logic is reusable; the scorecard and cost figures are not citable.
build
A docs bot that refuses to answer is working: the case for an evidence gate over a bigger window1 distinct publisher
build
Don't start at the model layer: classify inputs by reliability, then let RAG wait1 distinct publisher
build
Inference outside the Django app is what makes a multi-tenant RAG support product operable1 distinct publisher
build
Splitting one agent into five is a purchase, not a promotion1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 16, 2026