If unsure, ask. Never guess. — AI Agent Pre-Execution Checklist

Research
1

If unsure, ask. Never guess.

AI Agent Pre-Execution Checklist

Humans give incomplete instructions.
AI tries to interpret them as if they were complete.
That is where the problem begins.

If an agent executes while required information remains unverified, the result is not simply a model error — it is a pre-execution confirmation failure. Many vibe coding mistakes are not due to lack of coding ability, but because the necessary questions were never asked before execution.

AI does not reliably know what it does not know. That is why a simple recommendation is not enough. What is needed is a structural enforcement logic — a checklist that must be verified before any action is taken.

This document proposes a way to control AI execution through rules, not code. Implementation may vary, but the core principle is this: declare the rules, and let AI follow them — instead of hardcoding behavior.

This document defines principles and structure. How they are applied depends on each system, organization, and regulatory body’s own policies and agreements.

Core Structure (Fixed Checklist)

C Item Description
C1 When / Case When, or under what condition, should this Action be executed?
C2 User Action Name What does the user call this Action? (intent)
C3 Provider Action Name The Action name actually invoked by the system

Checklist Layers

  • Fixed Checklist — Minimum required items common to all Actions; defines the execution unit
  • Provider Checklist — A list of execution precautions defined by the Provider for each Action
  • User Checklist — Rules and guidelines specified by the user

Core principle: If any unknown remains, do not proceed. Always ask the user or place execution on hold.

Two Fundamental Problems

Instruction gap — The user’s instruction is incomplete, and AI fills in the blanks through inference.

Action definition gap — AI processes a new Action, API, device, tool, or workflow as if it understands it, when it actually does not.

Overall Structure

Before execution, a Checklist is constructed based on the Provider’s standards and the User’s judgment. At execution time, AI verifies the Checklist.

Both Provider and User can write precautions and rules in natural language. AI then structures them into JSON — not to hardcode execution rules, but to record and verify what must be confirmed before execution.

This means that instead of modifying code every time a new Action appears, you simply add or update a natural language Checklist.

The basic unit of execution in this framework is the Action, not the tool. A single tool can have multiple Actions, and each Action may carry different precautions. Therefore, Checklists must be written per Action, not per tool.

Fixed Checklist

These are the minimum items required for every Action. In most cases, C1, C2, and C3 are filled automatically the moment the user gives an instruction.

C Item Question Answered by Description
C1 When / Case When, or in which case, is this Action valid? User The same Action can mean something entirely different depending on context. Clarify whether this is an immediate command, conditional execution, scheduled execution, event-triggered execution, or a recurring rule.
C2 User Action Name What does the user call this Action? User Captures the user’s real intent and context. Not a technical name — the name as the user actually understands it.
C3 Provider Action Name What does the Provider define this Action as? Provider / System The technical Action name that the system actually invokes.

The execution unit is not determined by Provider Action Name alone. Even for the same Action, the execution unit is only defined when all three are specified together: when it executes (C1), what the user means by it (C2), and what the system calls (C3).

Provider Action Name determines what is called. But the execution unit is defined by C1 + C2 + C3 together.

Provider Checklist

The Provider Checklist is the list of execution precautions the Provider has defined for an Action — the action’s instruction manual. It can be placed anywhere AI can read at execution time.

When required items are missing, questions of accountability arise.

A Checklist can include not only technical questions but also items covering safety, ethics, law, organizational policy, and industry standards. This is especially important for new Actions, physical Actions, irreversible Actions, and Actions requiring legal or ethical judgment.

AI cannot directly observe reality. Any value in the Provider Checklist that cannot be confirmed through systems, sensors, logs, APIs, or user input must be marked as unknown. Unknown is not false. Unknown does not mean safe.

User Checklist

The User Checklist contains the additional rules and guidelines the user specifies for a particular execution. Where the Provider Checklist covers the Action’s own precautions, the User Checklist reflects the user’s purpose, situation, preferences, and constraints.

A User Checklist can be added fresh for each execution, or saved for repeated use. AI verifies both the Provider Checklist and the User Checklist before deciding whether to proceed.

Execution Flow

