Essay maps LLM tool-call failures to wrong values, unchecked conditions and missed intent

An engineering essay published on GitHub and upvoted to Hacker News's front page argues that when a language model misuses a tool, the failure traces back to one of three root causes: a wrong value, an unverified precondition, or a misread intent. The author, writing under the name Jang-woo-AnnaSoft, pairs that taxonomy with a concrete mechanism — a pre-execution checklist whose items are resolved by lookup rather than inference.

Three ways execution goes wrong

According to the essay, tool calls fail in three distinct ways. Wrong execution covers fabricated inputs — an account number or ID the model invented rather than retrieved. Uninstructed execution covers calls that ran without checking authority, timing or circumstance, such as whether a balance is sufficient or a recipient exists. Off-target execution covers calls that were syntactically fine but did not match what the user actually wanted.

The intent failure gets its own nuance. Tool names are labels, not capabilities: one provider might name an action turn_off_light, another set_device_power, while a tool called light_control might only adjust brightness. The essay argues tool selection should match on the state change a tool can produce, not on surface similarity between names.

Why human approval stops working

The essay's central observation concerns forms. Filling in values used to be a human job; now the model drafts the form and the person signs it. That changes the question the human answers from “is this correct?” to “shall we proceed?” — and the second invites rubber-stamping.

The problem is invisible on paper. A looked-up value and an invented value look identical once rendered, and a condition that was never checked does not render at all. The common prompt instruction to ask when something is missing fails upstream, the author writes, because the model itself decides what to ask about — and it cannot ask about a gap it does not recognize. You can request confidence about what is present; you cannot request awareness of what is absent, which is the reason experienced surgeons still work from checklists.

Slots, unknowns and a search order

The proposed fix defines two terms. A slot is a single item that must be confirmed before execution. An unknown is a slot still empty after every designated source has been checked. The essay's key move is to make the goal of the computation the list of unknowns rather than an execute-or-not verdict; execution should then accept only a recorded verdict as its basis.

The checklist splits by who can answer each item. A fixed section applies to every execution: which tool, whether timing and circumstances permit it, and what the user calls the action. A provider section varies per tool: required fields, types and formats, prohibited or extra-approval conditions, and the state change the tool produces. A user section varies per environment: intent, current context, execution limits and preferences.

Each slot gets a designated lookup source, searched in order: the user's answer, the instruction, preset values, observed values, then prior state. The author stresses this is a stop-at-first-match order, not a ranking of trust. Anything still empty is an unknown, and needed unknowns go to the user — no inference fills a required value. Because slots become independent once the goal is the list, lookups run in parallel as memory comparisons rather than extra model calls, and serial back-and-forth questioning collapses into a single round trip.

Whitelists, not blacklists

Telling a model to search but exclude what it inferred cannot work, the essay argues: retrieved and invented values are indistinguishable from the outside, and classifying them after the fact is itself inference. The answer is to whitelist permitted sources and record where each value came from. The same logic applies to the checklist itself — enumerate everything that needs confirming rather than instructing the model not to omit anything.

Why it matters

For practitioners building agent systems, the taxonomy works as a debugging rubric: each failure class points at a specific fix. Invented values implicate the lookup chain; skipped conditions implicate gaps in the provider checklist; wrong-tool selections implicate unfilled intent slots. Notably, most of the required data already exists in tool descriptions and input schemas, so the scheme is plumbing rather than a new model capability. The broader lesson is one of governance: when the model drafts the form, human sign-off degrades into click-through, and moving scrutiny earlier — into what gets asked — matters more than the final approve button. One caveat applies: this is an engineering argument, not an empirical study, and the essay reports no benchmark results, so teams should treat it as a framework to test rather than a proven outcome.