Build1 distinct publisher3 min readPublished
A dev.to design note inserts code gates and a human approval between the model and the tool, which is the right shape, though a policy layer that reads a severity field the model itself wrote has not moved the authority anywhere.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Read the class assignments in that diagram, not the arrows. The LLM node and the Review node share the same `ai` class, Code Gates carries a guard class of its own, and Approval is a person [12]. Three stages sit between reasoning and the tool call, and only two of them are outside the model [14]. The path went from four nodes to eight [13]. Two of those additions can refuse a call for reasons the model cannot influence, and that is the part doing work.
The post is right that an instruction to confirm before important changes is not a security boundary [3]. Prompt-as-policy has roughly the enforcement properties of a code comment.
Where I would push on the design is the example check. `risk_ok = diagnosis.severity in {"low", "medium"}` reads a field the model filled in [10][9]. Schema-constrained output fixed the parsing problem, but the authority stayed exactly where it was. For the gate to hold under an adversarial or merely confused input, severity has to be computed from facts the model does not author: which tool was selected, which resource the parameters point at, whether that resource is production, how many rows the write touches. The model's own severity estimate then feeds logging and triage instead of opening the door.
The RAG check has the same shape. `citation_id in retrieved_documents` proves the identifier came from the retrieval set [11]. Whether that document actually supports the sentence attached to it is a separate, harder question, since entailment costs far more to test than membership. The supplied text breaks off mid-sentence at that point [11], so I will not guess at the rest of the author's argument.
The benefit list attached to code-first routing is lower latency, lower cost, easier debugging, predictable behavior and deterministic regression testing [8]. That claim rests on the mix of tasks routed, not on agents as a category. It transfers if the `has_known_failure_signal` branch catches most of your traffic [7]. If it catches little, you have added a classifier, kept every model call you had, and pushed the remainder into a queue of people, because `human_review` is the fallthrough [7]. The branch ratio measured on real tickets is the number to have before promising anyone a cost reduction.
In my context the guard runs server-side, inside the tool, on the same side of the call as the state change, and it re-checks at execution rather than trusting a decision taken earlier in the loop. A gate living in the agent process can be routed around by the model selecting a different tool. The separation the post asks for between reasoning, validation, authorization and execution [5] only holds if authorization is code the model cannot address. The ordering in the diagram is right; where the guard node is deployed decides whether it is one.
Ranked by verification strength, evidence, and original report placement.
The post describes verifying a model citation with the check citation_id in retrieved_documents, and the supplied text ends mid-sentence shortly after that example.
The dev.to post describes demo-style agents as reducing to User -> LLM -> Tool -> Action: the model receives a request, reasons about what should happen, selects a tool, generates the parameters, and the tool executes.
The post argues that in that pipeline the same probabilistic system does two jobs, deciding what it believes should happen and authorizing that thing to happen, so that a bad answer can become a bad state change.
The post says a prompt instruction such as "Always ask for confirmation before making important changes" is still an instruction and not a security boundary.
The post's production-oriented flow runs User -> Evidence -> LLM -> Review -> Code Gates -> Approval -> Tool -> Action.
The post says the production design separates reasoning, validation, authorization and execution, and that those responsibilities should not always belong to the same component.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Force the tool call, then hand Lightsail a long-lived key1 distinct publisher
build
Retrieval Is Not A Cheap Agent, And An Agent Is Not A Smart Retriever1 distinct publisher
build
The refund button is the architecture: inside the tool-use layer of a support agent1 distinct publisher
build
A cache hit is a quota refund: semantic caching with trigrams and no vector database1 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.
Its own only witness
One dev.to post, printed in enough detail that what the author designed is beyond dispute — the flowchart, the classifier, the schema and the gates are all shown. What is missing is anyone else: no second account, no run, no failure it was written in response to, and a text that stops mid-word before the final enforcement example is finished. Verifiable as a proposal, unverified as engineering.
No system named
Nothing here is reported as deployed. classify(task) and the five-field diagnosis are teaching snippets rather than extracts from something the author says is in production, and no team, workload or incident count appears anywhere in the post. There is no adoption to measure, only a design to consider.
The title outruns the diagram
"The most important AI agent design choice" is a large claim for a design that keeps the model inside the decision twice over: Review is coloured as an AI stage, and the demonstrated risk gate consults a severity value the model selected. Move those two out and the argument holds exactly as advertised — which is the tell. The shape is right and oversold by roughly the width of the headline.
Credibility, not revenue
There is no product in view: no vendor, no pricing, no benchmark being defended, no tool the reader is steered toward. What the author stands to gain is standing, and the cost of that shows up in exactly one place — the superlative in the title, attached to advice that costs nothing to be wrong about. A mild pull, and an easy one to read around.
Sure what it says, unsure it works
High confidence on the content and on the internal contradiction, because both are printed on the page. Low confidence on everything a reader would actually want to know: whether this survives a real incident queue, what it costs, whether anyone runs it. One publisher, no numbers, truncated text. Treat it as a sketch worth arguing with.