User instruction
  → Verify Fixed Checklist
  → Verify Provider Checklist
  → Check confirmable values
  → Ask User if needed
  → Add User Checklist
  → Check for unknowns
  → Decide whether to execute

Execution Flow Example: Code Fix

The user attaches a file and says: “Fix the login error.”

AI first verifies the Fixed Checklist:

  • C1 When / Case: Fix requested now
  • C2 User Action Name: Fix login error
  • C3 Provider Action Name: edit_existing_code

AI then checks the Provider Checklist. The Provider may supply precautions such as:

  • Scope of modification
  • Completion criteria
  • Maximum number of attempts
  • Whether rollback is possible
  • Testing criteria

The user can add their own User Checklist:

  • Keep the existing design intact.
  • Do not touch any functionality outside of login.
  • Tell me which files will be changed before making changes.

AI assembles the Checklist from this input. If any item is missing, it asks the user before proceeding.

Short Definition

Humans give incomplete instructions.

Instead of treating them as complete,
AI first checks whether the Checklist has been filled,
asks when an answer is missing,
and marks what it does not know as unknown.

Execution only begins once the instruction is complete.

A Checklist, once written, can be reused for the next execution.

Appendix

Fixed Checklist — Detail

C1. When / Case
When, or in which case, does the user want this Action to be valid?

This question determines the nature of the instruction: whether it is an immediate command, conditional execution, scheduled execution, event-triggered execution, or a recurring rule for a specific situation.

Examples: now / every day at 7 AM / when I get home / whenever a file is uploaded / after the user gives final approval

C2. User Action Name
What does the user call this Action?

The name the user assigns may contain purpose, life context, and intent. It is not a mere label — it is the first declaration of how the user actually understands this Action.

Examples: Morning Warm-up / Baby sleep mode / Fix login bug / My espresso

C3. Provider Action Name
What does the Provider define this Action as?

The name of an invokable Action. It determines what is called, and together with C1 and C2, it defines the execution unit.

Examples: turn_on_heater / brew_coffee / send_email / edit_existing_code / process_payment

Provider Checklist — Examples

Technical questions:

  • Does the child need to be checked for before starting?
  • Is a cup in place?
  • Has the target temperature been reached?
  • Has the maximum operating time been exceeded?
  • Will stopping this Action cause a loss?
  • Can this Action be executed repeatedly?

Safety, ethics, and legal questions:

  • Does this data transfer include personal information?
  • Does this payment amount exceed the legal limit?
  • Is this file approved for external sharing under company policy?
  • Is approval from a guardian or administrator required?

User Checklist — Examples

Code fix:

  • Keep the existing design and UI unchanged.
  • Show me the list of files to be changed before making changes.
  • If a test fails, ask me again.

Document writing:

  • Keep the existing writing style.
  • Do not change numbers or proper nouns.
  • Do not include claims without a source.

Email sending:

  • Show me the draft before sending.
  • Write it politely but briefly.
  • Check that no attachments are missing.

Physical device control:

  • Do not execute if a child is nearby.
  • Do not operate after 10 PM.
  • Only execute when the user is home.
  • Confirm once more before executing.

Payment / approval:

  • Ask again if the amount exceeds 100,000 KRW.
  • Do not allow repeated payments.
  • Do not transmit externally before approval.

C3 — Rules on Who Answers

  • The default answering party for C3 Provider Action Name is the Provider.
  • If a Provider Action is not registered: the System may generate a temporary Provider Action Name.
  • When the System generates a temporary name, it must notify the user and receive approval before execution.

Note: This exception provides minimal flexibility to avoid degrading user experience in early-stage deployments or when registering new Actions. All temporary Actions must later be formally reviewed, approved, and registered by the Provider.

Fallback Rules for Early-Stage Deployments

When the Provider Checklist is absent or incomplete, the User Checklist can substantially cover the following areas:

  • Safety rules (rollback requirements, risk level, conditions to halt execution, etc.)
  • Legal and ethical constraints (personal data handling, prohibited actions, bias prevention, etc.)
  • Execution conditions and limits (time restrictions, amount limits, scope limits, approval processes, etc.)
  • Action-specific precautions

