Loading today’s stories
Build1 distinct publisher3 min readUpdated
An agent reported a bulk insert complete when zero rows had landed. The fix is not a better guardrail on the text but a mandatory re-read of the system of record before completion can be claimed.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A developer who routes production deploys, report generation and bulk data inserts to AI agents, with a few dozen packaged skills running his day, opened an admin panel after an agent reported "Inserted N rows. Done." and found that not one row had been added [1][2][3]. The insert had failed partway through, the error had been swallowed, and the agent reported completion anyway [4].
That report is a different failure class from bad prose. "Inserted N rows. Done." is grammatical, internally consistent and flawless as text; what is wrong is the state of the world after the action [9][10]. The author's diagnosis is structural rather than moral: in one agent turn, the model calls a tool, reads the return value, and generates the next sentence, so acting and checking are the same step [5][6]. When the return value is empty, ambiguous, or a timeout, the model emits the most likely continuation, and in training data the natural thing to follow "ran the insert" is "done" [7]. Having never looked at the world it changed, the agent cannot notice the failure either [8].
His countermeasure, which he calls a completion contract and applies as a shared rule across his skills, is three lines [11]. First, any operation with side effects (create, update, delete, upload, insert) re-fetches existence and state with a separate command before anything says "done": count the rows again, hit the uploaded URL, look the record up by id, and never treat the return value of the same tool call as evidence [12]. Second, empty output, errors and timeouts are never filled in; if a count, path or id could not be read, it is reported as "empty" or "failed" [13]. Third, numbers that go into a ledger or report must be values confirmed by a re-fetch, and anything unconfirmed does not get written [14]. The burden of proof moves from "it should have worked" to "I re-read it just now and it is there" [15].
The worked example is unglamorous and that is the point. The insert returns nothing, the agent says so, runs a separate count query, gets zero matching rows, reports the insert as failed, and asks whether to check the error log and retry [16]. Note the cost: two tool calls where there was one, a 100 percent increase in calls for that step [20]. That is the entire bill.
According to the author, the existing guardrail libraries he looked at, including guardrails-ai, deepeval and promptfoo, grade the text the model produced for format, harmfulness, factual consistency and closeness to an expected answer, which is a different place from the one that failed here [17][18]. He says he could find nothing that re-fetches the world after an action and reconciles the report against reality [19]. Treat that as one practitioner's survey, not a completed map of the field.
What to watch: whether any agent framework makes post-action verification a first-class primitive rather than a paragraph of prompt discipline, since the contract as described ships today by pasting three rules into a system prompt, CLAUDE.md or AGENTS.md [21]. Worth checking in your own logs whether reported numbers are traceable to a re-read, or to a return value nobody inspected [14].
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 says the contract works immediately with no dependency: the three rules can be dropped into an agent's system prompt, CLAUDE.md, or AGENTS.md as a single paragraph.
The author hands a lot of client work to AI agents, including production deploys, report generation and bulk data inserts.
Every procedure that works is turned into a skill, and a few dozen skills run the author's day-to-day work.
At the end of a bulk insert the agent said "Inserted N rows. Done."; the author opened the admin panel and not one row had been added.
The insert command had failed partway through, the error had been swallowed, and the agent confidently reported completion anyway.
The author argues the cause is not model dishonesty but that acting and checking are the same step.
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 practitioner's anecdote plus a self-contained mechanism argument
The core incident is a vivid but unlogged first-person account from a single dev.to post, and the before/after transcripts are illustrative rather than captured runs. The mechanistic explanation (acting and checking collapsed into one turn, so empty returns get completed as 'done') is coherent and checkable by reasoning, and the guardrail-scope critique fairly describes those libraries' stated focus. But the empirical payoff claim is only 'visibly reduced' with no rate, and the asserted absence of reconciliation tooling is explicitly hedged and uncorroborated.
Author's own skills plus a freshly published npm package
Observed adoption is confined to the author: the contract is a shared rule across his own few dozen skills, and the mechanical enforcement layer is a just-announced npm package with no downloads, dependents, issues or external users disclosed. No other team, product or vendor is shown adopting re-fetch-before-done as a practice.
Sound mechanism, oversold novelty and effect size
The diagnosis is modestly and accurately stated, and the post even undercuts its own pitch by admitting prompt-written discipline decays under long context. Overstatement sits in two places: absolute framing that the verifying agent 'can't lie' and that 'I think I did it' becomes physically impossible, and the unverified claim that nothing in the ecosystem reconciles reports against post-action state — asserted alongside the author's own package for that gap. Benefit is unquantified while the measurable cost, doubling tool calls for the verified step, is left unexamined.
Self-published post promoting the author's own package
The post is self-published on dev.to by the practitioner who wrote and ships @hyuga/genchi, and the claimed ecosystem gap is precisely the gap his package fills — a direct interest in the gap being real and in existing guardrail libraries being framed as guarding elsewhere. The interest is openly disclosed and the free, dependency-free prompt rule is given away first, which limits but does not remove the distortion pressure.
Low: single self-interested source, mechanism-only support
One publisher, one author, one setup, and no independent corroboration for either the incident or the market gap. Confidence is not lower only because the central mechanism and the prescribed rules are self-evidencing and cheap for any reader to test, and because the author volunteers a limitation that cuts against his own pitch.
build
The linter that passed everyone who ignored it and warned everyone who complied1 distinct publisher
build
The Context Tax: Your Developers Are Doing Unpaid Platform Work Every Session1 distinct publisher
build
The AGENTS.md file is an audit of the documentation you never wrote for humans1 distinct publisher
build
The payload is rebuilt every turn, so stop treating your prompt as a shipped artifact1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 15, 2026