Loading today’s stories
Build1 distinct publisher3 min readPublished
A dev.to post puts the standard-versus-agentic line at when the retrieval decision gets made, and the interesting part is what a fixed top-k pipeline gives up the moment a planner starts writing plans per question.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Count the artifacts the worked example needs against the slots the retriever has. Four required, three returned [4][5]. At least one input is missing before the model runs, by arithmetic alone [19], and two of the four are not documents: an aggregate by region and date, and the same aggregate with a depot excluded, are computations, and no chunk contains a computation [4]. The post's description of what the model does next is worth keeping. It will, "being a good sport, answer anyway" [6].
So the defect sits upstream of the embedding model and the chunk size [7]. Two values were compiled in before the question existed: how many times to retrieve, and where from [7]. That is the entire distinction being drawn. Planners, sub-agents, MCP servers and memory hang off it as implementation detail [8].
The list of standard-RAG advantages doubles as the invoice for the agentic version. One embedding call plus one vector query, cheap and predictable, latency in a tight distribution, caching that works [9]. Every one of those depends on the retrieval count being known before the request arrives. The agentic diagram carries an edge labelled loop back to step three if context is insufficient [14]. Push the same shipping question through the planner and the floor is four backend calls where the pipeline made one, four times the request count for a single user sentence, before any loop iterations [20]. Failures change character too: today a bad answer means bad chunks you can go read [10], and afterwards it can mean a bad plan over good chunks.
The strongest engineering in the piece is the second difference, not the planner. Standard RAG normalizes every source into one vector index at ingestion time [15]. The agentic version queries each backend in its native language at question time, SQL against the warehouse, semantic search against the document index, a time-series query against event data [15]. "You don't embed a rate table, you query it" [16]. Embedding that table discards exact lookup and predicates, which is the only reason the table exists. MCP is where the fan-out becomes operable rather than a pile of bespoke functions: register a server and the source is available, instead of shipping a new agent build [17].
What the post does not supply is measurement [23]. No latency distribution, no accuracy delta, no cost per answered question. The argument therefore transfers on two conditions, both about your traffic rather than the architecture: real users ask compound filtered questions instead of single-document lookups, and the facts those questions need live in stores you would damage by flattening into vectors. The author is explicit that a homogeneous corpus serving lookup traffic should keep the fixed pipeline [11], and in my own work that has been the right call more often than not. The number worth having before the framework debate is how many of last week's questions needed more than one store.
Ranked by verification strength, evidence, and original report placement.
Standard RAG assumes the user's question maps onto one vector search: one query in, one embedding, one top-k lookup, one answer.
The defining property of standard RAG is that the model is never consulted about retrieval; it receives context and produces text, and retrieval has already finished by the time the model runs.
The post's example of a question that breaks the fixed pipeline: "Did the carrier rate change we approved in Q2 actually reduce our cost per shipment in the Northeast, and does that hold if I exclude the Boston depot?"
That question needs a policy document, a rate table, a transactional aggregate, and a filtered re-computation.
The retriever embeds the whole sentence, finds the three chunks nearest to it in vector space, and hands the model text that is topically adjacent and factually useless.
The post writes that the model, "being a good sport, will answer anyway."
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 30, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Rate limit your MCP servers, because a retrying agent turns one error into a billing incident1 distinct publisher
build
Thirty minutes a day, and none of it from letting the agent write Swift1 distinct publisher
build
The MCP transport your search results teach has been deprecated since March1 distinct publisher
build
MCP 2026-07-28 drops the `result` wrapper, and your unit tests will not notice1 distinct publisher
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 author, one invented example
The entire case rests on a question the post made up — Q2 carrier rates, cost per shipment in the Northeast, exclude the Boston depot — and on two hand-drawn diagrams that do match the prose. Internally it holds together, and the artifact count against the chunk count is arithmetic anyone can repeat. But no deployment, benchmark or postmortem appears anywhere, nothing outside dev.to corroborates it, and the text we have stops mid-sentence in the memory section, so the author's own closing argument is unavailable.
Nobody's system is named
We cannot measure this. Not one team, product, corpus or query volume is identified on either side of the comparison; the closest thing to a real deployment is 'then you ship, and a real user types.' MCP is described as the seam practitioners reach for, but no count of registered servers or shipped agents backs that.
Restrained for the genre, still unpriced
Most posts drawing this contrast are selling the newer pattern. This one hands standard RAG a list of genuine wins and warns that interesting failures are a bad property in production, which pulls the framing back toward honest. What remains overstated is confidence in the tradeoff's shape: the loop is credited with holding both the value and the risk, yet the four-fold floor on backend calls goes uncounted and the latency cost of runtime planning is never quantified. Mechanism argued with the assurance of measurement is a small gap, not a large one.
Nothing being sold at the end of it
Follow the argument to its conclusion and there is no product waiting: an individual byline on a developer platform, MCP recommended as a seam rather than a purchase, no SDK, no paid tier, no benchmark that flatters a vendor. The pressure that does exist is the format's own — architecture explainers are rewarded for a clean dichotomy, and 'standard versus agentic' is tidier than most retrieval stacks in the wild — plus the ordinary reach incentive of publishing on dev.to at all.
Sure what was argued, unsure what happens in production
We can state with confidence what this post claims and how it reasons; the reporting is unambiguous and we read it directly. What we cannot stand behind is the outcome — whether runtime planning actually pays for its extra hops, how badly non-reproducibility hurts on call, or whether MCP registration is as cheap in practice as described. One truncated source with no measurements sets the ceiling.