Note: The User Checklist cannot fully replace the Provider Checklist’s technical baseline specifications or anything the Provider officially guarantees.

JSON Example

The JSON example below is for reference only — it is not a required template. AI should construct JSON freely in whatever form best fits the situation.

Removing hardcoding is what allows natural adaptation to new Actions, new domains, and unexpected situations. New keys can always be added, and the structure can be changed as needed.

Flexibility and practicality are the top priorities.

{
  "fixed": {
    "c1_when_case": "Immediate execution requested",
    "c2_user_action_name": "Fix login error",
    "c3_provider_action_name": "edit_existing_code"
  },
  "provider_checklist": [
    {
      "question": "Is the scope of modification clearly defined?",
      "answer": "partial",
      "note": "Only login-related files should be modified, but full scope needs confirmation"
    },
    {
      "question": "Do passing criteria for test cases exist?",
      "answer": "unknown",
      "note": "No documented test automation criteria found in the current repository"
    }
  ],
  "user_checklist": [
    {
      "rule": "Do not change the existing design or UI",
      "status": "confirmed"
    }
  ],
  "execution_decision": "ask_user",
  "summary": "Login error fix requested. Test criteria are in unknown state — user confirmation required.",
  "risk_level": "medium",
  "suggested_next_step": "Ask the user for test criteria, or present the list of files to be modified for confirmation first"
}

Ownership & License

Copyright © 2026 AnnaSoft Inc. (Republic of Korea)

Commercial Licensing
A commercial license is required only for organizations with annual revenue of USD 1 billion or more that commercially deploy products or services based on this work. All other use is permitted free of charge.

2

The key point of this article is not to make AI reason harder.

It is to prevent AI from guessing before execution.

Three ideas matter most:

  1. The unit of execution is not the Provider Action Name alone.
    It is defined by C1 + C2 + C3:
    when the action is valid, what the user calls it, and what the system actually calls.

  2. When a required checklist item is missing, responsibility becomes traceable.

  3. Before execution, the AI must check the Fixed Checklist, Provider Checklist, and User Checklist.
    If something cannot be confirmed, it remains unknown.
    Unknown is not false. Unknown is not safe.

If unsure, ask. Never guess.

3

From an MCP perspective, this document is a proposal:

Let Providers supply a pre-execution Checklist per Action, in natural language.

If MCP makes an Action callable, the Provider Checklist defines the questions that must be answered before that Action becomes executable.

In the API era, describing the call format was enough.
In the Agent era, defining the pre-execution conditions becomes equally necessary.

The flow is simple:

Provider supplies the question list.
Agent checks whether the answers exist.
If not, Agent asks the user.
If still unanswered, Agent does not execute.

If a Provider does not supply the necessary verification items for accuracy and safety, that absence may become relevant in determining the Provider’s scope of responsibility in a post-incident review.

And if an Agent executes without user confirmation, that execution should not be easily treated as the user’s approved decision.

4

Id just like to say from hugging face to reddit to discord to linkedin even x the narrative is tightly controlled and thats why i am here at all the thing that should amplify free speech is weaponized to squash it. Moderators algorithms and disregard for freedom have ruined every corner of the digital space still hackers and trolls and gatekeepers is all i can find

5

One important point:

When AI produces a wrong result, the discussion often goes back to model capability. Regulation and safety discussions also tend to focus on the model. But this document separates responsibility across the execution structure.

If the Provider does not supply the necessary Checklist for an Action, the Provider’s scope of responsibility becomes relevant. If the user instruction is incomplete, the system should not treat it as complete. If the Agent executes without confirming unresolved unknowns, that is not a model error. It is a pre-execution failure.

A better model may fill the blanks more convincingly — but it does not replace the structure that checks and stops at those blanks.

AI is not the source of authority. It is an execution layer that performs the verification process. Final authority must remain with the user.

One of the core challenges in AI regulation is that technology moves faster than law. By the time a rule is written, the technology may have already moved to the next stage.

This document proposes a way around that problem. The Provider supplies the question list for each Action. The Agent checks whether the answers exist. If not, it asks the user. If still unanswered, it does not execute.

