This article proposes a protocol for AI agents that replaces knowledge-based inference with presence-based verification using a declarative Checklist, ensuring that agents only ask for missing information and execute deterministically based on declared requirements.
The Brake That Stops AI Before It Fills Missing Intent with Fiction From knowledge-based inference to presence-based verification. Most people can't explain why "If you don't know, ask" fails in practice. They just know it does: the agent asks about things it already knows, yet stays silent about the one missing detail that actually matters. The problem is not intelligence. The problem is that the model has no objective way to determine whether it has enough information to execute. Underneath every instruction, it is still deciding: based on its own internal reasoning. This protocol replaces that question with: That distinction is easy to see in Claude Code. Default mode may guess the intended scope and continue. Plan mode tends to ask about everything, including information already available. Neither is actually checking what is missing. Solution Execution no longer depends on what the model believes it knows. It depends only on whether the information required for execution is present. Present → Continue Missing → Ask User or Hold Only missing information is queried. Information already provided is never requested again. This changes execution from knowledge-based inference to presence-based verification. Why a Checklist? Presence can only be verified against a declared set of required information. That declaration is the Checklist. Without it, "missing" is still a judgment made by the model. The Checklist simply defines what information must exist before a Tool can execute. The structure stays the same across domains. Only the checklist content changes. Why This Matters As MCP separates Agents from Tool Providers, neither side can reliably infer the other's requirements. A Provider knows what a Tool requires. An Agent knows the current conversation. The Checklist is the contract between them. Why AI Agents Keep Hitting This Problem Most modern Agent frameworks already separate planning from execution and support tool calling. However, they still rely on the model to decide whether it has enough information before calling a Tool. That means the execution boundary still depends on the model's internal reasoning rather than an explicit verification step. This protocol proposes moving that decision outside the model's reasoning and into a declarative Checklist, making execution deterministic regardless of the underlying framework. How It Works The previous section established why execution must depend on presence, not inference. This section shows the mechanism that makes it work in practice. Separation State and execution logic are kept apart. A judgment result is recorded into state. Execution only ever reads that state—it never re-derives it. Validation Only predefined required fields are checked. AI's role here is matching, not reasoning. For each required field, it records whether the current input makes it known or unknown. An unknown field is never filled by inference. Enforcement AI does not generate questions. It only relays unknown fields to the user. Whether a question arises → decided by the unknown state. What value fills it → decided by the user. Whether execution proceeds → decided by the count of remaining unknown fields. Traceability The final JSON state itself becomes the audit log: What was known What was missing Who resolved it Why execution was allowed or blocked Core Execution is gated by recorded state, not the model's internal state. Every question therefore maps to exactly one declared requirement. Every question is traceable back to that requirement. What This Really Is None of this is new. Software has relied on input validation and schemas for decades. We temporarily stopped applying those ideas because LLMs seemed intelligent enough to reason about missing information. For execution control, however, AI should behave like any other software component: validate inputs before acting. Once an agent moves beyond drafting text and starts triggering real actions, deterministic execution becomes more important than impressive reasoning. Posting here because this isn't specific to Claude Code or any single framework. It seems to appear wherever LLMs move from generating text to executing actions through Tools. Curious whether this framing resonates with your experience building AI Agents.
The article describes giving an AI coding agent a deterministic architecture linter that checks Event Storming diagrams for mechanical gaps and open questions, ensuring the agent doesn't fake completion.
This paper introduces Cartograph, a verification layer for AI scientists that couples subspace experiment steering, ambiguity resolution, and library inadequacy detection. The framework outperforms baselines in autonomous discovery testbeds and retrospectively flags inconclusive claims in the A-Lab materials system.
A practical note on AI agent reliability, arguing that production agents need explicit gates for evidence thresholds, retry budgets, and impact assessment rather than relying on memory alone to determine task completion.
A developer discusses challenges in detecting when AI agents silently skip actions, highlighting the difficulty of distinguishing legitimate omissions (e.g., policy blocks) from failures, and calls for collaboration on agent reliability tooling.
The article argues that reliable AI agents require deterministic control flow and programmatic verification in software, rather than relying solely on complex prompt chains.