External Publication

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

Hugging Face Forums [Unofficial] June 9, 2026

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

This document is distributed under the CC BY-NC-ND 4.0 license. Non-commercial sharing is permitted. Distribution of modified versions and commercial use require separate agreement.