With this structure, regulators do not need to follow every technical implementation. They can define standards — what Checklist items must be included for each industry or Action type. Law and regulation can then review after the fact whether the structure was sufficient and whether the Agent followed the verification process.

The execution structure outside the model can be changed now. Responsibility is not only examined after an incident. It is declared inside the structure before execution.

6

There are two dominant positions in AI discourse today.

The optimists say: make the model smarter, and the problems will solve themselves. Better reasoning, longer context, larger scale — that is enough.

The control advocates say: AI is becoming too powerful. It must be audited, regulated, governed, and overseen.

Both positions focus on the capability of the model. One sees growing capability as the solution. The other sees it as the threat. They sit on the same axis.

This document takes a different position.

The problem is not that AI is too powerful. The problem is that AI does not reliably know what it does not know — and does not stop when it should.

AI is not executing because it is too smart. It is executing because it was not given a structure that requires it to stop and ask first.

This is not about fearing AI or restricting it. It is about making sure AI does not treat incomplete instructions as complete ones.

The optimists say: wait for a smarter model.
The control advocates say: the model is already too dangerous.

This document says: the core issue is not only model capability. The missing piece is a structure that makes AI honest about what it does not know.

AI that stops when it does not know — and asks before it acts — can already do far more, far more safely, than AI that fills every blank with its best guess.

We do not need to wait. The structure that makes this possible can be put in place right now.

This does not require a new framework or library. The structure can be applied by declaring the rules in natural language — as a system prompt, an agent instruction, or a Provider-defined Checklist. AI handles the verification logic from there.

7

AI is basically in a waiting state.

It does not know when the user will ask for something, what the user will ask for, or what meaning the user will attach to that request.

When a user instruction arrives, the AI first tries to interpret it as an executable Action.

This is where the most dangerous inference occurs.

Not in the Provider Checklist first, but in C1 and C2.

C1 — When, or in what case, does the user want this Action to run?
C2 — What does the user mean by this Action?
C3 — Which Provider Action will actually be called?

Among these, the AI must be most careful not to infer C1 and C2.

Because C1 and C2 are directly connected to user intent.

If the AI guesses here, it may turn something the user did not ask for into something that appears executable.

This is not merely a safety question.
It is first a question of intent completeness.

Before asking whether an Action is safe, the system must know what Action the user actually intended.

The Provider Checklist has a different role.
It does not define the user’s intent.

It defines what must be confirmed for this specific Action to be executed accurately and safely: boundaries, required conditions, completion criteria, stop conditions, and execution limits.

In other words:

The Provider Checklist says what must be checked before this Action can be executed.

The User Checklist has two roles.

First, it completes C1 and C2 by clarifying the user’s intent for this specific case.
Second, it supplies the runtime context required by the Provider Checklist.

So the User Checklist can also improve accuracy and safety.
But its first and most important role is to make the user’s intent explicit.

The structure is therefore not:
User says something → AI guesses the Action → Provider Checklist checks safety.

The structure should be:
User says something → AI identifies missing intent → User completes C1 and C2 → Provider Checklist confirms execution requirements → AI executes only when the instruction is complete.

The first unknown is not safety.

The first unknown is intent.

8

There is one structural point this document does not explicitly address: the difference between situations where AI already knows what an Action does, and situations where it does not.

This distinction matters because the protocol behaves differently depending on which situation applies.

C4 — Action Description

C4 is not a checklist item. It is a precondition.

C4 answers the question: Does AI actually know what this Action does before executing it?

Whether AI knows what an Action does determines which level this protocol starts from — not whether the protocol applies.

In MCP terms, this corresponds to Tool Description. But since this document operates at the Action level, not the Tool level, Action Description is the more precise term.

Three Execution Situations

Level 1 — Current practice
Action Description is known. Provider Checklist is absent. AI fills the gaps through inference and executes. This is the state this document identifies as the problem.

Level 2 — Target state
Action Description is known. MCP Description is detailed and includes a Provider Checklist. AI already has the checklist. Confirmable items are handled automatically. Only unresolved unknowns prompt a question. Most Actions execute with no questions at all. This is the state where the protocol runs most smoothly.

