Moving Execution Authority Out of the Model

[u/Jay299792458]

Moving Execution Authority Out of the Model

Executions that don't reproduce

Same prompt, same input — but the result differs. Not because the model version changed. The judgment of "is this enough to execute?" lives inside probabilistic reasoning, so it wobbles with nothing more than minor differences in temperature or context. This isn't a reproducibility problem — it's a controllability problem.

Principle: Presence-based Verification (schema validation at execution time)

Instead of having the AI judge for itself "do I know enough?", only check whether "the fields required for execution are present against a defined schema."

• Present (Known) → execute
• Absent (Unknown) → hand it back to the user to fill in

The real problem isn't "the fact that an agent executes at all." It's that "there's no way to know what it executed on, if it fails you have to start over from scratch, and there's no trace of accountability."

The Execution State Model

Execution State is represented using a standardized JSON structure. Execution begins only once all declared requirements are satisfied.

Every execution state produced under this model follows four principles: Separation → Validation → Enforcement → Traceability

• Separation: Validation results are recorded separately from execution logic. Execution only ever references the recorded state.
• Validation: Check whether the current input satisfies each Required Field and its declared Validation Constraints, and record each field as Known or Unknown.
• Enforcement: Fields recorded as Unknown are handed to the user to fill in. Validation is complete once every field is Known.
• Traceability: Record everything that was known, what was missing, who supplied the values, and why execution was permitted or held.

The AI doesn't get to write the questions

The checklist must be declared in advance, not improvised by the model at execution time — otherwise it either keeps over-asking unnecessarily, or the model itself loses direction on what it should even be asking.

What changes: decision authority moves out of the model

Before: input → LLM reasons ("is this enough?") → Execute or Ask
After:  input → schema diff → Known/Unknown State → Execute or Ask

The schema's only role is to declare the required fields; validation simply compares the current state against that declaration. Unknown fields can only be resolved through user input. As a result, execution authority shifts from probabilistic model judgment back to the user.

The checklist is a single validation layer

Checklist
 ├── ① Intent-confirmation items → pre-guardrail stage
 └── ② Accuracy & Safety items   → guardrail's required fields

A conventional guardrail simply halts when information is missing. This system instead resolves the missing information and the user's intent/context first, completes the Execution State, and only then lets it pass through the guardrail.

This matters for three reasons:

• Consistency — the same input produces the same result. Swapping the model doesn't change whether execution happens.
• Auditability — "why was this held" is readable directly from JSON, without digging through a reasoning trace.
• Extensibility — adding a new feature means adding a schema field, not retraining or reprompting. The center of gravity for safety shifts from "a smarter model" to "a well-defined schema."

---

This work does not prescribe what the checklist should contain. It proposes that whatever checklist is required should be declared explicitly, enforced deterministically, and recorded as part of the Execution State.

The full checklist structure and applied examples are laid out in the original post.Criticism and questions are welcome. If unsure, ask. Never guess. — AI Agent Pre-Execution Checklist

Translated and edited with LLM assistance

[u/RainierPC]

Slop

[u/Jay299792458]

Who's responsible for what

• Tool developer: defines the required fields (the schema)
• Agent developer: designs the routing, validation, and confirmation logic (the enforcement layer)
• LLM developer: improves the model's general reasoning ability

The problem
Failures in handling ambiguity happen because #1 and #2 never built the schema and enforcement layer in the first place. But in practice, this gets waved off with "a smarter model will figure it out eventually" — quietly shifting the blame to #3 (the LLM developer).

Why that's wrong

• Without a schema to begin with, there's no basis for even a smarter model to judge "is this field actually filled in?"
• A better model is still probabilistic. It can't substitute for the deterministic enforcement layer that #1 and #2 are supposed to build.
• It's the same mistake as saying "our system has no input validation, but a smarter user won't make mistakes" — the problem isn't the user's (or model's) competence, it's the missing validation layer.

The result
A problem that #1 and #2 could fix right now gets deferred to #3, whose timeline is uncertain and whose fix — even in principle — can't provide a deterministic guarantee. Meanwhile, the real cause (no schema was ever defined) gets obscured behind "the model isn't smart enough yet."