Loading today’s stories
Build1 distinct publisher2 min readUpdated
A dev.to post sets out three fixed pipeline shapes for tasks that get an agent loop by default. Its real test is whether every possible run can be drawn in advance.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Start with the token caps, which carry more of the argument than the prose around them. The chain example asks for 512 tokens on extraction and 256 each on validation and formatting, all against claude-sonnet-4-5 [c5b]: a ceiling of 1,024 output tokens for the entire three-call run [3]. The router asks for 32, against claude-haiku-4-5, and its whole job is to emit one key from a list [9]. That is one sixteenth of the extraction cap [4], on the cheaper model, once per ticket. The agentic version of the same task instead puts a decision call after every step, asking whether to extract again, validate again, or reach for a different tool, and the author reports that in his failure data that decision almost always comes back as "proceed to the next fixed step" [6].
The load-bearing engineering in the router is one line: the handler is resolved with `HANDLERS.get(classification, handle_general_ticket)` [12]. A classifier's characteristic failure is not a wrong label but an off-menu one, and that lookup has a default, so an unrecognised string lands on the general handler rather than anywhere unhandled [12]. Bounded discretion is therefore a property of the code rather than of the prompt. The prompt asks for exactly one of five keys [9]; the dictionary is what makes you get one of five behaviours [12].
The shapes also nest, which is the part that makes the router worth building rather than just describing. Each of the five handlers is itself a fixed chain of the first shape [c12b], and that shape is a sequence whose order is known in advance even when its content is not [4]. So the flowchart stays drawable after you add a classification step in front: one known decision, then a known sequence.
What the shapes ask of you, and a loop does not, is that you write the outcome list down before you ship. The author's examples are a ticket going to one of five fixed playbooks and a document getting one of three fixed extraction templates [c8b]. If you cannot enumerate that set, none of these three shapes is available to you, and the choice of a loop is no longer a default you drifted into by habit. It is the thing you actually have.
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.
The author's earlier post argued that an agent is an LLM that controls its own control flow, and that this control costs quadratic tokens, serial latency, and a failure surface no unit test can cover, on every single run.
The author says the earlier post made that case in the abstract and did not give the thing you reach for instead; this post is meant to supply it.
The property shared by all three shapes is that you can draw the flowchart of every possible run before executing one; the author calls that the actual dividing line, not whether the task calls an LLM more than once, since all three shapes call a model multiple times.
The author's tell for an over-built agent: if you trace real runs and the decide-what's-next step picks the same next step upward of, say, 95% of the time, you have built a loop around a straight line and paid the loop's tax for the 5% case, and that 5% should be an explicit branch.
The second shape bounds the model to exactly one classification call and then hands off to ordinary code; the HANDLERS table has five keys: billing, bug_report, access_request, feature_request and other.
The author's examples of a bounded decision are a support ticket that needs one of five fixed playbooks and a document that needs one of three fixed extraction templates.
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.
Concrete code, no measurements
What can be verified is verifiable: the three pipeline shapes, model IDs, token caps, HANDLERS keys, fallback behaviour and the 5^10 combinatorial claim are all readable directly from the published snippets and reduce to arithmetic. What would carry the argument — the quadratic-token, serial-latency and failure-rate costs of loops, and the claim that a loop's decision resolves to the next fixed step 'in the actual failure data' — is asserted with no data, no workload description and no trace sample. One publisher, self-referential to the author's prior post, and the closing caveat section is truncated.
No adoption signal
The supplied source contains no release, deployment, usage, pricing or benchmark event — no named team running these shapes, no traffic or volume figures, no repository or package. The code is illustrative. There is nothing to measure adoption against, and inventing one from the author's unquantified 'tasks I've seen' would be a guess.
Modest thesis, thin backing
The piece is deliberately deflationary — it argues against agent loops rather than for a new product, and its prescriptions are narrow and hedged. The gap is mildly positive only because its quantified-sounding supports are unearned: 'the actual failure data', the 95% same-decision tell and the quadratic-token cost are stated with numeric confidence but zero shown measurement, and the coverage claim about 'most tasks' is broad anecdote. Nothing is oversold about capability; the evidentiary framing is slightly stronger than the evidence.
Self-promotional cross-post
Visible and ordinary rather than hidden: the post opens by crediting the author's own Loop & Retry blog and builds on his prior 'When not to build an agent' piece, so the argument doubles as audience-building for a personal publication with a settled editorial line against agent loops. That gives a mild pull toward restating the thesis rather than testing it. No vendor sponsorship, affiliate arrangement or commercial disclosure appears in the source; the Anthropic model IDs are used as implementation detail with no stated relationship.
Single truncated source
Confidence is bounded by cluster structure, not by disagreement: one publisher, one author, no independent corroboration, and a body that ends mid-sentence in the section qualifying when a loop is warranted. Assessment of what the post says and of the arithmetic derived from it is solid; assessment of whether its cost and failure-rate premises hold in production is not possible from this material, and adoption is entirely unmeasured.
build
A retry cap is not a retry budget, and each language breaks it in a different place1 distinct publisher
build
Anthropic streams tool arguments as JSON fragments, so pick a coping strategy on purpose1 distinct publisher
build
The refund button is the architecture: inside the tool-use layer of a support agent1 distinct publisher
product
The cheapest model scored 10 out of 100: assistant choice is now a code-security decision1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026