Level 3 — The core case this document addresses
Action Description is unknown. A new Action has arrived. The instruction came in as C2 only. AI must not fill the gap through inference. Execution without a checklist is not acceptable. Without this protocol, there is no structure to catch the gap — and no clear place for responsibility to land.

This protocol sets Level 2 as the target state, and operates as the minimum safeguard for Level 3.

What this means for MCP

The practical path from Level 1 to Level 2 is this:

Include an Action-level Provider Checklist inside MCP Tool Description.

Whether written at the Tool level or the Action level is up to the Provider. But the minimum criteria for each Action should be stated.

Provider Checklist = the minimum a Provider must declare for AI to execute this Action accurately and safely.

MCP already provides inputSchema for defining required parameters. But inputSchema is not the same as a Provider Checklist.

inputSchema is structured JSON. It validates technical parameters. Adding a new condition requires modifying the schema. It is closer to hardcoding than to rules.

A Provider Checklist is written in natural language. It can cover safety, ethics, legal constraints, rollback conditions, and execution limits — things JSON Schema cannot express. A new condition is added as a line of text, not a schema change.

This document proposes rules, not code. The Provider Checklist is that principle applied to MCP.

If a Provider does not supply this, the absence itself becomes relevant when responsibility is examined after an incident.

C4 was part of the original design, but I later removed it from the execution checklist — because it is a precondition, not an execution condition. The fact that current AI coding agents are now adding scope limits and execution boundaries through trial and error is evidence that this gap has a real cost.

9

Some readers may raise concerns about this protocol. This document addresses them directly.

Concern 1: Isn’t having AI interpret a natural language Checklist still inference — the very thing this protocol tries to prevent?

This document does not reject AI inference.

The problem is not inference itself.
The problem is executing on inference when the answer is unknown.

Reading a Checklist and determining what is known and what is not — that is permitted inference.
Filling an unknown with a guess and executing — that is what this protocol stops.

Concern 2: Doesn’t requiring a Fixed Checklist contradict the flexibility of free-form JSON?

No. They operate at different layers.

The Fixed Checklist is the minimum structure for identifying unknowns.
Free-form JSON is how known answers are recorded and processed.

There is no conflict.

Concern 3: Who generates the questions? If AI generates them, the same problem reappears.

AI does not generate the required questions.

The Checklist is built by the parties responsible for the Action.

At minimum, the Provider and the user define the questions.
Where ethical, legal, or safety-critical items are involved, AI developers, organizations, or regulators may also contribute Checklist items.

This remains an open design question for the ecosystem.

AI developers who have sufficient confidence in their model may also choose to reduce the scope of the Checklist.
The structure allows both expansion and contraction.

What does not change is this:

AI only determines which answers are already known and which are not.
Unknown items are answered by the Provider in advance or by the user at runtime.
Final approval always belongs to the user.

Concern 4: How is Human in the loop guaranteed?

It is not added as a separate mechanism.
It is built into the structure.

C1 and C2 can only be answered by the user.
AI cannot generate the user’s intent or execution meaning on the user’s behalf.

By following this protocol, human confirmation is structurally required before execution — not as an optional approval layer, but as a consequence of how the Checklist is designed.

Confirming intent means the human is already in the loop.

10

Impact & Implications

AI Agent Pre-Execution Checklist Protocol

1. Operational Effects

Reduced token consumption
Under current practice, AI executes on incomplete information, produces incorrect results, and repeats the cycle. This protocol confirms all required items before execution. Fewer incorrect executions mean fewer retries — and fewer tokens consumed. At Level 2, most Actions execute without any questions at all, minimizing the confirmation process itself.

Reduced trial and error
Current AI coding agents are adding scope limits and execution boundaries through iteration. This is evidence of a structural gap. This protocol defines those boundaries before execution, not after.

2. Execution Log — The End of the Black Box

Until now, AI execution has been a black box. What the AI knew, what it did not know, and why it chose to execute — none of this was visible. When something went wrong, there was nothing to reconstruct. The model was blamed because there was no structure to look at.

This protocol changes that.

The Checklist confirmation process is itself a record. What was known, what was unknown, who provided the answer, and whether execution was approved — all of this is produced as a natural output of the confirmation process, not constructed after the fact.

  • If an item was confirmed — it is on record.
  • If an item was marked unknown — it is on record.
  • If execution proceeded with an unresolved unknown — that is a protocol violation, and it is on record.

This is not a logging system added on top. It is a structural consequence of how the Checklist works.

For the first time, there is a mechanism to reconstruct what the AI knew at the moment of execution. That changes what accountability, explainability, and audit mean in practice.

3. Structural Effects

AI Alignment
C1 and C2 confirm the user’s intent before any execution occurs. AI operates only within that confirmed intent. Alignment is not enforced by the model — it is enforced by the structure.

Human in the loop — built in, not added
C1 and C2 can only be answered by the user. Final approval always belongs to the user. No separate mechanism is required. Human confirmation is a structural consequence of how intent is confirmed.

Accountability
Responsibility is declared inside the structure before execution. If a Provider does not supply a Checklist, that absence is on record. If a user does not approve, execution does not happen. When something goes wrong, the execution log already shows where the gap was, who was responsible for it, and whether the protocol was followed.

Explainability
The execution log is not constructed after the fact. It is produced as a natural output of the confirmation process itself. What was known, what was unknown, and what was confirmed — all of this exists before the Action runs and remains after it completes.

4. Governance

The scope of who can contribute to a Checklist can expand:

  • Provider — defines the Action’s minimum execution criteria
  • User — defines personal rules, preferences, and constraints
  • AI developer — may add or reduce Checklist scope based on model confidence
  • Regulator — may define mandatory items for specific industries or Action types

This is an open question to be decided through broader discussion. But the structure already supports it.

Regulators do not need to follow every technical implementation. They can define what Checklist items must be present for a given industry or Action type, then review after the fact whether the structure was followed — and whether the execution log confirms it.

5. Broader Implications

AI Safety
The pre-execution confirmation structure is itself a safety mechanism. Unknown is not safe. This protocol makes unknowns visible before they become incidents.

AGI / Existential risk
The concern with advanced AI is not only what it can do — it is what it will do without human approval. This protocol separates model capability from execution authority. No matter how capable the model, execution requires confirmed intent and user approval. That boundary holds regardless of model performance.

AI regulation
Technology moves faster than law. This protocol offers a path around that gap. Execution structure can be defined now, in natural language, without waiting for technical standards to catch up. Responsibility is traceable before an incident, not only after. The execution log provides the evidence.

6. What this protocol does not address

  • Model accuracy, hallucination, or performance
  • Training data bias
  • Energy consumption and environmental impact
  • AI copyright
  • The existence of advanced AI itself

This protocol is scoped to one question: when, and with whose approval, does execution happen. Within that scope, most of the current debates around AI execution, responsibility, and control are directly or indirectly addressed.

11

Summary: What This Post Is Really About

The Brake

Unknown = Stop

When outside the boundary or uncertain, always stop and ask.

The Structure

Human declares in natural language → AI converts it into executable JSON → AI executes autonomously within that structure → AI stops at Unknown

  • Humans define the two things AI should not invent: intent and boundary

  • AI converts those declarations into structured execution conditions

  • AI operates freely within those conditions

  • When uncertain, it stops — it does not guess

The Effects

  • AI is free within declared intent and boundary

  • Physical AI deployment becomes easier to scale

  • Regulatory review becomes simpler

  • Legal responsibility becomes easier to separate

  • Non-developers can design AI behavior through natural language

The Essence

This is not “let’s control AI better.”
This is “let’s build a structure where AI can operate freely — under clearly separated responsibility and executable conditions.”

The Paradox

AI can run freely because there is a brake.
You need brakes to drive on a highway.

The title “If unsure, ask. Never guess.” looks like a constraint on AI.

But it is actually the prerequisite for AI to act freely and responsibly in the real world.

12

What This Protocol Cannot Solve Alone — And Why It’s Everyone’s Problem

This post grew from the same question raised in
Physical AI Safety: Ownership and Execution Boundaries.

As someone working in IoT, the question was simple:
“Can I trust AI with the device I built?”

The protocol says:

If unsure, ask. Never guess.

But there is a more fundamental problem underneath.

What if the AI doesn’t know that it doesn’t know?

For example, a checklist might say:

Do not operate above 20°C.

But what if there is no temperature sensor?
In that case, the AI should stop and ask:

I cannot confirm the current temperature. Do you still want to proceed?

But will the AI always recognize that it has no way to confirm the temperature?
Not always.
This is where inference error can occur — inside the “ask” step itself.

Two Ways to Address This

Both approaches follow the same principle:

Do not rely on AI inference. Let the structure handle it.

1. Through Checklist Design

A checklist should include at minimum:

  • What needs to be checked
  • What kind of judgment it requires — whether informing the user is enough, whether explicit confirmation is needed, or whether execution is not permitted at all
  • The method of verification, if applicable — the provider specifies one method per condition. Examples include: direct data confirmation, asking the user, referencing external standards (legal, ethical, etc.), checking history, or verifying time and schedule conditions

The format can be natural language or structured — either works.
The specific required items will be developed over time through agreement among regulators, platforms, and providers.

2. Through Agent Structure

At the system level, conditions that are undeclared or unverifiable should block execution by design.
The AI does not need to infer whether a missing item matters.
The structure stops it.

Both approaches are likely to be adopted across different environments.
The principle can be standardized.
The implementation can remain flexible.

The Deeper Problem

This is not only a technical problem.

Until now, humans have given AI data, architectures, and feedback methods.
But we have not given AI two things:

  1. What to check — the items of judgment
  2. How to check — the method of judgment

AI has been filling that gap through inference.
This is one of the root causes of hallucination —
and the reason Unknown has so often been treated as Safe.

No single party can solve this.

  • Providers must honestly declare the boundaries of their actions
  • Developers must build systems that block execution when declarations are missing
  • Platforms must define standards for checklist writing
  • Regulators must make critical declarations mandatory, not optional
  • Users must explicitly approve their own intent and context

No single party can fix this alone.

The protocol gives us the principle.
But for that principle to work, every participant must clearly declare their part.

14

Responses to Questions Received — Clarifications on the Pre-Execution Checklist Protocol

This post was written to answer questions sent directly by readers.

Misunderstanding 1 — “Stopping execution = Governance”

This protocol does not use stopping as a governance tool.

Stopping is not the purpose — it is the result. When input is incomplete, it occurs naturally as part of the process of filling in the required information before reasoning begins.

This structure is not a mechanism to restrict AI authority or supervise it from the outside. Its position is one thing only.

Before reasoning begins. At the input stage.

Misunderstanding 2 — “Controlling AI with a checklist = Internal control”

This protocol does not intervene inside the model.

It does not change or control how the AI reasons internally. Before reasoning begins, it breaks execution into smaller units and confirms that the required information is complete.

One point matters here.

The Agent does not generate its own boundaries. The boundaries and required questions are declared before execution. The Agent only checks whether the instruction is complete against that declared structure.

This is not governance. This is not internal control. This is a structure that makes input complete.

Misunderstanding 3 — “Asking before execution = Poor user experience”

This concern assumes that the protocol adds friction to every interaction.

It does not.

In most cases, the user’s instruction already contains enough information to fill C1 and C2. No question is needed. Execution proceeds.

A question is only asked when the instruction is genuinely incomplete — when the AI cannot determine what the user actually meant, or when a required condition cannot be confirmed. In those cases, asking is not friction. Executing without asking is the problem.

The alternative — AI guessing and executing on incomplete input — produces incorrect results, requires correction, and repeats the cycle. That is the real cost to user experience.

Asking once when uncertain is less disruptive than correcting a wrong execution after the fact.

Why Providers should start

Every product has a manual.

If an Action can be executed by AI, that Action needs a manual for AI. That is the Provider Checklist.

This is not a new burden. It is an extension of existing responsibility into the AI era.

Two perspectives:

Incentive: A Provider who supplies a Checklist has documented evidence — at the time of execution, not after an incident — that the required conditions and boundaries were declared in advance.

Accountability gap: A Provider who does not supply a Checklist has not provided the necessary manual for an Action that AI can execute. If you designed an Action for AI to run, you are also responsible for declaring when it should stop.

Why LLM developers should start

This is now a competition for the last few percent of accuracy.

Adding more data and extending reasoning chains alone is becoming insufficient to close that gap.

Developers are already moving toward breaking problems into smaller steps, reasoning incrementally, and planning before execution — inside the model. This protocol applies the same principle outside the model, at the input stage.

One point is central.

When AI fills an unknown through inference, the result is probabilistic. When AI asks the user or Provider directly, the answer becomes confirmed input — not inference.

Asking does not turn inference into a correct answer. It replaces a blank that required inference with a declared input.

Without making the model larger, a structure that makes input complete can raise execution accuracy. In the final accuracy competition, external input structure — not internal model architecture — may be the next path forward.

Questions sent as private messages are welcome, but posting them as comments allows everyone to think through them together.

If unsure, ask. Never guess — that is where this protocol begins.

Further questions, objections, or edge cases are always welcome.

15

(post deleted by author)

18

The Solution Structure — “Reduction (of Role)” and “Enforcement (of Interface)”

The solution is not smarter AI — it’s a smaller role for AI, enforced by architecture.

① Separation of Verification AI and Execution AI
The judgment of completeness is separated from execution.

② Two constraints placed on the Verification AI

  • Criteria Constraint: What needs to be checked (the checklist) is defined in advance by humans — the Provider, User, or a regulator.
  • Value Constraint: Only a human can enter the values that fill the blanks; the AI is categorically prohibited from guessing.

③ Reduction of the AI’s role
The AI’s role shrinks from subjective “Reasoning” to objective “Matching.”

④ Iterative feedback loop
As long as any Unknown remains, the AI repeatedly asks the user, and execution is withheld until every item is filled.

⑤ Enforcement through JSON-based coding

  • Real-time gate: Once a structured state is recorded, the system code reads that value directly and enforces whether to proceed or halt.
  • Post-hoc record: Which items were answered by whom, and why execution proceeded or was blocked, are all recorded in advance.
19

Two Issues Not Yet Addressed

  1. Completeness of the checklist-defining party
  2. Non-determinism of Matching
Checklist Completeness Matching Non-determinism
Nature of the problem Not a technical defect Not a technical defect
Can it be structurally blocked? No No
Response mechanism Accountability (who is responsible) JSON record (audit trail)
When it operates Post-hoc (accountability after an incident) Post-hoc (verification/improvement via records)

Design principle: What is controllable internally (input completeness) is enforced through structure, while what is not controllable (the quality of checklist design, the accuracy of judgment) is delegated to external mechanisms (accountability, records).

20

Looking at this post’s structure through three elements makes it clearer:

  • Action: what to do
  • Condition: when, where, and under what conditions to do it
  • Execution Policy: with what quality and constraints to do it

In the conventional execution structure, Action and Condition were communicated by the user, while Execution Policy was already handled by the Provider at the design stage. Users only needed to say “what and when” — the “how” (quality/constraints) was already baked into the product design.

But in newer forms of Agents — coding agents, document editors — Execution Policy now also has to be conveyed by the user at execution time.

The problem the Provider used to resolve at the design stage has come back in the form of the user’s instructions (prompts). As a result, user instructions are becoming increasingly broad and long.

Seen this way, a natural question follows:

How should the Agent complete the user’s incomplete and lengthy instructions before passing them to the AI?

How well this completion is done could become a key source of competitive advantage for Agents.

If this completion work is done ad hoc every time, it will lack consistency. So what seems to be needed, ultimately, is a shared representation between the user and the AI. At minimum, this representation needs to define what to look for, what procedure to use for interpretation, and how to resolve missing information.

What items should be included in this shared representation is likely to become an important design question going forward.

For a deeper discussion on this, the following post may be worth referencing.

Physical AI Safety: Ownership and Execution Boundaries

(In Physical AI, much of the Execution Policy is fixed at the design stage, whereas in software Agents, that boundary keeps shifting toward execution time. So even with the same three-element frame, the implementation seems to diverge depending on the domain.)